Why organizations using DevOps tools are getting ahead of the rest

The benefits of DevOps are widely known and simple to understand. The practice brings together people, processes, engineering, operations, and technology to deliver products faster, better, and more confidently to meet business goals. However, some organizations do this better than others. Separating the leaders from the laggards is the use of tools. The teams that use DevOps tools achieve outstanding results. Our experience shows that using DevOps tools can reduce lead times to deployment by 45 percent, reduce failure rates by 50 percent, and bring down support cases by 70 percent.

With such a promising upside, the DevOps market is naturally set to balloon. Industry studies suggest that it will grow from an estimated $8.66 billion in 2022 to $47.81 billion by 2030, growing at a CAGR of 23.80 percent over the forecasted period.

Life before DevOps: Chaotic

DevOps, through the adoption of agile and lean practices, has introduced a sea change in the science and art of product development. Life before DevOps was chaotic for project managers. Miscommunication between developers and the operations team would result in haphazard development, delayed deployment, the need to constantly monitor application maintenance and performance, a lack of continuous integration, and spiraling operational costs. A simple code issue would set the project manager off to see if the data team had changed values or if the developer had a reason to change a column name and to see what the tester had to say. It was a never-ending chain of debugging—with the primary outcome being employee burnout.

Life after DevOps: Under control

This has changed. The chaos can now be brought under control. Using DevOps tools and processes, program managers can now quickly identify which code broke functionality, who wrote the code, and the time it will take to fix.

In Azure DevOps, user stories are task descriptions that are treated as work items. A developer is assigned a task and must transform the user story into a functionality. To do this successfully, the developer needs, say, a database table and an API. This information is captured in the work item, along with the relevant test cases that get updated in a tool. When the developer commits the code, it is linked to this work item.

Improving the value of DevOps

Every organization that embraces DevOps believes it has evolved as a business. In reality, these organizations, without realizing it, are living with sub-optimal results from their DevOps initiatives. The situation is comparable to that of generative AI. Every organization claims to be using generative AI. However, the value of generative AI is directly linked to the data it is trained on. If the data is inadequate, the model cannot be effective. It is the same with user stories. If the project manager does not record detailed user stories, outcomes will be sub-optimal. DevOps tools are critical to avoid this prospect.

DevOps tools allow user stories to be captured in detail. Typically, the tool will capture the features a user story needs to deliver (see Figure 1), the acceptance criteria and standards (usability, design, performance, security, etc.) that will be considered to judge if the user.

Story has been successfully executed as a feature, the difficulty level in completing the task, the developer or the team to which the task has been farmed out, dependencies/impediments, associated feature requests, time spent to deliver a task, task status, etc. These tools provide a platform to record discussions and conversations before the work item is committed as code. The complete end-to-story helps the program manager stay on top of what is happening without human dependencies. Organizations that are not using these tools cannot claim to have embraced DevOps. These organizations have only implemented an Agile process with standup meetings and scrum calls. The project manager’s role should be to ensure the tools and systems capture the details.

Once the details are in the system, a dashboard can provide a deep dive (see Figure 1): How many stories and work items do we have? How many commits have been done for a particular code snippet? What is the build health? What is the quality of the code before it is put into its environment? How many builds have been successful? Is the developer doing unit testing before pushing the code?

The barriers to benefits

Several DevOps tools are available to capture development tasks (see Figure 2). These include Azure DevOps, Bitbucket, Gitlab, GitHub, Selenium, etc., which help inject transparency into development. The challenge for the project owners and managers is to ensure the team is ready to move away from traditional development models and embrace transparency. Without a mindset change and a cultural change, the tools cannot be ineffective.

Part of the reluctance to change the mindset is rooted in a misconception. Many believe the tools will eliminate the need for humans in the process. This is not true. The tools merely show the efficiency of the process that the team is following. The tools tell us how clean the product is when it goes to market, what kind of observability we have, the time a task is likely to take, etc. Tracking this information is a huge and complicated job. The tools simplify it; they automate nothing.

Organizations need to realize—and eventually, they will—that they have been using DevOps for 15 years but have not simplified it. This is because they are resistant to change. The organizations that close the culture gap and change will move ahead. The rest will play catch-up.

How to trigger cultural change with Agile Methodology

The challenge for organizations is to address the gap quickly. Here is one way to do it: Most project managers have two or three projects to manage simultaneously. The Project Management Office (PMO) should make sure there are daily calls for each project, and the manager is forced to provide a status update. Usually, the manager is a layman, not a developer. To them, the PMO should ask, “The developer did something. Did you understand what was done?” The obvious answer is, “No!” But this is where the change can be triggered. The PMO must ask the manager to read the details from the DevOps tool and get on top of the delivery. The point is to challenge managers with simple questions, “How much time will the developer take for the next build?” or “Who do you think is the right resource for the task?” or “What are the dependencies for a task?” The answers to these questions can be generated by the tool. Many of these tools have pre-defined queries, making them simple to use.

It is easy to see that organizations that claim to have embraced DevOps may not be extracting as much from the practice as possible. Their ROI is low. For example, they may not be able to unlock the ability to experiment and innovate, deliver superior product quality, release code quickly, dramatically improve time to resolution, address unplanned work with agility, reduce the cost of production, and reduce developer burnout. To all this, there is one simple answer: Create Agile culture that uses DevOps tools like a pro.

Author:

Swetha Yalamanchili,
Head of DevOps