Gamifying Agility at Trainline

As the Agile Coach across the Trainline Group, where we have enjoyed a rapidly expanding tech contingent, I have had to put my mind to devising ways in which I can quickly assess the agility of individual teams.

It is also important to ensure a common culture and common understanding. If you have been in tech for any length of time at all, you will be well aware of the fact that “Agile” means different things to different people. To some extent, this is OK. My own natural inclination is not to be too prescriptive, and this is part of the strength of Agile principles. However, experience has shown me that this can often lead to a kind of entropy — an “anything goes” approach which, once adopted at an individual level, leads to the disintegration of a team in all but name.

If this is an extreme of going to the particular — where every person’s “Agile” is his/her own snowflake, different to everyone else — the knee-jerk response is to reach for the opposite extreme of over-generalisation. And we quickly see this breaking down because each team does have its own specific needs.

You’re probably aware of your own personal preference: do you tend towards the general or the particular? I take the view that the general and the particular constitute a yin-yang relationship: a balance has to be found and you are probably always in a state of trying to find that equilibrium between the two.

The general and the particular constitute a yin-yang relationship

How can I assess the agility of a team?

So, back to my original question: how can I assess the agility of a team? What general criteria can I use to do this at scale (the general) whilst honouring the specific characteristics of each team? (the particular)

STEP 1: Create an Agile Community of Excellence

A few months back, I formed an Agile Community of Excellence (ACE). Since the rapid expansion of tech here, the Development Manager in each team, who had previously taken on the Scrum Master role, is now a little further away from the day-to-day activities. Some teams already had someone else who fell naturally into this role, others not. What I wanted was an Agile point of contact in each team who would help share best practices from around the company. This needed to be someone with a similar geeky interest as me in process, coaching and facilitation :-)

This idea of a community formed to share best practices for a particular function is based on the famous “Spotify model” — so a Trainline community is analogous to a Spotify guild or chapter.

STEP 2: Brainstorm what we mean by Agility

I ran a couple of workshops with the Agile Community to define what we meant by Agility. I could, of course, have come up with my own list, but by working together with people from across all teams, the intention was that we could come up with generalisations which were genuinely valid for everyone.

First, we brainstormed all the elements which could be considered important for agility — lots of buzz words and phrases flooded out, for example: working in short iterations, delivering early and often, small cross-functional teams, daily stand-ups, customer focused, estimation, user stories, quality, face-to-face conversations, retros, planning, sprints, showcases, Scrum, Kanban, WIP (work in process/progress) limits, pairing, unit tests, TDD, BDD, XP, automation and so on and so on.

STEP 3: Abstract a generalised list of Agile criteria

The next exercise was to theme all these elements into a concise set of dimensions of Agility — I wanted to be able to reach a point where anyone could assess the agility of a team based on a standard set of dimensions. Here is the list we came up with, with a brief guide of what these refer to:

Trainline Dimensions of Agility version 1

Dimension of AgilityExamples1Team Coherencehuman-sized team, cross-functional, everyone trusts each other, team delivery over individual delivery2Delivering Incremental Valuevalue released into production on a regular basis, internal and external customers are happy3Qualitygood test coverage, pairing, code reviews, good monitoring, attention paid to performance and security4Smooth Workfloweach item of work flows smoothly and predictably from start to finish, team capacity is clear and workflow is managed accordingly through sprint cycles or WIP limits5Communicationwhat a team is working on is transparent and easy for anyone to see without too much struggle, customers and stakeholders know how to contact you and how to request things of you, people know who you are and what you deal with, you share knowledge outside of the team in various ways, showcases, tech talks, blog posts, etc6Kaizen: Continuous Improvementyou have a process to improve your process, you regularly reflect on how you work and ways in which it can be optimised

STEP 4: Gamification!

Once we had come up with some criteria which everyone could buy into, I wanted to make it fun to carry out “assessments”. Cue GAMIFICATION. For those of you who are not familiar with this, Gamification can be defined as the application of the mechanisms of games to typically non-game contexts to motivate people to do them due to them being more enjoyable. It is a fascinating area to get into!

Some object to the concept because it is somehow deceptive or incentivising the wrong thing. Others argue that if it is motivating you to do something good, then shouldn’t you be doing it anyway?

Well, perhaps. On the other hand, these arguments suggest that the absence of gamification implies the absence of deception / incorrect incentives etc. This is not the case. I prefer to take on board the words of expert game designer, and author of Reality is Broken and Super Better, Jane McGonigal: “The opposite of play isn’t work, it’s depression”

When we are highly engaged in an activity, it ceases to feel like work and it takes on more and more characteristics of a game: clear focus towards a goal, clear feedback on progress, the feeling that you are participating as an end in itself. For example, I much prefer playing a sport such as football, rather than running on a treadmill … and I frankly don’t care if football is deceiving me into keeping fit!

Anyway, I digress — this post is not a debate of the pros and cons of gamification. If you are intrigued by the concept, I urge you to find out more.

STEP 5: Design the game

Back to the Agile Community. These guys have been great at getting this stuff going, I have to say! We came up with the idea of teams earning badges for demonstrating that, in their respective teams, they were carrying out activities which contributed to one of the 6 “official” dimensions of agility. For example, if your team had a retro, this would earn you a Kaizen Badge. If you completed everything you intended to in a sprint, you’d get a Workflow Badge, if you delivered something of key value into production, you’d get the Value Badge, for a Team Badge you may have had a team lunch. And so on.

