There’s nearly always too much work. Certainly there is often too much work for one team. Considering the optimum team size (in Scrum) is between 5 and 9 people, it doesn’t take much of a backlog to require us to have multiple teams.

When this is the case, it introduces the problem of how to divide the work up between the teams.

The two most common ways I’ve seen teams organised are as Component Teams and Feature Teams – but which is the best way of organising your company? This is an area that is often debated. They are contrasting approaches to software delivery and I’ve heard many arguments in favour of each. Let’s have look at them.

Component Teams

Component Teams are considered to be made up of experts that specialise in a specific domain and they are focused only on the knowledge and technology related to their domain. It ’stands to reason’ that if there is an area of complexity needing work performed on it on a regular basis, we should have a team dedicated to it. Common examples are the user interface (UI) or the database (DB), we may well have a team for each of those. Areas are commonly known as components as it is deemed that they all plug into each other like the components of a machine. 

In an architectural diagram, each component, or team, would be represented as a layer, or part of a layer, of the system:

Having experts perform the work in these (and other) areas means the work is always done by people specifically qualified to do the work. This, in turn, means the work is done efficiently with a low defect density but we do need to be aware that using this approach introduces at least three problems:

Problem 1

Each team only solves one piece of the problem and that causes the teams to act as stages in the delivery cycle. The more stages there are in the delivery cycle, the greater the number of items of work in process (WIP) there are at any one time. If the work has three stages, there will usually be three items of WIP at any one time. Little’s law tells us the more WIP we have, the longer the lead time. In other words, every stage we add to the delivery process makes the delivery process longer. Working as Component Teams increases the amount of time it takes to deliver.

Problem 2

Consider too, what happens when, for example, the business logic team starts on a piece of work. For them to complete the work, they need to define the interface between their layer and the other layers, like so:

This needs to be done in consultation with the other two teams but as they are probably working on other, perhaps unrelated, pieces of work they will most likely be unwilling to take time out to discuss it. In all probability, they won’t even know what the interface should look like until after they’ve done their share of work anyway.

This will only become a problem later, so for the moment, the business logic team can simply design the interfaces as they see fit and consider that piece of work complete before moving on to the next item on their backlog. Not forgetting to inform the project manager of their progress, of course.

It’s only later when the UI team starts on their part of the work that they find out the interface designed by the business logic team is not appropriate for what they need to do. When this happens, they go back to the business logic team in an attempt to remedy the situation but by now the business logic team have moved on to a new challenge and are unwilling to revisit work they thought they had satisfactorily completed some-time, maybe even months, ago. Even when they eventually decide it has to be fixed, it will take a bit of time to recall all the details, making the fix even more difficult. Unless we can somehow determine or design the interfaces between components beforehand, working in Component Teams will have a negative effect on productivity that cannot be over emphasised.

Problem 3

When planning the makeup of our Component Teams, we will, of course, take into account the amount of work required in each area of expertise and populate their teams accordingly. We’ll do that by taking an average over the last year, or maybe even as precise as the last quarter. What we can’t easily do, though, is determine the sequence or shape of the work that will arrive in the future. The next piece of work might be all UI work, the piece after that may be all DB work. What do we do with our specialist teams when there’s little or no specialist work for them to do? If we’re lucky we’ll have a big enough queue of work so that, even if there’s nothing really important for them to do, there will at least be something. If nothing else, they can always do some housekeeping or maintenance work, even though there may be a surplus of high-value work for the other teams. Running Component Teams leaves us vulnerable to the risk that they will have to perform non-optimum work at the expense of items that are more valuable to the business.

Feature Teams

The alternative approach is the Feature Team. Rather than consisting of a group of experts working on a single component or architectural layer, Feature Teams contain multi-disciplined, or full-stack, individuals that have the ability and freedom to work in any area of the system. These are not, however, ‘jacks of all trades and masters of none.’ 

The Feature Team usually has at least one member with specialist knowledge for each layer of the system but all members are able to confidently and competently work on anything, knowing when to turn to someone else if their knowledge or skills run out.

This allows Feature Teams to work on what are known as ‘vertical slices’ of the architecture, completing whole features, rather than just a single piece of the puzzle. Working this way alleviates all of the problems and risks inherent in Component Teams. Of course, Feature Teams have their problems too.

Problem 1

We’ve all heard the horror stories about untrained or inexperienced workers making a complete hash of some extremely complex piece of work to the massive detriment to the company concerned. This, of course, is probably the biggest rationale behind the use of Component Teams.

However, just a little analysis shows that a lot more needs to have gone wrong to allow an untrained or inexperienced employee to deliver a poorly designed piece of work into a live environment. What were the experts doing when this happened? Where were the reviews? What happened to the testing? Don’t forget you need at least one expert for each component in the team to make sure this doesn’t happen.

Problem 2

Where do you get the personnel? How do you find employees that are willing to give up their roles as gurus to become the ‘generalising specialists’ that are required for a Feature Team? The whole IT recruitment industry is geared around selling us all as experts in one field or another.

Take a look at anyone’s CV and you’ll see that yes, we may well be experts in one (or maybe more) thing but we’ve also got a myriad of other skills listed. Usually in acronym format. Although we think of ourselves as single skilled, we are belied by our very own work histories.

Both sides of the Argument

The argument in favour of Component Teams is that due to their high level of expertise, they are naturally more efficient as their front-end specialism can achieve local optimisation. However, using them makes the overall process much slower, as they only work in a single area and need to hand over to the next team, and so on, to get the work completed.

A common misconception of Feature Teams is that they contain individuals who do not possess a suitable level of knowledge and expertise to work on specialist tasks, resulting in numerous errors and subsequent delays in completing the work.

In reality, the opposite is actually true; as each member of a Feature Team will progressively increase their expertise over time, until a full team of multi-discipline experts are in place, all of whom are able to work on various items simultaneously.

The choice is yours:

Component teams may well work for you if:
• your employees can’t or won’t work full-stack
• you and your customers are happy with your lead times
• you can confidently design future component integrations
• you can plan the future to ensure a balanced workload

On the other-hand you might want to consider Feature Teams if:
• your employees work full-stack
• you prefer to optimise your lead times
• you cannot confidently design future component integrations
• you want to always work on the most valuable items

I’m sure there are other considerations but the ones I’ve listed here are the major concerns we encounter in our work. All other things being equal, I know which one I’d go for.


If you’re looking to develop your understanding of the technical aspects of Agile and Scrum (such as Component Teams and Feature Teams) then why not join me on one of my upcoming courses. Full course info and upcoming dates can be found on the respective links below;

Agile Analysis & User Story Workshop
Certified Scrum Developer (.NET)
Certified Scrum Developer (Java)