There are only three types of buffers: extra capacity, extra inventory and extra time. This is one of the great take-aways from Factory Physics that I have frequently quoted since Thomas Blomseth introduced me to it on our lean study-tour to Japan earlier this year.
It is an essential piece in approaching process optimization.
Most processes have (and this is not a bad thing) critical steps that govern the throughput of the whole process.
For example, consider a development organisation that wants to improve its output. Assuming that the development process consists of the definition of work (the work of the Product Owner), the implementation of this (the work of the development team), the acceptance of the work (the PO again) and the user testing (the test team).
In our case, let's assume that we have an overburdened product owner who does not have enough time to specify the work properly and is hard pressed to check the work done by the development team, finding many misunderstandings after the work has been done, leading to much rework. We also assume that the PO is actually involved in doing a lot of testing - something that is often the case, but many times also a sign of poor acceptance criteria in the requirements.
In our case, the work is governed by the PO - in the work definition role and in the acceptance role. Until this bottleneck is removed, we can quickly conclude that there is no point in hiring extra developers since they would just be sitting idle. The PO capacity is the bottleneck.
Let's try the exploring the issue from the perspective of the three buffers.
First, we consider adding extra capacity for the PO role.
There are several approaches to think of - the first being "eliminate waste". We look at the PO's work and see if he is spending time on non-critical or non-value-adding work. This can either be eliminated or delegated - in fact, it is often a good idea to delegate to someone who are not so good at it if they have spare capacity. This includes training others to help extend the capacity of the PO-role.
The next thing is to look for extra inventory. To use this approach we would build up inventory of PO work in front of the development team, for example by giving the PO a head start on the project to build up a huge backlog so the team cannot catch up. Call this an analysis phase and we get to waterfall development. The downside here is that by doing this we practically eliminate the learning about the project that occurs in the feedback loop between work definition and implementation so it is probably not a good idea either.
This also applies to having the PO focus on the definition only and building up inventory before the "to be acceptance tested by the PO" stage, effectively building a huge inventory of work-in-progress of an unknown quality - something that is generally regarded as a very risky endeavour.
An alternative approach could be to eliminate the queue in front of PO acceptance could be to keep the work flowing and the cycle-time in check could explored by testing the hypothesis that we could off-load the queue by timeboxing on the PO testing and automatically promoting features to system testing after, say, one week in the "Waiting for PO acceptance" state, or by having the PO do prioritised testing of the key features inside this timebox or even uniting the PO and user testing into a single team. The hypothesis we should test here is that if there is extra capacity in the user testing stage it can be used to substitute for PO capacity even if it mean more rework or more work for the testers, using some of their spare capacity. By applying an end-to-end process this could turn out to be an improvement of the total system.
The last approach is to look for the extra time angle. The approach here is to lower the capacity of subsequent steps to near that of the PO throughput (usually with enough extra capacity to absorb the variation in the PO step so the system is kept stable). In our case this could be moving people from the development team do useful work on other projects or let them use their spare capacity to improve their development process - cleaning up legacy code, improving the build process, learning new skills etc. By trading for the buffer of extra time we slow down the delivery of the project to the gating factor (PO capacity), but waste less developer time in the meanwhile. In some cases this is a very good approach as a smaller team has less overhead for communication etc.
Turning back to the upstream steps we must also examine the PO role with respect to constraining the definition of work. We can address this in many ways, but the best way is to ask the team and the people involved to see what is really going on in the "Gemba" where the value-creating work is being done.
In some cases it could be that the PO is so stressed by the amount of work that badly defined work is being accepted by the team which in turn increases the burden on the PO to check and suggest changes to the work produced in the "PO acceptance" stage - something that impairs the POs total capacity by a vicious cycle on the constrained resource.
In this case we can explore approaches such as involving the team or the downstream testers more in the work definition stages to improve the requirements and make PO acceptance a lesser burden by delivering the right product.
By starting with Factory Physics, systematically exploring the problem from the angles of extra capacity, extra inventory and extra time gives us a simple, yet powerful tool to ask good questions and analyze the process. As such it is a great starting point for the team to generate ideas to try out to improve the process - and that's the way to creating better software faster.
Building better software faster is Martin's mission. He is a partner in Ative, and helps development teams implement lean/agile software development and improve their craftmanship teaching hands-on development practises such as iterative design and test-first. He is known to be a hardliner on quality and likes to get things done-done.