Global Process Optimization

by Jens Coldewey, Senior Consultant, Agile Product & Project Management Practice

Watching flight attendants doing service on a short-distance flight, you can learn a good lesson about global process optimization. There is just enough space in the aisle for a single trolley; overtaking is impossible. In most cases, the first attendant starts his service in row one and then services the rows consecutively. As soon as the purser has finished her post-takeoff checks and has prepared her trolley, she closes up to her colleague, who in turn skips a few rows the purser now services.

You may think this is trivial; I consider this a perfect example that only global optimization leads to a reasonable process. If the first attendant would just start servicing faster -- optimizing his own performance locally -- the purser would stand there unemployed, and the overall service would break down. The attendant has to stop his service for 10 or 20 seconds -- thus being less efficient -- to enable his colleague to start working at all.

Why do I write about this? It is exactly this second irrational behavior I observe over and over again in the software industry: Developers who try to finish their personal-development tasks in overtime and by programming "faster" usually deliver poor code and design quality. Later testers who have to test the junk or other developers who have to change it experience very bad performance. In particular, the clients have to pay the bill, though often enough they hold their share of the responsibility because they had put irrational pressure on the development. This operational rush is not even egotistic, because it may even be the developer himself who runs into trouble later. It is simply shortsighted.

There are other players who may play different games of inadequate local optimizations: testers that delay testing of finished features because "it is not on our schedule"; product owners who think that changing priorities all the time helps to ease their pain; and, of course, managers who often not only tolerate behavior like this but cultivate and reward it.

Why do flight attendants perform so much better? At least on the short flights within Europe, they train their process four to eight times a day in changing teams. They have close contact to their customers, who are willing to provide clear feedback if the service is bad. And they have the freedom to try different processes variants and learn from their choices.

Agile development also uses short iterations, direct client contact, and retrospectives to foster global optimizations rather than burn the team in the operational rush of shortsighted local optimization.

I welcome your comments on this issue of the Cutter Edge and encourage you to send your insights on the market in general to me at jcoldewey@cutter.com.

-- Jens Coldewey, Senior Consultant, Cutter Consortium