STEP 6: Name the game

Our Agility game needed a good name. Again, I could have come up with a name myself but, left to my own devices, there’s no telling what kind of horror could have emerged. Better instead to leverage the now famous Agile Community of Excellence, who I now trust with my life, and hence with coming up with a great name.

Just for fun, and also to understand the wisdom of me asking others to come up with the name, here is my (cringeworthy) brainstorm list :-)

• Agilify
• Cunning and Agile (instead of “cunning and guile”)
• The Way of the Agilista
• Crouching Coach Hidden Agenda (instead of “Crouching Tiger Hidden Dragon”)
• Agilistix
• SuperkaliAgilisticExpialidocious
• TeamHealth
• Five a day … plus another one (would have worked if we had come up with 5 dimensions of Agility, not 6)
• (I just dropped in to see) what condition my condition is in
• Good shape
• Fighting fit
• Hearty and Hale
• Lean Team Agile Machine

Luckily, by putting it out to the Agile Community of Excellence, we came up with the very Zeitgeisty:

AGIMON GO

What a great name! At least, that’s what we thought anyway (“sobre gustos, no hay nada escrito” … “there’s no accounting for taste”)

STEP 7: Create a tool for the game

We needed to store the data somewhere quickly and easily. To do this, we leveraged existing tools: Jira and Jello. Jira, or “JIRA” (Atlassian prefers to use uppercase, for some reason, as if JIRA were an acronym, which it is not) is our standard, company-wide backlog management tool and Jello is a thin client which I created and uses the JIRA REST API to present JIRA data in ways which are not supported by JIRA itself or by any of the JIRA gadgets out there. Believe me, I’ve done the research. The amount of times I’ve heard: “oh there’s a JIRA gadget that does that” is equal to the number of times I have tried a gadget which failed miserably. But anyway, once you get the hang of what JIRA can and can’t do, and become more accepting of its limitations, your life becomes more peaceful …

So anyway, here are the steps to creating our gamification tool using JIRA:

1. create a JIRA project called Agimon Go
2. create some custom JIRA issue types (the basic unit of work in JIRA) to be used as badges for each of the six dimensions: Team Badge, Value Badge, Quality Badge, Workflow Badge, Comms Badge, Kaizen Badge

Agimon Go JIRA Issue Types

1. create a custom image for each badge — again, use the Agile Community for this one — here are the images they came up with
2. create custom JIRA workflow statuses: Game On, Awaiting Thumbs Up, Woohoo

Agimon Go JIRA Workflow

1. create an Epic issue type to represent each Agile team — an Epic in JIRA acts as a bucket to put other issue types in
2. create a JIRA Agile Kanban board with swimlanes grouped by Epic to administer the game
3. teams claim a badge by creating a JIRA issue with the relevant issue type badge, adding a brief summary and assigning it to the Epic for their team; the workflow status at this point is “Game On”
4. add some description about what was achieved, then move the badge to the “Awaiting Thumbs Up” status. This notifies me to take a look and to approve or not
5. once approved, the badge gets counted — workflow status = “Woohoo”
6. create custom web page which queries the JIRA REST API and outputs a lovely board showing all the teams and their badges for the month (filter on status = “Woohoo”)

Agimon Go JIRA data displayed on a Jello Dashboard

If you are interested in using JIRA in similarly weird and wonderful ways, give me a shout!

STEP 8: Launch the game

We ran Agimon Go for the first time in January. In the first month, I was quite permissive about approving badges. What mattered most was engagement in the game. Some teams found it easier than others to be able to articulate clearly in what way their activities contributed towards a dimension of Agility. And this was great! This is exactly the purpose of the game: to encourage teams to reflect on their activities and work towards streamlining them in order to focus on the things that we decided were important in terms of agility! I also noticed a surge in team lunches :-)

STEP 9: A prize for the winner!

The team who achieved the most badges was awarded a team lunch! Congratulations!!!!!

STEP 10: The second month

In the second month, I wanted to raise the bar slightly. So, while in January, I pretty much approved anything, in February, I added comments in the JIRA ticket asking for further details or asking some questions. An important point here was to base the raising of the bar on a team-by-team basis. As much as possible, I wanted to encourage incremental improvement for each team. So it was about each team improving on its own performance from the previous month.

STEP 11: The third iteration

In March, I have again evolved the rules. In January and February, it was basically 1 point for 1 badge, but in March I am awarding a range of points per badge based on the “richness” of the badge. To take a simple example, running a retro may give you 1 point, but having some clear actions out of it may get you 2 points, while demonstrating the carrying out of those actions would get 3 points, and so on.

STEP 12: Objectives

The Agile Community members now need their Agile efforts reflected in their objectives. So, we have come up with the idea of having the objective

“Be a great Scrum Master”

And the measure for this is the team’s performance in Agimon Go. If the team you are the Scrum Master for regularly scores well month after month, then this is a sure sign that you are doing what you need to do as a Scrum Master and that the team is healthy!

The Future

It is still early days for Agimon Go and I am certain that it will continue to evolve. Whether it is the structure of the game or whether we decide to adjust the dimensions of Agility, we are ready to improve it month by month. Let’s see how it goes!

About the Author

Haran Rasalingam is the Trainline Group Agile Coach. A linguist, a psychotherapist and JIRA hacker, who veers between playing chess and doing stand-up comedy, he also loves all things Agile, of course, and is passionate about unlocking the potential of individuals and creating truly engaged, motivated and happy teams.