“With the rise of the serverless movement, you only have to care about code”
It’s very easy for organizations to pick good practices from forward-looking companies and put them here and there, but truly effective teams are those that constantly question the status quo. We asked Eduards Sizovs, the leader of the Latvian Software Craftsmanship Community, to comment on the myth of one-size-fits-all Continuous Delivery, the importance of automation and more.
“Continuous Delivery is a journey.” Organizations are complex systems, but if people and departments do not share the same goal, they are bound to fail. We continued our discussion with Eduards Sizovs, the leader of the Latvian Software Craftsmanship Community, about the importance of Continuous Delivery, what it’s like to tailor it to fit your company’s needs and the myths revolving around automation.
JAXenter: Is Continuous Delivery the best way to deliver software?
Eduards Sizovs: I find it hard to define what the best way really is, as “the best” for one company can destroy another. Every organization must find their own delivery sweet spot and should be constantly questioning their fitness. The latter is critically important. It’s so easy to pick good practices from forward-looking companies and put them here and there, but truly effective teams are those that constantly question the status quo. They continuously evaluate tools, processes and globally accepted best practices with a strict rigor. We have to remember that there is no such thing as best way of doing anything, even though vendors do their best to prove you the opposite. Will your delivery methodology be the same for an intranet back-office application and an HFT system? I hope it won’t. What is good for HFT will be an overkill for back-office application. What makes back-office customers happy will unlikely be satisfactory for demanding HFT market.
For large organizations, Continuous Delivery is still a challenge.
Always remember that the best (and fancy) is the biggest enemy of good. “The good” solves current problem, implemented in a reasonable time and is gentle to the budget. I seldom see “the best” satisfying mentioned criteria, as catching “the best” is like infinitely catching your own tail. Good for you is the best.
Returning to the original question. Early and continuous delivery of valuable software is our highest priority, as Agile Manifesto and common sense says. Lower-case continuous delivery is not the best way – it’s de-facto, mandatory, not negotiable. Capital-case Continuous Delivery with its surrounding practices is a context-specific choice.
JAXenter: From your experience, how do people respond to the idea of automation?
Eduards Sizovs: As long as automation does not put someone’s work at risk — people are happy. Sometimes automation makes some roles obsolete. It’s important to understand that automation makes roles obsolete, not people. I was once working on a testing automation initiative in a large corporation. Traditionally to silo-ed organizations, senior-principal-lead manager of a testing department was responsible for coordinating all the testing activities. It was a body shop inside the organization, where one had to beg the manager to lease a test engineer for a project purpose. Imagine how upset the manager became when the company announced its transition towards cross-functional teams, where every team has its own testing professional. Acts of non-constructive criticism and sabotage have been followed by a resignation letter. Boom!
We must be flexible enough to adapt, switch roles and take new responsibilities, otherwise progress will always make us feel uncomfortable. Learn how to automate or be automated out!
JAXenter: How important is measurement when putting CD into practice?
Eduards Sizovs: Measurements are extremely important. How do we set goals and objectively measure the impact otherwise? For example, we can easily measure how long it takes for a build to pass. Say, the build passes in five minutes and our goal is to reduce build time to three minutes at most. So easy! Lead time, cycle time, number of issues, MTTD, MTTR are relatively easy to measure and many companies I work with do that.
For trivial working environments and projects, Continuous Delivery is becoming a commodity.
Some experiments are not easy to measure, though. For example, how can we quantify happiness? Imagine a team has started meeting with a customer much more often that before. Everybody feels that communication has improved significantly, but can we really measure the impact objectively? Actually, we can! By implementing a mechanism similar to Spotify’s Squad Health Check model, we can go beyond naked, emotionless numbers and start measuring seem-to-unmeasurable, like work dynamics.
During the transition to continuous delivery, many (if not most) changes are non-technical. We take extra responsibility, becoming more accountable, reducing the ego in favor of the team, staying out of the comfort zone. Management usually asks me how to measure the impact of a non-technical work. A simple survey with a single Net Promoter Score (NPS) question can reveal the whole picture:
How likely are you to recommend your delivery team to another business unit?
The measurement is quantitative and is very hard to trick. I encourage you to run similar surveys in your organization regularly to see how well your teams go.
JAXenter: Is CD still a theoretical concept or are we beginning to see its benefits?
Eduards Sizovs: Many teams have been working in accordance with continuous delivery even before the book came out. For trivial working environments and projects, Continuous Delivery is becoming a commodity. The toolset is mature and you can build deployment pipelines of any complexity either completely free of charge or at a very low cost. The completely automated deployment pipeline that provisions infrastructure, builds, tests, deploys and monitors app can be built quickly without the need of deep technical expertise. In fact, with the rise of the serverless movement, you don’t even have to care about anything, but code. With Amazon Lambda you can build and run an application without the hassle of virtual machines, containers or any infrastructure for that matter. Isn’t that awesome?
For large organizations, CD is still a challenge. Most of the issues hide under the accidentally complex organization structures. Slowly but surely, fast-growing rivals are forcing corporations to change their structures, re-organize in order to accelerate product delivery and keep up with the market demand. I am very excited to be part of that change!
Thank you very much!