Scaling Agile Tricks Series: Economically efficient teaming

Welcome to the fourth blog in the Scaling Agile Tricks Series.

So far we have covered The Leadership Cell, the Mitosis division of teams, and Pipeline management techniques.

In this blog I will cover how to setup teams so that they deliver more efficiently. I am not the first person to talk about different types of teams and would like to highlight that a lot of this content has already been previously covered by Kenny Rubin in both his presentations and his book.

What is economic efficient teaming? To me it is about:

reducing handoffs and dependencies
which in turn is about reducing risk and improving efficiency

There are a number of different options when structuring teams who work at Scale:

Feature Teams
Component Teams
Architectural Layer Teams
Customer Journey Teams

Let’s take a look at what each of these means and the pro’s and cons of each of them.

Feature Teams

What is it?

Let’s take a look at the example feature below.

If we have a product that relies on multiple types of systems, lets say a mobile banking app, you would likely have to build both an android and an iOS front end. Additionally on the backend, to talk to the core banking system you would have a number of interface points – in this example a simple .net controller before a middleware tier. In this scenario most of the middleware services already exist due to an existing web front end system.

The design of this team is such that any business feature can be delivered wholly by the team without any other interactions to other systems or teams. The team has all the skills that it needs to build a feature across both of the front ends. They can even adjust the web banking solution if the feature needs it to.

A feature for this type of team would be “As a banking customer, I want to know if my recurring payment will overdraw my account, so that I can manage my accounts to not get an overdrawn fee”. The feature goes to only this one team to deliver.

Pros:

No dependencies or hand-offs with other teams
Encourages big picture thinking – the team can consider the need and fully implement an alternative solution if they believe it will better meet the need
Low inventory waste – assuming there is some investment in cross functional capabilities, the movement of work is limited to only the capacity of the team. The team can swarm to get work done and fully own the reduction of work in progress to deliver the feature.
Low integration – the feature can be integrated across the multiple systems by the team itself without having to co-ordinate across teams for integration
Very low end to end cycle time – all of the above factors compound to a really low cycle time.
High cross product knowledge
Low susceptibility to peaks and troughs of work

Cons:

High investment of cross functional capabilities with a moderate change concern of people having to learn systems and languages outside of their comfort zones
Unable to scale easily past a few systems – if the team also had to do the middleware changes and the core banking system changes this approach would fall down heavily due to either too much knowledge having to be retained in the the team or over bloat of the time size. Commonly this risk is mitigated by having one or two middleware developers shared across the set of teams that move in and out of the feature teams depending on the feature.
System instability due to lower ownership of architecture and technical debt – because multiple systems are being maintained there is less strength and care than what occurs when only a single code base is being changed. Feature teams do result in higher amounts of technical debt being created if the Technical Lead role in the Leadership Cell is not empowered.
Reduced likelihood of asset reuse – the feature team will tend to not think outside of the box of how the feature could be extended for the future. They will build for the knowns of today without knowledge of similar trends being delivered by other feature teams around them.
Higher chance of code merging – because other feature teams may hit similar screens or pages there is an increased risk of misaligned user interface design and increased code merge cost.
Higher costs to get consistency in practice – best practice will need to be shared with all the team across all of the feature teams for all of the systems in the scaled cluster.
Higher chance of defects due to dispersed knowledge of the product.

Component Teams

What is it?

Using the same feature as before, it would be split and handed to two different teams to implement. One team will do the detection mechanism on knowing if the recurring payment will overdraw the account, the other team would process the notification to the customer. The two teams would need to agree on the design, implement them separately and then integrate it when both have completed.

Component teams are especially useful when the code base is all one massive system and you want to break it down into logical groupings. Spotify is renowned as being a heavy user of the component team concept where portions of the screen that you see are owned by different teams. It isn’t mandatory that component teams are used where just one code base or system exists – in the above example you may still have an iOS, android and .net developer in each team. However it is likely that team composition will differ in the component team scenario.

Pros:

