Three step DevOps model Solidify

Three step DevOps model

Published March 15, 2017

Raise your hand if you’ve ever had the thought “DevOps seem amazing, but how do I actually introduce it in my organization? Is there perhaps a DevOps model to use?”. This is a common question. It will often be followed up with “management just doesn’t understand“, “everyone keeps discussing tools”, “QA calls me dangerous”, or something similar. When you’re thinking about <a href="http://solidify.se/getting-started-with-devops-donovan-brown/">getting started with DevOps</a> and talk to colleagues about it you might be met with the feeling of being an interruptive and annoying phone salesman. It’s hard enough to change something personally, not to mention on organizational level. But this is also good news; it doesn’t have to be that hard to introduce DevOps. Using the right DevOps model and a structured method, you can easily convince the right people that DevOps is worth betting on. Are you ready? Let’s begin. <h2>The three step DevOps model</h2> Before you run into your boss’ office screaming that you’ve found the holy graal, you will need a foundation to stand on. You will need a process that involves a transformation of the organization in a practical and accessible way. You need a DevOps model. <ol> <li>Create a business case. Management’s first priority is to help business and work towards the organization’s or department’s main goals. With a clear and solid business case you will create better chances that they will listen to you.</li> <li>Build a common DevOps vision. Everyone involved needs to see the system and workflow in the same way. With this, everyone understands feedback and can better contribute towards the end goal.</li> <li>Improve continuously. Your job is never finished and you need to measure your results as well as brainstorm improvement ideas and repeat.</li> </ol> <h3>Create a business case</h3> Let’s make one thing clear: DevOps is not a business case. The word itself has no meaning to your management unless the overarching goals of the organization can benefit from it. Simply said, there’s only one type of work worth doing – work that justifies itself by contributing to the bigger picture. According to the management philosophy <a href="http://www.leanproduction.com/theory-of-constraints.html">The theory of constraints</a>, among other things mentioned in Gene Kim’s famous book <a href="https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988262592">The phoenix project</a>, all work made to improve areas outside of the main bottleneck (or constraint) is merely an illusion and not actual improvement. The first step in this DevOps model becomes to convince those in leadership positions (both formal and informal). You therefore need to base your arguments on the goals that leadership is interested in. These will vary from organization to organization and probably even between departments. This means that you need to talk to various people of interest and make sure you build up a complete picture of what’s required in order to fulfill these goals. For example, is your service losing customers to competition because they have better functionality? Then DevOps can help by increasing the feedback loop speed. Is the main goal to stay ahead of new technology. Point towards how <a href="https://devops.com/driving-innovation-devops/">DevOps drive innovation</a>. <h2>Build a common DevOps vision</h2> Step 2 in the DevOps model is about reaching a common vision regarding DevOps and how to execute the actual work. Here it’s important to remember that you’re teaching a way of thinking instead of a simple process. When somebody in your organization talks about DevOps, your goal is to ensure everyone sees the work in a similar way instead of simply following written-down procedures. To have everyone push in the same direction, they need to understand the work system that they’re a part of. What work actually needs to be done and how does it contribute to delivering value to the end users? When everyone possesses that knowledge, the next part is about understanding the workflow. Regardless of where in the work system someone moves, they need insight into how the work flows, where the bottlenecks are, how the work moves within the flow and their role in it. After this comes skills for feedback and analysis. Coworkers not only need to understand the feedback they receive, they also need to be able to conclude why they receive it and what’s needed for a different result. Finally, everyone involved needs to actively seek out areas of improvement. In true DevOps spirit, you find these areas, improve them, iterate and keep looking for the next bottleneck. <h2>Continuous improvement</h2> Just like in science where a hypothesis is being presented, tested and adapted according to results, continuous improvement within DevOps is about creating qualified theories about what can be improved and then test these theories. The most famous method for this type of work is called <a href="http://asq.org/learn-about-quality/project-planning-tools/overview/pdca-cycle.html">Plan-Do-Check-Act</a>, which is simply this: <ol> <li>Identify a possibility and plan for its improvement</li> <li>Implement the change in small scale</li> <li>Analyze the result to determine whether or not the change was successful</li> <li>Act upon the result and either expand the change or adapt the plan</li> </ol> It’s <a href="http://solidify.se/problems-in-transformation-how-to-avoid-them/">never easy to create a transformation.</a> By planning well from the beginning and realizing what’s necessary for success you can increase your chances dramatically.   Have you started using this or another DevOps model? Do you need help with any of the steps along the way? Let us know in the comments below!