I recently had the opportunity to become certified to lead a simulation based on the best-selling IT book The Phoenix Project. When I went through the training, it was apparent that the developers of the simulation had created something very special. The Phoenix Project simulation is not a product as much as it is an experience. The realistic scenarios, challenges and pain points embedded in the game created a creative tension in a safe environment and allowed everyone (including me) to discover new insights into applying DevOps to improve flow throughout the value stream: from the business request through IT and to customers!
DevOps and Agile practices are built on the back of Lean principles that go back decades to before the Toyota Production System. As someone who attempted to apply Lean to IT long before DevOps came into existence, I have always said that DevOps is about creating an environment where it is safe to observe, experiment and learn based on outcomes. I was fortunate to meet with Gene Kim many times while he was writing The Phoenix Project. We always talked about lean thinking, lean systems and lean tools. Those discussion eventually morphed into The Three Ways – the core principles of DevOps!
Alignment with the business changes the feel of work
The simulation put people in a position where It was easy to see and feel the impact of not being aligned with business and not being coordinated with all the elements of it (AppDev, Engineering, IT Ops, Change Management, etc.). In each round the team was able to reflect and learn from the experience and experiment with new ways of working. What we all experienced was profound: the DevOps principles, systems and tools are effective only when the team directly experiences the frustration of a broken work system and works together to see, understand and act.
What was amazing to see was how quickly people took on the personas of the functional tole they had been assigned. The woman who took on the role of Retail Operations (you may remember Sarah in the Phoenix Project) became rather aggressive as she demanded results. The CISO (John in the book) constantly nagged people about SOX-404 issues. And of course, the CEO was a royal pain on everyone! Although we all knew this was a simulation game, everyone reported the stress and tension they felt as we embarked on round one with no real plan of how we were going to transformto a DevOps team.
You can’t improve what you can’t see
What became instantly apparent among the chaos of trying to get the work done was that the team had no visibility of all the work nor priorities. True to life, there was more work that our people could handle so we needed a way to see the work, compare it to our capacity to do the work, identify trade offs and then work with the Business and other stakeholders to set priorities. Once the team was able to accomplish this (through some trial and error) we all could feel the alignment of purpose, see the smile on peoples’ faces as we created value and feel what collaboration between silos is really like.
This discovery was just the tip of the iceberg. As a coach and facilitator, I was able to ask the team questions that positioned them to reflect on what had just happened and see within themselves additional changes that needed to take place to improve the quality, speed and volume of our deployments. Some of the other topics which were experienced and later expanded on include:
- A recipe for coordination among silos
- Making time for improvement, learning and technical debt
- DevOps without Value Stream Mapping can be hazardous to your health
I’ll share some thoughts on these topics soon.
At the end of the day, DevOps is about creating an environment where it is safe to observe, experiment and learn based on outcomes. The Phoenix Project Simulation creates an environment to give everyone that experience. From there, they return to work and begin their journey.