Continuous Delivery — Is it for everyone?
During the Meetups or conferences, I have seen many raising the below concerns about Continuous Delivery:
- I think it works only for technology companies. Does it work in high-security environments like banks and insurance companies?
- It works for high performing teams like Amazon, Facebook, and Netflix. Our project is unique, so it may not work
- Our business is not ready for Continuous Delivery
- The investment required is too significant which, our company can’t afford
- We’d invested the time, but got little returns.
Let me share a few of my experiences about how Continuous Delivery impacted great business outcomes and team performance.
A Dream come true
“A longtime dream come true! It is exciting to be able to educate patients while they wait in the exam room. They select and view topics of their choice. The presentations are engaging and free of commercial bias. This is the future”.
~ Feedback from the senior doctor at the clinic
In one of my earlier posts, I mentioned a product we developed for a Media Company, where we deployed Android Tablets and Linux Media Players as Kiosk Devices in clinics across the US. These devices, air informative content relevant to the patients visiting the clinics.
We deployed the first kiosk mode tablet within six weeks. We received excellent feedback from both the patients and the doctors. The content improved the relationship between the patients, doctors and the clinic as patients became more curious and optimistic about being cured.
The Constraints
Once the number of devices increased in the field, we identified that the “initial setup of the device” was the most time-consuming process. We automated the same using a Custom ROM, which increased the number of installations drastically.
We were using a commercial software we were using commercial software — a well known Mobile Device Management Software. The software was costly and had reliability issues. But the focus was on acquiring customers, and the cost was manageable until the customer base reached a certain threshold.
But later the cost became a constraint as the reliability of the software affected the revenues. We had to make frequent updates to the devices to learn faster from the field, but because of the unreliable nature of the off-the-shelf software, we couldn’t deploy as frequently we expected.
We invested in porting it to own custom solution over a period and got rid of the commercial software once we got enough confidence in our solution.
Without the speed of the Multunus team and the ability to show real live tablets, we would not be in the position. So, thank you and congrats.
Speed, Discipline, and Quality — Not a paradox
Delivering on the business cadence wouldn’t have been possible without Continuous Delivery — delivering software continuously sustainably and predictably.
It is not simple to bring in that cadence. There was always pressure to deliver faster with compromises, especially on the code quality.
It is the business policy to hustle, and that is where the great engineering culture comes into the picture. A culture that balances discipline, quality and speed. Many consider speed and discipline don’t go together. But if you practice Continuous Delivery well, you see that it can be done.
To take one instance, one of the major struggles for us was to Test Drive Android Code. Because of the way the Android Framework was designed and also because of the device dependency to run the test suite, the unit tests were slower which has affected the pace of development. We moved to Robolectric, but learning Robolectric while writing the production code was a challenge which we balanced and overcame over a period.
Christmas every week
We consider Every Tuesday meeting [the lending meeting] as Christmas every Tuesday.
~ Feedback from a loan officer about the weekly production updates
A few years back a Micro-Finance institute approached us to build end-to-end loan processing application. They were managing the entire cycle through Zoho, and Google Docs integrated with 3rd party APIs.
When the number of manual steps became a bottleneck for scaling to more users, they approached us to build an end to end solution.
The weakest link was the loan closing module. The loans are requested for different reasons or purposes — an individual to start a business, a group of people starting a business as partners, a small business taking a loan to expand their business — as examples.
So we need to slice the entire the loan processing system into multiple modules and automate one by one. We identified the workflow to be automated, agreed on the UX considering that this needs to be used by non-tech savvy people and built the first version in eight weeks.
Handling Resistance
The first version was basic — support for only one type of loan — just enough to get early feedback. Our customer was embarrassed to release it to his loan officers. We were very persistent because we value Continuous learning and experimenting, so told him “let’s try this once, and later if you think releasing early is not working let’s not do that anymore”.
Once it went into production, our customer and his team saw the value of the same and got the power of “Done means Released” and “Iterative Development”.
Our customer was a programmer too, and the build pipeline gave him the confidence to change the code and deploy. Feature Toggles gave him the power of turning features on/off according to his discretion with no dependency on us.
All these were possible because of the investment we’d put in for a build pipeline to make the codebase ready to deploy anytime.
The above case studies show how Continuous Delivery can result in positive business outcomes. The focus is on the discipline of delivery, to become predictable and sustainable through iterative and incremental development.
But one question everyone may have is Where do I start? How can I implement Continuous Delivery?
Iterative and Incremental
Bear in mind: continuous delivery is not magic. It’s about continuous, daily improvement — the constant discipline of pursuing higher performance by following the heuristic “if it hurts, do it more often, and bring the pain forward.”
Paul Hammant has an exhaustive list of recommended processes that need to be followed by a team to move from very infrequent releases, say once in every few months, to one or more releases per day.
The team should start with setting up Continuous Integration in the right way. Continuous Integration is the foundation for Continuous Delivery which allows the team to integrate early and often.
More Stories
The above are the highlights of my experiences with Continuous Delivery.
If you want to hear more stories about Continuous Delivery check out the following links. It talks in detail about implementing Continuous Delivery across different domains, the challenges faced and how the teams overcame the same.
Banking on Innovation & DevOps — Capital One
Fighting the #fintech Wave with DevOps
Updated version of my earlier post published at www.multunus.com.
