High Functioning DevOps Team | Part II

Part I of our focus on DevOps addressed Team Foundation and overall roles and skills that are critical to its success.  How it fits within a corporation is largely dependent upon organizational structure, and ROI in DevOps can be determined by examining certain KPIs and metrics. While DevOps teams theoretically can fit into most if not all organizational structures, some are better equipped than others to handle the only thing constant about it as a whole, that being constant change over time.

DevOps Within a Corporate Structure

While a DevOps team relies on the talents and knowledge of team members, they are not devoid of structure and leadership within organizations. Simply put, DevOps teams cannot thrive without the right organizational structure in place which supports their mission. Companies looking to adopt DevOps practices must consider their own corporate structure as either a facilitator of change or a detriment to it. There are a number of factors which influence corporate structure strategies; there is no one size fits all model. Here are a few organizational structures I have seen work in supporting high functioning DevOps teams with varying levels of success.

• Holacratic: Popularized by Zappos, this organization structure relies on completely decentralized teams or circles, eschewing individual titles and rigid structure, instead focusing on tasks that need to be completed.
• Flatarchy: It has become commonplace to see flatarchies form in startups and new businesses. A flatarchy, as the name implies, has very open lines of communication and spread leadership. The focus of flatarchies is creativity and innovation and are considered temporary structures which evolve into more traditional structures once ideas are proven.
• Functional: This bureaucratic structure groups individuals together based on skill sets and specialties. Individuals and limited to a specific set of functions which helps to limit confusion.
• Matrix: Team members here have horizontal and vertical reporting chains often balancing workloads between functional day-to-day activities and project work.
• Projectized: All work is grouped into activities and is organized into portfolios and projects. Resources move from project to project.
• Composite: Combinations of the above structures to fit the needs of the business.

In my career, I have been fortunate enough to have worked in several types of corporate structures, with a diverse client base, each operating in their own unique manner. Each of the above corporate structures can absolutely support DevOps teams but not without certain drawbacks. Flatarchies are known for innovation but run into issues scaling and can suffer from a lack of strong IT leadership. Functional teams require strong leadership and cross-department communication, which, if poorly managed, can result in silos being created and teams unwilling to work together to deliver on objectives. Matrix organizations, in my experience, can work on a large-scale basis when there are thousands of employees to manage. Resource managers must prioritize labor hours to staff DevOps based initiatives while balancing day to day operational tasks. It is a fine line. On small scale, having worked on a small team in a matrix construct, I witnessed an inherent lack of accountability across reporting lines and elevated overhead costs, which introduced unnecessary operational risk. Projectized structures, which I subjectively believe can best support DevOps efforts, rely on small, highly skilled teams, commonly referred to as ‘Tiger Teams’. Tiger Teams can quickly deliver value to organizations and work across diverse functional teams on multi-phase projects. The issue with projectized structure does involve cost. Often the resources necessary to support project-based efforts is highly skilled and typically procured and retained for a defined period of time, which if extended based on delays or extensions can add up quickly. Conversely, lulls in project work can cause issues with underutilized staff. To mitigate this risk, I have seen organizations dedicate these resources to internal process improvement-based initiatives and short-term training. This total cost is typically less significant than the overall value delivered by projectized teams.

Measuring Success of the DevOps Team

In order to know how successful investment in DevOps initiatives are, leadership needs to determine if existing efforts are meeting expectations. We can use Key Performance Indicators (KPIs) to determine high performing DevOps teams. Below are a few sample KPIs which can be used to measure performance.

Figure 3: Sample KPIs for DevOps Teams

We can also observe the success of DevOps team structure over time as individuals add new skills based on the DevOps core principle of sharing. By sharing information, DevOps teams can overcome current challenges and create institutional knowledge to ease the burden of future endeavors. One of the ways that this knowledge base can be built is by truly understanding and embracing the retrospective, a key component of scrum and AGILE methodology and a core tenant of DevOps. During retrospectives, the AGILE team reflects on what happened during the previous sprint or iteration and identifies both the success and opportunities for improvement moving forward. A high functioning DevOps team takes retrospectives seriously as a way to continuously improve. Areas where sprints could improve can become really great knowledge articles about how to overcome certain technical blockers. I have seen shared databases of retrospectives leveraged not only to help onboard new team members but queried regularly as a first time in overcoming roadblocks or root causes analysis.

Another tried and true method of sharing that most people have heard of is the concept of a lunch and learn, in which team members present on a topic, usually focusing on a success from a current or previous project. An alternative to the lunch and learn is where a project team would present on an issue currently experienced in an active project. The lunch and troubleshoot model would pull in individuals from other project teams who may have the expertise to ultimately resolve the issue. In this way, over time, there can be a sharing of skills across DevOps teams to the betterment of the company overall.

Conclusion

A high functioning DevOps team is the product of the environment which they live. Companies can get the most out of their DevOps investments by staffing the correct resources and skill sets, promoting collaboration within the team and providing the necessary structure to maximize their human capital strategy. By making the necessary investments in people, companies can achieve long term success and maximize the return on that investment.