In software development we often end up with local optimization. Developers focus on getting the development work done, testers focus on getting the testing done, and the analysis team focus on getting their work done. This is a problem, because local optimizations does not optimize the whole.

The development process should be optimized for global productivity. Work should flow thru the development pipeline without batches of work accumulating within the pipeline.

In the following diagram imagine the work flowing from left to right. First it enters the analysis team, then it’s developed, then tested, then finally it is delivered to the customer. A work item is indicated using the letter “x”.

This shows a situation where the testers are a accumulating work because they cannot process all the work the developers are handing over. Notice every team is working with top efficiency. This way of working introduces problems.

Problems caused by large batches

What are these problems we are creating ? If you look  at the entire development process as a queue of work going from left to right, you will see that more work in process creates a longer queue. A longer queue means that the time it takes for one item of work to pass thru the entire queue is longer. This means that the delivery time of our software increases ! When work in progress increases, the delivery time increases. This is obviously a problem for many reasons that I will not go into right now.

There are other problems with the above work flow as well. Developers continue developing before their previous work is validated by the testing team. This means that they are creating work based on possible false assumptions. When this propagates thru the system it creates even more problems.

Limit the work in progress

The key is to limit the work in progress. In the previous scenario the testing stage of the software development process is the bottleneck. To avoid the accumulation of work in progress we need to increase the thruput in the test team, or lower the rate at which work is arriving. One solution could be to move some of the developers over to the testing team. Another would be to slow down the work upstream (to the left) of the test team, by giving the craftsmen there some “slack”.

Having people not doing the work they should be doing is often a problem for managers. They measure success by how efficient their  team is. Suddenly we are back to local optimization. Having slack is actually a good thing. In the right enviroment it creates opportunities for learning and innovation.

In rigid  functional teams, it is hard to do anything to modify the flow. People are happy with local optimization. In cross-functional teams it is easier to modify the process to accommodate the flow.

Some additional thoughts

1) It is easy to think of work in an software organisation as small items of work flowing thru the pipeline. In reality the work items varies in size as they flow thru the pipe. Also the issue of rework puts a little brake on the happy path. Keep this in mind as you take your next steps to improve the flow :)

2) There are things to be said about having the testing team upstream from the development team and making the batches of work smaller. That’s something for another post.

3) Focusing only on the work in progress withouth thinking about keeping the team members happy from a social point of view is a good way to fail in the long term.

Feel free to comment :)

Inspired by:
Kanban Chalk-Talk  (http://vimeo.com/7814701)

F Share