Advisor

Is Merging Agile and DevOps Worth the Pain?

Posted January 17, 2019 | Technology |

A lot of attention has been directed toward merging Agile and DevOps in the last few years. The reason is simple. Packaging, deploying, and delivering software products upon their release to operations is the next step in getting products into the users’ hands. Streamlining processes and using common infrastructures and tools across the enterprise makes sense because it cuts time to market and costs. Delivery speeds up as well, since products are continuously integrated and flow nonstop from software groups to the customer through release and deployment trains.

Yet the question I often hear when suggesting combining Agile and DevOps is: how do you bridge silos, plug gaps, increase delivery pace, and get different groups to work together efficiently? My answer (based on personal success stories) revolves around implementing a Lean business process to facilitate the flow of the product from requirements through deployment using a common infrastructure, toolset, and set of operational procedures. This flow is designed to allow teams to focus on getting quality products to the user quickly, with a minimum of effort. Doctrine plays an important part in the implementation strategy because it establishes the pillars that act as the enablers for automation, user feedback, visibility, and governance (i.e., policy enforcement, security, quality). Moreover, infrastructure and tools act as the facilitator since they make it easier to automate many of the repetitive, tedious processes. Ultimately, procedures provide guidance for getting the scoping of activities done with a minimum of conflict and duplication.

This Advisor considers the development of a continuous deployment process for software by combining Agile methods and DevOps. After first looking at the salient characteristics of both techniques, we discuss why bringing together Agile and DevOps — and the resultant continuous delivery and deployment chain — is truly worthwhile.

Agile vs. DevOps

Let us review the two terms and their important characteristics. Agile refers to a group of software development methods based on iterative development, where the requirements and solutions evolve through collaboration between teams and an emphasis is placed on delivering working products that provide value. Scrum, the most popular Agile framework, uses short work sequences known as sprints and small, self-organizing teams. The focus of a sprint is on delivering working software products that generate value for the user/customer. Product rather than project management principles guide the development process. Integration testing is continuous, and products are released to operations frequently to gather feedback and demonstrate progress. In con­trast, DevOps refers to groupings of people, practices, and tools that organizations use to package, test, deliver, and deploy solutions operationally to the field.

The overall focus of combining DevOps elements with Agile development practices is on increasing the pace of products through the release train. The tactic employed is to merge business, software development, and support processes via a common infrastructure, so they can support each other. Ideally, DevOps enables the software generated by the Agile teams to be integrated and released continuously to operations using common tools and compatible processes. Whereas Agile emphasizes continuous integration and test, DevOps focuses on continuous delivery and deployment. Table 1 summarizes and compares the most important characteristics of Agile and DevOps.
 

Table 1 — Important characteristics of Agile and DevOps.

Table 1 — Important characteristics of Agile and DevOps.
 

Agile, which began in development organizations, has gradually expanded into other downstream activities, including delivery, deployment, and operations. In the merging of Agile and DevOps, teams, then “teams of teams,” then cross-functional teams, and now integrated product teams (IPTs) have been brought together and become connected. By combining and streamlining all processes, these teams have forged a workable infrastructure, embraced common tools, gathered feedback, and increased everyone’s ability to continuously deliver products at a faster pace due to merging operations and achieving efficiencies of scale. As Figure 1 illustrates, by creating a single delivery and deployment chain, an organization can focus the “efforts of many” on product deployment and operations rather than just on development and delivery. This method breaks down stovepipes to create a standard way of getting products to market.
 

Figure 1 – Continuous delivery and deployment chain for use by all.

Figure 1 – Continuous delivery and deployment chain for use by all.
 

So, Is Combining Worth the Pain?

The answer is a definite yes. When done correctly, bridging these two disciplines gets various groups within an organization working together instead of getting in each other’s way. This combination speeds time to market and reduces cost. How fast and by how much? This is difficult to precisely say because there is so much hype about the returns. The best way for me to ultimately answer this question is with my own data.

Based on data collected over the past year for 18 firms, combining Agile and DevOps to create a continuous delivery and deployment chain cuts the time needed to get a product to market by 20%-40% and reduces software deployment cost by 10%-25%. However, the combination does not reduce software development and operations costs because they are performed at a fixed staffing level. However, the mix of people and activities changes in these organizations as different groups perform tasks normally done by develop­ment personnel. For example, operations personnel in some manage the tool chain and are in charge of enterprise-wide licensing. This simple change can cut licensing costs, depending on volume, by a factor of 20%-50%. As a second example, having operations rather than development personnel take charge of packaging and distributing software frees development people to work on the backlog. This results in the number of items in the backlog being reduced by an average of 10%-30%.

In 12 of the 18 cases, a cross-functional team was chartered to lead the activity. Certainly, when merging Agile and DevOps, senior management support and funding is a pivotal issue, as is which organization leads the team. Jealousy is often an issue, too, as are personalities. Business people generally do not like it when technical team members run the show, and vice versa. The moral of the story is that you need to choose the team lead carefully and ensure that team members as well as management support your choice.

Combining Agile methods with DevOps takes time and effort to pull off. On average, it takes two to three years to transform the organization and costs an average of US $1.2 to $1.8 million. Startup time is about a year. Going operational with the new process takes the remainder of the time. The costs come from training, consultants, and personnel who are working on the initiatives.

It was interesting to note that two of the 18 firms abandoned their transformation efforts after two years because they were not realizing senior management expectations. Based on my initial assessment, this was not surprising because both firms were not ready to take the leap. Each was in the midst of organizational changes. Although both claimed to be using Agile methods, neither truly was on that path. In addition, one was embarking on an Agile-at-scale initiative. As a result, focus was scattered and management support for the effort was lukewarm.

[For more from the author on this topic, see: “Merging Agile and DevOps.”]

About The Author
Donald Reifer
Donald J. Reifer is recognized as one of the leading figures in the fields of software engineering and management, with more than 40 years of progressive management experience in both industry and government. He has built businesses, managed key programs, and led major R&D initiatives. Mr. Reifer is often called upon by clients to review troubled programs, examine red team proposals, and perform competitive assessments with an emphasis on… Read More