The famous depiction of Dev handing off work to Ops over the wall is etched in the minds of early adopters of DevOps. It demonstrated the need to merge Dev and Ops teams into unified DevOps teams to better collaborate on releasing applications at high velocity. But in reality, for almost a decade now, DevOps adoption has been focused on engineering automation to develop CICD pipelines for applications. Thus, building unified DevOps teams took a backseat.
In retrospect, it was probably the right approach for that period as, without end-to-end automation, the velocity of releases was not high enough to demand a merged Dev and Ops team. By working in agile iterations, the size of releases was reduced, but manual activities and handoffs still resulted in longer release cycles. Multiple agile sprint cycles were then grouped together to form a final release. Essentially, without faster releases, there was no need for Dev and Ops to collaborate frequently and thus the need to break the wall between Dev and Ops was not felt.
But with CICD automation, and in some cases extreme hands-off automation, increased release velocity has become a reality. Release frequency has improved from once every nine months to once a week or even faster, on-demand. These high-velocity applications now have to take note of frequent handover challenges from Dev to Ops to support newer releases. There is increasing pressure on Ops teams to maintain the same service levels in production despite the change with frequent releases. This increasing frequency of application releases has made unified DevOps teams a strong argument in favor. And we see more and more organizations looking to form such teams for their digital applications at a minimum.
Associate Vice President and Head of DevOps COE at Infosys Limited.
Challenges in building a unified team and how to address them
However, creating unified teams isn’t as simple as having development and operations teams sit together at the same table and calling it one team. There are a few key considerations for building successful unified DevOps teams.
First, unless an explicit effort is made to change the culture and mindset, it won’t be easy to get development and operations teams to work on each other’s tasks with equal commitment. A mindset shift is necessary to get them to realize the larger goal and overcome the barrier of rating certain tasks as superior to others. A good “DevOps coach” can help change this mindset through techniques such as enablement, business interactions, establishing common KPIs and metrics for the entire team, and removing any performance measurement for individual development or operations tasks.
Secondly, the “DevOps coach” needs to be supported by an organizational change where a common product owner is identified for a unified DevOps team. The product owner who understands the importance of Dev and Ops tasks and can prioritize one over the other based on business needs plays a crucial role in the team. Without a common product owner, there will always be a task prioritization challenge and teams will continue to play individual Dev or Ops roles.
Thirdly, simply forming a team combining Dev and Ops will not result in a team of DevOps professionals. Both Dev and Ops require cross-skilling through a very structured training approach. It is not just a simple goal to teach a developer how to perform Ops tasks and vice versa. Developers will also need comprehensive training on support processes, SLAs, problem analysis, and troubleshooting. Most importantly, they need broader domain and system knowledge to locate and resolve issues correctly. Similarly, it is not just about allowing Ops members to code – as there are different Ops support levels such as L1, L2, and L3 which have their own levels of coding expertise, it is not practical to expect all of them to start coding. The “DevOps coach” should create a plan for each Ops support level with the goal of gradually adding Dev activities. For example, L3 support staff can probably learn to code very quickly and start contributing to user stories. But a level 2 person can’t start working on user stories straight away, so a gradual learning path that first allows them to work on level 3 tasks and then on user stories would be better. A good DevOps coach can create custom learning paths and a plan for roles and responsibilities to ensure that we get a truly cross-functional team over time.
Finally, while it seems easy to put a training plan on paper, finding time for busy Dev and Ops teams to learn new skills and work on other DevOps tasks without impacting their current velocity or SLAs is a difficult task. Where do they start first? Should some of the developers’ user stories be deprioritized and they asked to contribute to Ops tasks so that Ops has the bandwidth to learn coding skills? Or do Ops members take the lead? A good DevOps coach can make contextual decisions about how to create enough bandwidth for teams to cross-skill with minimal impact on the business.
Transformation of people
In short, if one thought that CICD engineering automation was the hard part of DevOps adoption, that is definitely not the case. People transformation has always been a very subjective topic and does not come with a predefined formula for success. Forming unified DevOps teams is much easier said than done. But paying close attention to how these teams are built under the guidance of a competent DevOps coach can amplify the benefits of DevOps for any application.
Introducing the ultimate collaboration platform for teams.
This article was produced as part of TechRadarPro's Expert Insights channel, where we showcase the brightest and brightest minds in the tech industry today. The views expressed here are those of the author, and not necessarily those of TechRadarPro or Future plc. If you're interested in contributing, find out more here:
