Choosing Continuous Improvement over Perfection.

Just a few weeks back, a former colleague put up as his Skype status the quote from Mark Twain, “Continuous improvement is better than delayed perfection.” Stumbling on this, being a software quality assurance enthusiast, the first thing that came to mind was the attitude of stakeholders to software development.

My observation over the years working with various teams on different IT solutions involving product owners and stakeholders has been that of a demand for product perfection. I seem to be of the opinion that deployments and roll outs can be more effective and quick if we focus on ‘what should be done’ rather than ‘what can be done’. While it’s not a question of whether the stakeholders are being too ambitious in the planning phase, it’s more an issue of stacking too many deliverables and features in a single roll-out (or product launch) to deliver a perfect product.

My understanding of the Agile practice says that teams should deliver working software frequently within very short timescale hence the reason for sprints, versions, user stories and epics which are meant to drive a specialized incremental development process. Alas! We still see teams and product owners who boast of practicing Agile yet want to implement a report page, with 15 search parameters, export buttons for pdf, xlsx and csv formats as well as upload feature and a barcode scanner within two weeks! No one needs a genie or soothsayer to tell them that unless the team chooses to break the deliverables into bits and roll out features gradually, no deployment will be achieved in the stipulated time.

I am of the opinion that the desire to achieve perfection is a temptation many product owners and PMs fall into while trying to ‘wow’ the customers and stakeholders. At the end of the day, the developers have their fingers in too many pies, roll out dates are shifted many times causing the customer not to be able to notice any tangible progress for a long time.

First and foremost, delivery cycles should be kept short with each cycle lasting not more than 2 weeks. This way, the team has the opportunity to get important feedback from the users/customers which eventually becomes a defining factor for the final changes or improvements.

Also, we should work towards limiting the amount of work in progress at a time so as to force the team to focus on smaller set of tasks.

Finally, each delivery cycle should deal with only tasks/deliverables related to one feature or user story especially a feature that is most valuable to users immediately. Thus, at the end of every cycle, a fully functional feature/user story should be ready instead of having many half-done user stories in one delivery cycle.