Marcato

There are many books that I have read over the years that have influenced my thinking about software developer processes, but probably the most influential had nothing to do (at least on the surface) with software development. That book is “The Goal” by Eli Goldratt.

Eli is a physicist with the rare talent to be able to apply his understanding of the mathematics behind the behavior of complex systems into a very easy to understand novel about a plant manager faced with the challenge of trying to figure out how to save his plant and make his company more profitable.

At the risk of spoiling the book (it won’t, and it’s such an easy read that you will find that you learn much more by doing it), let me tell you about what I learned. The first and most important lesson is about process bottlenecks and how to identify them. Every process with dependent steps has a process bottleneck – to find it all you need to do is to look for the step that has work in process piled in front of it. Closely related to this is the notion that all work in process us waste – “lean” thinking in manufacturing or any process design focuses on removing that waste by balancing the capacities of all steps in the process.

In the book he tells a memorable story about a scout troop that has a goal of getting their entire troop to a destination by a certain time. Inevitably, there is one scout that just can’t keep up (more of that rampant obesity in America’s youth!). At first they just let him fall behind, but someone finally realizes that this doesn’t work as they still fail in their objective. Next they try tying a rope between themselves so that no one can go any faster than the slowest person. This keeps them together but

Then good things start to happen – because they are tied together, they realize that the only way they can succeed is to help the slowest person go faster. They start volunteering to help carry his pack and other supplies, and the net result is that the team starts to move faster.

I read this book during a time when I still thought of testing as a downstream function performed at the completion of coding activity. I was also working on shortening release cycles and was looking at how to pipeline releases so that I could keep the developers busy building v2 while v1 was being tested. However, what I saw was that this trapped us in a cycle that guaranteed the testers could not participate in design of v2 and led to frequent complaints about inadequate design documentation and lack of access to the developers during testing.

My systems engineering training taught me one important thing – delays in systems lead to instability. In effect, the delays between development and testing were leading to both poor quality as well as lots of gyrations to try to accommodate the differences in time of these activities. Also, there was a tendency to under staff the testing function, further exacerbating the problem as this shared resource pool was frequently switched in and out of projects based on timing and need with no long term association or specialization.

To solve all of the problems, I needed a “rope” to tie these functions together. That rope took to tangible forms – first, testers were assigned into teams so that they were part of the team for the full lifecycle of the work, and second, we started adopting agile practices with shorter iterations focused on completing whole features and no one on the team was done with the sprint until the whole team is done and the story can be closed.

With this model in place lots of things became apparent – there was not enough testing capacity, so developers had to lend a hand in certain situations until we could fix the ratio. Testers were part of the full cycle of developing the feature and should never be left behind. I no longer had large piles of work in process sitting waiting for testing resources to become available. And finally, perceived throughput better matched real throughput – in fact, the perception of every company I have been in that does this is that even if it means fewer developers, more features are making it to market faster.

So, if you are looking for inspiration yourself, check out “The Goal”.