The Phoenix Project Simulation (DevOps) at SPOC

Not to spoil the game itself, the team in the simulation is expected to increase income of the company (thus, share price) after a market failure. They have 4 rounds (months) to achieve that.

Each round consists of 4 stages: Plan, Do, Reflection, Preparation (sounds familiar? PDCA cycles). Apart from me being a CEO in the game, I was also an instructor and teacher. I let the team invent their own solutions on how to cope with increasing challenges they experience and afterwards explain them that they have just reached a conclusion being a known DevOps practice. My role is to share with them broader context behind each practice which, hopefully, reinforces their learning experience.

Let's move to the record of the game divided by rounds.

ROUND 1:

Observations:

• Team working in 5 subgroups (silos) communicating a little between each other. Everyone is focused on their piece of work having limited responsibility for the overall process.
• VP of IT operations (in red t-shirt with black sleeves) is a leader who acts as a controller and coordinator. By walking around he creates communication ‘paths’ between silos. Sometimes, he orders people what they should do and they accept it with no hesitation.
• A person in green t-shirt is responsible for change management and seems to have a lot of spare time since he did his job in the round. He could have helped other people who seemed to be very occupied in figuring out what they should do.
• No process is visible whatsoever. There is more improvisation than structured work.
• (not seen in the movie) Team had a problem in deciding what they should do first which resulted in a fairly random decision on what should be delivered to production.

Conclusions from retrospective:

• The team identified a bottleneck at one of the roles
• The team started to share knowledge between roles to eliminate silos and reduce possible bottlenecks in future (capacity is distributed more evenly within the team). A cross-functional team is born.
• The team started to understand that flow optimization (value needs to travel through the system as fast as possible) is more important than resources optimization (everyone needs to be fully occupied at any given point in time)
• QA was verifying work once it was done - it is a very long feedback loop not protecting against waste connected with doing useless or irrelevant things. They decided to introduce QA before actual work is started to collect feedback from them if all relevant things will be done with no overproduction (so called ‘moving quality to the left’).

Business outcome: the round ended with a loss of money (and, consequently, lower share price). Failure.

ROUND 2:

Observations:

• Work began to be visualized on a table
• Business team (3 people sitting/standing at a table on the right) started to prioritize features/projects and hand them over to engineering team (one can see a Human Resources manager walking from their table to the engineering table)
• VP of IT Operations is still the driver of work - he asks questions about who is doing what, announces bugs on production and gathers people to solve them
• (not seen in the movie) Amount of unplanned work significantly increased (eg. bugs on production) and the team had a tough moment at the very end of the sprint on what should be delivered to production. Lack of spare capacity of the team induced significant chaos.

Conclusions from retrospective:

• Improvement of the visualization tool to understand the process better and make better decisions - the team moved from a table to a whiteboard with more detailed information
• Apart from feedback loop from QA to other engineers, there needs to be another feedback loop: estimates from engineering team should help business people make final decision about priorities. Otherwise, the risk is high that nothing will be done if the most important thing is too big to be delivered in one round

Business outcome: major increase in income (and share price) due to relevant work done and reducing costs.

ROUND 3:

Observations:

• Due to continuous improvement the team becomes more autonomous and less dependant on the leader (VP of IT Operations). They are able to coordinate and control themselves - the role of leadership changes (!)
• All people are involved in optimizing flow and not their work locally
• Large projects were split into smaller batches of work which helped the team to deliver value to production more frequently (and earn money earlier!)
• Number of interactions and their frequency increased
• The team did not plan their work up to their full capacity. Slack time helped them to deal with unplanned work.

Conclusions from retrospective:

• Continuous improvement helps the team gradually achieve better business results
• Visualization tool can be further improved

Business outcome: still increase in income (and share price) due to better focus on generates highest income (short-term and long-term)

ROUND 4:

Observations:

• The value stream is physically visible (people sitting at their desks, doing their job but also ready to help someone if there is a bottleneck) - clear overview of end-to-end process.
• The amount of chaos is reduced to minimum
• Team members agreed that the comfort and joy of work was higher in this round than before (less firefighting)
• Planned and unplanned work is managed smoothly
• Team could operate without VP of IT Operations who could devote more of his time to strategic initiatives instead of the operating ones.

Business outcomes: eventually, the team managed to achieve the desirable income and share price.

I know it sounds too happy to be true but the team has actually made it. However, the simulation is not about winning the game after all. It’s about what the team has learnt in a safe-to-fail environment. The key takeaways outlined by the team were:

There were things which we didn't manage to experience: reducing WIP limit to increase flow, true conflict between Development and Operations resulting from different goals, importance of culture aspects (smart failures, blameless attitude, transparency). It was not a problem, though, as every game is different and different aspects of DevOps become more visible.

If you ever considered learning what DevOps is I have a tip for you based on feedback I get as a trainer and consultant helping organizations to adopt DevOps. If I had 1 day, I would take part in The Phoenix Project simulation game. If I had 2 days, I would participate in the game and 1 day training of DevOps basics ("DevOps Experience” training). If I had 3 days, I would take part in DASA DevOps Fundamentals course (and, optionally, take the exam). In a perfect world, if I had 4 days to devote, I would take The Phoenix Project simulation game and then the DASA DevOps Fundamentals course.

At the very end of this article, I would like to thank the team at SPOC for having me at their office. It was a great pleasure to work with you and see how you self-organize towards achieving better business results in the game. It doesn’t happen always and there were teams in the past who failed. According to me, the training was a success, as it was you who invented most of the DevOps practices as a way of dealing with challenges. I just helped you name them and gave you broader context to help you understand why it works. I also learned a lot when working with you.