The title of this blog is a saying that supports our Agile way of working, with the delivery of increments of working software each sprint.
It could happen that teams working with sprints struggle to deliver working software at the end of their sprint. Often because they are still (partially) stuck in that waterfall mindset where everything needs to be perfect before it can be delivered. Some teams even decide to abandon the use of sprints altogether because they feel that it is impossible to deliver anything in a fixed time frame due to the nature of their work. This is where I believe we should make the biggest shift in our mindset. What if I tell you that done is even better than perfect?
Say you are a user moving from a bespoke legacy system to an (almost) all-IP environment, so you’re confronted with more complexity and more possibilities. This makes it very difficult to predict everything that you are going to need from your product in advance. You would find more value in putting your hands on high-quality done but not perfect increments of working software where you can still provide feedback during the development process, as opposed to not seeing anything at all for months on end and getting the “perfect” product that was agreed upon months ago, instead of the product you need knowing what you know now.
In many ways a done increment is better than perfect. It lets you objectively test previously made assumptions. It already gives early value starting from the first increment and provides the development team with valuable hands-on feedback for the next increment. The team will also get to know the device or feature while adding more to it. And if for any reason, let’s say … a pandemic… the project is paused, there is already something useable. All the time, money and efforts spent have not gone to waste.
“Getting started is more important than being right”
Interesting quote Jochen. I’d love to be right from the start, but how does anyone know what is “right” in a changing complex environment? The info we have at the start often turns out to be incomplete or even inaccurate. That’s where verifying quality increments of working software towards initial assumptions gets its merit. You can still make changes without having huge costs.