Welcome to part 6 in our series on twelve-factor DevOps. In this post, we’ll get to the very heart of what it means to work in a DevOps mindset: team organization.

Factor 6: Organize

The hallmark of DevOps is that it breaks down barriers between development and operations, getting features and fixes from development to production faster and more efficiently. A recent trend is to speak of “DevSecOps”, indicating that information security needs to be in the mix, and “DevNetOps”, implying the application of DevOps principles to network operations. These terms muddy the waters; DevOps is inclusive by design, incorporating key members of each discipline, and can be applied to almost every aspect of the business.

At the beginning of a DevOps transformation, it’s likely that your teams will be composed of developers who contribute to individual projects. When their work is finished, they hand it over to operations to deploy, who in turn hand it to support to manage. These hand-offs almost always result in lost time and a lack of communication and goals which are at odds with each other result in rework. Blame-shifting is rampant.

A common first step is to form a “DevOps team” which rests between the development and operations staff as glue. This can be useful in the short-term while things are being proven and the rest of the business catches up but is by no means a final destination.

The high-functioning DevOps organization has its teams organized around a product, and each team includes members from multiple disciplines who work out of a common backlog. They all have their own role to play on the team, and they all have the responsibility to articulate their domain-specific specific needs and wants and relay information back to their peers.

How do these different groups all contribute to the product’s success?

• The product goals come from the stakeholder (typically the product owner) in the form of user stories and customer needs.
• Developers are responsible for writing the code to complete the user stories, and they need a stable environment to run it. They list what runtimes and libraries are necessary, and write the core business logic.
• The Operations personnel need to know things about how the product should be deployed and managed and they can talk intelligently about interactions with other products.
• QA must know how to test the features and ensure the product is behaving as expected.
• Staff from Security will help make sure that the code is being built and run safely. They should explain or document any potential liabilities.
• Support will have questions about any new features and how to help end-users use them.
• Finally, the Marketing team needs information about the product and its features to be able to sell the product to a larger audience.

Not every organization has all these roles. Sometimes a given discipline handles multiple responsibilities (such as Sales & Marketing, or Operations, Infrastructure, and Support), and other times there is more granularity. The product team should ideally be no larger than 5-9 people. If more people are needed, the product may be too ambitious and should be considered for splitting into multiple smaller ones.

It’s important to understand that everyone on the team doesn’t have to be cross-disciplinary themselves (it can, in fact, lead to spectacular failure), and it does not mean that the developers should be managing production operations tasks (and vice versa). Cross-training facilitates communication and can accelerate the overall process, especially on small teams, but it’s more likely that you’ll have distinct domains of knowledge. That’s okay; in fact, that’s great. A robust DevOps team structure lets people play to their individual strengths while removing barriers between them through collaboration and visibility.