Ranger4 DevOps Blog

Tales from The Phoenix Project Game Taster

Posted by Helen Beal on Wed, Sep 7, 2016 @ 11:09 am

On Monday this week we ran another The Phoenix Project Game Taster session in London. We did a half day session this time in order to make it easier for people to take time out of their day and had twelve attendees (perfect!) from a variety of banks, insurance companies, building societies and charities. It was in some ways a slightly nerve-wracking approach in that the danger was that we would only be able to run two of the four rounds of the game so people would leave at the point where they reach the 'slough of despond' having not played all the way through to the end where all the dots are connected and all of the loops closed. I'm pleased to report that it wasn't a disaster by any means and people understood plenty about where the game was going in order to be able to imagine what would happen next and were happy about being able to get back to their desks in the afternoon.

At Ranger4, we practice what we preach and continually improve our products, tools and services so, in addition to being a great sales tool, these taster sessions are an ideal opportunity for us to receive feedback on the game experience from a variety of individuals and organisations. Here's what we learned this time around:

Visualisation

We know that a key turning point in the game is when the team realise they need to set up a central space where they can all see the WIP and collaborate to prioritise the backlog. In this taster session we gave a firm steer in this direction - when we're playing the game 'for real' we prefer to wait for someone in the team to realise this is what's needed and set it up. Typically it's one of the key change leaders, perhaps someone who already uses Scrum or Kanban extensively to do this. It's usually the same person who was the first person to walk around the room to look at other people's cards and ask them about their role and workload. And often it's also this person who initiates stand ups or townhalls. In the second reflection it was observed that this would work even better if they coordinated this effort i.e. agreed to do 5 minutes at the start, go back to their desks for 10, back for 5 etc which was an improvement the team would have implemented in Round 3 had we been playing it. I think we're seeing a pattern here in that the change leader can feel more or less empowered to initiate these activities depending on what role they are given to play - for example, a player feels they have more authority if they are playing the Head of IT Operations role than the Lead Engineer role. I think we should continue to challenge this since in devops what we are often trying to do is distribute authority and promote autonomy, mastery and purpose.

Victimisation

We delivered the game with our partner, OpenLimits, with Nigel playing the role of CEO/CIO and Games Master, and Philippa running the reflections. Since a primary purpose of the game is to surface cultural tensions which inhibit the consumption and proliferation of devops principles, we spend a good deal of time looking at behaviours and asking people to describe how they feel while they are playing the game. After the initial round, there is often a temptation we observe for people to say: "I wasn't told this", "nobody helped me with this" and generally not take accountability for figuring out what to do next. I discussed this with Philippa as, broadly, I feel you may be able to categorise people into two types: those who have the 'do' attitude and those who have the 'done to me' attitude. Philippa pointed out that although this could be true to come extent, a person's passivity or willingness to step up, figure it out, make it happen, could vary according to where they are in their career, what their current work situation is like or even what they feel like in that moment. I think we both agree though that it can be a learned behaviour - to feel empowered, and, again, the promotion of autonomy is a key part of devops culture.

Business Led Change

One of the key pieces of feedback we had from the majority of players in the game is that they want to feel like they are spending less time figuring out HOW to play the game and more time actually playing it. We have a number of actions we'll implement in the next iteration to try and address this concern, namely:

  • A 'Top Tips' part of the briefing (e.g. most of the players can ignore the numbers on the cards that as facilitators we use to set up the game and score, explain what 'implement change' means for the Change Management section)
  • More time to be spent examining the types of cards on the table and reviewing them with the team
  • A follow up conversation I had yesterday with one of the players, who has booked a full day's game for his organisation, was that one of the things he most enjoyed was the feeling of empathy he had for the role he was playing (Head of Retail Operations - Sarah in the book). He and I agreed that for his game, we would assign the roles a couple of days before the event and I will spend 15 minutes on the phone with each player before game day helping them get into character and prepare for the game - I'm really looking forward to seeing the impact this will have on game day

One suggestion we had from a player was that they would like to have instructions on how to start the game. Although we want to make it as easy as possible for people to play the game, this one I feel strongly we shouldn't do as this is a key part of the learning and brings me back to the heading of this section - business led change. The game begins when the business section communicate to the rest of the room what the project is that they are working on - that's something they need to work out for themselves.

It's a fine balance here between giving the players everything they need to know to play the game and pre-empting the things the game is designed to help them learn.

In conclusion, the players liked the game very much, got it enough in half a day to see the value for their own organisations and gave us great feedback to help us make their games as successful as possible in driving change. Another piece of feedback we had is that not all organisations can imagine getting 12 of their own employees to be able to commit to a full day but could see that if they could bring along a handful of their colleagues to a public, paid game like the taster, they could make this work and it would be a very useful experience. I'm off on holiday for a couple of weeks to volunteer for a turtle conservation charity but this is top of my list for when I return. Stay tuned!

Topics: DevOps Game, The Phoenix Project, The Phoenix Project Game