The Case for DevOps

The Case for DevOps
Making the business case for DevOps

DevOps is a combination of processes, practices, culture, tools and technologies that when combined enhance collaboration between the development and operations team and improve the quality of design and reduce time-to-market. Your product organization may be following DevOps already or perhaps it is new to DevOps. Either way, you need to get on the DevOps train if you want to remain competitive in the digital era.

Typically, organizations fall into one of the following three categories:

New to DevOps: The organization needs to be more agile, but it doesn’t know where to start or how DevOps can help. Most of the low performers are in this category.
Maturing: The organization already follows DevOps practices, but does not meet customer expectation or is not yet in a high-performing cluster. Most of the average performers are in this category.
Mature: The organization, or a group within it, uses DevOps practices but may be having difficulty quantifying the benefits or justifying the ROI. These measurements are challenges for even the highest performers.

The first step for organizations new to DevOps is to create a business case for implementation of DevOps. The case should include both business and operational benefits of DevOps. Organizations that are already using DevOps should periodically review their practices and performance to measure their progress and, if need be, make a case for additional investment if improvements or enhancements are needed. The case for new investment should identify how the funding DevOps innovations will help move the organization up the maturity ladder to meet future business objectives.

Having self-assessed the state of your DevOps capabilities and identified your current DevOps category, the next step is to prepare your product organization to meet future demands and gain a competitive edge. The objective of first creating and then regularly reviewing the DevOps business case is to move towards the high-performing cluster. This blog aims to help you build a successful case.

Understand the Need for DevOps in Your Business

Before starting the DevOps journey, it is important to understand what DevOps will mean to the organization. It is also important to know the DevOps myths. The first step is to read case studies of leading innovators, such as Netflix and Amazon, to understand how they apply DevOps and how they benefit from it. Such insight is valuable for building a firm foundation for successful DevOps implementation.

Next, identify the challenges of meeting the organization’s unique objectives and determine if DevOps can help address these challenges. For instance, is the challenge to increase revenue, customer loyalty or boost internal delivery efficiency? In all cases, DevOps will help; you just need to focus on the primary challenge.

Articulate why you need DevOps and what precisely you are trying to solve. Answering the question, “Why are we doing this?” is more important than, “What are we going to do?” to get the development team’s buy-in and support. Sharing a gap analysis between the current state of product development and the ideal DevOps state is a valuable tool for convincing wary staff members of the need to adopt DevOps. Specifically:

■ Identify the gaps concerning people and culture
■ Identify the gaps in process and technology
■ Identify the automation opportunities

Explain how the organization can reinvest saved staff-hours in experimenting with new features, understanding the customer by improving business intelligence or making small, continuous kaizen-based improvements.

Understand Your Customers and Define Business Objectives and Goals

One of the very first recommended activities is to improve your understanding of the end customer and to be empathic to their needs. Once that understanding has been codified, create a strategy for meeting those customer needs, identify the objectives and define the goals. Make sure the entire team-from development to operations-is on the same page. Though difficult to achieve, this shared mission is fundamental for the implementation and long-term success of DevOps. It may require forcing cultural change, such as creating cross-functional teams that collaborate and work together to achieve a common goal. There should be no barriers or conflicting goals or priorities between the teams involved.

It is important to define success upfront. For example, success could be defined as being able to respond to customer feedback within a certain number of hours. It could mean recovering from failures within X seconds; growing revenue by x% month-on-month; or increasing the user base by x% every month. Whatever the definition of success, organizations should be able to quantify the goals and keep track of performance against the goals.

The set of success metrics should be shared with all stakeholders. There should be no contradictions between the goals of the development, testing and operations teams. Also, the goals and performance metrics should be transparent and communicated graphically to stakeholders across the organization. There should also be goals for sharing internal learnings and making small kaizen-based improvements.

Understand the ROI of DevOps for Your Business

The most important question you’ll get from business leaders about DevOps-or any process improvement project, for that matter-is, “What is the return on investment?”

It is relatively easy to calculate a DevOps ROI for businesses where revenue is directly connected to your product performance. At times, it may not be possible to measure ROI monetarily. Instead, it might be measured in terms of staff time savings, where ROI would be dependent on how the saved time is reinvested.

The State of DevOps Report 2016 breaks down ROI into two categories:

