To stay relevant in a digitizing world, organizations must master continuous improvement. Because many – if not all – of the necessary changes for this kind of optimization are driven by software, businesses face a never-ending challenge of improving their software platforms faster and making them more flexible each day.
Evidently, though, evolving from semi-annual or monthly releases to virtually continuous roll-out is no easy feat. Using DevOps as a lever for release management is a clever and increasingly common strategy to make organizations more agile. Unfortunately, a prescriptive set of steps to implement DevOps principles and practices for this purpose does not exist. But don’t fret just yet! I have you covered with a structured, scientific framework from the DORA* research program.
*DORA (DevOps Research and Assessment), acquired by Google, is a leader in conducting scientific research in and publishing about what’s driving high-performing technology teams.
Many organizations still apply a traditional approach to release management, gradually accumulating large batches of change and releasing them by launching a new version once or, at best, a few times a year. Can we blame them? Not really. After all, money doesn’t grow on trees. Testing and stabilizing a new version cost a lot (not to mention the amount of time and energy that goes into it).
Moreover, there’s always the chance that the software still turns out not to meet the quality mark. Some organizations try to overcome this by taking things slower and boosting their quality assurance efforts, but by doing so only end up sabotaging themselves. Unable to keep up with the rapidly changing demands of the industry, their business is headed for failure in the long run.
That doesn’t mean, however, that organizations who do try to tap into the potential of DevOps for their release management are automatically in the clear. Many of them suffer from growing pains, having started a DevOps trajectory but struggling to roll it out towards multiple teams. Sometimes, this can even drive a visionary wedge between infrastructure and application development. For these companies especially, establishing a tried and tested framework is key.
While many possible approaches to using DevOps for more agile release management exist, AE purposely opts for the DORA framework. Our experts take the annual ‘Accelerate State of DevOps’ report by DORA to heart and translate its scientific insights into a pragmatic approach for our customers, enabling them to embed a process of continuous improvement into their software delivery step by step.
In a nutshell, the DORA approach consists of three phases:
Assess your organization’s status quo thoroughly (that means conducting interviews, carrying out surveys and collecting all the objective figures you can lay your hands on), taking into account the three following dimensions:
Depending on the results of the assessment, the improvement tracks delivering the highest, most tangible value, are brought to light. It will also become clear what will (or should) be your first (pilot) project or proof of concept. Typically, this phase requires on-the-job coaching (read: co-delivery) at different levels and within multidisciplinary teams consisting of business analysts, architects, developers, test automators, … and so forth.
Finally, through an iterative process of measuring, learning and adapting, the ideal mechanism for continuous improvement is embedded in the organization. To identify (measure) what constraint to tackle first, value stream mapping can come in handy, among other methods.
Solving the constraint can be done in different ways as well, from eliminating wasteful activities such
as lengthy status meetings and no longer allowing teams to be placed on hold, to increasing the constraint’s capacity, using the constraint in a different (smarter) manner and even making the constraint unnecessary for the organization to thrive (cloud infrastructure versus maintaining all infrastructure in-house, SaaS ALM DevOps versus home-made deployment pipelines, ...).
Does this sound familiar to you? Then perhaps you have already heard of something called the theory of constraints. A methodology for pinning down the most important constraint or bottleneck that stands in the way of achieving a certain goal, the theory of constraints ultimately comes down to devoting all your energy to systematically solving that one bottleneck. Once successful, you move on to the next bottleneck and repeat the process.
But isn’t it more efficient to try and fix multiple issues instead of only one at a time, you ask? Well, no. According to the theory of constraints – and as years of experience tell us – only improvements to the most crucial of all constraints lead to an improvement of the end-to-end flow. Everything else is a local optimization at best, or – worse – only makes the most constraining bottleneck even tighter.
If only DevOps were a prescriptive set of steps, you could simply follow once to achieve success after success, right? I hear you. But know that you’re not in it alone. If you’re struggling with continuous improvement and have your mind set on using DevOps as your key to success – a smart move to make – I'm always happy to help.