I recently had the opportunity to act as an observer during a Phoenix Project Game at the Headquarters of The Royal Society for the Protection of Birds (RSPB) in Sandy. I've wanted to observe a Phoenix Project Game (TPP) for a while now and this was a the perfect opportunity to do so. On top of that, I got to see Sandy's beautiful surroundings.
What is the Phoenix Project Game?
The Phoenix Project Game is a one day business simulation based on the best selling novel of the same name by Gene Kim. It focuses on real life situations and problems that businesses face. Participants play one of the characters from the company in the book (Parts Unlimited), which makes each player a part of a department. Departments vary from Change Management to Application Development, Testing, IT Operations, HR, Finance, Retail Operations and Security.
The simulation plays across four rounds with each round focusing on a different topic. Each round has three stages; preparation, planning and doing. During the course of each round, there are projects that need to be completed with some having higher prioritires than others and major issues/errors being introduced by the CEO (played by the Gamesmaster). At the end of each round, the performance is scored on how close the players were to reaching each round's revenue target, what issues and projects have been completed or missed and the impact everything's had on the company's share price. In addition, a revenue loss figure is also generated. All of this is based on scores on the simulation cards. Furthermore, a group reflection takes place after the results of each round, which focuses on what's happened in the round and what improvements could be made next time.
The RSPB had their own observers in the game (this is best practice - there are 11 roles to play in the game and we recommend a further two or three observers who will have an active role in the reflections too).
Round 1: Flow, Visualisation and Process
Round 1 was about Flow, Visualisation and Process. Throughout it, I noticed that some people were finding it hard to decide what tasks or actions they shoud take on. One of the observers also said out loud that "It was a headache to be the lead developer". Hearing this, I instantly thought to myself: 'Why is that the case?' 'What silos are they facing?' 'What impact does this have on their daliy worklives and the business as a whole?'
Players were also looking to see where it would be best to use their work units. Work units are the number of points that each department has. For example, to install a certain piece of software, a company would have to use three work units. Players started to prioritise and a lot of them were curious about training other departments, with quite a few going over to the Application Development department. There were discussions in mini groups and communication was properly structured. At the end of the round, the IT Support department were asked if they knew about the website being down, which they didn't. This emphasised the communication problem even more.
At the end of Round 1, Part Limited's revenue increased by $8,000 from $100,000 to $108,000. A loss of $2,000 also incurred. Share price went up from $21.00 to $22.60.
Remember, DevOps isn't a tool or a team, is it a continuous learning process and it will only improve with practice. It's also important to point out that DevOps strongly encourages failure. Saying that, it looked like the Application Development department had developed applications which were outside of the user's requirements and could actually be classed as waste to lead engineers. On the other hand, anything done in that department is good. Lastly, players didn't know what tasks/work was going on and they were relevant.
During the first round's reflection, the following observations were made:
- Inefficient flow and lack of communication
- Lack of organisation
- Lack of leadership
- Players didn't know who to talk to
- Invisible support burden
- Use of boards for work visualisation has to be a priority
- Some of the completed work was wrong - was caused by systematic failures
- Communication was raw and it needs to be clearer
- There should be visualisation of company's current state
- The flow of work should be improved
- Visualisation of the current work in progress (WIP)
- A clear understanding of where issues introduced by the CEO or CIO should go
- Become more effective at work prioritisation
Round 2: Fast Deployment Tool
Fast Deployment Tools are DevOps tools and during the simulation, the business department only had the capacity for 12 work units. The tool itself costs £20,000 plus, additional time would need to be allocated for training. If the players chose to implement it, the number of work units would go up to 20 and this would also have an effect on Change Management's calendar.
From the start, I noticed departments informing each other regarding to who should be listened to first. IT Operations were now explaining what's on the project planning board, which brought up a whole new discussion. Also, the VP of IT operations was explaining what was on one of the boards (shown below), which brought up a joint group discussion.
The business department were now looking at revenue and share price targets and were prioritising which tasks and projects to take on (shown below).
The board on the left focuses on dividing tasks by departments and current live issues in the company. This is a big improvement from Round 1 as players are now able to see what tasks they are working on, to whom the tasks are allocated and the live issues in the company. On the other hand, the board on the right focuses on tasks and improvements the company should think about. Both boards demonstrated work visualisation, project management and change management in an effective way.
Further into the round, the business department now seemed to be focusing even more on targets and prioritising work to achieve to those targets. Players were now walking over to one another and asking if Change Management has heard about the the two payroll issues. This was really good as effective change management is key to DevOps. Also, the CFO let everyone know that he'd sacrifice the current month's revenue target to achieve the overall revenue target. Everyone seemed to agree with him.
During the 'doing stage' of the round, a new issue came up, which made printing of documents to be very slow. The issue was passed on to Human Resources. In addition, priorities were now being set depending on capacities.
At the end of Round 2, Part Limited's revenue increased by $7,000 to $115,000. There was a loss of $3,000. The share price increased from $22.60 to $22.40. Also, three of four issues were cleared and all projects were completed. This is quite an improvement from Round 1.
After the second round, the players came up with the following points:
- IT Test team was unreal on workload
- Capacity wasn't known overall between the IT Test team
- A visualusation board would help a lot (another element of DevOps)
- The team needs to agree on an approach to projects (methodology)
- There has to be a central facilitation point
- IT Test team has to fill in the cards and pass them around, whilst sticking to 1 card per item
- It would help if all cards were neatly organised on desks
- It would also help for all tasks and requirements to be kept underneath other cards
Most of the reflection now focussed on the IT Test team and a lot of the points refer to organisation and automation of work, which are core elements of DevOps.
Building more on the 'visualusation boards' point:
- Central facilitation
- Clearer priorities
- One project through process at a time (key)
- IT Test team to be clear on workload
- Shared knowledge of the overall available capacity
This was excellent, as the players were now focussed more and more on the organisation, automation and prioritisation of work.
Round 3: User Feedback - Agile Approach
The CIO suggested having somone responsible for operating for the boards and he demonstrated an example of a project/task completion board. As soon as this suggestion was brought up, the players implemented it.
At this point, the organisation and prioritisation was very good, completely different to Round 1. There were two boards based on project management (illustrated below).
The top part of the left board focused on projects/tasks, which were now split into different phases and departments whereas, the bottom part focused on live issues. On the other hand, the board on the right focused on projects as a whole, it llustrates project allocation to different apartments. It also contained the actual project game cards. Both of these boards enabled anyone from any department to easily see what is being worked on by whom, what's been completed and what needs to be finished.
At the end of Round 3, revenue increased by $24,000 to $139.000 (double the amount from last around). There was a loss of $16,000, the biggest so far. The share price increased to $26.85. Futhermore, it became clear that there was no effective approach in place to deal with urgent issues.
There was an additional person in charge of the visualisation improvement board and there were comments being made on it as to what was being completed, what has been achieved and what hasn't been done yet. The comments read:
- Identifying where problems occur from the development team
- Getting the data to make decisions
- Awareness of what the company is currently doing in Planning, not doing in the Doing stage
- Central facilitation
- Business making arbitrary decisions and as a result
- Clearer priorities
- One project through process at a time (players didn't do this)
- IT now had a better understanding of the workload
- Overall capacity was now better known
It's clear that the team has greatly improved from Round 1. Players now seemed to clearly understand their roles, what is required and expected from them. Itterative improvements were now visible in their work and were ticked off (unlike at the start of the simulation).
During the round, there were more comments made on the visualisation improvement board:
- Estimation flow of work has been structured
- An issue buster is needed for process problems
- People delivering value aren't interupting others anymore
- Process issues need to be captured during work (not at the end of projects)
- As a whole, everyone was much calmer
At the end of Round 4, revenue increased by a big amount - $79,000 to $218,000 - though, the game's overall target of $300,000 was missed. A loss of $56,000 also occurred. The share price rose to $35.16, which was the biggest increase so far, but was also short of the game's goal of $40. You may think that the game was a failure, but DevOps is all about failing, learning from it and trying again. Remember, the starting revenue sum in Round 1 was $100,000 and now it's double that! Furthermore, losses will also occur as DevOps requires learning and is a continuous process, meaning negative things will happen and learning from them is crucial if you want your people and company to grow.
At the end of simulation, there was a big discussion, where each player spoke individually on what they learned and thought about the simulation. Some of the comments included:
- Visibility of what and where in terms of workload
- Resource estimation practice - someone brought up the point that they could be better at calculating and figuring out their rescourses (their capacity and how much is required for projects)
- Limit WIP (work in progress) - don't start other stuff, even if it means waiting
- Start to implement Agile practices into the organisation ( I actaully remember one of the observers mentioning that they'll be doing Agile training a week after the simulation)
- Focusing on working as a team
- Empowerment among each other
- Brief others on the value that will be added on tasks and projects
- Have end objectives
- Analyse benefits and risks ( I think a SWOT or PESTLE analysis would be ideal here)
- Acting on lessons learned (very important)
- Improved business engagement with other departments
Feedback from observers:
- The daily work culture of RSPB was immediately apparent
- There was no ownership in work, people were all over the place and this was very clear throughout the whole round
- People went back to their old ways of working
- People started to take ownership of work and stood up. This was very interesting for them to see
- They've also noticed that certain people were moving cards without informing others about it
- IT Team said that everyone agreed to stick notes on the boards, but people didn't. As a result, they stood up and pointed this out to the group. This is more emhpasis on the point of speaking up
- Small iterative improvements were now being made consistently and game cards were being passed along to others
- There was mutual overlap on roles, but not too much of it
- The team overall was much more proactive
This was the first time that I had observed the simulation and I was very intrigued to see what happens when a team of work collegues switch their professional roles for one day, work together to complete certain projects, try to solve urgent issues and improve throughout the day. I was particularly interested in seeing how improvements were implemented in each round, as well as how and why some things were mentioned, but missed in the next round. It was also great to see certain players being in charge of visualisation of work, which added structure and a flow. I was just impressed with the structure of the simulation itself, as I was with the performance of the players. I strongly believe that businesses could greatly benefit from The Phoenix Project Game as we can all sometimes get cought up in the way we work individually and as a team, making little room for innovation and improvements in work approaches. At the end of the day, an enterprise will not survive without innovation, constant implementation of change and fosterting the grow of its employees, which is where DevOps can come in and help.