07 Feb The Phoenix Project
Over the last 2 weeks I had the opportunity to play the DevOps business simulation “The Phoenix Project “ with 3 corporate teams in India. Incidentally all of them had 2 days of DevOps Foundation course (DOI) followed by the experiential learning. This blog summarises the experience and feedback received from 2 teams going through the entire process of understanding the basics and fundamentals of DevOps and exercising practical implementation of DevOps using the Phoenix Project.
The First team had a combination of people from Dev, QA, Testing, Infrastructure Operations and Business. The roles were randomly picked from the Phoenix Project to simulate an actual DevOps environment of cross functional collaboration and self organised teams.
The Second team was completely from Infrastructure operations that had pretty much solid ITSM experience with minimum work with Dev and QA teams.
The teams were entrusted with the responsibility of yielding a revenue of 300k USD within 4 rounds and take the stock price of the company to 45. While the target milestones were clearly laid down at the beginning of game it was difficult for the teams to get hold of the situation due to various unknown parameters. It took them quite sometime to understand the different moving parts of flow, dependencies, business impact of projects, issues and features that came up in every round and make appropriate choices and decisions.
Round 1 Reflections
- a) Chaos and Confusion b) Over Collaboration ( Too much Engagement) c) Too much Interference from the Business d) Communication channels were not streamlined e) Requirements were not clear f) Flow could have been faster/better. g)The prepared Flow did not get executed well h)Managing Time was not done. i) Everyone was busy with their own work and absence of governance j) No Visualisation k) Lead Engineer became a bottleneck
The teams made some step changes every round to improve their overall efficiency and effectiveness in delivering business value.
Round 2 Reflections
- Lack of Visualisation. Oversight. One of the Issue did not get tracked to closure
- Rework due to inaccurate reading.
- Interdependency between teams was not handled. The Instruction within cards was overlooked
- Business did not invest on Fast deployment. They were busy managing IT without understanding their core responsibilities and deliverables
- Continuous Integration Issue – The defect was not detected earlier which invariably passed through downstream creating rework
- Communication and Collaboration issues were observed among the team members
- Testers were waiting for their task to be completed. [Waiting – Waste – Lean]
- Team attempted to do work of Round 3 which was not completed and resulted in rework – [ Over Production – Waste – Lean]
Reflections from Round 3
- Flow was better streamlined with identified SPOC from each team [DevOps First Way]
- Testing was available throughout [Continuous Integration and Continuous Delivery]
- Focus was more on Agility to deliver more projects and faster deployment that Issues were not resolved [ Balance between Agility & Stability]
- Business felt that the IT kept them in dark without any update/progress about deliverables
- Reprioritisation of Projects had to take place in order to deliver projects that produced maximum business value [Understand Business Impact of Projects ]
- It was clear that not all projects /issues can be resolved within the Time period. [Theory of Constraints]
Reflections from Round 4
- Business and IT collaboration was very effective.
- Business could report easily to CEO with the Metrics and KPIs tracked to produce business value
- IT was able to use the Financial Projections to decide the projects on priority and optimise business value
- Team became expert in completing projects on time with good collaboration, communication and integration. [ DevOps Definition & DevOps Third Way]
- Focus was given to solve pending issues and improve stability
The teams experienced significant learning, sharing and collaboration over the 4 rounds and had loads of fun. One common feedback from the teams were to insist on having this game mandatory after every 2 days DevOps foundation course.
Consolidated Summary of Feedback from both teams
The business simulation helped them to achieve the following objectives
- a) How to make everyone work towards a common goal [Collaboration]
- b) How to make each and everyone in the Self Organising team empowered? [Characteristics of DevOps team]
- c) There was visible difference in the maturity of the teams over the 4 rounds in adopting DevOps principles and practices
- d) The business impact of doing a project and not solving the issue was clear to make appropriate decisions
- e) It demonstrated clearly what is not DevOps [Exclusions and Myths]
- f) It gave a working knowledge on how ITSM and DevOps are complementing each other [ Change Management and Improved Flow]
- g) It gave a good understanding of how different roles and responsibilities in the organisation contribute to the overall success of the project.
- h) For the first time, we witnessed how to engage a meaningful dialogue between business and IT
- i) Several Myths about DevOps did get addressed while working towards the common business goal
- j) The Game demonstrated to get end-end visibility of the flow from requirements till satisfied customer/end business [Improved Flow – Way 1]
- k) It helped people to overcome the blame game and take collective ownership [ DevOps Culture]
- l) It moved the mindset from I to We during the progression of rounds [ DevOps Culture]
- m) There was a visible sense of involvement and collaboration between diversified teams. [Cross Functional Teams]
- n) Sharing of Knowledge was witnessed when the App Developer moved to Change Management and Vice- Versa [DevOps values]
- o) It demonstrated that it is not easy to build collaboration, communication and integration. It takes time and there is a lot of patience and team work needed to make this a reality. The DevOps Culture takes time and has to be nurtured through self organising team with mutual respect, sense of pride and collective ownership to work towards a common goal
- p) Breaking up of team in Silos were distinctly evident over the 4 rounds of the game [Goal of DevOps]
- q) This game demonstrated shared responsibility and collective ownership
- r) It allowed people to take in initiatives and empower [Agile – Self Organising teams]
- s) It removed clutter in the process, identified wastage and improved productivity [Lean & Value Stream]
- t) The speed of execution improved over the rounds using short feedback loops, continual improvement and applying lessons learnt from previous rounds.
- u) It demonstrated how leadership team`s involvement was important from both business and IT side. [ Organisational consideration of DevOps]
Finally the teams made over and above the required target of revenue and stock price. The winning moment was enhanced by the significant learning opportunity and ability to bond with diversified cross functional teams