Ever been in a standup and heard something like this - "I could complete this task but I'd like to re-factor the code one more time"? What about this one - "All the acceptance criteria are met so I could move this story to done, but I won't because there are a couple of additional cases I think it should handle as well... So I'll add a couple of extra tasks and work on them today"? What about this - "The feature is complete but we can't put it in production yet... It really needs to be bundled with that other feature to make an impact in the market" ? Or this - "The MVP is done but we have decided to hold off on releasing it to market because it's not the complete, fully featured solution our customers would expect"? Or this - "We have decided to delay the release by another couple of sprints to add in some additional features that will enhance the customer experience some more"?

One description of agile is "the art of getting things done". Done is a great thing to aim for. Done means delivering value, making a difference, achievement. Unfortunately, a lot of the time we are pretty bad at it. Done has a mortal enemy that tries to prevent us from ever reaching Done. It continually moves Done further and further away from us. We take one step towards Done and its mortal enemy moves Done two steps further away. The name of this mortal enemy? Perfection.

We all do it. I do it all the time. These articles I post are typically rewritten several times and I often agonise over one or two words to get my point across... Perfectly. There is one big problem with perfect though - it's impossible. Striving for impossible perfection distracts us from the fact that what we have is already good enough, often way better than good enough, to achieve its purpose.

That release you just held back so you can improve the customer experience a little more - is what you have ready now already an improvement to the current experience? If not then why did you do it? If it is better, then why are you denying your customers that better experience? What you have ready now is better than what your customers use today. It is already an improvement. Give it to them. Then take those extra features you were going to hold the release for and make another release that improves the experience still further. That way your customers get two improvements rather than one. Actually they get two improvements rather than none because chances are you will hold off the release again, and again, and again to make it even better. Sure it will be a great release (if it ever gets released) but in the mean time your customers are still using the old system (and may well be looking at your competitors). You may delay so long that there is no value left.

Striving for perfection is getting in the way of releasing something that is already better than what is out there.

What about than MVP you decided not to release? Sure it's not fully featured yet, but the point of an MVP is to test assumptions. Do your customers even want this? Can we make money out of it? By not releasing it, and spending more money on making it bigger, we delay our learning. If the assumptions were wrong (and they often are) you just wasted a whole bunch of money and effort on a failed idea. If the assumption was right, you just wasted a whole bunch of money and effort potentially building features no one will use. Far better to get something into the market fast and learn what they really want rather than making guesses. Don't delay so long that there is no learning left.

But your customers expect a fully featured product. Sure they do. But not if you tell them it's an early concept. Not if you tell them it's a trial to gauge interest. Not if you tell them it's for the purpose of collecting feedback about new product ideas. And look at it from their point of view - it may not have all the features they'll want, but at the moment what do they have? That's right - none of the features they want. Even that sketchy MVP is better than what they have now.

Striving for perfection is getting in the way of releasing something that is already better than what is out there. And it's getting in the way of learning.

Same with that story you want to hold back to add some extra cases to. Add those extra cases as a new story. If they are important they will make it into a future sprint. In the meantime, by making that story done, you have just added some functionality to the product - it's better than it was before.

And that code you want to re-factor - is it better than the code that was there before? Is it good enough to release? Then release it. What you have now is already an improvement on what is there already.

Wanting to do a good job is a great thing. It shows pride and craftsmanship. But we can't let this become a search for perfection. You have to stop sometime. If I am making something in the workshop, I could keep sanding and sanding the wood looking for a perfect finish but eventually I would sand so much that there would be no wood left. I would have destroyed the value of what I had just done. It's the same with what you build at work. You can work on making it perfect for so long that there is no value left in it.

Making it perfect also stops you working on something else. I could sand the mantle again or I could call it done and start working on the bedside tables (for which my wife has been asking for years) instead. I could re-factor the code again or I could start working on that other story and add even more value. Good enough is what you want.

Don't ever mistake "not perfect" for shoddy. The finish I put on the wood may not be perfect but it will be damn good. That code may not be perfect but it is damn good. The release may not be perfect but it is a huge improvement on what is there now.

Learning when to stop is an important part of developing craftsmanship. Good enough to meet the need it was built for. Good enough. Not perfect.

I will now declare this article done. Not perfect. Good enough.

Done.