It seems that there is a lot of confusion out there about what Continuous Delivery ‘CD’ is. Continuous delivery? Continuous deployment? To prod? Not to prod? Related to continuous integration? I use a tool that claims to do Continuous Delivery, so we’re good, right? It makes my life easier, that’s it!
A lot of the confusion comes about, in my estimation, because everyone seems to forget the ‘why’ – why should I care about CD? Why is it a buzzword now? Why do all the blog posts out there espouse it as the way of the future?
I think there are some foundations to grasping the ‘why’ of continuous delivery that can help us.
We Work in Complex Systems
Every forward step you take without any kind of validation is a step based on what you observed the landscape to be at that point – simply put – your theory of success has an expiry date. Complexity says that every step you take brings with it a new landscape. If your theory has long expired, what results will a continued path bring? How lucky are you? Are you ready to admit that control is not possible?
Compound Errors Run Deep
A decision to use a certain library is based on a mistaken interpretation of the spec. Six weeks later, the spec is reviewed and the error discovered. How much code was written in six weeks that is based upon that library? How much toil will be required to undo that change? What happens when sunk cost fallacy sets in?
The Economics of Sustainability
Because of the first two, this one hits extra hard. If you have no comprehension of how complexity constantly changes the landscape, it will be inconceivable to you that the product you took three long years building no longer has relevance. If you fail to grasp compound error in code, that three years might be six. Because of a slow-moving organization that fails to make work a joy, high churn could turn the six to a never.
Systemic choices
Continuous delivery is NOT an engineering choice, it is an organizational choice. ‘Finding answers, quickly’ should be a natural outcome of the system’s values and choices, it cannot survive limited to one silo. Indeed, a single-silo decision on this matter guarantees failure. What are the ramifications of this? Leadership (hierarchical and natural) sets the stage, the rest of the organization follows.
So, complexity says control is unlikely, errors not only delay but deliver a costly bill to the organization’s sustainability, and your choice of ‘do I continuously deliver or not’ is actually not your choice. Fantastic. Now what?
Practical matters
Let us talk practice – it’s all well and good to understand the concepts. What do we actually do? What should you care about? Here are some practical ways to re-adopt continuous delivery with the correct ‘why’.
- Organize around a shared understanding of what customers’ jobs-to-be-done are, what they value about your product – and then institutionalize continuous discovery of this – the landscape is always changing.
- Start small and cheap on a framework of ‘most of this will fail’ – humans are intensely bad at throwing things away, therefore, make it a discipline. Turn this into an organizational institution employees rotate through.
- Once you have a product that sticks, seek feedback – the ideally having software that continuously and automatically flows to production at which point it can start generating feedback – you can start testing your theories.
- Build software with the expectation that it’ll get thrown out – electing to do otherwise builds ‘failure intolerance’ (fear of failure) into your system, which causes change to grind to a halt; organize your teams around work-enabling platforms instead – give them a well-supported ability to produce new ideas for testing, migrating successes into the longer-term platforms
- Make flow visible – you want to prioritize making work flow, and choose to find and remove flow friction; it should be easy to accomplish work no matter how challenging the problem. This changes as you move through the spectrum of ‘proving an idea’ to ‘startup’ to ‘SMB’ to ‘enterprise’.
- Create a culture of change starting with yourself. A new way of working requires a new you, and leadership means self-as-example. How do you demonstrate these ideals? How do you test your own theories? Are you willing to make that testing public?
What are some signals that you’ve gone off the rails?
Software is hard, and things don’t always go the way we want them to. What are the signals we can observe that tell us we’ve missed the ‘why’ of continuous delivery?
- What the customer is trying to accomplish has been forgotten, or takes second place to anything else.
- You are more focused on achieving your team goals than seeing the organization succeed (even if, and especially if, you are incentivized that way)
- Engineering is a silo that never hears from the rest of the organization
- Profit or growth at any cost
- Theatre and blame instead of humility and seeking understanding
So. Continuous Delivery? Continuous Deployment? Prod or not? I trust you no longer care about such distinctions. The question ‘why would we ever want continuous delivery?’ is actually ‘why would we ever want to quickly validate our theories about what customers find valuable?’
Suggested reading
- What customers want (understanding value)
- The Principles of Product Development Flow (understanding the economics of product development, why flow matters)
- The Fifth Discipline (understanding the pillars of building a learning organization, including your own contribution)
- Continuous Delivery (software mechanics and whys of continuous delivery as a concept, from the horse’s mouth)
Are You Ready for a DevOps Transformation?
While software continues to eat the world at an ever-increasing pace with DevOps, the challenges and struggles of companies implementing DevOps is very real. We all can overcome these challenges by working together, improving our tools, processes, knowledge, and training our workforce.
Indellient is a Software Development Company that specializes in Data Analytics, Cloud Services, Managed IT Solutions, DevOps Services, and Document Process Automation.
2630 Bristol Cir #100 Oakville, On L6H 6Z7
+