■ Savings - This will be an immediate gain and may include:
12345Cost of downtime. This is a standard calculation for any organization. According to a 2015 IDC report, hourly downtime costs range from $1.25 to $2.5 billion for a Fortune 1000 firm. The average cost of a critical application failure is $500,000 to $1 million per hour. Because of the size of the expense, this is a critical item for calculating ROI.[1]
12345Cost of excess rework. Again, most organizations have a standard way to measure this. According to the State of DevOps Report 2016, high-performing teams spend the least amount of time on unplanned work and rework, estimated at about 21%. As a result, they can spend 49% of their time on new work, such as new features that add value to the business. The remaining 30% of their time is spent on maintenance, customer and team meetings, internal workshops and other routine tasks.
Value - This is generally created over the long-term and may be generated through:
12345Faster releases. Potential revenue and new customers gained from releasing software more quickly.
12345● Innovation. Gains by reinvesting the productivity on new tasks and innovation.
12345● Happier staff. Increased morale motivates employees to go the extra mile to help the organization, but is difficult to quantify.

Identify and Define Metrics and Measure the Success of It

Once business goals and objectives are defined, the next step is to specify how those goals and objectives will be measured and how individual performance is assessed and rewarded in a DevOps organization.

If the success and benefits cannot be measured, they may not be sustainable. Organizations should review their metrics and align them with the core business objectives and expected outcomes. Uncertainty is reduced when employees know and understand their common goals and how they will be measured.

Implementing DevOps is meaningful only if it helps the company or the team reach the stated business goals and objectives, so getting the metrics right is critical. In many enterprises, performance metrics often capture conflicting business priorities; these conflicts must be resolved.

For example, management might judge the success of the business by measuring the number of customer changes, the time it takes to provide feedback to customer questions, and how quickly these questions are addressed in production. However, operations management might measure success by how few changes there are in production.

In this case, if the operation’s change control board does not know about the business objectives, it might review the change and reject it. In fact, employees could be rewarded for stopping the change. However, this is inconsistent with the business objectives, and hence such decisions from the change control board need to be challenged. DevOps is meant to enhance the trust between the groups due to early involvement and a strong collaboration culture, which is contrary to the legacy change control board’s mission and approach.

Some new metrics that should be brought into the DevOps environment include:

Volume of change/work. Measure how many customer feedback notices, user stories or lines of code are completed every day/week/month.
Deployment frequency. Measure how often software is deployed into production.
Uptime/Downtime. Measure the rate of both uptime and downtime monthly.
Lead time. Measure the time between receiving a user story or feedback, and the time the change is deployed into production.
Mean time to repair (MTTR). Measure the time it takes to recover from production failures.
Increase in application performance in each major release. Measure how much performance improvement has happened after the last major release. This lets the team focus on non-functional aspects.
Increase in user volume month-on-month. Measure the rate of growth of new users. It is also important to measure how actively the users are using the software.
Increase in revenue month-on-month. Measure the rate of growth of revenue. However, sometimes the product revenue information may not be visible to the technical team. In such cases, revenue can be measured indirectly. Though these indirect metrics may not accurately represent the change in revenue, they can be used as indicative performance metrics. For example, by measuring:
12345● Reduction of customer complaint calls
12345● Increase in online orders versus offline orders
12345● Increase in inquiry to order conversion rate
Retention rate. Measure staff morale by monitoring the attrition rate.

Remove Bottlenecks and Non-value-add Steps in the Delivery Pipeline

In many organizations, the DevOps process is followed without questioning or analyzing how it relates to the software value chain. The process steps and delivery items that do not add value should be isolated and removed. The sources of inefficiencies in the delivery pipeline should be trimmed down. Each step in the process and each delivery item should be categorized as one of three types:

Value add. Typically, a feature that directly and positively impacts the customer.
Required waste. For example, rework is required because of a quality issue uncovered late in the process or during regression testing. Manually documenting the test results is also an example of required waste.
Pure waste. Typically, the development of functionality that the customer does not require.

In addition to optimizing the pipeline by removing waste, it is important to smooth the flow from start to end. The wait time between process steps should be minimized, and resource capacity should be adjusted to reduce the backlogs.

For example, the process of provisioning physical resources is time-consuming and can interrupt the flow. Therefore, it is recommended to use software-defined infrastructure to expedite the process and make it repeatable. Another example is the issue of capacity. The development team might be capable of developing five features at a time but only can test two at a time, which causes a slowdown in the flow resulting in a backlog in the testing queue.

Identify the Automation Opportunities

At each stage of the delivery pipeline, organizations must be on the lookout for automation opportunities. Some of the DevOps processes ripe for automation include:

■ Continuous testing
■ Continuous integration
■ Continuous delivery and deployment
■ Continuous monitoring

Organizations should plan to automate and introduce a process of continuous improvement at appropriate stages along the pipeline. Automation makes the process reliable and repeatable, drives the delivery velocity higher and improves efficiency across the business.

