5 Minute DevOps: Designing Product Teams
7 min read 1379 words
http://www.picpedia.org/highway-signs/c/chaos.html
What does a product team look like? You'll hear lots of DevOps-y buzzwords: "T-shaped people," "cross-functional," or "Two Pizza Team." So, what is a viable product team, and what are some common team anti-patterns?
First, a personal irritant of mine.
<rant>
**Please stop saying "DevOps team."** DevOps isn't a job. If you have a "DevOps team" doing release management or support for you, spend time educating people on flow, feedback, and learning.
</rant>
```text
Now that we've cleared that up, a product team has a few recognizable traits:
The team has the skills and tools to build, deploy, monitor, and operate their portion of a product until the day it is turned off. Team members have no individual responsibility for components. Instead, they pull work from the backlog in a priority sequence. The team is not dependent on any outside dependencies, either technical, informational, or process, to deploy their product. If there are hand-offs, then quality is reduced, MTTR will be too high, and the team will not feel the pride in ownership required for quality outcomes.
## Anti-patterns
- **Release management team:** having another team responsible for deploying code prevents the product team from committing to deliverables and increases MTTR. It also makes release challenges opaque and prevents the team from improving their delivery flow effectively.
- **External QA:** Outsourcing testing reduces quality and delays delivery. People who understand testing should be included on the team and, rather than primarily performing tests, should assist developers with test suite design to enable rapid feedback from the pipeline.
### **Sole Source Ownership:**
The team has sole ownership of their repositories. This does not imply that the repositories should be private. Repositories should be openly readable unless there is a security risk. Teams need veto power over any change made by an outside contributor to ensure those changes meet the team's quality standard. The team owns quality. Larger products should be divided among teams in a way that allows each team to have sole quality responsibility.
#### Anti-pattern
- **Shared source repositories:** Everyone who can modify a repository directly is the **de-facto** team. If that team is broken up into smaller "teams," then process and communication drag will impact quality and the ability to deliver with agility. CI will not function, and quality standards will be impossible to enforce. Delivery is delayed as process overhead increases in a failed attempt to overcome this structural problem.
### **Co-located in Time:**
The team works on a schedule that enables them to collaborate effectively. They need not be co-located physically, but they must have enough overlap in working hours to allow a sustainable continuous integration process. [Paul Hammant has an excellent article on evaluating your CI process.](https://paulhammant.com/2017/05/01/scoring-continuous-integration/) As the amount of overlapping working hours decreases, the communication lag between team members effectively silos the team. Team members will naturally divide into sub-teams who can collaborate to deliver. Remote teams should be in frequent contact to avoid this fragmentation. The team needs to stabilize around working hours that support CI and protect value delivery.
#### Anti-pattern
- **Teams siloed in time**: CI is the core of continuous delivery and requires a high degree of collaboration. The feedback loops needed to move value from idea to production must be as rapid as possible. If a team is divided in time so that they cannot effectively communicate instantly for the majority of their day, they become **de-facto** separate teams. These "teams" do not have sole quality ownership and delivery times will be extended as the "teams" adjust by adding process overhead that allows both "teams" to review the code. Over time, the sub-team cultures evolve independently and impact code review cycle time. [Innersourcing](https://paypal.github.io/InnerSourceCommons/) processes can mitigate quality issues by making only one of the teams a contributor instead of the owner, but there is an increase in process overhead.
### **Responsible:**
The team has *primary support responsibility*. There are **only** two groups related to any product who **care** about the quality of that product, the end users and the product team who wakes up when things break. A high-performing product team will ensure that their application has the resiliency, instrumentation, and alerting required to detect pending failure before the end user detects it.
#### Anti-pattern
- **Grenade Driven Development:** Project teams require support teams to hand the project off to. Project teams are ephemeral. This type of development practice, where code is developed and "thrown over the wall" for another team to support, is destructive to the product and to the morale of the victim team. Product teams, by definition, have operational responsibility. They may not be the first people called, but only they can approve changes to their code. It's up to them to ensure Operations has the information needed to alert the team effectively.
If the above principles are not true, it's not a product team. It's a "**Pandemonium of Developers**."
### Other considerations
*Copyright 2019 Bryan Finster*
### Functional Domain
[Domain Driven Design](https://en.wikipedia.org/wiki/Domain-driven_design) isn't just a good idea; it's an excellent way to align teams. As we decompose a product into sub-domains or as more functional domains emerge, we should be deliberate about assigning those capabilities. Things that should be tightly coupled should be assigned to the same team. Things that should be loosely coupled should be separated. If I use a back end for the front-end pattern, the UI and the service should be on the same team. Otherwise, the dependency drag for implementing any change will result in glacial delivery. If I also need the capability of tracking account transactions, I can easily assign that to another team and allow them to develop that solution independently. In that case, we assign the capability based on capacity planning.
### Desired Architecture
The impact of placing two capabilities on one team is that they will tend to become entangled. That can be as simple as becoming a single deployable or as complicated as functionality drifting across interface boundaries. If the capabilities are closely related, this can be an advantage. Combining them into fewer deployable artifacts can result in less operational overhead. Microservices aren't always the answer (avoid Conference Driven Development). However, if the capabilities are unrelated and things start to merge, you'll need to invest in marinara before you tackle refactoring the resulting spaghetti.
### Vertical or Horizontal?
*"Do we create a UI team and one or more service teams? Do we divide the UI across teams?"*
Take a look at your wireframes. Are there discrete functional domains represented in the UI? A component for showing stock prices, one for showing account balances, and another for scheduling bill payments? Those can easily be developed in functional pillars and developed and deployed independently. Aligning teams to a business domain instead of the tech stack removes hard dependencies to feature delivery and allows the teams to become truly full-stack. Not only do the know the full technical stack, but they also own the entire problem they are solving. They know the **business stack**.
This isn't always possible, and it does sometimes make sense to have a UI team, but that should be a fallback position. Better outcomes come from a team who is expert in their business domain.
### What's a Team?
Product teams deliver quality. They care about their team, their product, and their ability to meet the customer's needs. Random assemblages of developers taking orders do not. It falls to technical leaders to know the difference and to optimize teams for delivering business value. Grow your product teams. They are **strategic business assets**. Happy developers with tight collaboration who are experts in their problem space can work miracles. "Development resources" do not.
Want to grow a team fast?