Topics In Demand
Notification
New

No notification found.

Why organizations using DevOps tools are getting ahead of the rest?
Why organizations using DevOps tools are getting ahead of the rest?

May 17, 2024

232

2

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?

devops KPI metrics dashboard with total builds
Figure 1

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.

enterprise agile devops platform
Figure 2

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.

 

agile methodology
Figure 3

About the author:

author image
Swetha Yalamanchili 
Head of DevOps - ITC Infotech

With expertise in cloud foundational services and strategic initiatives, I specialize in architecting and strategizing solutions for digital transformation. My skills include Legacy Application Architecture assessment, conducting Cloud Feasibility, and Cloud Suitability Assessments for migration to Cloud Platforms. I bring a demonstrated history of success across various industries, including retail, hotel, insurance, gaming, and transportation. My experience encompasses cloud computing and deployment strategies tailored to optimize operations and drive business growth in dynamic environments.


That the contents of third-party articles/blogs published here on the website, and the interpretation of all information in the article/blogs such as data, maps, numbers, opinions etc. displayed in the article/blogs and views or the opinions expressed within the content are solely of the author's; and do not reflect the opinions and beliefs of NASSCOM or its affiliates in any manner. NASSCOM does not take any liability w.r.t. content in any manner and will not be liable in any manner whatsoever for any kind of liability arising out of any act, error or omission. The contents of third-party article/blogs published, are provided solely as convenience; and the presence of these articles/blogs should not, under any circumstances, be considered as an endorsement of the contents by NASSCOM in any manner; and if you chose to access these articles/blogs , you do so at your own risk.


ITC Infotech is a leading global technology services and solutions provider, led by Business and Technology Consulting. ITC Infotech provides business-friendly solutions to help clients succeed and be future-ready, by seamlessly bringing together digital expertise, strong industry specific alliances and the unique ability to leverage deep domain expertise from ITC Group businesses. The company provides technology solutions and services to enterprises across industries such as Banking & Financial Services, Healthcare, Manufacturing, Consumer Goods, Travel and Hospitality, through a combination of traditional and newer business models, as a long-term sustainable partner. ITC Infotech is a wholly owned subsidiary of ITC Ltd. ITC is one of India’s leading private sector companies and a diversified conglomerate with businesses spanning Consumer Goods, Hotels, Paperboards and Packaging, Agri Business and Information Technology. For more information, please visit: http://www.itcinfotech.com/

© Copyright nasscom. All Rights Reserved.