I recently had an opportunity to observe the Phoenix Project Game in action at UCAS headquarters in Cheltenham. Here's what I saw!
During the Introduction I learned:
- A few players had heard of this thing we call DevOps and read The Phoenix Project book - neither is a pre-requisite to playing the game although it's useful to have a few in the room with awareness of the DevOps principles - that is what we are here to learn though!
- Many of the players played their own roles in the game - some customers like to do this, some like to mix it up I have noticed. I guess playing a role that isn't your own is an opportunity to build more understanding and empathy for the challenges our colleagues face, but the advantage of playing your own is to be able to directly apply learnings to your everyday life. I don't think it's possible to switch roles during the game though - I think that would inhibit the flow of learning.
In the First Round
At the start of the first round, the CEO (the Game Leader, in this case, Helen) sets the high level business goals for the game - there are two:
- Revenue target - $110,000
- Share price - $23.00
Teamwork was visible from the start with Application Development's and Change Management's curiosity in what other players had at their disposal. A clear hierarchy was demonstrated with Retail Operations, the CFO and Human Resources taking turns in leading group discussions. It was also good to see players discuss the round's business objectives and current live issues around VP of IT Operations & CISO tables.
Furthermore, something unusual for this stage of the round happened; all game cards were brought over to one desk, an excellent tactic for visualising and organising work.
- Better chain of command
- Double checking tasks
- Who should speak?
- Swarming - successful, but wasteful?
- Making sure everyone is aware of what's going on
- Getting business priorities first
- Better visibility
This round intoduced a Fast Development Tool at a cost of $10,000. There were great examples of work visualisation; writing business objectives on the board and discussing current projects & upcoming deliverables. This was built upon further by HR and CFO gathering everyone around the board.
We know that in business we have to consider using tools, resources and the value they could bring - this was clearly demonstrated in this round.
Reflection/changes for next round:
- Visibility for decisions
- Kanban (mark remaining and achieved work)
- Better order of resolution
- Some capacity was unused
- Create a process to follow when incidents happen
From the start of this round, players went back to gathering around Retail Operations and Human Resources tables with the purpose of evaluating capacities on live issues and what the outcomes would be from using different game cars. This was further emphasised by business forecast and planning.
There were further examples of work visualisation through:
A) A Kanban board
B) A capacity tracker ticklist for monitoring capacity levels in different departments
C) Use of a Kanban board
Further into the round, HR the CFO and Retail Operations went to IT Suppot and Lead Engineers for the first time. Players were implementing their improvements regarding double checking of work and not knowing what's happening - this happened for the first time.
The round was an improvement, players expanded capacity in both Change Management and Business. Full cross training across the organisation was achieved and IT Test team now felt more in control though, IT Operations felt there was a lot of capacity leftover.
Reflection/changes for next round:
- Communication was better, but still an issue
- There's still a lack of group discussions
- Need better capacity monitoring
Right at the start of the final round, players jumped into a discussion on how to use Kanban better and made someone from IT Test team in charge of it. There was now more evaluation on the games's current and future projects, apps and tasks. In addition, something not seen before was happening; HR was saying out loud how much time there was left until the end of each stage in the round. On the other hand, Business was missing capacity and Change Management were also under capacity, which other players weren't aware of.
This round finished with 7 minutes remaining and everyone was confident that they've finished everything.
Players had a 100% deployment rate and solved 100% of their issues. This was the best round so far and it should be mostly credited to the use of Kanban, continuous improvement and monitorization.
Feedback from observers:
Andrew Irving, Head of Service Assurance
Andrew's read The Phoenix Game book and mentioned that UCAS have been implementing Agile across the entire organisation for the last two years. He had to say the following:
"It is interesting to see how the format of the simulation works".
"It's not the typical work set for people".
"It's a timed simulation, which forces collaboration".
"The simulation helped to better understand what DevOps is."
The simulation helped to bring out collaboration and one of the main reasons for it as mentioned by Andrew, is the fact everything is timed - creating pressure, forcing prioritization of work and getting players to think outside the box. The aim of The Phoenix Project Game is to learn and experiment with DevOps practices and principles to improve teamwork and communication between IT developers and operations professionals and to bring out something that may be much harder to do/create using other ways - bringing a table to the middle of the room and placing game cards on it. In the case of UCAS, if not for The Phoenix Project Game, it might've taken the company months or years to realise that they were really missing something in their everyday work - this can also be applied to continuous improvement, bunawareness of what your colleagues are doing/working on, and having unoticed issues in collaboration and communication. Looking at the rounds of the game, major shifts can be spotted when looking at the business results of round 1,3 and 4. On the other hand, the game finished 7 minutes early with all players being confident in the completed work, which strongly paid off, as round 4 had the best results.
Ranger4 are DevOps evolution experts based in central London. Click the button below to enquire about your Phoenix Project Game: