🎯 DevOps Transformation: More Patterns, fewer Programs

If 7 out of 10 transformation programs fail, what does work?

Two embarrassingly simple answers are patterns and models, especially regarding DevOps and engineering productivity. 

The desire and need for organisations to transform is nothing new [we/they] need to change [how we work] to [go faster/do better/be agile]. It is becoming the norm - Engineering teams and their organisations are in an ever-increasing state of change. Engineering often feels like agriculture; we plan with our goals, experience and the landscape we control. Then continuously adapt to the climate and market.

Stuck in the middle

Not changing is not a viable option. If you’re not improving, your competition will. The DevOps movement is ~10 years old, and the DORA program has highlighted both the value of continuous delivery and that most organisations are not getting there. The middle-low performer group is growing faster than the high or elite group. So much so the elite group is no longer statistically significant as a category!

As an industry, we've been trying to transform Engineering, often with programs or frameworks or oversimplified cloud adoption and modernisation drives. However, continuous delivery continues to hit three groups of obstacles:

1. Low adoption of tooling and automation (e.g. Quality Controls)
2. Teams and individuals need to change work patterns and practices to leverage tooling and automation (e.g. adopting test-driven development)
3. Organisational barriers in adopting new habits and techniques (e.g. governance functions accepting green builds automatically deploy to production)

That's a lot for any transformation program to tackle. Furthermore, Research from Boston Consulting Group and others have highlighted what many of us suspected but thought an anomaly - 70% of large transformation programs fail. BCG and others outline how to increase the likelihood of success. However, a program is still risky for me, and there is a more straightforward, more effective approach for many situations.

The illusion of control

Programs are very appealing in concept, primarily because of the controls they appear to provide:

1. Success criteria (or what would have been a success at the time of writing)
2. A defined scope (based on things that were important at the start)
3. Senior-level sponsorship (at least while #1 and #2 are still valuable, or as long as the same execs are in the roles)
4. A budget (based on whatever was true for #1 and #2)
5. Best of all, a deadline. We'll be transformed by the end of the financial year.

When all the variables of a transformation's equation constantly change over time, it's no surprise that the majority fail or miss badly. 

In reality, very few of these program parameters are static, or even controllable over more than six months.

• The people come, go, get promoted, go on leave, get distracted 
• Organisation priorities change in response to internal or external forces
• Changed priorities mean adjusted budgets
• Processes and frameworks that support some groups actively inhibit others
• The best technology choices are reset almost quarterly after each major show-and-tell conference. 

My passion is helping software teams start or become high performers by transforming how they deliver and maintain software systems. Our mission would be a lot easier if transformation programs worked, but, increasingly they don't. The main reason I see why is the ever-increasing pace of change across people, processes and technology.

Models and Patterns - the program alternative to transformation. 

If extensive programs are too good to be true, what is a better way to help software teams and organisations transform their Engineering capabilities?

My experience resonates with research from the DORA program and numerous other manufacturing, lean and reliability engineering publications. To achieve the outcomes we desire and make them stick, leadership should:

🎯 Drop the deadlines but keep the urgency, focus,vision (and some budget)

🔁 Give up the illusion of program control in favour of continuous improvement patterns

🌱 Use culture as a grass-roots amplifier and feedback on priorities, progress and capacity

🤝 Continue to use outside expertise and tactical, short-lived projects to diagnose, support and kick-start action. 

⚠️Your milage may vary

For leadership, it can be off-putting to use continuous improvement as the primary way to change things. By its very definition, improvement is never finished. However, tools like the KATA improvement model do work. Applying patterns and removing anti-patterns take less energy in the long run, with built-in course correction and load-balancing to keep change aligned across teams and at a pace they can sustain.

Pulling it all together

Talking of models, patterns, and frameworks can get overwhelming. There are many to discuss and compare. To simplify, discuss; however, Getting more specific, I them in the following way:

0️⃣Data holes. Ensure teams understand their capacity, flow and type of work (e.g. % of unplanned work, support or new value). Measurement may take up to three months to establish. However, it is straightforward and builds the case for change, one leader and team at a time.

1️⃣Use models to understand the current state and identify patterns, anti-patterns, opportunities, and vision 

2️⃣Choose framework(s) and external support appropriate to the context to support taking action

3️⃣Continually energise the team culture to empower, recognise and reward

Our mission is to help more engineering teams reach their potential - delivering 2x, 5x, and 10x faster while keeping their customers and teams happy at the same time. We would love to hear from you and your story if you're considering or part-way through your own transformation.