Making Code Speak

A weblog of tools, techniques, styles and habits for programming with fluency.

Process Forest Fire: An Agile Game

“Individuals and interactions over processes and tools,” says the Agile Manifesto. And yet, almost all the various Agile methods do bring along some processes.

In some environments, a team can easily start to pile on new ones. “We’ve noticed some design problems slowing us down, so we added an extra round of code review before calling a story done.” “We wanted to mix things up more, so we’ve declared that we’ll switch pairs at noon and 3:30 every day.” “We wasted some time building something in a way the customer hadn’t wanted, so we’re going to make sure that they’ve signed off on a detailed acceptance test before we start any story.”

A few of these processes can be good. If the team’s functioning well, they’re usually designed to solve real problems. But if you started doing something for a reason, it can be hard to stop doing it even when it doesn’t make sense any more. And as more and more processes accumulate, it can start to make work feel like a bureaucratic nightmare, where it’s impossible to get anything done.

Faced with this situation a few years ago, I decided that something had to change. I asked if anyone would mind if I ran the next retrospective and did something a little different with it. Then I announced my plan: In order to reduce crowding and make room for new growth, there was going to be a process forest fire.

Equipment

For this game, we needed:

Round 1: Seeing the Forest

I set the stage: “There are a lot of processes we routinely follow during our work. Some we explicitly agreed to, others seem to have started with some unspoken understanding passed down from before we were even on this team. Many of them may have good reasons to be there, but if we never examine them, even the good ones can keep us from discovering still better ways of doing things.”

Then it was time to brainstorm processes: “With that in mind, I’d like to spend a few minutes brainstorming all the processes we follow. Write them down on the green stickies, and stick them on the table. They’ll be the forest.”

At this point, I set a timer for five minutes. At the end of that time, I did a quick grouping exercise to clear up multiple instances of the same thing, and then moved on to…

Round 2: Setting a Fire

“Now we’re going to have a process forest fire. The goal is to burn down anything we no longer have a reason to do, anything that no longer seems like a good idea, and anything that seems like it’s preventing better alternatives from arising.”

I described the rules: “Over the next five minutes, I want you all to identify processes that might be worth abandoning, and set them on fire by dropping fire tokens on them. If you like something and want to save it, you can put a water token on it to put out the fire – one water token for each fire token. When the time is up, we’ll take every process that burns down, and abandon it then and there.”

The next five minutes were the liveliest I’d seen in some time. It turned out everyone had some processes they were ready to drop, and a few that they wanted to save. Until a few seconds before the end, it looked alarmingly likely that we were going to stop doing daily standups. In the end, some process had been left alone, and some had been saved, but quite a few had burned down.

Round 3: Cleaning Up

After it was done, we collected the list of processes we’d abandoned. I read each one out loud, and everyone acknowledged that we were letting them go. We chatted a bit about what we thought the consequences would be, and whether we thought the change would last. And then we returned to work, which suddenly felt about ten pounds lighter than it had that morning.

Aftermath

In the weeks and months after this game, it seemed to have lasting effects. Many of the processes we’d been following proved to have been completely unnecessary. Working together to remove them seemed to remind us of our ability to self-organize, and to encourage us to experiment more. It left our team less bureaucratic, and more ready to learn and adapt.

An Observation on Vulnerability

There’s one thing that I think was critical to the success of the game: we were all totally prepared to accept the consequences. If the daily standup had burned down, we were ready to find a new way to organize ourselves each day. If TDD had burned down, we’d be watching the effects on our code quality, but we’d have stopped TDDing things for long enough to see. Without this commitment, it would have felt like a silly game. With it, it became an exercise in trusting ourselves to do the right thing.

posted by Moss on 24 January 2014