Orthogonal teams: A hybrid team formation proposal for large software projects

One of the projects of my current employer is large enough to include dozens of developers working on its different aspects. When the project started it was formed around component-centric SCRUM teams (or rather, teams focusing on sets of components in the same bounded context). Eventually we realized that this led to delays due to dependencies among components (managed by different teams) that would arise during sprints; forcing us to either bring new tasks inside our sprints, which is naturally frowned upon, or postpone said dependency implementation to the next sprint(s).

When the time came to reconsider the formation of teams in view of the upcoming 2nd phase of the project, the discussion was between the existing component-specific formation model, and the other well-known paradigm of feature teams that deliver complete features and affect the full codebase. This article provides a succinct overview of the concepts. Most companies will usually go for a mix with some feature teams closer to the app/domain and some component teams closer to the platform services. However, our architecture is microservice-based, so pretty much all teams had to deal with the “platform”. This had me thinking, why can’t we have the best of both worlds?

Before I move on to explain the concept of orthogonal teams, a couple of things about how our teams are organized: Each team includes the developers, a senior developer acting as a tech lead (TL), a business analyst (BA, equivalent to Product Owner) and a delivery lead (DL) that also acts as the SCRUM master, moderating the usual SCRUM ceremonies etc.

The proposed “orthogonal teams” formation model combines feature teams with component teams and affects only the software developers in the sense that they have to operate under “two hats”. Henceforth, the term Team will refer to Feature Teams; lacking creativity, I will be using the term Tribe for Component Teams.

A tribe is a stable/permanent group of people owning a set of services (or components, but from this point on I will only mention services) and being responsible for the quality of the code within those services. Tribes are represented by TLs and consist of developers only. The size of the tribe depends on the number of services it owns, but the typical guidelines of Agile could be followed with approximately 4–7 developers per tribe. It is crucial that all developers of a tribe are experts on all codebases that the tribe manages; that is, any member of a tribe can write code on any of its services, and review code on any of its services. Members of tribes are co-located on a single desk to cover for the fact that all ceremonies are taking place within teams, not tribes.

A team is an agile team of developers with no TL role, but with BA and DL roles. Teams are also stable/permanent and implement the stories that their BA creates in the team’s backlog. The DL is tracking the team’s progress and is accountable for the delivery. As said, agile ceremonies are only team-related (i.e. there are no ceremonies for tribes, the TL may only call for exceptional meetings to discuss technical matters that affect the services that the tribe owns).

Stories/Features that require changes in service A, whereby that service is owned by tribe X, should be implemented as code within that service A by the team member that also belongs to tribe X. It is important to understand that each developer wears two hats: One for the tribe she belongs, and one more for the team she belongs. As soon as changes are completed, a merge request should take place towards another member of the same tribe, who will review the code and accept the request. This member could also be the TL; whether the TLs will participate in teams or not depends on their availability and may be tested during the first few sprints.

In practice, a company can adopt feature teams to improve upon business dependencies and help the BAs to create more stories that deliver value to the customer, but still keep code quality at an acceptable level, avoiding the complexity and traps of multiple teams changing multiple services without the teams’ members having sufficient understanding of the services and the logic they implement. The full tribe is acting as a gatekeeper for the services it owns, hence experience is taken advantage of and throughput is maximized.

Finally, in order to satisfy temporal spikes in workload of certain teams, tribes could have a rotating (per-sprint) bench that can be assigned to different teams on a need-basis. That means that the teams that these members belong to will have to forego their support on that sprint, and will therefore need to be coordinated among the DLs and BAs.