Identify the Business Constraints

It is advisable to create a DevOps business case with minimal constraints. However, once the business case is complete, the team should prioritize the rollout of practices based on business priorities and constraints such as budget to yield maximum benefit. Here are three common constraints to consider:

Investment. It is important to have a rough estimate of additional investments required to implement DevOps-such as resources required for automation-as well as a schedule for when and how the organization can achieve the planned ROI. Knowing the schedule will allow the team to manage the implementation incrementally.
Resources. The team should ensure it has sufficient resources to implement DevOps, including people, tools and technologies.
Compliance. There may be cases where some of the processes cannot be changed for compliance reasons. For example, an external operations-specific change control board may be required to participate due to compliance reasons.

Emphasize the Benefits for All Stakeholders and Identify Cultural Changes Required That Create the Least Friction

There is a close relationship between employee engagement and organizational success. The same applies to the rollout of DevOps. The success is based on how wholeheartedly people adopt and support the new process. DevOps gives more importance to this principle by aligning the people and culture with the DevOps core pillars. When team members are enabled, they perform at their maximum potential and innovative ability. As a result, they feel like an important part of the organization.

One useful metric is the employee promoter score, which measures an employee’s willingness to recommend their organization to others on a 1-10 scale. The aggregate score provides a fairly accurate indication of how the DevOps initiative is faring.

The State of DevOps Report 2016 found that employees in high-performing organizations were 2.2 times more likely than low or moderating performing organizations to recommend their organization to a friend as a great place to work, and 1.8 times more likely to recommend their team to a friend as a great working environment. Other studies have shown a high aggregator score correlates with better business outcomes

Identify and Highlight the Value Realized

It is important to identify the potential incremental value that would result from following DevOps practices. Some of the common examples of the added value DevOps delivers include:

Increased agility. Developing a culture, practices, process and automation enables faster, more efficient and more reliable software delivery to production. When adopted as a business capability, DevOps provides the tools and culture required to facilitate efficient release planning, predictability and success. The definition of value varies from organization to organization and even from project to project, but the goal of DevOps is to deliver this value faster and more efficiently.
Improved innovation. Reduction of waste and rework shifts resources to higher-value activities. An example of a common practice in lean thinking is A-B testing, in which organizations ask a small group of users to test and rate two or more sets of software that have different capabilities. Then the better capability set is rolled out to all users, and the unsuccessful version is rolled back. Such A-B testing is realistic only with efficient and automated mechanisms such as those that DevOps facilitates.
Enhanced customer experience. The business gets the capability to respond to customer feedback promptly and in a well-engaged manner. This improves customer experience and loyalty. Experts say, “If we do it right, it provides customer delight.”
Stability improvements. DevOps recommends releasing a small set of features often. This approach means there will be no big surprise at the end of the process. Also, the practice enables the organization to switch back quickly if the release fails, which helps in improved MTTR.
Ability to deal with complexities. Enterprise applications are so diverse and composed of multiple technologies, databases, end-user devices and so on that only a DevOps approach will be successful when dealing with these complexities.
In fact, without DevOps processes and practices in place, having a huge product in microservices architecture is difficult to maintain.
A high-morale team. DevOps success requires a trust-based culture with a lot of collaboration. There will be no conflicting priorities or communication barriers if it is done right.


While the depth of DevOps implementation may differ between organizations based on business and customer needs, being more efficient, agile and responsive in the end-to-end software development, testing and deployment process is not an option that can be ignored. The first step on the journey is to create a business case for investing in DevOps.

The objective is to improve the organization’s performance and drive profitability. The return on the DevOps investment is measured in financial terms, but the value extends deep into the organization: improved employee morale, higher customer satisfaction and loyalty, and productivity improvements that drive investment in new areas.

In summary, the DevOps business case typically includes:

■ Briefing
■ Current State
12345● Where is the organization today?
12345● Self-assessment report
12345● Competitive analysis
12345● Potential business missed if current practices are left in place
■ Business Drivers
■ Future State
12345● What does the future state look like?
12345● Value added to the IT organization, business and end customers
12345● Waste avoided
■ Recommendations to exceed customer expectations
■ Different approaches of DevOps to take
■ Investment required in people skills, training, tools and technologies
■ Required support and decisions from management
■ Assumptions
■ Return on Investment
■ Next Steps


■ State of DevOps Report 2016
■ 2016 Cloud Automation and DevOps Report
■ Getting started with DevOps: Build the Business Case


Leave a Reply

Your email address will not be published. Required fields are marked *