Playing the Phoenix Project DevOps simulation game
GamingWorks, together with Quint Wellington Redwood, organized a DevOps workshop. A team got together to experience how the business simulation game, the Phoenix Project, could help support a DevOps initiative. Frederik Schukken (Managing Consultant at Quint & member of the DevOps Agile Skills Association) and Dominque van den Boom (Executive Manager at the Lean IT association) attended the session to explore how the simulation can be used to help engage employees and teams to create awareness, and to develop DevOps and Lean capabilities.
DevOps & People: Engaging for success
The State of DevOps report in 2015 confirmed ‘’…that there’s a lot more to IT performance than technical practices. In order to create sustained high performance, organizations need to invest just as much in their people and processes as they do in their technology”. The 2016 survey went on to stress the importance employee engagement for organizational success”.
The Phoenix Project DevOps Simulation
The Phoenix project simulation has been developed by GamingWorks, together with input from Industry experts. The simulation is based upon the book with the same name. Delegates play the roles of the ‘Parts Unlimited’ organization. At the start of the game financial performance is poor, the share price is low. They are being outperformed by their competitors. Survival is at stake! The business initiates an ambitious IT enabled turn-around program – ‘The Phoenix project’ – however the current IT capabilities also present a significant business risk. The team must demonstrate they can apply DevOps and Lean theory and principles to achieve the company goals. The CEO puts the team directly under pressure. The team objective: a large amount of new software features must be rapidly, and faultlessly deployed to increase revenue and improve share value….failure is not an option!
The preparation phase…
‘…we need a stand up meeting….’?
‘…who will take charge…’?
‘…how does work enter the system….’?
‘…what does the process look like…’?
‘…what does the business need…’?
…and then work enters the system.
‘…where did this come from? Who submitted this work request…’?
‘…where is the POS project? Who is working on it’?....
‘…what is this I just heard about a critical outage?....who is dealing with that’….
‘…what do I need to test?....how far are we’?....
‘…what is happening to my business project’?.....
Team observations after round 1
- unclear communication lines creating confusion, wasted time, duplicate effort, frustration.
- unclear roles and responsibilities, work was left undone, duplicate actions, assumptions being made.
- flow unclear, causing wasted time, unnecessary waiting, missing activities, missing dependencies
- unable to get a grip on the workload and unclear status of work in flow
- unclear decision making such as priorities when resource conflicts arise (unplanned vs planned work)
- KPI’s unclear
- no visibility to business about outcomes
- no visibility for IT manager to identify bottlenecks
- unclear flow of work for ‘projects’ vs ‘issues’
- unclear overview of the different types of work and how much was related to issues and unplanned work.
Round 2…continual improvement and learning
Scrum and Agile use terms such as retrospectives, Lean talks about KaiZan ‘change for the good’ the whole idea of continuous improvement is that it is unceasing and without end. ‘No boundary between improving the work and doing the work’. A critical capability for DevOps and agile working is the concept of ‘Continual learning and experimentation’. After the first game round the team explored some of the critical concepts of DevOps and of Lean, and agreed to apply some Lean tools and make some critical improvements.
- Visual management – a Kanban board was made to help visualize the work and the flow.
- Constraints were identified and countermeasures put in place.
- The value stream was identified and improved to create a smooth flow of work through the end-to-end team.
- Improved engagement with the business to obtain ‘feedback’ and the ‘Voice of the customer’ in prioritizing work and for breaking work into smaller components of MVP (Minimum Viable Product).
- At the end of the second round the team improved their internal KPI’s (amount of deployments, reduced rework, improved resolution), however there was still room for more improvement at the next iteration (game round).
A fool with a tool is still a fool
An interesting discussion arose around prioritizing improvements. Should the team first improve their people and process and then adopt fast deployment technologies? Or should they invest in the technology whilst there is still ineffective communication and collaboration – ‘a fool with a tool is still a fool’.
- From one of the participants who recently certified in the DevOps Fundamentals: “doing the game after the training adds real value. After lots of theory, exercises and discussions, the real message and value of DevOps really sinks in during the game. Most valuable!”
- From a customer organization attending: “I feel like being at work. All these things happing within the game are the same things going on in our organization…. Doing this together with your team to experiment with Lean/Agile/DevOps principles in a practical way is very effective”.
- The simulation clearly shows the importance of cross team communication and collaboration.
- The simulation helps people translate theory into practice….end-to-end.
- The simulation is a great way to engage with teams and employees to experiment and explore how DevOps principles can improve performance.
“The Phoenix Project game succeeds from the first minute to confront delegates with real life challenges faced by many IT organizations. It is also interesting to experience how easy it is to succumb to SILO working, failing to effectively communicate, collaborate and make agreements, Despite the fact that all delegates were doing their best to realize results. It was also powerful to see how significant performance improvement can be realized by applying simple DevOps principles and tools (visualization, prioritization with the customer, optimizing flow of work instead of optimizing resource utilization, cross functional teams etc). I would recommend this type of experiential learning to organizations wanting to develop DevOps awareness and capabilities”. Frederik Schukken, Quint/DASA “I was impressed by the pragmatic set up of the simulation, the way in which situations and dependencies are built into the scenario. The game shows in a practical way the potential next steps that delegates can make in developing their knowledge and capabilities: where are we missing knowledge around organization or communications? (such as Lean, ITIL, DevOps knowledge). Dominique van de Boom, LITA
Interested in the Phoenix Project DevOps simulation?