Struggling with a Transformation? Try Serving Stone Soup

The fable of stone soup is often told as a lesson about group cooperation in times of scarcity. I’ve used a pattern based on this allegory to help groups make incremental steps toward improving themselves and the way their team approaches work.

The Fable of Stone Soup

A traveler comes to a village, carrying nothing more than an empty cooking pot. Upon his arrival he finds each family has different foods but they are unwilling to share. The traveler goes to a stream and fills his pot with water and places it over a fire. The traveler then drops a stone into the water and leaves it to boil.

Eventually a villager asks what the traveler is doing. The traveler explains he is making stone soup and asks the villager if he’d like to try some. The villager tastes it and comments that it’s a bit plain. The traveller suggests some garnish would improve the flavor. The villager did not mind parting with a few carrots to help out, so they get added to the soup.

One villager at a time comes by to taste the soup and offers to improve it by adding the garnish he has. Eventually the traveler has a delicious soup full of good vegetables and other spices. The villagers all share the finished meal and wonder why they hadn’t worked together in this way before.

“Agile Won’t Work Here ”

I coached a team working in a culture where waterfall was best described as a religion. Upon arrival I was told, “Don’t try agile on us. It doesn’t work here.” I acknowledged what they said, then asked if they would be willing to try working iteratively. They agreed.

One of the first things I told the team was we had no authority to ignore processes. We could only find new ways to work within them or ask to have them changed. In our team room I posted the Agile Manifesto but labeled it “Team Manifesto” (including the twelve principles but removing references to agile). The team agreed to work in a mini-waterfall process, delivering working software at the end of each iteration. We had daily standups, weekly retrospectives, weekly planning meetings, and lots of information radiators.

As the project started there were lots of questions, but I said we would figure things out as a team. With each challenge I kept pointing to our Team Manifesto and asking how the team’s actions aligned to how we agreed to work. In essence, the Agile Manifesto became their guiding light for improvement without their knowing it.

Many of their waterfall processes would make your toes curl: code reviews that would take three days, review processes requiring upward of twenty sign-offs, database changes only a database administrator could do . . . . We challenged anything threatening our goals for improvement.

At the end of the first iteration the team had found ways to improve and deliver more than expected in two-thirds the time allotted. (Remember, it was waterfall still). At the end of the second iteration the improvement trend continued. By the fourth iteration the team had improved their approach to the point they were delivering working software to the customer every two to three days. The waterfall was fading!

The mini-waterfall was certainly not the most efficient way of working. To be honest, I was nervous about it failing completely. However, this experience is what this team needed to shift away from their waterfall religion.

“We Don’t Have a Problem”

Not all of my stone soup experiences are success stories. With one team we started with a simple kanban wall and asked everyone to put all their work on the wall. We didn’t impose work-in-progress limits or many other good kanban practices.

We started having daily standups, weekly retrospectives, and planning activities. Everyone was happy at first. The manager even said, “Wow, I had no idea this much is going on.” The team was happy with the visibility and collaboration kanban was providing them. They were starting to feel there was an avenue for addressing all those work requests coming in the back door. We were on a good track—at first.

After a few weeks I explained to the manager it was time to stop serving stone soup. There were numerous impacts to this, but notably we were going to implement the use of work-in-progress limits. Our soup spoiled when I explained the limits would mean saying “Not yet” to new requests. Until this point we believed we had the manager’s support, but that turned out not to be true.

The result was the buy-in we had gained early with this team started to erode. The lack of management support at a critical time meant the team wasn’t able to realize significant improvement to their working lives. It seems we only added bureaucracy with kanban. The last time I talked with this team, resistance was continuing to build and I suspected they were seeking ways to work around kanban.

“Now I See It”

Another time, I coached a different team that, much like the team in the previous story, had far too much work going on. This story is pretty much the same, except for one basic difference.

The story changes at the point the manager told the team leader, “You’ve been telling me how much work your group has going on at once. Now I see it!” Unlike in the previous team, this manager fully supported limiting work in progress, among other practices. The result was drastically different.

When we instituted work-in-progress constraints, the team didn’t take on any new work until they were able to, within the limits. Through time they continued to improve, and now they are a highly effective and reliable team.

Is Stone Soup for Your Team?

When I serve stone soup I have learned to consider questions like the following:

• Am I really being asked to just “fix the team”? When managers are asking for a fix, the team will likely feel threatened, so stone soup may seem like an easier alternative than a drastic change. However, this doesn’t address the real problem: that real and impactful change must start with management.
• Why not just do it all at once? I would prefer to come in and just help the team immediately make the transition to Scrum, kanban, or whatever methodology they prefer. Am I clear on why serving stone soup is the better choice?
• Do I really have management support for all the changes to come? Or are they just supportive of the first step, as it’s not too disruptive or painful?
• Do we have the time it will take to serve stone soup? I believe the team will have a stronger result as they build to it themselves, but it will take longer than just flipping the switch in one day.

Unfortunately, I cannot offer a magic recipe for stone soup. I cannot tell you whether stone soup is the right thing to serve your team. All I can share is an approach I’ve had success with (but not always).

However, I also know hitting people over the head with the big agile stick doesn’t always work, either. I’d argue there is no right way to ask people to change the way they’re working. It’s more important to have a variety of approaches and to use the right one in each situation.