Yesterday we ran a public version of The Phoenix Project Game to give a bunch of people a feel for how it works and the kind of outcomes they could expect when they run the game with their own teams. If you missed this one but it sounds like something you want to do, we have another one in October; you can register yourself on it here but be warned - the last one booked out super-quick!
It was during the final round when the lead engineer and IT support roles gleefully announced: "We're sharing!" that I had a flash of inspiration on how to write this post about the outcomes of the game. The game is experiential learning; in a simulated environment it teaches us key DevOps principles based on the book of the same name. I'm going to use the well-known DevOps CALMS elevator acronym to explain how those learnings play out as outcomes in the game.
We know that this nebulous thing we call culture is the sum of the values, habits and behaviours of the humans in a given system or organisation, and we know that we can't change culture but we can change behaviours. We can describe and quantify the behaviours that we would classify as DevOps and we see them being learned in the game. The kind of outcomes we see are:
- Appreciation of and improvement in the capability to collaborate: just the action of getting up and going to talk to somebody else with the intention of understanding their goals and how they align to yours and how together you can help each other to achieve them sounds so basic, but you'd be surprised how often people need a nudge. I enjoyed one of the observer's comments as she walked past the IT test team and change management desks to find them empty because the players had gone to investigate other parts of the organisation, that that never happens in real life! But it should.
- Something interesting happened in this game that taught us a lot about autonomy: as the team began to collaborate better they tried to centralise the coordination of the tasks and the leaders of this exercise took the cards they thought were needed to complete the work from the teams' workstations. This was chaotic and unreliable. Not to mention wasteful as there were then resources unutilised. This was not the group's best round but once they granted autonomy to the individuals to self organise and plan their own work as part of the group's overall goals there was significant improvement.
- The importance of transformational leadership is learned as the game starts in chaos because there is no process. As the game progresses, the team start to build their process and this works best when they base their process on the flow of work. We don't tell people they are going to be a leader in the game, but there are roles that are more easily identifiable as those who can take the lead to create the process. And we give them some tools as clues. It's hard for a bunch of strangers who have literally just met to take on these leadership roles and it's interesting to see how this plays out in a public game versus a private game where leadership hierarchies are already embedded into the teams. You can read more about transformational leadership and its correlation with DevOps and high performing IT organisations in this year's State of DevOps Report.
- In DevOps parlance we embrace courage and encourage experimentation and failure as a learning opportunity. The game surfaces lots of opportunities to try to manage work in different ways and, in true DevOps style, we take the time to reflect on what we have done with a retrospective session at the end of each round, we collect the improvement opportunities from the team and plan the experiments for the next round.
- To be successful in the game you must focus on the business goals set by the CEO and how, as a team, you can deliver the best value outcomes. We encourage all organisations we work with to focus on value outcomes at all times and think about the cycle from idea to value realisation; how to measure it and optimise it.
- One of the ways to optimise the flow from idea to value realisation is to remove a common constraint around testing and in the game one of the outcomes is the learning of the importance of testing: doing it as early and as frequently as possible (underpinning all that we do in DevOps is the concept of little and often, or small batch, reducing risk and amplifying our feedback loops thus building quality in, constantly).
- So often we speak with people who are consistently challenged with having conversations with 'the business' about making improvements in IT that will require them to take time and resource away from the innovation and change team. Whether they want to take time to build a deployment automation engine, automate a bunch of tests, learn Test Driven Development, so often we hear: "We can't find the time to save time". In the game we learn why we sometimes need to throttle change in order to make improvements that improve our capacity downstream.
- The game helps us focus on the flow of idea to value realisation and facilitates discussions on how to do that using the tools we have at our disposal. For example, how we might tie our product backlog to an application performance monitoring capability that could tell us if that user story we wrote, now that the feature has gone live, is delivering the value we hypothesised it would.
One of the biggest lightbulb moments in the game is when the team recognises the fundamental need to visually collaborate. Without using some sort of tool to help the team understand, together, in real time, what the flow of work looks like in order to see the constraints and make decision about priorities it's really very hard to get stuff done. Just like in real life. And when issues occur and incidents happen, which they invariably do, it's really hard to respond in a timely manner. Unfortunately we created quite a lot of waste in this game when we accidentally wrote on a white board in permanent marker on a board and had to spend some time cleaning it up. The learning? These things do happen, as a team, we fixed it, rearranged our resources whilst we resolved the problem and kept the work going and found a workaround whilst that part of the board was unavailable. And removed the waste thus improving the ongoing flow.
We also get to see very quickly how the business can sometimes request too much work without an appreciation for the downstream impact and constraints and how poor prioritisation and understanding of the whole system causes waste and confusion.
At the end of each round in the game we measure performance against revenue and share price goals. We spend a lot of time talking with people about what are the real metrics that matter in the context in DevOps and what the business really cares about (and most people agree that if IT isn't the business today and their organisation isn't a technology company yet, then that's where they want to and need to be). The business doesn't really care about uptime or quality - they would love to be able to assume that a system's always up and it does what it should do. What they care about is the value outcomes being delivered and the game keeps us focussed on this and the impact of the decisions we make around the work that we do and how we do it. This facilitates discussion around that DevOps loop - measuring from idea to value realisation as described earlier. It teaches us about the importance of having our business people properly involved in product owner roles, writing value into the user stories in our product backlogs, measuring the outcomes and using those feedback loops to help us plan and measure the success or failure of our next experiments.
This one brings me back to the start and the gleeful comment: 'We're sharing!". We learn about the importance of knowledge sharing and cross skilling in the game. We have opportunities to do it and, if we don't, it severely impacts on our capacity. Sharing knowledge breaks constraints. Breaking constraints improves flow. Improving flow means delivering more value outcomes faster.
As a final thought, I'm going to leave you with a comment from one of the participants, Kev McCabe from Hermes:
“Playing The Phoenix Project Game as an observer allowed me to see the benefits that playing the simulation of a real world IT development function with people who don’t normally see the pain they cause with their requests. They start to feel the pain also and to ask the questions that wouldn’t normally ask when they play a role outside of their daily life. The Ranger4 Team made everyone feel welcome and made the whole day fly by. Just watch out for the game master throwing in the curve ball issues just like everyday life in IT.”