Gamify your process
I encountered my first evil wizard in sixth grade. It was a winter afternoon and I had three friends with me. I was confused and a little dazed - this was, after all an all powerful evil wizard. How do you overcome something like that?
It's been more than twenty years since that fateful role-playing game session. In Behalf, the company I currently work at, we have overcome a few evil wizards. In fact, we have now moved on to dragons. Right now, we are tackling the dark caverns of the Three Headed Dragon Lord known as "Management Overhead". Once more we are confronted with the question: How does one overcome such an evil?
The answer is seemingly simple: You have a process.
In Dungeons and Dragons (the world’s most popular role-playing game), that process is the combat system. Each player acts on his or her turn and performs certain actions or activates certain powers. Some players are clever planners. Some are lucky. Some know the rules really well. Others just tell a really engaging story. Together, the group beats the odds.
When you think of it, this is not so far removed from our day-to-day office life. We may be fighting the dragons of the mind but they take different shapes in different realms and challenge us daily. The process is our weapon to handle these foes and it is the process which we constantly try to improve to respond to new and more difficult challenges.
The problem with changing the process is that it is really hard to do in mid-stride. This becomes exacerbated when you make a large leap - really revamp your process in such a way that the old one is completely discarded. People become confused and the new guidelines get ditched before they were ever given a chance.
I found that in training a team to handle a new process - and especially when this new process has never been tried before, it really helps to simulate it. A simulation is basically a game that emphasizes the process rather than the work it is meant to serve. By dry running the process a few times in a room, you get a few valuable results.
The simulation trains your people to know the process. To feel how the process works. It punches through the petrified synaptic blockages formed by the previous process or previous bias and concepts. It reprograms people’s brains to think in a new way, based on a tangible example.
The simulation shows you a bird's eye view of the entire process. You get to feel the different flow options come to life. You make new connections and the process may be further modified (for the better) by these new insights.
The simulation is fun. It is a game and people like games - even the grumpy ones. The game is a challenge and to each participant it is a different challenge. Once again there are people who know the rules and how to use them. There are those that are lucky. There are those who like to plan ahead. Others just tell a really great story. Your people become a team.
I ran such a simulation and it was hard, fun and fascinating. I had finally found a way to bring my primary hobby into my professional life.
Since every Agile Process is a different story I will dedicate a separate article to our specific process at Behalf. Right now I will try to lay down my preparations and observations about the game I created and ran. As I lead a team of developers, this simulation was heavily skewed towards our inner world. YMMV.
Before we start, remember that as a game, this is an abstraction of the process. While it is important to keep the process in focus and grounded within the game, you should keep in mind there is such a thing as too much realism. On the flip side, there's also too much simplification. You must find a happy middle ground between simplification and details.
Guideline: Simple games run faster. Detailed games provide more freedom, more player options. Both can be engaging and depend on tastes and circumstance. Overdoing it to either extreme can ruin player engagement.
For example, in my game we track development days. A developer can perform one "action" a day and only one. This made the game flow quickly but created strange "wait, can't I just do both things?" moments. In our case, we found the simplification was worth it.
The simulation should follow the process
Write down your process as a set of rules or a flow chart. You will need that as printed handouts. Make sure your participants are actually familiar with it and the game's rules.
The simulation includes three important aspects
Time, Tasks management and Code Version Control. These three aspects were tracked on a large (er ... huge) white board as a Calendar, a Kanban board and a VCS visualization graph, respectively.
The Calendar tracked development days. The Kanban tracked the progress of stories (sticky notes). The graph tracked how our code commits interacted with each other and with our automation system.
The simulation needs a random factor
Whoever it was that said that computer science is an exact science never used a computer. Life is funny in software development. That tiny task turns into a monstrous system change and the huge terrible feature turns out to be not that bad.
The simulation should make the actual coding completely abstract, to focus on the process. This means that to simulate failure and development surprises you need a random device - a die, a deck of cards, a coin...
That said, make failure represent progress. A task that wasn't completed in one day, as originally estimated, has a higher chance of being completed on the next day. That is because the first day isn't wasted - the developer did work and that investment is not lost, it just was not enough.
Open a discussion after you are done
In the game, you are the host. You run the show. Do not stop to discuss the game rules or the process during the game. Just see how it rolls.
If things don't turn out the way one party wanted it to, try it some other way in the next turn. Keep the feedback and non-gaming discourse to the end of the session. Then have the (very important) feedback discussion.
The simulation must include player participation
If you (the game's host) are running everything in the game, you leave no room for participant engagement. Leave as much of the activities as you can to the participants.
They should roll the dice (draw the card, flip the coin...). They should move stories on the board, they should write their commits on the graph... Enjoy the show. You can now sit back and relax.
You run everything the players do not
What are you doing?! No time for relaxing!
It is up to the host to adjudicate edge cases in the game. Introduce surprises (oh no! production hotfix!) and run automated (non-player) processes such as Integration Testing and the like.
For example, in our process, there was a chance that Integration Testing failed and a bug would be added to the board. It is the host's job to roll the dice in this case and do the work on the board.
You, the host, also enjoy the bird's eye view of the process and its integration points with other processes. It could be useful to bring in another observer that can add more insight into what worked and what didn't.
Keep your game mechanics uniform
By that I mean that if a die roll determines success in a few different possible actions, make the calculations simple and uniform for all tasks.
For example, if action A succeeds if you roll the die and it comes up with a number which is greater or equal to some other number - make all other rolls behave this same way. Try to make all calculations behave in the same way always. This will reduce confusion and keep the players focused on the process as it is described instead of getting bogged down by minutia and rules.
Do not be afraid
This is your chance to go crazy in a safe environment. If something's not ticking well in your process, or seems redundant or incorrect, try to change it or remove it. Don't worry about keeping the "Story" of the game completely logical and uniform.
That said, try to constrain yourself to single, small changes. Otherwise, your players will get confused and engagement will deteriorate.
Vanquish your evil wizard, just don't call it a game
D&D, role playing and board games are all pastimes I enjoy. However, not everyone can accept those as legitimate tools for the workplace. In my society, games and other such frivolities are not proper pursuits for an adult (Adult. HA! If only they knew). Some may even accuse you of making a mockery of the whole thing - as if that wasn't the whole point.
Call it a simulation. Call the dice a Random Number Generator. Call the horse a zebra. It doesn't really matter what they call it, as long as it works. Then, when it does work, you get to call it whatever you want.
Together, the group beats the odds
In the end, this is a cooperative game. The rival here is the Evil Wizard or your local Dragon, not other teams or even the bugs and challenges that are "defeated". The group wins if the process works correctly. The satisfaction of victory will be added to a shared feeling of security and trust in the new process.
That, after all, is our ultimate goal.
Good luck, have fun and may your rolls always come up 20.