Working on the bottleneck – the right one
Posted by Yannick Martel on June 12, 2009
From Lean Management and The Goal, you know where to look for when you wish to improve a complex process: you need to search for bottlenecks in the process flow, and first of all the major bottleneck. Find it and then concentrate all your actions on improving it. Then the process will get better (produce more and/or faster), but you will find have another bottleneck, another limiting factor. Just find it and work on it, and so on.
In IT, Agile has been proposed as a solution to the difficulties in the software product development process. As Agile concentrates on software design and development, it can really help only if difficulties were indeed in design and development. That’s probably partly true as we effectively see improvements when Agile practices are really applied in development projects.
But then from Lean Management, we know we should look for the next bottleneck in the process. Where to look for it? We get an answer by looking at a typical Agile project: somewhere between three and eight weeks after the beginning, the pressure is no more on the development team but on the product owners. And thus we have found our next (and maybe really first and most important – why not?) bottleneck: the team in charge of knowing what to ask.
To me, it is particularly important to effectively address this bottleneck, first because the bottleneck is stronger: knowing what to code is at least as important as knowing how to code it – and generally coding correctly is easier that knowing what to code. Once the development team is ready and eager to produce value, all concentrated on it, it can gell pretty fast and request to be guided, request to know what to produce – pressure has moved.
But there is another, more subtle, reason: softtware development is more related to product design and development than manufacturing (more related to designing a new model of Prius than manufacturing it). It is a profoundly creative activitiy, requiring communication, trust and confidence. If a strong bottleneck is left in the process and it is not addressed, then you risk mining the efforts which have been done elsewhere and loosing everything you’ve earned. More concretely: if your product definition process is visibly the bottleneck and you don’t address it, the demoralizing effect will destroy whatever gains you’ve done by implementing Agile in your development team and you’ll quickly loose the discipline to go on with Agile practices and continuous improvements – maybe creating a secondary bottleneck again.