Part 2 in How We Can Do Better. Continuous Delivery and how organisations can push past the struggle to adopt it.
We often conceive of software delivery as a pipeline. For many years, this pipeline was rigid, mechanistic and drew much inspiration from early manufacturing production lines. Indeed, the downsides to this approach (lets loosely refer to it as the Waterfall approach) are many, varied and well documented (we won’t go into detail here).
As software engineering as a practice evolved, so too has our thinking. Many of us now think of software in terms of Lean Manufacturing. We recognise the benefits that can come from working in dynamic, high feedback pipelines.
Our thinking has changed with the recognition that software is hard to describe and ever changing. The process of creating software can be chaotic, and often the harder we try to control it, the more chaotic it becomes.
“Software can be in three states: Near Disaster, Disaster, Unused”— Kent Beck
The Agile practices that grew out of Lean Manufacturing acknowledge this chaos and the value in being flexible in approaches to software delivery.
If there is one practice that embodies the difference between the Waterfall and Agile approaches to software delivery, it is Continuous Delivery.
Successfully adopting Continuous Delivery can drive improvements in the DORA metrics (discussed in our first post), which can in turn result in improvements in organisational performance.
What does Continuous Delivery look like in practice?
Put simply, it is about confidently deploying all changes into production as quickly as possible, while maintaining a safe, sustainable pace. To do this, we try to work in small batches, limit work in progress, and strive for short lead times. There is a great depth of knowledge out there on Continuous Integration and Continuous Delivery, so we won’t focus on them now.
Instead, let’s talk about why so many organisations still struggle to adopt this way of working. Many organisations know they are struggling because of their long build times, slow feedback cycles, and high failure rates. They know there is a ‘better way’, but can’t seem to make a successful move to adopt a Continuous Delivery practice.
The aim of this post is to focus on this conundrum, and suggest some techniques that make it possible to adopt Continuous Delivery as a core practice.
Entrenched Helplessness and Knowing Your Constraints
Why do organisations get stuck? Why is it so hard to change? One answer here is Entrenched learned helplessness, where it can feel like the problems are just too big. Change would require buy-in from too many stakeholders, and reaching consensus would take months, if not years, and would be expensive to implement.
So, how can we move past helplessness? The real question becomes, how do we approach a problem that is just too big to solve?
If we return to the idea of software as a pipeline, the problem can start to take a solvable shape: one that can lead to real change.
All pipelines are designed to allow flow, and where there is flow, there are bottlenecks. These bottlenecks are the constraints on our system. In the Devops Handbook, Gene Kim outlines four common constraints that can impede the flow of software delivery:
- Tight Architectural Coupling — tight coupling of engineering teams and products
- Test and Build — manual data and testing are required to ensure quality releases
- Code Deployment — lack of automation of build and deployment steps to all environments
- Environment Setup — manual setup of production, staging and test environments
Using this list of constraints can help break down problems into steps that can be thought about more clearly. These steps might otherwise have felt too big to be owned. Doing so can help zero in on where the real constraints are right now, reduce the scope of the problem and focus energy.
What is even more valuable is the next observation:
“Any improvement not made at the constraint is an illusion — Eliyahu Goldratt”
In fact, this does more than focus energy, it directs our energy exactly where it is needed and where it will add the most value.
So, we’ve broken down the problem. What next?
Below are four focus areas for any organisation looking to change delivery practice and achieve more agility. How software goes from idea to reality impacts everyone from the executive to the engineer. Accordingly, these focus areas span the spectrum from strategic leadership through to how we write our code.
1.Know your Constraint Points — At any point in time, know where your constraint is and focus on it
Continuous delivery won’t work unless your team has confidence in your delivery pipeline. It is crucially important to look at the constraint points we listed above and understand where the blockers are and where the team lacks confidence in the process.
Sometimes you may need to improve tooling. Other times, you may need to focus on engineering practices. In other cases you may need to address larger organisational attitudes around risk, or the structure and ownership of the product.
Look at the pipeline of work from discovery through to delivery. As a group, be honest about where the choke point is, focus the effort there, and then work to free it up.
2. Two-Pronged Approach — Top Down and Bottom Up
Bottom up changes made by motivated and skilled individuals may succeed for a while, but won’t truly take root and spread without strong support from leadership.
For leadership, providing a clear vision won’t gain the momentum needed if it isn’t backed up on the ground by people who have the skills and motivation to see that vision through.
Big organisations or code bases need a two-pronged approach to change. Throughout the process we need to ensure both executive leadership and engineers building products are aligned and solving the same problems.
Consider an organisation struggling to respond to changes in the market fast enough. Engineers may be frustrated due to slow delivery caused by ageing build infrastructure, while executives are disappointed by continuous delays in product launches.
Rather than setting goals based on the throughput of features, alignment can be achieved when both leadership and engineers focus on reducing the lead time it takes for a change to get to production.
3. Empowerment and Trust — Let Teams Build Their Own Way
Empowerment and trust enable motivated teams to make necessary changes.
Don’t aim for consensus, democracy or consistency. Don’t focus on fear or risk. Don’t add gates and checks to a process that is already slow and unstable.
Instead, make sure the team cares about their product and can exert real influence over how they achieve their day-to-day tasks.
Continuous Delivery requires that a team feel confident and safe knowing the code they commit is heading straight to production.
Give them time and let them choose the tools to adapt their practices so they build this confidence. Let them remove frustration and uncertainty and instead create a truly enjoyable developer experience.
4. Create a Pit of Success — Fall into Good Practice
Finally, create an environment that makes it easy, desirable and fun to do things the right way.
If we know where our constraints are, have the backing of leadership and a strongly motivated team, and feel empowered to work based on shared principles and vision, then we can safely make change.
Teams can experiment and try things, they can build MVPs and attempt new ways to get code into production.
They can do things differently to other teams—and that is ok. If their way of doing things works and is safe and fast, then the other teams will be inexorably drawn to it—they will fall into the pit of success.
Start small, repeat
The change required to introduce Continuous Delivery can be difficult. Know the problem you are solving, align all levels to a common goal, empower, trust and start small. Repeat.
The more often we apply this pattern, the more easily it can be applied. The ultimate aim being that we do this continuously. Through this, we can achieve real agility that allows us to grow, improve and respond to changes quickly and calmly.
If this is a challenge you are facing and would like to discuss more about our experiences working with companies adopting Continuous Delivery, we’d love to chat.
