The Addictiveness of Failure

If great teams deliver great products, what do poor teams deliver?

At some point, a team will identify a need to refactor, fix, clean up, re-write, or otherwise undergo a highly-technical bit of rework. Without fail, this will be converted into a work item of some type, immediately de-prioritized by a product owner.

This is a failure by the development team.

Consider the alternative, the team identifies the need, and says that they will address it immediately at the cost of delivering the rest of the sprint. How hard is that conversation going to be? How likely is it that the team will be supported in their decision to actually do this?

How much easier would it be to fail and let it become a work item lost in a backlog?

This is how failure becomes seductive to a team. The team knew how to do a better job, how to actually deliver towards a goal of high quality software that can change over time, and allowed someone else to tell them not to.

There are numerous times when you work on a team where a situation similar to this will come up, and before long it becomes a habit. It becomes the standard way to handle non-feature techie stuff. It becomes part of the working agreements to delay all work that would improve the quality of the product until a time that the Product Owner decides that it is more important than any other feature.

In time, the people who first identified those things will stop identifying them. After all, why should they? That part of how they think critically shuts off. Now, even if they were allowed to do a good job for a change, they have literally been trained not to. It would be hard for them to be as effective at cleaning up those mistakes or seeing the opportunities to make it better. They have no practice, no skill, no experience in delivering quality work.

Managers will remember the Iron Triangle, and how of the options, fast cheap, and good they are allowed only two. Consider the scenario above and what two have been chosen. Consider how that choice would impact the overall product.

I want teams to actually have the courage and support to choose good for a change. I want Product Owners, Scrum Masters, managers, and tech leads to recognize that excellence happens in the hundreds of small choices we all make like the ones above.