Playing The Phoenix Project DevOps business simulation game – a reflection by GamingWorks
Quint and Xebia organized a DevOps Masterclass conference in the Amsterdam Arena. The event was entitled ‘Better, faster, smarter with DevOps’. The growing strategic importance of IT and the pace of change require a transformation in the way IT is managed. IT organizations need to be ‘better, faster, smarter and safer. Many organizations are waking up to the fact that DevOps is becoming mainstream and a real enabler to achieving business value and minimizing outages.
Interested playing the Phoenix Project game with your team? We can offer the game in different languages.
The Masterclass was aimed at showing how the underlying DevOps principles and related culture are crucial to realizing more agile IT organizations.
As part of the Masterclass Quint & Xebia together with GamingWorks organized a workshop using the Phoenix project business simulation game to help delegates explore: what is DevOps? What are the underlying principles? Is DevOps relevant for us? And what should we do to bring this about? Jan Schilt from GamingWorks introduced the simulation and stepped immediately into his role of CEO of Parts unlimited in the simulation. He showed the delegates the press release from the morning papers. ‘Parts unlimited share price is falling and there is bad publicity around the company. IT must transform its capabilities if we are to survive’ explained the CEO ‘….Welcome Bill I am happy you are prepared to bring this about’ said the CEO to the delegate playing the role of VP of IT Operations (VPO). The VPO looked like a rabbit caught in the headlights. ‘….and Sarah, from Retail ops will ensure that the Phoenix project will realize the necessary business growth and profitability’ declared the CEO introducing the delegate playing ‘Sarah’.
'I’m not just going to give my knowledge to IT support’
As the team started preparing their work and discussing how they will apply DevOps principles the lead engineer in the game said to me ‘….I’m not just going to give my knowledge to IT support
’ declaring this is what he hears in his organization. On the one side knowledge is power, and the other side there is little collaboration and trust with support. Clearly signaling one of the core critical success……AND fail factors of adopting DevOps. It represents a significant change in culture and collaboration. The team huddled around the flip-over to discuss the new way of DevOps working…….they ignored the lead engineer who sat studying the new technology. Another example of ‘communication, collaboration and engagement’.
State of DevOps finding: IT performance & employee engagement . ‘Employee engagement is not just a feel-good metric — it drives business outcomes’.
The report revealed that companies with highly engaged workers more than doubled revenue growth compared to those with low engagement levels, as well as impacting share value. As well as being a significant success factor this area is also one of the largest barriers to success, as Gartner stated ‘Cultural resistance and low levels of process discipline will create significant failure rates for DevOps initiatives’.
The team started straight away with a stand-up meeting. ‘Everybody needs to be here’
said the VP of operations. ‘Me too’!!
? asked the lead engineer ‘Again I get taken away from my work’
! – nobody explained WHY the lead engineer was invited and what the purpose was of the stand-up meeting. ‘Can I get back and do some real work now’
!? asked the engineer.
State of DevOps finding on Lean product management: ‘When employees see the connection between the work they do and its positive impact on customers, they identify more strongly with the company’s purpose which leads to better IT and organizational performance’.
The team had built a Visual Management System(VMS). Was this effective? Various roles did not understand it. It did not give an overview of ALL of the work needed to complete the projects. The team was busy discussing the VMS, meanwhile the head of retail operations went off to each specialist (SILO) trying to find out ‘Who has got the Pos outage? who is dealing with this’? causing disruptions as the VMS provided no value. After the first round the team reflected. These were some of their key discoveries:
- The team built a VMS but did not use DevOps principles to ensure the board was effective. The team didn’t discuss ‘the backlog of work’, as such the VMS didn’t show all the backlog. ‘Types of work’ – there was no differentiation between the ‘planned’ and ‘unplanned work’. The incidents requiring Development effort were not visible. Then the concept of the ‘value stream’ or ‘flow’ was discussed– how does work now flow through the value stream? Who needs to do what? The VMS did not show all of the teams that needed to do work.
- The team built the VMS but didn’t explore with the various roles ‘what do you need from the VMS to be able to do your work more effectively? To help you prioritize? To help identify WIP and limit WIP’?
- When the board was filled with the projects and issues the WIP became visible to all. Suddenly the business asked ‘Wait a minute, who prioritizes all this work’?
- Tester : ‘nobody saw my value, it was all dumped on me at the end. I tried introducing the need for integrated testing but the team didn’t understand why or feel the need for it’.
- Tester: ‘The IT manager stood and took control “telling people” what we would do, 3 or 4 people tried asking questions or giving suggestions and were ignored. As I result I thought - OK I’ll stop giving input’ – showing how poor collaboration, poor engagement and lack of 2 way communication prevents effective ‘feedback loops’ and ‘Continual learning’ and showing how leadership styles need to change.
Results after round 1
At the end of the first game round the scores showed that the team could celebrate 2 successful releases which stopped the share price falling and raised $10M new revenue, but issues had not all be resolved which meant -$10 M. ‘How come’? asked the VPO. It was discovered that the team was primarily focused on business innovation and developing new applications. This revealed a need to focus both on value creation AND value leakage. This was a recognized issue from the team. ‘The product owners and Agile teams focus on the innovation and growth and give no priority to the backlog of issues and maintenance work’. The team explored the 2 types of work entering the system ‘Planned work and projects’ come in through Development. ‘Issues, representing unplanned work’ enter through support but both types of work come together in the stand-up meeting to prioritize the work in progress based upon agreed business value, or impact and risk. The business MUST be engaged in setting priorities was a conclusion of the team. This led to the need for Development not to plan all WIP on new features, but reserve time for unplanned work for dealing with issues. The team discovered that what they were doing between rounds was a retrospective, somebody needed to facilitate this. The team was learning, exploring and identifying improvements. But they could not carry out all improvements AND do their daily work. DevOps is an iterative journey of continual learning, experimentation and improvement. After making improvements and applying DevOps principles the team raised performance from 50% throughput and success to 66% and resolution from 50% to 70%. What were important discoveries? How did they make this improvement?
- Having the ‘Rhythm’ and flow – less going back up-stream and improved overview of WIP
- Facilitator role to manage the process and flow
- People took more responsibility for the integrated testing – not waiting until the end
At the end of the day the simulation delegates were invited on the Podium to share their discoveries:
- Business: I recognized the importance of engaging with the business. The business must be part of the team to help prioritize. It is Bus-DevOps.
- The importance of the retrospective. Listening to each other, and agreeing end-to-end improvements. Progressing iteratively.
- The importance of embedding testing activities into the team. Let the team test and directly identify faults before passing downstream. Integrated testing in the end-to-end process and in the team.
- The team had discovered a number of crucial success factors as described in the State of DevOps report for 2016.
The team had discovered a number of crucial success factors as described in the State of DevOps report for 2016.
State of DevOps finding Improving quality is everyone’s job. High-performing organizations spend 22 percent less time on unplanned work and rework
. As a result, they are able to spend 29 percent more time on new work, such as new features or code.
The DevOps mantra of continuous improvement is both exciting and real, pushing companies to be their best, and leaving behind those who do not improve’.
Shifting left - is about building quality into the software development process. When you shift left, fewer things break in production, because any issues are detected and resolved earlier.
As one delegate stated. This is a powerful way of bringing end-to-end teams together as well as management AND business owners to show the importance of engaging, collaborating and really communicating.