The Reality of Building Successful, Unified DevOps Teams
The famous image of Dev throwing work over the wall to Ops is etched in the minds of early DevOps adopters. It demonstrated the need to merge Dev and Ops teams into unified DevOps teams to better collaborate for rapid application releases. But in reality, DevOps adoption for nearly a decade has focused on engineering automation to develop CICD pipelines for applications. As a result, the creation of unified DevOps teams took a back seat.
In retrospect, it was probably the right approach for the time period, as the velocity of releases without end-to-end automation wasn’t really high enough to require a merged Dev and Ops team. Working in Agile iterations reduced the size of releases, but manual activities and handoffs still resulted in longer release cycles. Multiple Agile sprint cycles were then merged together to form a final release. Essentially, without faster releases, there was no need for Dev and Ops to collaborate frequently, and therefore the need to break down the wall between Dev and Ops wasn’t felt.
But with CICD automation and, in some cases, extreme no-touch automation, the increase in release velocity has become a reality. Release frequency has improved from once every nine months to once a week or even faster, on-demand. Such fast-moving applications must now consider the frequent Dev-to-Ops handover challenges to support newer releases. There is increasing pressure on Ops teams to maintain the same service levels in production, despite the flux of frequent releases. This increasing frequency of application releases has created a strong case for unified DevOps teams. And we are seeing more and more organizations strive to at least form such teams for their digital applications.
Associate Vice President and Head of DevOps COE at Infosys Limited.
Challenges in Building a Unified Team and How to Overcome Them
However, creating unified teams isn’t as simple as putting Dev and Ops together and calling them one team. There are a few key considerations for creating successful unified DevOps teams.
First, unless there is an explicit effort to change culture and mindset, it will not be easy to get Dev and Ops to work on each other’s tasks with the same dedication. A mindset shift is needed to help them realize the bigger picture and overcome the barrier of evaluating certain tasks better than others. A good ‘DevOps coach’ can help change this mindset through techniques such as enablement, business interactions, setting up common KPIs and metrics for the entire team, and removing performance metrics for individual Dev or Ops tasks.
Second, the “DevOps coach” must be supported by organizational change that identifies a common product owner 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 the needs of the business plays a critical role in the team. Without such a common product owner, there will always be a challenge to prioritize tasks and teams will continue to play individual Dev or Ops roles.
Thirdly, forming a single team by combining Dev and Ops will not result in a team of DevOps professionals. Both Dev and Ops require cross-skilling through a highly structured training approach. It is not just a simple goal to teach a developer how to perform operations tasks and vice versa. Developers also need extensive training on support processes, SLAs, problem analysis and troubleshooting. Most importantly, they need broader domain and system knowledge to properly pinpoint and resolve issues. Similarly, it is not just about empowering operations members to code, since there are different levels of operations support such as L1, L2 and L3 who have their own levels of coding expertise, it is not practical to expect them all to start coding. ‘DevOps coach’ should create a plan for each level of operations support with a scope of gradually adding Dev activities. For example, L3 support staff can probably pick up coding very quickly and start contributing to user stories. But an L2 person can’t pick up user stories right away, so a gradual learning path that allows someone to work on L3 tasks first and then on user stories would be better. A good DevOps coach can create such customized learning paths and role-responsibility plans to ensure that we get a truly cross-functional team over time.
Finally, while it may seem easy to get a training plan down on paper, it’s tough to find time for a very busy Dev and Ops team to learn new skills and work on other area tasks without impacting their current velocity or SLAs. Where do they start first? Should you deprioritize some of the developer user stories and ask developers to contribute to Ops tasks so that Ops has the bandwidth to learn programming skills? Or should 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.
People transformation
In summary, if anyone thought CICD engineering automation was the hard part of DevOps adoption, that is absolutely not the case. People transformation has always been a highly subjective topic and does not come with a predefined formula for success. Forming unified DevOps teams is much easier said than done. But by paying close attention to how these teams are created under the guidance of a capable DevOps coach, the benefits of DevOps can be amplified for any application.
We’ve highlighted the best collaboration platform for teams.
This article was produced as part of TechRadarPro’s Expert Insights channel, where we showcase the best and brightest minds in the technology sector today. The views expressed here are those of the author and do not necessarily represent those of TechRadarPro or Future plc. If you’re interested in contributing, you can read more here:
