You hear the words greatness, excellence and leadership quite often in the worlds of business operations and software development. Every person, team, organization and company should strive to be the best — but don’t go too far.
What’s too far? Perfection. You don’t need to be perfect — not even close. The results you produce need to be better than they were last time; better than the competition; better than whatever you’re replacing; better than your stakeholders expect … but not perfect.
Pursuing perfection paralyzes performance.
It goes back to a variation of the over-used 80-20 rule. In this case, you can achieve 80% of perfection in about 20% of the time it would take you to reach true perfection (assuming you could get there at all).
For example, let’s say it takes us 3 months to get to 80% of the ideal goal — perfection. It would take 15 months, five times longer, to reach the ideal. If we’re building a revenue-generating product, we’d have to sacrifice an entire year of revenue to get to 100%. If the software will be used internally to improve the organization’s results, we’d have to sacrifice an entire year of improvement.
Is that a tradeoff worth making?
I know some readers will shrug this off thinking that neither they nor their teams seek perfection. But, perfection can gnaw at us in subtle ways. Consider these:
- Fear of making mistakes
- Unwillingness to take prudent risks
- Refusal to incur any technical debt
- Obsession with grammar and formatting
- Inability to make critical decisions
- Hesitating to try anything new and different
You get the idea. Perfection isn’t only about the whole project. It’s also about the artifacts and components that make up the project — the little things. Spending an inordinate amount of time on any single issue or item can derail the entire project. Before long, a year has gone by and the business is still waiting.
photo credit: becca.peterson26 via photopin cc
Agile reminds us that perfection can be tricky, as you say, and that oftentimes “good enough” — for the customer, the business, the team — is all we need. The danger, of course, is not to swing from perfection to the other extreme of duct tape development. (I came upon a nice wording for this in a post by Steve Berczuk: there’s perfect, good enough, and good riddance.)
Gil
http://www.TheHumanSideOfAgile.com
Hi,
Good point! The agile approach is balancing between excellence and results, between doing and talking, developing and analyzing.
It’s complicated to explain the iterative approach and the journey through the cone of uncertainty.
More pragmatically, in offshore project this is the typical pitfall when “outsourced” shall to get 100% of their engagement done at iteration’s end without taking into account the increasing risk coming from the increment: ex. you get the money if you reach 100% each time produce overtime in sprint +1.
Agile is a permanent discussion based on effectiveness!
Cheers
Pierre