Scrum - Part XI: Module teams or feature teams?

As this blog has seen its fair share of dilemmas, it's time to add another one: namely, the eternal debate of module vs. feature teams.  

Just in case you have a tiny question mark hovering over your head: 

• Module teams are organised around technology and components. For example, a module team may own driver abstraction in an OS kernel, a database layer, or a processing engine.
• Feature teams deliver features end-to-end and are comprised of engineers from different modules. E.g. a single feature team may deliver the telemetry example from my previous posts. 

Module teams - a thing of the past? 

There's plenty of prior art on this topic from Agile gurus, and it tends to paint pictures similar to the one below:

You can easily recognise feature teams on the left panel and observe gradual descent into module teams on the right. I might be a bit cynical here, but you're welcome to check Table 1 in this link, and then come back here.

The upshot is that component teams are passé, that they trigger Conway's law, give rise to complex coordination, and inhibit Agile practices, such as common sprint goals and backlog.
And, actually, some of that is sometimes correct in some cases (see below). 

However, whenever a guru comes over and draws a comparison where there's heaven on one side and hell on another, a warning light should start blinking. Conceptual simplicity might be good for pre-Renaissance art, but it is not necessarily as good when software development comes in.

The mantra that's going through this blog is that management is an art, and delicate decisions require deliberation, experience and strong understanding of the company and its products. Decisions do not come much more delicate than deciding how teams should be organised.


Feature teams - can they backfire?

Well, yes, they can. There are quite a few situations where feature teams have their own cons:

• Many small changes. Let's say you have a fairly mature product, and you spend a significant chunk of your time dealing with customer escalations, assisting Technical Support and resolving defects.
  Then, it's rarely that interaction between components is required; the changes are small and contained. There's little benefit in having developers from other modules in the Scrum, while on the other hand, engineers from the same module can contribute to the sprint goal.
  Same would apply if we have many self-contained featurettes.
• Refactoring is an inevitable reality. Interfaces, classes, source directories appear as features add up, and design mutates beyond its original purpose. 
  Note: In case you disagree, or the term is unfamiliar, have a look here.
  This is almost always a modular change; there's more oomph behind developers who know the same component inside out, and can design and refactor together.
• Varying team experience. Imagine you have a team with a few senior guys and a few newcomers to the industry. Placing a newcomer into a feature team is a bit like throwing them to the lions as they'll be expected to represent and develop their component on their own.
  This actually means that they'll have to lean on the senior guys in order to represent their component, and that in turn means that the latter belong indirectly to several feature teams.
  And, again, in turn, it means that we have de-facto module teams. That leads into the next caveat:
• Periodic team meetings and backlog grooming. Back at the start of this blog, I've argued that daily stand-ups have their own quirks. However, let's assume that you diligently and regularly perform some form of meeting where engineers share what they do (and you really should).
  An ideal dialogue in such a meeting is:
  
  Developer A: "I'm working on this new dynamic evaluation interface to retrieve widgets by their moniker, but was stuck yesterday figuring out the widget class hierarchy."
  
  Developer B: "Hey, I've refactored those classes two years ago, I'll run it past you on the whiteboard after the stand-up."
  
  Now, what are the chances that developer B will be available in a feature team Scrum as opposed to a component team?  
• Shared function and team size disparity. Let's say we have a handful of specialists who are needed on most projects, but don't do the bulk of work there. For example, a UX designer, a TechDoc engineer, or a Product Manager. Should they belong to all the feature teams? If yes, will they have to attend all the ceremonies in 5-odd teams and keep their sanity at the same time? Should they attend only a few ceremonies?
  Should they be instead in a separate unit providing services/dependencies to feature teams?
  If so, then we do not have a pure feature-based Scrum.

Feature teams - do they always backfire?

Absolutely not! There are teams/products/times when they work, and work well.
 
The art of management is recognising those, and, as we start playing the "spot-the-feature-team" game, greenfield projects come into view closely followed by large cross-functional roadmaps.

These get most benefit from a project Scrum team and few of the detractors.  

1. The project is big enough, so several people from each team work on it.
2. There are few disruptions and customer escalations.
3. No refactoring to worry about (at least for greenfield projects)
4. Enough room to accommodate dedicated UX/TechDocs. 

This is the "sometimes correct some of the time" I alluded to above. Feature teams is definitely an option on big new projects with few outside interruptions. Established, mature products with an incremental roadmap is a different beast altogether.

But what about Conway's law?

Indeed what about it? I'm advocating old-school module teams for stable products; would not it constrain architecture and solutions along the team structure?

There are two counter-arguments to that: firstly, architectures get spawned when new projects come into existence. This is exactly when project Scrum teams work best, so there is no contradiction.

The second point is even more important: component teams do not have to operate as silos.

In more layman terms: if I'm in a module team, it does not mean I should not care about the rest of the system. Of course, I might not understand another team's module well enough to refactor it, but I should be aware of what it is, and avoid designs that are purely restricted to what my own team does.

Yes, you might claim that this is not what happens in real lives and silos do appear. Maybe yes, but from personal experience - it is not always the case. 
Feature teams do not hold monopoly over understanding system end-to-end, and there are many ways of spreading awareness across teams: demos, lunchtime engineering sessions, cross-functional design reviews and so on.

Summary

As systems become more mature, there's less and less reason for feature teams, and more case for module teams.

Moreover, same way as few people are doing pure Waterfall, few are running pure module teams, where everything that's outside of own component is "not my business" ^(TM). 

Scrum teams can reorganised as products evolve, though it always comes at a cost. It's up the powers to be to decide whether the benefit from functional teams at the start of the project is worth the price tag.