Frequent upgrades make for better products

Even in the days of the old waterfall model , one of the key factors of success was to identify issues and defects as early as possible so as to minimize remedial costs. But what if the wrong product is being made in the first place? This is a quality issue which is much harder to identify internally. In fact, it’s often not identified until the product is already in the hands of the customer.

However, the days of the old waterfall model are long gone. Yet, the more modern approach of Scrum , with its two to six-week fixed sprints (which potentially waste time) doesn’t safeguard developers from making the wrong product. Let’s do the math, based on a 4-week sprint. Let us assume a company with 50 developers working full-time on its software product. If 75% of their time goes to developing new functionality, that comes to a total of 6,000 hours spent on new functionality during one of these sprints.
That’s a lot of work and time put in before getting feedback.

Of course there are internal feedback mechanisms in place, but at the end of the day, it’s the customers’ verdict that matters. What should be done is to minimize the time between development and deployment.

The goal is to always be ready to release all new functionality as soon as it has passed quality assurance. In fact, we aim for a release – at least to our release candidate customers – as soon as the minimum viable product of a certain feature has passed quality assurance.

In practice, this is achieved using the Kanban process , where each feature goes through our development process of analysis, development and testing, independent of other features. For each feature, a new installation package is created, ready to be deployed for instant feedback.

This minimizes the waste in the development process and allows more time to design great features, resulting in a better product for customers.