November 9, 2017
In software development we can learn a lot from production companies. Especially to make software development better and more efficient and to use it more purposefully for the success of organizations. The per piece production model offers a solution, also for software. This should be the (new) ambition for every organization involved in software development.
The per piece production model - also called: one-piece-flow - stems from the Lean management philosophy. By carrying out work directly from start to finish (in one flow), wastage is avoided. In this way, the activities are better carried out, is the idea. For this purpose, production companies carry out all sub-processes of a product directly one after the other. Each partial operation is therefore not carried out on several products at the same time (batch processing).
In this way, production companies shorten their lead times, reduce stocks and - more importantly - run considerably less risk of bad products. Because they immediately see whether all parts fit together properly. With batch production, you only know this much later and you can therefore only make improvements later.
Disadvantages of traditional batch production
The same considerations are important in software development. Traditionally, software was developed with batch production. Renewed software then contains, for example, 20 new features. These are all made available at the same time in one new version. Slightly more modern processes, for example, launch an update once a month or quarter. Users who are waiting for one feature that is important to them must then be patient until that update moment. While their feature may have been finished a long time ago.
Moreover, the success of the update depends on the correct functioning of all features within the update. Is one of them not working properly? Then the update will be rejected, including all features that work perfectly. This is also time consuming for all users, testers and administrators. For users, a lot changes at the same time and all features need to be tested extensively. If an update is put ‘on hold’ or reversed, the whole process starts all over again. Doesn’t the whole thing work well then… which feature is it on? That is puzzling.
Advantages of one piece production
Batch production is inefficient, undesirable and even untenable for modern software development. Adopting the per piece production model is the solution. Each feature is then developed separately and immediately becomes available as an update. In small, fast and clear steps. The risk and impact for an organization is then small. Even reversing an incorrect update has no major impact. And the differences in quality, performance and user satisfaction are easier to control.
An important condition for successful piece production in software development is the optimization of the update process. After all, this always has to be done: with 1 or 20 features. It is crucial to realize this process as well and as automatically as possible, at the lowest cost. This continuous delivery must be an integral part of the development cycle of every modern software development project. When setting up continuous delivery (CD) and continuous integration (CI) properly, the frequency of update moments becomes a business decision, rather than a technical one.
Shifts in practice
In my daily practice at Ibuildings we see the shift from batch to one-piece development taking place more and more at organizations for which we develop web or mobile apps. We also see beautiful examples more and more around us. The popular website Etsy - a large online marketplace for handmade and vintage products - already took the step in 2014. Thanks to their new approach, infrequent and regularly painful updates - where the site went down - made way for a new model in which they very smoothly [update more than 50 times]a day (https://www.infoq.com/news/2014/03/etsy-deploy-50-times-a-day).
The new ambition
This isn’t just for Etsy. It is the future of software development. Every organization involved in software development should have it as its ambition per production model. The change is far-reaching and requires many steps - technical and organizational - but you get a lot in return.
The biggest reward is that your software contributes better and better to the success of the organization: in user satisfaction, innovative power and efficiency. That seems like a healthy ambition to me.