Avoiding the Easy Way: Selling Continuous Delivery in Your Business
Architect at Oracle
When you introduce continuous delivery into your company, you’re giving people a new capability that will save them time and improve reliability, visibility, repeatability, and quality. But that does not mean that they will use it—or even want to.
No matter how significant the benefits, no matter how well you demonstrate and quantify those benefits, people tend to be resistant to change. You should be prepared to “sell” it to all of the stakeholders and to take an active, hands-on role—to sit with people, one after another, and help each one develop the understanding and comfort he or she needs to make the investment of time to move to something new.
You’re also going to shine a light on and possibly exacerbate many existing problems in your current build–test–release processes—even in your source and binary management processes. It’s easy for people to blame these “problems” on the new approach, certainly much easier than admitting that the issues were always there. Introducing continuous delivery provides an opportunity to go back and correct some of those problems from the past. Many of today’s issues are steps that were taken for perfectly valid tactical reasons, but somehow no one ever got around to replacing them with something more strategic.
Be steadfast on the goal: do not compromise on quality. If you relax the rules, even a little, and let people find a way around things that are difficult, they will take the easy way out every time. Remember, one of the key tenets of continuous delivery is to bring the things that are difficult forward in the project to reduce risk.
It’s going to be a bumpy ride, so keep a firm hand on the wheel.