While it may seem that DevOps is past its honeymoon phase, quite the opposite might be true. As noted in the 12th Annual State of Agile Report, 48 percent of respondents said that their organization is currently undergoing a DevOps initiative. That leaves 52 percent who are only planning or are not even on their DevOps journey yet! However, 65 percent of respondents said that a DevOps transformation was important or very important to their business. So, why might there be a lag between adoption and acknowledgement of benefits?
One of the main reasons teams set out on a DevOps journey is because they want their organizations to continuously improve. While achieving this benefit, and several others, is the end goal, it can be really challenging to know where to start. An analogy I like to use, is likening starting a DevOps transformation to operating a train for the first time without ever having driven a train before through a switch yard. Many organizations we run into today see DevOps as this big monstrosity (like a train having to navigate a train yard and load cargo or deliver cargo), which can understandably be challenging to understand and implement. They don’t know how to begin because there are multiple places to start; further more choosing the wrong starting location or worse, derailing, can start or set the entire business off course.
In order to move from this chaos to making a definitive first step on a DevOps journey, there are four questions you should ask (and answer!) to help you decide where exactly to begin:
- How can you increase the quality of all of your DevOps processes?
If we are measuring, we need to be able to tell how long we are spending in development, how long we are spending in testing, how long something is sitting on the shelf, and then how long might it be in an A/B scenario where somebody is testing but it is not really fully out into production. We need to be able to identify bottlenecks and poor quality. Once these bottlenecks are identified through measurement and their resulting metrics, only then can we begin to see where improvements can be made.
- How can you accelerate delivery?
This is key to getting stakeholder buy in. If you can identify blocks of value and can track them through all the phases of maturity in the software delivery lifecycle, you can actually prove to the people who are making organizational decisions how fast we’re moving and how each phase of the process affects one another as well as how much quality there is within the process. This enables the third way (see The DevOps Handbook for a much better explanation than I can provide).
- Are you confident about what you’re delivering and how are you able to assess the riskiness of a deployment?
If you can tell someone that your release is this risky or that risky compared to another release, we know how much effort to put into validating and verifying it will deploy and run well in production. We know how much effort we need to expend to make sure that we have gotten all the defects out of our release and so we can do a valid risk assessment of our product. In other words, take your time and build up confidence your DevOps transformation is a journey of continuous improvements!
- How do we improve in compliance?
How do we get people to the table sooner in the process that are generally left until last or next to last for their input or validation and verification? For instance, enterprises that have high risk models or governmental regulations that they have to meet in order to get products out to end users, face a lot of lag time. However, it’s important to address security and compliance issues upfront and to have those teams in on conversations about development to address any conflicts before they get too deep into production. Studies of high performers by DORA show that moving security, configuration management and compliance farther left in the process improve lead times.
Why ask these questions? They address the main components of DevOps Performance Measurement and further address how to manage a Value Stream from ideation to release. When it comes to measuring DevOps initiatives, we are easily able to identify the input and the outputs and how to measure them, but we do not know what is in-between and how to measure that. So, we have to be able to say how good we are at doing DevOps so stakeholders can feel confident in continuing to invest in the transformation.
This is still definitely a lot to take in, but don’t be discouraged. Even the biggest organizations years into their DevOps initiative still come across points of failure and are continually learning. You won’t achieve DevOps tomorrow, or even next month, and maybe not even until next year. The best thing you can do today is ask the right questions, get the right metrics in place and prove to the critical members of your team that undergoing a DevOps transformation will be challenging, but overcoming those challenges and discovering new problems will be even more rewarding in the end!
Bonus: If you want to learn more about what it takes to undergo a DevOps transformation, and have the opportunity to ask us and some of the top tech leaders from around the world how they got started on their journeys, we encourage you to join us at DevOps Enterprise Summit London June 25-26, 2018. There’s still time to register. Hope to see you there!
Bonus bonus: Watch the recording of me delivering a talk on this topic at DevOpsDays Charlotte 2017:
About the AuthorMore Content by Logan Daigle