DevOps principles have been adopted with varying degrees of success in organizations. What constitutes a successful DevOps team and how can organizations structure their DevOps team to achieve designated business outcomes?
The successful DevOps team first and foremost embodies the DevOps core principles which I have addressed in a previous entry, focusing on open communication and a culture of accountability, sharing of skills and information, automation, adoption of lean and AGILE principles and proven effectiveness by real-time metrics and measurements.
Figure 1: DevOps Core Principles
Organizations with high functioning DevOps teams have reaped the benefits of their investment in human capital and organizational transformation. According to Puppet’s 2016 State of DevOps report, organizations who have committed to adopting DevOps principles have been able to:
- Decisively outperform their peers, deploying 200 times more frequently, with 2,555 times faster lead times, recover 24 times faster, and have three times lower change failure rates
- Achieve improved employee loyalty, as measured by employee Net Promoter Score (eNPS)
- Spend 22 percent less time on unplanned work and rework and 29 percent more time on new work, such as new features or code
- Invest in lean management, experimental product development, and continuous delivery to create sustainable value creation (1)
DevOps Team Foundations
When considering the need for a DevOps team, whether to implement some form of automation within an organization or to apply its capabilities to an existing product or service, one must first understand exactly what problem is going to be solved. In my experience, DevOps teams are outcome-based, and those outcomes are largely dictated by the business since they determine any perceived value-add.
Achieving any outcome requires cross-functional team membership from IT, largely categorized as Development, and the business, or Operations – hence the name DevOps. Matthew Skelton elegantly depicts several of these interactions of Development and Operations.
Figure 2: Collaborative DevOps Models (2)
While it is evident that the intersection of Development and Operations can take one of many different forms that can evolve over time, the main takeaway here is that a high functioning DevOps team requires a productive, collaborative relationship between business and IT that results in shared accountability. These collaborative efforts are noted in the green box above. Teams are more likely to fail in their objectives by developing a silo mentality or by seemingly ignoring the needs of key stakeholders, as depicted in the red box.
Gone are the days that developers build systems and pass them over to operations to support and simply wash their hands of user experience or any issues which arise. There is an inherent level of apathy in DevOps teams based on their collaborative structure. When Developers sit with business users they can experience various pain points first hand and they can experience alternate viewpoints. This type of apathy can be compounded when developers are expected to take part in on-call support, handle alerts, and address outages should they arise. A high functioning DevOps team adopts a, ‘We build it. We run it.’ mentality.
DevOps Team Roles
Once the business and IT collectively identify a problem to solve, it is imperative that the DevOps team has the right roles assigned and inherent skills to achieve the desired outcomes. There are various resources to add to a DevOps team, but I have found the following roles to work well in high functioning teams:
- DevOps Change Champion: Works with the cross-functional team to determine the value added by IT to the business based on DevOps initiatives. Also coordinates and manages releases of products and services.
- Automation Architect: Designs and implements continuous integration and continuous delivery strategies and core technologies which support the strategies.
- System Engineer: Works closely with the automation architect. Implements automation of identified pain points as a part of the overall automation strategy.
- Software Developer: Completes business requirements in a collaborative effort with business SME.
- Quality Engineer: Monitors and tests code per business requirements using automation. Ensures system can scale and perform to meet the business need before deployment to production.
- Customer Experience (CX) Engineer: Works closely with the Change Champion to monitor releases and prioritize the user experience in feature development and delivery.
- Security Engineer: Security is always a priority. Coordinates with all team members to prevent and eliminate system vulnerabilities.
- Business Subject Matter Expert (SME): Key stakeholders and team members who have substantial operational knowledge. Largely determine of the value being created by DevOps teams. Supply requirements for continuous improvement at a service level.
Having established the foundation of DevOps and the roles and skills that are critical to its success, we can next examine (in Part II) its place within the corporate structure, as well as the metrics and KPIs that indicate ROI in DevOps.
References:
- (n.d.). 2016 State of DevOps Report. Retrieved January 25, 2018, from https://puppet.com/resources/whitepaper/2016-state-of-devops-report
- Skelton, M. (2016, April 10). What Team Structure is Right for DevOps to Flourish? Retrieved January 25, 2018, from https://blog.matthewskelton.net/2013/10/22/what-team-structure-is-right-for-devops-to-flourish/
