English | EN 
Over the last few years, there has been an explosion of interest in DevOps.
To an extent, this is being driven by the new social, local and mobile solutions all of which have gotten consumers used to higher and higher standards of innovation, speed, service and convenience. These heightened customer expectations together with the current competitive environment have made objectives like faster time to market, flexibility, security and higher service standards absolutely essential for most companies. Movements like agile and DevOps, which can help meet these requirements, are thus increasing in popularity across sectors. DevOps, in fact, has become quite the buzzword with many of the clients I meet.
However, as with anything that becomes a buzzword, there seems to be a lack of clarity on what DevOps really means. For instance, just the other day, I spoke to a manager whose idea of DevOps was limited to automating the team’s software delivery pipeline. And this is not an isolated case. In my work as a consultant, I have seen widely varying interpretations of what DevOps really means. Sadly, while today a number of organizations claim to have implemented DevOps, very few of them fully understand what DevOps really means or the extent of the changes it entails.
At the same time, there are also a number of organizations which having started off with DevOps are now struggling with problems that they did not anticipate. One of the biggest problems that I see companies in the Netherlands struggling with relates to the company culture and the changes required in the mindset of workers AND managers throughout the organization. A proper application of DevOps principles often requires a disruption of established workflows and a willingness among employees to step outside their comfort zone.
This can sometimes prove to be a difficult obstacle to overcome. In one of my recent assignments, I encountered a senior developer who was simply not willing to share his knowledge with his team members, as he did not trust their ability to properly utilize that knowledge. In the end, positioning this developer as a mentor to his team-mates, with explicit peer reviews and further automated testing, turned the situation around, step by step. Some of the other problems which hold back a proper adoption of DevOps include issues with managerial patterns, test environments, resources and budgets as well as problems related to knowledge and skills.
It is to help with all such issues that the DevOps game called The Phoenix Project was developed.
The Phoenix Project is basically a business simulation that allows participants to experience the DevOps way of working. Organizations which are thinking of transforming towards the DevOps way of working can safely explore the full extent of the changes that DevOps will entail. Organizations which are already in the process of transforming towards DevOps can accelerate its adoption by applying this game. In other words, this simulation helps organizations derive the maximum benefits from a DevOps journey.
The Phoenix Project was developed by our partner GamingWorks, with the involvement and suggestions of a number of people from the industry, including myself. It is based on one of the most influential books in the field of DevOps- . Just like in the book, we start with a situation where our company ‘Parts Unlimited’ is not doing very well in the market. All the participants then pick up a role that allows them to experience what it is like to move towards and work in a DevOps environment. They are set certain challenges and left to work as an end-to-end team.
With the help of feedback given by consultants and game facilitators they are coached on how best to operate and improve in a DevOps environment and what sort of instruments, techniques and tools can be used to achieve the given objectives. Common topics the teams tackle include:
- Manage the team workload (eg. limiting work in progress)
- Create & improve flow (bottlenecks, batch size, queues)
- Feedback loops (ceremonies, testing)
- Collaboration & teamwork (silos, multidisciplinary, x-functional training, sharing)
- Technical debt, non-functional impact
- Continual improvement (business value, reflection)
- Small iterations (Minimum Viable Product, prioritization)
- DevOps behavior
