Dave Farley and Jez Humble talked at DeliveryConf about their expectations for the next ten years of Continous Delivery (CD). For CD to succeed, the IT industry needs to focus on three performance aspects: technical, organizational, and cultural. All of these are profoundly interrelated. DORA's report has shown that technical practices can lead the change, but they alone aren't enough.
Ten years after the book "Continous Delivery" by Farley and Humble, many new technical practices have emerged, such as distributed tracing, chaos engineering, and traffic shifting. Their book has a focus on the software deployment pipeline. However, they've seen organizations creating pipelines for each environment, and this is an anti-pattern of CD. What they initially argued for is to have a mechanism where changes come in one end of the pipeline, and releasable software comes out to the other end. In other words, the continuous delivery of ideas with quick feedback from users to validate the outcome. As Farley said: "teams need to have a great story on these technical practices to have great technical performance, which is a necessary driver for CD."
Additionally, teams need to have a better structure that helps them to collaborate more effectively and give them enough autonomy to deliver continuously; this is what Farley defines as organizational performance, and it's essential for success in doing CD on any scale. Moreover, according to Farley, having great cultural performance helps to focus on aspects like the team's behaviors, diverse thinking, and technical rigor.
All of these aspects–technical, organizational, and cultural performance–are interrelated. Farley said that "organizations can't succeed on doing CD at one of these aspects without the others." To highlight the importance of these aspects, Farley referenced an article from the Harvard Business Review magazine, which presented several impediments of embracing agile: "the greatest impediment is not the need for better methodologies, empirical evidence of significant benefits, or proof that agile can work outside IT, it is the behavior of executives."
One way of thinking about the problems of delivering software is to use the model from "The Art of Action" book by Stephen Bungay. Organizations are trying to achieve an outcome, and they need to have a plan, which is then carried out in order to achieve the expected outcome. Nonetheless, there are gaps in this model, such as knowledge level, people alignment, and the effects of the outcome. Farley said: "You can't close those gaps, but you can work to reduce them" by doing things like limiting the batch size of work.
According to Farley, software development is driven by learning and managing complexity, and organizations need to optimize for these drivers. For instance, to optimize learning, organizations can learn by employing feedback, working incrementally, running experiments. To manage complexity, organizations can implement architectural properties like modularity, separation of concerns, cohesion, or loose coupling. In other words, as Farley put it, "it's about engineering, applying rational scientific thinking to solving practical problems within economic constraints."
Additionally, Humble stressed the importance of getting feedback quickly when doing CD because "most of the ideas could be bad ideas when organizations are innovating." Feedback is critical to know if these ideas are right or not–as they could be variable and uncertain. Moreover, this feedback fosters experimentation. In the book "Accelerate," Nicole Forsgren, Jez Humble, and Gene Kim talk about product delivery and the importance of feedback: "Product delivery is about building an engine that gives you quality feedback promptly, enabling a deterministic flow from development to production, this is the engine where product ideas bake in."
Finally, one of Humble's expectations for CD is "that people do CI (Continuous Integration) in a way that CI is defined." This means the developers are doing check-ins into a master branch or integrating feature branches to a master branch at least once a day. If the build breaks, it's typically fixed within ten minutes. And also, having reliable automated testing as CI relies on it to validate every application code change.
At the end of the talk, there was an open-space to continue the discussion on what CD will look like in the next ten years. The audience discussed the challenges, successes, and what they would like to see.
DeliveryConf: What are the strategies to change the behavior of executives to adopt CD?
Audience: Do a cost analysis (an ROI), where you can put a number on it. This helps to make a case for it when talking to an executive so that they see that CD has a business value.
Farley: It's important to change to tone of the conversation. You're not going to win the hearts and minds of senior people in an organization by talking about technical strategy or deployment pipelines. We need to talk about business impacts or the ability to evolve.
Audience: Overall, you have to generate an emotional response to change your business. Many times I've seen the ROI approach. While that can be valuable, it just doesn't go quite far enough to change the culture, like the old say "culture eats strategy for lunch."
DeliveryConf: What successes have you had in this area?
Audience: In my organization, we used to have a huge script that delivered beats once you build them somewhere on the shared. So, I volunteered personal time to improve the pipeline.
Audience: The power of example is really useful in terms of bringing more people on board.
DeliveryConf: What would you want to see in 2-5 years?
Audience: I’d suggest a focus on training those (employees) that are in the company. Make an investment there.
Audience: CEOs to hold us accountable on the financial outcomes when we prove the benefits of better CD practices do accept that and take for what is forth rather than saying: "well, that’s not how we have done things before."
What do you think the upcoming years will look like for CD? Please share your comments below.
