DevOps is going to fail… unless!


DevOps is going to fail… unless!

How “The Phoenix Project” business simulation can help.
Many organizations are starting with DevOps. Some of them think about using it, some of them are using it already. I visited may conferences and was invited as speaker on many of them. Most of the stories were about ‘Technology’ some of them were about “People”. None of them really showed HOW to develop the skills of the people that actually are DevOps. I believe it’s time to put the focus on people. One of the powerful instruments are simulations. In this series of blogs I want to share my experiences with simulations and how they can support the activities to improve the performance of teams.

DevOps is going to fail
Traveling around the world with my box of cards, gave me a diverse picture of how organizations ‘see’ DevOps. My conclusion at this moment is that DevOps is going to fail as long as…
-    we keep calling DevOps another framework;
-    we not invest in the development of new competences in our organization;
-    we keep seeing Automation as the solution (Automate everything)
-    we focus too much on certification
-    we think we van ‘implement DevOps’
-    we start without a reason, business buy-in and management buy-in

My observations are supported by many publications.




Looking at one of the definitions of DevOps we see some interesting words that should trigger us that DevOps is not something we can obtain overnight.

“DevOps is a cultural and professional movement that stresses communication, collaboration and integration between software developers and IT operations professionals”
(DevOps Institute)

These words show that our journey has to focus on people-aspects. And not just on the technology.




So how can we avoid failure?
First, it’s about overall DevOps awareness within the whole organization. If you ask different people the question ‘What is DevOps?’ you will get different answers. I think DevOps is still in the early stage of their existence and we need to develop this clear and overall ‘picture’ in the organization about the following questions:
1.    What is DevOps?
2.    What can it bring our organization?
3.    Is our organization ready for this?
4.    How should our journey look like?

Question that are not easy to answer. To answer this question, you need to UNDERSTAND DevOps first.

The Phoenix Project simulation
For those of you who read the book ‘The Phoenix Project’, you remember how Bill got stucked in the IT jungle and found his way out by using DevOps principles. For many readers this was an eye opener.
When we got the rights to use this case for our simulation, we decided to build the simulation to give organizations the opportunity to answer the questions above, before starting their journey and make mistakes that could have been avoided.
After several sessions with customers it’s good to share some of the findings to (maybe) avoid failure. This is just a short list of many other learning outcomes. In the next blogs, I will explore more of them.

Three lessons learned from “The Phoenix Project” simulation

Lesson 1 – Business must be 100% part of the journey

Acting as Retail Operations in this simulation, I learned a lot about DevOps. I now see how Kanban is used, what my role as the business should be. Very useful.
Katrina Neary, People Operations Analyst at AutoTrader

Many organization already came with the word ‘BusDevOps’ to indicate the importance of the role of the business. During the simulation participants discover a lot of useful tips.

The business should also think Lean and Agile. Most of the business roles in the simulation throw their projects over the wall to IT. As a result, the backlog shows 10 projects and feature. If IT starts to ask questions like ‘When do you need it?’, or ‘Which part is most important?’ and “What are your priorities?’ the answers are always the same: “We need it fast and we need it all”.

Product Owner role. This role is not known in many organizations. The role is not defined and if it’s defined, people do not know what to do. After 2 rounds in the simulation, we see this role being more involved in the team, taking the responsibility to plan the work and solve priority issues with the team.

Starting point of the flow (Pull or Push). The business can make or break the flow. If they throw the projects over the IT-wall they will break the flow immediately. They learn how to make their own (business) plans, how to share them with the DevOps team and to translate them to small packages of requirements (MoSCoW). And how to manage the backlog by focusing on Pull instead of Push. Then the whole team knows the priorities and can pull the work through their flow.

Lesson 2 – We had the theory, but now we understand DevOps

DevOps theory is crucial. You need to know what it is and at least some of the definitions and meanings of the DevOps vocabulary before you start your DevOps journey. But there is a difference between ‘Knowing’ and ‘Understanding’. And even further, after you understand DevOps, ‘Applying’ it in your own organization.
This is one of the powerful aspects of simulations, bringing the participants from knowledge, to understanding to application. Look at the ‘Bloom’s Taxonomy’.

The return on training investments will take place AFTER the training, when you are using it to solve your day to day problems!
Let me show a few of the learning outcomes participants experienced during the simulation.

Visualization is a must to create this clear picture of the work we need to do and we are doing. It shows the workload, it shows the status and the issues. It will help us to support team work, decision making and organizing our work. However, we did not see many teams who knew how to setup the KanBan, how to use it and how to facilitate sessions in which the team was using the KanBan to manage their work.

Standups are very powerful tools. It brings people together for a few minutes with a clear focus. Standups are effective and efficient if you keep the short, focused and you need a facilitator (team member) to facilitate this session. We have seen lots of team who were not able to facilitate this kind of sessions.

Flow is the first way according to ‘The Phoenix Project’ book. Creating flow will bring fast delivery and many deliveries. Flow requires a clear process and clear roles and responsibilities.  Not many teams are able to create this flow in the first 2 rounds of the simulation. As a result, we still see Silo’s and as a result a lot of Waste like waiting, rework and upstream work.
Lesson 3 – We need to plan time for learning and experimenting
This is always the major learning outcome of the sessions. It seems that many organizations are not able (or willing) to plan time for learning while this is seen as a key success factor in the simulation. Experimenting is also challenging. Making mistakes and learn from it is mentioned as a key element of DevOps. During the reflections many participants say:

“Making mistakes and learn from it is a nice objective, but hardly to apply in the real world. How can you tell the business that the system went down for 1 hour because of an experiment?”

Simulations and DevOps
Simulations are seen as a perfect way of experiencing DevOps and learn what DevOps really means for the organization, the teams and the employees. It’s a good start of your DevOps journey.

We are 7 years ahead. We have been through all the aspects in this simulation before we reached where we are now.
Having this simulation 7 years ago we probably would have made bigger steps in our journey.
Jonathan Leckey, Head of Operations at AutoTrader

I never believed that this simulation would show the DevOps principles so clearly in just one day
Feng XU, VP Delivery at Pactera (China)

Only registered users can download the attachments of this page.
Your rating: None Average: 5 (2 votes)
Alejandro Debenedet (02/11/2016)

Thanks for sharing such an interesting content!

Paul Wilkinson (18/11/2016)

Powerful insights from experiences from many organizations struggling with this subject

Post new comment

  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <img> <br><p>
  • Lines and paragraphs break automatically.

More information about formatting options

This question is for testing whether you are a human visitor and to prevent automated spam submissions.