The second impediment, or why should you care about engineering practices?

Sometimes I think, Switzerland is land of product owners. Thanks to our strong economy, there is much more development to do than have capacity for. So we off-shore and near-shore quite a bit. And technical topics seem to produce a yawn among managers and product owners. “Not really my problem,” they seem to be saying. I’d like you to challenge that assumption!

I don’t often change the main messages of my Scrum courses. For years, I have been talking about “Inspect and Adapt”, “Multitasking is Evil” and “Spillover is Evil.” Recently I have added a new message:

Bugs are Evil.

Why this change? While researching for my Scrum Gathering Workshop on Code Dojo’s, I found a paper by Alistair Cockburn from XP Sardinia. He wrote, In 1000 hours (i.e. in one month), a team can write 50’000 lines of code. And they will send 3’500 bugs to quality assurance.

Doing the math based on industry standard assumptions, I found that that team will create 12’000 hours of effort for themselves, quality assurance, operations, and customer support. 1 year of waste produced for no good reason!

Is this really true? Well, at my last Scrum Master course, I met someone whose teams spend roughly 2/3rds of their time fixing bugs, much of them in emergency mode. Technical debt is a real danger! Imagine if you were paying 2/3rd of your income to pay the rent and plug holes in the ceiling of your apartment! That product is on the verge of bankruptcy!

Technical topics often generate a yawn among product owners and managers. But it’s your money and your team’s capacity which is being wasted!

So I’d like to encourage you to pay attention to engineering practices. Bugs are evil! Remember that and make sure everyone in your organization knows it too. As a leader, you are best positioned to ask the question, how can have fewer bugs?”

P.S. This is the topic for Monday’s Scrum Breakfast Club, “Why should you care about engineering practices?” Check out the event, and come to my Manager and Product Owner friendly introduction to Pair Programming and Test Driven Development.