Swift delivery is something that every organization is striving for. Any product or service that has a longer delivery cycle is either being disrupted by alternatives that offer faster delivery or undergoing an overhaul to speed up the process.

A major decelerator for the delivery is that the development and operations teams have been traditionally working in silos. It is more of a cultural obstacle than a functional one and software development organizations are no different. Communication between development and IT operations teams is limited to troubleshooting issues through a centralized ticketing system.

Until recently, IT and Operations did not match up to the Agile Development Team with respect to speed. Even if the developers could churn a functional code relatively early, the process was still impeded by siloed structure of testing and release departments. Shorter development iterations needed equally competent testing for seamless integration into mainline product.

DevOps has broken the silos between development, IT, and operations for an accelerated product delivery. Essentially, it is an evolved Agile methodology with Continuous Integration (CI) and Continuous Delivery (CD) being the main add-on.

With CI, developers can integrate code to the mainline continually and CD presses on the need to develop only the code that can be put to production. While there are many similar definitions proposed by different schools of thought, the main tenet of DevOps is to facilitate collaboration and break down siloed processes into functionally communicating central assets.

As per an observation by McKinsey Research, DevOps can cut SDLC from 89 days to 15 days. Through collaboration and automation, software can go live in less than 20% of the original time.

software product engineering

DevOps has facilitated collaboration across the departments of software product engineering in following three main ways:

1. Structuring Teams to be Cross-Functional

It is a common observation that team members communicate well among themselves. If the team has experts across the entire software delivery cycle, operational silos would be automatically broken.

A basic structure for a cross-functional software development team would comprise developers, testers, analysts, and database administrators. Each team member would contribute a code to the version-control or can modify a part of the software as per their assigned task.

In contrast, a siloed team would have only developers or testers with their own ways to deliver on a task. Such isolated teams are inefficient in inter-team communication and take longer to address an issue that requires collaboration. A DevOps team is focused on delivery and is evolved enough to tackle each issue as its own.

2. Employing Automation Tools

DevOps implementation in software product engineering demands efficient sharing of resources like information on framework or language used in product design. Communication tools like Slack, Planning Tools such as JIRA, Ticketing Tools like Confluence, and Automation tools like Docker or Puppet have filled in the gaps to enhance the collaboration between the teams.

software product engineering

Apart from enhancing collaboration, DevOps tools have made individual processes more reliable and transparent. Any work that is likely not to be the part of the final product or is not up to the defined standards is eliminated through continual checks or automation tools.

3. Centralizing Responsibilities

A common problem with siloed teams is lack of absolute ownership. It takes a few emails and calls to find the accountable resource and assign task for the needed. DevOps has bypassed the hassle of finding ‘who is responsible’ because a DevOps team is self-served and each team member is accountable.

In a DevOps transformation, McKinsey observed that there is almost a 50% decrease in the number of handoffs. DevOps efficiently reduces wait-time and unnecessary rework.

Due to multiskilled resources, specialist silos in software product engineering are broken. Any resource who is authorized to perform deployment can deploy the code or stop integration when needed. Versioning all artifacts like code, infrastructure or configuration helps in isolating changes and integrated change management prevents unnecessary rework.

Final Thoughts

Adopting DevOps model requires a systemic change across the organization. Such changes alter the whole IT value chain and not just the developers or testers. This reorientation requires careful planning to encourage cross-functional teams while balancing out the siloed functions during the transition.

It is also important to understand that DevOps is methodology to enhance the efficiencies but it can’t redeem an already inefficient process whose challenges are bigger than siloed teams. An experienced DevOps Consultant can help you in identifying the opportunity areas for transformation of product development process and point out the prerequisites before beginning with the DevOps way.

About the Author

gaurav_handa

Gaurav Handa VP – Service Delivery linked-in icon

Gaurav Handa, Vice President – Service Delivery, is a path-breaking professional and business savvy enterprise architect with extensive industry experience of over 18 years. Gaurav authenticates delivery of superior business outcomes for customers while formulating and delivering state-of-the-art technology and business solutions across various domains. He has always been instrumental in driving all organization-wide initiatives and bringing business efficiencies through his expertise in project management methodologies of Agile, Scrum, Waterfall and delivery technicalities of Onsite, Offsite and Offshore model coupled with excellent hands-on experience in developing and executing complex and large projects.