Gameification - How would you gameify work in an Agile team?

Question

During a recent open session at RallyON 2011 we talked about paradoxes in Agile. One of the items that came up during the conversation is when a high-performing team becomes so well greased that all the "agile-ness" has been sucked from the process. When introducing NEW change to the well-oiled Scrum team, they balk because things are going so well...

A way to keep learning going, we talked briefly about "gameification of work" in an Agile team. Has anyone done this before? What are ways to keep an Agile team fresh?

Answer 1

A while ago I asked a quite related question. I received small but worthy feedback and also an overall feeling that maybe there is nobody here who actually tried it (or there is a silent one). So I am glad you asked "how would I...", not "how did I..".

I would:

1. Make a list of things you want to achieve. What does it mean to keep the team "fresh"? If there is practice or behaviour you want your team to introduce (or keep using), put it on the list. In order to bring it to mind, you can think of your process and every activity being taken. It helps to remind what are your thoughts about it (for example: daily meeting and what you want to change about it).
2. Make a list of rules or "boundary conditions". For example: "achievements should be clearly visible to anyone" or "gamification should not make the work worse for people who do not feel they like to participate" or "game elements should be interesting even for new team members". Remember about the rules and stick to them while designing the concept.
3. Consult the idea with the teams. They will probably come with new ideas for things they want to achieve (#1) and rules (#2). You can also get the feedback about your ideas and concepts (badges, XP's, levels, rewards etc.) that are already on your mind after creating #1 and #2.
4. Design the solution. Yeah, I know, it is easy to say. But it's too complex problem to describe it here. It's probably too complex even for a book, and yes, I don't fully get it either. It's not much, but here are some links: Gabe Zichermann talk and presentation he shows, and much more resources.
5. Try to hack the system. People like to take shortcuts and like to make achievements. The question is what will happen when they try to maximize their XP and will think only about game achievements not the real life ones. Ask the team how would they hack the system? Make necessary modifications and you are ready to try it...

It's my vision on how to make gamification work (very short version), although I am not sure if it helps keep your teams "fresh". There are many hidden pits one can fall into, as successful game design isn't easy.

Answer 2

Talking from theory, not practice, and just looking at the StackExchange sites in general, here's some random thoughts.

• +1 To @Bartosz
• Wear the Evil Hat
• Make it easy for new teams to get a bit of initial love from the game
• Make it progressively harder for experienced teams to get to the next level/badge, especially without changing how they work
• Be sure to build in things that help build relationships across teams, such as "new practice adopted by another team: +10 team rep"
• Make reputation entirely at the team level
• Only explicitly reward good behaviors. Perhaps create an annual or quarterly "bloopers" award.
• Don't forget to reward the minor acts that crate a good internal community (i.e. +2 rep for edits on SE)
• Pay enough attention to the ease of tracking things per team, so that you know you'll keep it going long enough to tweak and evolve the system.
• Let the teams help design it as a multi-team-building exercise... get everybody together on a Friday afternoon to brainstorm the system, create some buzz ahead of time, get people excited about it before it happens (and then follow through)
• Once you get a feel for the scope, create some org-wide reward events (rather than team rewards, let the "league table pride" handle that part). i.e. "If total reputation exceeds 10,000 in a quarter we cater an awesome dinner for everybody" or some such. (Did I mention the Evil hat?)

Answer 3

Most high-performing Agile teams have flexed and changed their own processes so much that they feel as if they own them (rightly so). Someone external to the team coming in and asking them to change again will meet resistance just because they're external to the team and don't share the team's context.

Instead of introducing the change, why not introduce the goal and let the team decide how to meet that goal? You didn't give examples of the changes, so here are some which I've met in the past:

• We've realised that only Ben knows XYZ technology, and we think this is risky. How can we reduce this risk?
• How can we make our deployments go more smoothly?
• How could we get them smooth enough to deploy every week?
• How can we help team B adopt the process you're doing so well?
• How can we get George on the team and up to speed quickly?

By getting the team involved in the solution you turn it into a problem for them to solve, rather than a change for them to adopt.

Also do the things which @Eric and @Bartosz mentioned. Since Eric's already mentioned the Evil Hat, I'll link to my other blog on gaming culture with Dreyfus modelling. This was for newcomers to Agile, but you can probably get some ideas for how to game experienced teams too.