Introduction to DevOps for Business Analysts

Have you ever had a product or a feature or a system rollout fail once it reached the customers because it just didn’t meet their needs? In the IT environment, your role as a Business Analyst is up front and center in designing requirements based on both customers’ needs and changing markets. You spend much of your time analyzing needs, designing requirements, and estimating time and costs associated with getting new software releases “out the door” and into the hands of the customers. So, what goes wrong when there is a release that meets with less-than-satisfied customers? It happens all the time. There is a multitude of possible reasons for a project to fail when it deploys. (And a full discussion of all the reasons is outside of the scope of this article.) However, many times a project is considered a failure because there was so much time involved in getting it developed, tested, and deployed that the customers’ needs changed in the interim, which results in there being a lack of value in the product with the customer.

When this scenario occurs, no one is happy. The customer isn’t happy because their need wasn’t met. Operations isn’t happy because they probably had to deal with the customer’s dissatisfaction. As a Business Analyst, you aren’t happy because you thought you designed what the customer wanted. Management isn’t happy because a lot of time and money went into the project and now it is considered a waste. (Developers may or may not be affected because they did their job and got it out the door.(!)) By employing the DevOps methodology the unhappiness factor isn’t there. DevOps enables companies to deliver high-quality products with value for the customer in a timely manner and, at the same time, eliminate waste. DevOps brings the feedback from the end of the cycle up to the front end of the cycle so that quality is built in from the very beginning. This article discusses what DevOps is–in particular how it is different from the traditional way of doing business–and how important the Business Analyst’s role is in a DevOps environment.

DevOps Methodology

The goal is to meet the customer’s need quickly and DevOps delivers. How does the DevOps methodology achieve this?

• By building a high-trust, high-performance culture
• By viewing IT capabilities as strategic assets instead of overhead
• By creating cross-functional teams
• By creating a process that is highly automated
• By enabling continuous delivery of software

Let’s look at each of these.

Building a high-trust, high-performance culture

In a DevOps environment, you create cross-functional teams that have a unified mission and aligned incentives, thereby doing away with functional silos where missions and incentives are at cross-purposes. Team members have little fear of failure because failure is expected and welcomed as part of the process. Failure is seen as necessary in delivering high quality. As a result, team members experience better balance and a higher quality of their work life where they enjoy working closely. Teams are high-performing and quick to deliver. This is a very different culture than the traditional culture where each function is in a silo and has opposing missions and incentives. For example, the traditional “status quo” development silo has been rewarded by creating and getting new products done on time and budget while the traditional “status quo” operations silo has been rewarded by reducing downtime and having stable systems. When products are designed and developed without the input or feedback from either operations or end users, many times failure comes at the end of the cycle, which is extremely too late. When this happens, the process goes back to the front-end of the cycle to develop, then test, then deploy again. Costs skyrocket. Unhappiness prevails.

Viewing IT capabilities as strategic assets instead of overhead.

Teams in a DevOps environment are seen as assets where management develops pools of talent that are able to deliver quickly. This culture of valuing skill sets permeates from the top down. By seeing IT as an asset and not overhead, the entire perspective on IT changes. Everyone owns the end goal of the project. Stakeholders are more involved throughout the process and, therefore, teams are high performing and products are high quality.

Creating cross-functional teams

By being a part of cross-functional teams that are engaged in communication feedback loops throughout the project, as Business Analysts and front-end designers you can be more effective because you are more connected and involved in the entire process. The system is set up for fast feedback throughout all functions. You can build quality into the beginning—the very outset of the project—because you are informed. Designers, builders, testers, and operations all work together. This means that everyone understands the needs and goals more accurately and is more informed by people who are using the product. Traditionally, the biggest obstacle has been in the very large gap between the development silo and the operations silo. When operations isn’t part of the team, there is a huge disconnect between the design of the product and the user. With DevOps, there is no gap because everyone is on the team and working together for the common goal.

Creating a process that is highly automated

Testing must be integrated with development in order to assure the necessary feedback loop that results in continuous delivery. You cannot silo the development and the testing in a DevOps environment. Testing is part of the development. Testing even becomes part of the code and automation is incorporated wherever possible in order to streamline the process, resulting in a mature deployment pipeline. By automating tasks like testing that have historically been manual, those steps become part of the code, which allows for an integrated feedback loop to occur much earlier in the development cycle.

Enabling continuous delivery of software

DevOps prescribes a culture using automation where you follow a regular, iterative flow to push out features, projects and IT work. In doing so, you can achieve continuous delivery through shorter cycle times. This is at the heart of both Agile and DevOps. By taking minimum requirements that are prioritized for the most value, working smaller chunks, and limiting work-in-progress, you facilitate continuous delivery. In their book “Continuous Delivery,” Jez Humble and Dave Farley show how an organization can engineer software teams, IT systems, infrastructure, testing and release for fast deployment of the highest quality. Their illustration of the traditional process, which they call “Water-Scrum-Fall,” is heavy on the waterfall, traditional method of getting software created and deployed. This graphic shows how the “fuzzy front-end” where requirements are designed (“water”) leads to many inefficient iterations and hand-offs (“scrum”). The result is a quality assurance silo and IT operations silo that runs the “last mile” with many headaches leading to deployment. ***Insert water-scrum-fall slide***

Role of the Business Analyst

As a Business Analyst, you are at the front-end of the process and, as such, can impact the establishment of a new culture and workflow. In the DevOps world, the Business Analysts are a part of the cross-functional team and have immediate and ongoing input regarding the needs and progress as development, testing, and operations all work together for the common goal of providing value quickly to the customer. You can drive the method of working in smaller chunks to be more agile and deploy continuously. Limiting WIP is key to achieving the goals of continuous delivery. The Business Analysts prioritize the requirements based on those with the highest value, therefore directing the teams in their focus. This is a critical part of the continuous delivery of high-quality value releases. In summary, remember these key points where DevOps is concerned:

• Stakeholders are integrated into teams and projects.
• Quality is tied to value and is everyone’s responsibility from requirements and code creation to deployment.
• Deliver often, delivery early, learn and adapt. Roll planning into the continuous processes.
• Testing and quality assurance is not a separate function. It is a key enabler of continuous delivery.
• Expect failure and plan for contingencies.

You have a critical role that is directly impacted by the DevOps environment. However, in actuality, anyone with a stake in the outcomes of an application project is an important part of the DevOps environment!

Catherine Perry