High technical ownership of debt and architecture – teams have a strong purpose and focus on cleaning up their area of the product, they are also likely to have peaks and troughs in work that gives them the time to focus on this as well
High asset reuse – if the work goes to the notifications team, they would likely focus on ways to make that component re-useable or available for other teams in different ways. Additionally they would likely have visibility of multiple similar requests.
Low chance of code merge – the team are the clear owners to the code and are highly unlikely to have code merge clashes
Lower defect likelihood due to depth of understanding in their part of the code base

Cons:

Highest number of dependencies for delivering a complex customer need (economically nonviable at scale)
Cross product knowledge very low
Susceptible to peaks and troughs of work
Small picture thinking (my job is this one tiny bit)
Requires integration

Architectural Layer Teams

What is it?

Using the same feature, teams are split by their specialties and consequently the feature has to go to three teams and then be integrated together.

In my experience architectural layer teams are often mistakenly called component teams, but the key difference is that work is split by capability and not by a portion of a product.

Most waterfall teams are setup as architectural layer teams.

Pros:

Minimal disruption to challenging people’s specialties, resulting in low change resistance
Supports massively complex organisations where a single change impacts dozens of systems
Favors contractual agreements
High technical ownership of debt and moderate ownership of architecture
Reduced costs to get consistency in practices
Low chance of same code being worked on by two different teams

Cons:

High dependencies, which leads to long cycle time (very high if each team is part of a separate agile release train)
High inventory waste (work sitting idle waiting for integration)
Discourages sharing of information through silos
Small picture thinking (my job is just this bit)
Moderate susceptibility to peaks and troughs of work
Requires integration
Cross product knowledge very low

Customer Journey Teams

What is it?

Using the same feature, multiple teams exist for the product, each one taking care of a logical portion of the customer’s journey through the product. Let’s say that this feature came about due to a number of complaints of people leaving the bank because they cited their hatred for overdrawn fees (especially as they believe the bank would have known it would have been overdrawn if the scheduled payment occurred).

Because customers were leaving, the feature went to the Retention team.

In this example the end to end product is supported through a number of different systems. What teams have what system capability is dependent on the system relevance at the journey step. The Retention team needs to have capabilities in both System 4 and System 2.

Customer Journey teams are the newest team structuring kid on the block, and whilst there is still not a lot of evidence of whether it works or not it has a lot of promise as it is more like a cut down version of feature teams.

Pros:

Very low chance of the same code being worked on by two different teams
Low dependencies or hand-offs with other teams (unless the feature crosses multiple customer journey steps)
Encourages big picture thinking – the team can consider the need and fully implement an alternative solution if they believe it will better meet the need
Low inventory waste – assuming there is some investment in cross functional capabilities, the movement of work is limited to only the capacity of the team.
Low integration – the feature can be integrated across the multiple systems by the team itself without having to co-ordinate across teams for integration
Low end to end cycle time – all of the above factors compound to a really low cycle time (unless the feature cross multiple journey stages).
Higher empowerment in reducing technical debt
High likelihood of asset reuse

Cons:

High susceptibility to peaks and troughs of work (certain customer journey points tend to be heavier in work than others, especially in a banking app solution)
Low cross product knowledge
High investment of cross functional capabilities with a moderate change concern of people having to learn systems and languages of their comfort zones
Unable to scale easily past a few systems
Low cross ownership on architecture
Higher costs to get consistency in practice – best practice will need to be shared with all the team across all of the journey teams for all of the systems in the scaled cluster. A good example is consistency of UX elements and design.

Summary

Who would have thought it wasn’t so clear cut how to split teams? The struggle often is that people don’t know of these options and the trade offs that they are choosing. The choice is not clear cut.

You also don’t have to have all of your teams in one pattern. In one organisation I moved four architectural teams into two component teams and two feature teams. The number of feature teams eventually grew to over ten, but we still found it useful for quite a while to keep the two component teams in place because of the significant complexity in that part of the code. To grow capability of the architectural teams into feature teams wasn’t easy either, it took half a year of struggling and many frustrations, but I had multiple people tell me a year later that it was the best thing that happened to the area and worth it despite the pain (and this was from some of the most strongest opponents).

Feel free to post a reply if you disagree with the pros, cons and have any other team cutting options.