ACME systems evolution phase 3.0

Now that the CD and DevOps team has official backing from high up, its members start to address the broken culture and behaviors, and develop ways to overcome and/or remove the barriers. They are no longer simply a technical team; they are a catalyst for business change.

The remit is clear—do whatever is needed to streamline the process of software delivery and make it seamless and repeatable. In essence, implement what we now commonly refer to as CD and DevOps.

The first thing they do is to go out and talk with as many people across the business as possible to ensure they are also aware of the broken process and its root causes. Simply put, if someone is actively involved in the decision-making process of getting software from conception to consumer, or involved in supporting it when it's live, they are a chat target. This not only gathers useful information, but also gives the team the opportunity to evangelize and form a wider network of like-minded individuals.

The team has a vision, a purpose, that its members passionately believe in what needs to be done, and they have the energy and drive to do it.

Over the next few months, they embark on (among other things):

• Running various in-depth sessions to understand and map out the end-to-end product-delivery process
• Refining and simplifying the tooling based upon continuous feedback from those using it—where applicable, replacing in-house built solutions with off-the-shelf ones
• Addressing the complexity of managing dependencies and the order of deployment
• Engaging experts in the field of CD and DevOps to independently assess the progress being made (or not, as the case may be)
• Arranging offsite CD and DevOps training and encouraging both R&D and Ops team members to attend the training together (it's amazing how much DevOps collaboration stems from a chat in the hotel bar)
• Reducing the many handover and decision-making points throughout the software-release process
• Removing the barriers to allow developers to safely deploy their own software to the production platform
• Working with other business functions to gain trust and help them to refine and streamline their processes
• Removing the us-and-them attitudes and behaviors, and reinforcing trust-based relationships
  
• Working with R&D and operations teams to experiment with different agile methodologies, such as Kanban, scrum, and lean
• Openly and transparently sharing information and data around deliveries and progress being made across all areas of the business
• Replacing the need for complex performance-testing with the ability for developers to closely monitor their own software running in the production environment
• Removing the need for downtime to release changes
• Evangelizing across all areas of the business to share and sell the overall vision and value of CD and DevOps

This is by no means a walk in the park and it takes determination, steadfast focus, patience, and, above all, time to produce quantifiable, positive results, however after some months, the vision and benefits start to be realized. Now the process of building and delivering software has transformed to the extent that a code change can be built, fully tested, and deployed to the production platform in minutes many times per day—all at the press of a button and initiated and monitored by the developer who made the change, all with no downtime and little/no impact on the customers. The stakeholders have a trusted and reliable way of delivering value to their customers, the R&D team has the tooling and empowerment to deliver value as and when it is needed, and the Ops team has a stable and reliable platform that it can support and optimize.

Let's look again at the software-delivery process flow to see what results have been realized.