DevOps is continuously evolving. Ever since the term was coined in 2009, the state of DevOps evolved exponentially year on year. Fast forward in 2019, organisations of every sizes and shapes (enterprises to start-ups) share great amount of excitement around DevOps. Each organization has their own DevOps story. Some of these stories are yet to begin, some are in their infancy, some are matured and some have reached their pinnacle. Unlike other stories, there is no end to a DevOps story as it’s about continuous improvement.

As businesses increasingly become digital and software driven, there is greater realization about the nature of DevOps journey and possibilities. Not just engineers or technology leaders but also business leaders are interested in the DevOps concepts, practices and applications. There is a wider acceptance of the need of DevOps for achieving business outcomes i.e. speed, quality and time to market etc.

The 2018 State of DevOps Report is one of the great resources available online to understand and learn how DevOps is shaping the software delivery across industries. This report greatly summarizes the trends and challenges of software delivery. In this report, IT Performance is referred as Software Delivery Performance to differentiate Software Delivery work from IT help-desk and other support functions. This is a welcome change and was long awaited.

The report highlights four aspects of Software Delivery Performance as below:

  1. Deployment frequency – For the primary application or service you work on, how often does your organization deploy code?
  2. Lead time for changes – For the primary application or service you work on, what is your lead time for changes (i.e., how long does it take to go from code commit to code successfully running in production)?
  3. Time to restore service – For the primary application or service you work on, how long does it generally take to restore service when a service incident occurs (e.g., unplanned outage, service impairment)?
  4. Change failure rate – For the primary application or service you work on, what percentage of changes results either in degraded service or subsequently requires remediation (e.g., leads to service impairment, service outage, requires a hot-fix, rollback, fix forward, patch)?

These four aspects are then measured to rank the performance in four buckets: Elite, High, Medium and Low. The table below (referenced from the report) indicates the details for each of these aspects against the buckets.

One more aspect that I highly recommend to be added to this list is “Team Engagement Index” i.e. how happy and engaged are the teams. I am of the opinion that the team performance is directly proportional to the team engagement. The higher the team engagement i.e. the more happier & engaged the teams are, the better outcomes they produce.

Another topic from the report is the J-CURVE OF TRANSFORMATION. The diagram below highlights how automation helps low performers progress to medium performance level and then test requirements, tech debt and increased complexity lead to manual controls resulting in slowing down the progress. This is an interesting and “must-note” observation. It highlights that automation is not the answer always. If you automate a wrong process, all you get is wrong outcome, and faster.

Relentless improvement, learning and sharing and leveraging expertise take you to high or elite performance levels – the journey to elevate your teams to elite performance requires more than tools . Persistence, perseverance and grit at all levels (i.e. team level, leadership level and sponsor level) are critical to breakthrough from low or medium performance level to reach highest potential of your teams.

If we draw the journey to Elite Performance, you would find Automation, Technical Practices and having a Continuous Improvement plan as the catalysts for your journey. Where as test requirements, tech debt and increased complexity would be your blockers. I find the Anchors and Engines (SailBoat Retrospective) format provides a quick & interesting way to visualize the catalysts (engines) and blockers (anchors) in one single picture (as below).

 

Why you need a DevOps Strategy?

In this super VUCA world, leaders are under constant pressure to deliver and tend to go after quick wins, instant results without understanding the nature of this journey. Quite often we see gaps in what leaders expect vs how the journey shapes for an enterprise. Bridging these gaps require a well thought strategy. Understanding and appreciating the nature of DevOps transformation journey is essential for everyone involved.

When teams begin to explore DevOps transformation, usually most teams start with exploring ideas for a problem in hand, they look at case studies and solutions by others and form their hypothesis. The focus is to identify quick wins. More often than not, teams rush to prove the viability / feasibility of the solution approach or hypothesis through a pilot (which is a great way to get started). In this mega rush of proving out, teams should avoid “copy paste” or “imitation” of someone else’s journey. What worked for someone else, might not work for you “as is”.  It’s important to understand the context and vision of the enterprise so that you can define the approach and guardrails accordingly.

When pilot outcomes are satisfactorily achieved, the team usually rolls out same elements of approach, tool-chain etc. to other initiatives or teams. This is an important juncture, scaling the benefits of the pilot across the enterprise, needs a view of business goals, current value stream, blockers and drivers and inventory of your technology estate.  The strategy should be able to clearly articulate Why we are adopting DevOps, What business goals/outcomes we are after, Where we are currently and What good looks like. Encompassing all these element, a solid and well thought through DevOps Strategy can stand the test of enterprise ambiguity, legacy infrastructure and technology modernization.

Majority of tool centered DevOps implementations start and end with tool setup and metrics. Mapping these metrics to real business outcomes is really critical. If you do what others do without understanding the context, you may get undesired results. Taking shortcuts and cutting corners on foundation, can only take your journey so far. Our experience tells us every environment is unique and need “fit for purpose” approach. Your DevOps strategy may look different than others and that might be a good thing.


How to define DevOps Strategy

Composing your strategy requires several steps as below:

1) List down your business goals that you are targeting as an organisation. For examples, your business goal might be “Increase customer acquisition in X region or X segment by 12%”, “Increase Profit Margin by reducing operating cost by 10%” and so on. Ensure you list them all.

2) Identify and list down the Business metrics and measures. What business metrics are you going to capture to track your business goals? How often you are going to measure?

3)  Identify your Technology Portfolio Snapshot – gather inventory of all your applications and respective infrastructure. Categorize them to understand the spread of your technology portfolio in terms of strategic vs non-strategic, legacy vs new, enterprise app vs eol/non performing etc. Categorize your infrastructure as well to understand your infrastructure current state.

4) Identify challenges that may prevent your DevOps journey

5) Identify drivers that could accelerate your DevOps journey

6) Draw your current operational value stream 

7) Draw your desired operational value stream

8) Define Toolchain principles considering different domains of development i.e. front end, back end, data, infra, virtualization, monitoring etc.

9) Compare current and desired value stream – identify themes that you would like to implement as part of your DevOps journey. Arrange these themes in order of priority to create your DevOps Backlog

10) Identify key DevOps metrics that you would measure and map them to the business metrics.


These activities may sound simple but there are not. It involves a great deal of collaboration with senior leaders from business and technology and prep work to get the required level of details and facilitation / grouping techniques to arrange all these details in form that is well understood by both business and technology people. Based on my extensive research and learning of over a decade, consulting and leading DevOps engagements in different industries and regions, I have created a innovative tool to capture all the details in a canvas called “DevOps Strategy Canvas – Accelerating Business Outcome (V1)“.

Here is the link to the DevOps Strategy Canvas:

https://www.sandeepmvp.com/devops-strategy-canvas-accelerating-business-outcomes

As as strong believer of “we learn by doing”, I would keep iterating the canvas based on feedback and continuous learning. Let me know what you think about the DevOps Strategy Canvas and my approach as summarized above. If you have employed some other tools or approaches to create a DevOps Strategy, please comment and collaborate. Happy to discuss and looking forward to hear your views!

#DevOps #DevOpsCanvas #DevOpsStrategy

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.