An opportunity for improvement came up recently on a coaching engagement that reminded me of the book, Switch: How to Change Things When Change Is Hard, by Chip and Dan Heath. The authors found that in a wide range of circumstances, people had approached very challenging changes in a similar way; basically, by finding the bits that were working well and using them as the basis for further improvement.
Sometimes the bits that are working well don’t look all that great at first glance. One of the stories the authors of Switch share is that of Jerry Sternin, who was charged with improving the nutrition of children in Vietnam. Rather than approaching the problem as a large-scale infrastructure problem, as had been done up to that point with poor results, Sternin went to a single village to learn how children were fed.
He noticed that some children were well nourished. Setting aside those who had Party connections, and therefore access to better food, he investigated how the well-nourished children were fed. He found their mothers mixed additional sources of nutrients into their rice, including wild plants, small shrimp and insects that could be found without cost. To a Westerner like me, mixing insects into my rice sounds rather nasty; but sometimes opportunities don’t come at you waving their arms and shouting, "Hey! I’m an opportunity!"
Sternin also learned the mothers of the healthier kids fed them four small meals per day rather than the two large meals that are customary in Vietnam. It turns out that small children can’t fully digest large meals, and they assimmilate the nutrients more effectively when they receive four small meals per day. He then recruited some of those mothers to teach the others in the village. The first village became a working model for others.
Those of us who work in the area of organizational and process improvement don’t often have to solve problems as serious as that one. Yet, sometimes the opportunities for improvement don’t look very appetizing at first glance. One client of mine has a linear software delivery process that includes an iterative portion in the middle. The iterative portion of their process only includes the programming step in the typical linear sequence (sometimes called "waterfall"). Like many other organizations, they had convinced themselves that by making tick marks on their calendar every two weeks, and changing absolutely nothing else about how they were structured, how they measured progress, or how they worked, they had become "agile."
When an organization introduces iterations in that way, they incur additional process management overhead as they attempt to mimic the "agile" ceremonies they have read about in books, but they don’t reap any benefits from it because they are still doing things the same way as before. The idea of an iterative process is that we iterate over the "requirements." If the requirements are all set in advance, then iterating over the programming tasks doesn’t really do much for us. Various iterative and time-box models, including Spiral, RUP, Evo, Scrum, Extreme Programming, and others make it clear that we incrementally plan, analyze, design, code, test, and deploy, ideally with the goal of generating hard value, and we want feedback from real users in each iteration. We don’t carve out the programming bit from the middle of the "waterfall" and pretend to iterate over just that, in isolation from the rest of the process. To do so would be like mixing bugs and weeds into our rice. On the surface, not very appetizing.
But this non-appetizing thing turned out to be a lever, and with one of those we can start to move things. In a conversation with a few area managers and project managers, someone mentioned that their biggest pain point is integration and deployment. Code is built by different groups who work independently and who don’t integrate the various parts of the code base until late in the delivery cycle, at a point when change is expensive and unexpected change doubly so. Without integrated code, no one practices the deployment procedure until the very end of the delivery cycle. More surprises, more changes, more expense, more frustration.
The make-believe iterations aren’t doing anything for the company, but at least they provide a mechanism for iterating and the people in the various work group silos are already comfortable with the idea of iterations. We are addressing their pain point by extending the scope of the iterative portion of the process to include integration, acceptance testing, and deployment. My primary mandate was originally to introduce the practice of specification by example (which is also known by a few other names) using Cucumber. But this won’t help very much unless the executable examples are actually used by the development groups as the basis for building product. We have had good support from both the business analysis and QA areas, and indeed the walls between those two silos are mostly gone, but the reactions of the other silos involved in software delivery have ranged from bemusedly tolerant to openly hostile. Extending the iterative activities beyond just the programming tasks is a significant step forward for this organization. Since all the silos share the pain of integration and deployment issues, it’s a natural lever to move the organization toward a more-effective delivery process. People are thinking about pain relief rather than about how to avoid change.
Don’t worry if you can’t change the whole world all at once. Find a lever. It might not look like a lever at first, but it’s there, somewhere, hiding in a bowl of rice or in a make-believe iteration.