Feature Teams or Component Teams

Okay... for the sake of this post, we are going to put aside our discussion of the Agile Product Owner.

For now, we need to talk about some basic patterns for scaling agile projects. To talk about how we are going to scale, we need to talk about how we are going to organize. We'll pull it all back together in a post or two.

Agile software development is all about small teams. So... what is the ideal agile team size? As far as I am concerned there is no hard rule, but most folks I talk with recommend somewhere between six to eight people. Smaller is okay... larger, not so good. There are just limits to how well more than six to eight people can really communicate with each other.

So what happens when you have a project that needs more than six to eight people? Well... you break the larger team up into several smaller teams. Makes sense, right?

To me, this is where agile starts to get really interesting. When you have more than one team working on a single project, maybe even a single code base, what is the best pattern for splitting the teams? There are two primary schools of thought.

Organize Around Features

The traditionally taught... and almost universally accepted... approach for organizing agile teams is to organize around features. For a very thorough explanation of feature teams go find the book "Scaling Lean & Agile Development" by Craig Larman and Bas Vodde. According to Larman and Vodde a feature team is a "long lived, cross-functional team that completes many end-to-end customer features, one by one".

Highsmith states in "Agile Project Management" that "Feature based delivery means that the engineering team builds [customer centric] features of the final product." I cheated here a little and grabbed the Highsmith quote from the Larman and Vodde book also. I figured it was okay because I read the Highsmith book too ;-)

Larman and Vodde summarize the ideal feature team as cross-functional, cross component, and co-located. They are working on complete user functionality, the team is made up of generalizing specialists, and typically six to eight people in size. In other words, our prototypical Scrum team.

The authors also point out several challenges with the feature team approach.... which I really appreciated by the way. Common barriers include... concurrent access to code, shared responsibility for design, difficult to learn skills, and organizational structure. Their assertion is that with modern tooling these challenges can be overcome... but it could take years.

I have to admit... this is clearly the most straightforward... and probably most effective way of organizing agile teams... but it makes some assumptions about your teams and your engineering practices. Like all assumptions, these need to validated. For a complete treatment of the feature team concept, go find the book... it is a good read.

Organize Around the Architecture

A more controversial approach to scaling agile teams can be found in Leffingwell's book "Scaling Software Agility".

Leffingwell introduces the idea of a design/build/test component team. The component team shares many of the same attributes of the feature team in that it is small and contains all the skill-sets necessary to delivery the user story. Leffingwell's component team is empowered, self-organized, and self-managing. In short, they are a typical Scrum team. But... and this is a big but... they are working on component features... not end user features.

This is really the exact opposite of what is recommended by Larman and Vodde. A feature team would be made up of specializing generalists from each of the component teams. These specializing generalists would have collective responsibility for delivering the customer centric feature end to end. Not quite the same as a component team, huh? I told you this was going to get interesting.

Where Leffingwell is going... is that at some level of scale... on some projects (let your imagination run wild here)... the system WILL get big enough that a single Scrum team cannot contain enough specializing generalists to cover a single feature. In some systems... not all, but some... we are dealing with a systems of systems. Some organizations... some products... require a systems of system.

Just to be fair... go get Leffingwell's book too... it is also a good read.

It's a Tough Call

So... our first really important decision is to figure out if the feature team approach is going to work in our environment or if we need to go with component team model. Personally... I tend to start with the feature team approach and only move toward components if I have to... but the decision is very situationally specific.

To make this decision you'll have to explore the diversity of your technology... how well your system is designed... what tools you have to manage your code base... the size and competence of your team... how much work the organization is running concurrently... and the quality of your automation.

You'll need to get real about the politics and power structures in your organization. You'll need to look at how well, and how empowered, all your cross-functional feature teams can operate. You need to take a hard look at what scale your feature teams WILL break down... at some scale they WILL break down. Is scaling to this level something we need to address now or can it wait?

Next post we are going to explore what being agile means to you. We'll think about just how agile you want or need to be. There are a few key questions around this topic that you'll have to ask... and answer... before we can decide how you are going to scale. The post after that we'll plan to pull it all together ;-)

Comments

[Dean Leffingwell]

Hi Mike,
Well to add a little color:
1) To be fair in, my book I used the "component team" metaphor primarily, but I also noted that agile teams can be organized around features, components, or services.
2) if you are approaching an enterprise of scale, for example 500 practitioners, they are ALREADY ORGANIZED (most likely into component or subsystem teams)and attempting to reorganize them into collocated feature teams or any other agile mental model you prefer will likely kill the initiative or at least delay results. Who wants to be the one to put out this memo: "150 of you and your families will now be relocating to live with your new agile feature teams?
3) I'm working with projects where it takes many hundreds of developers to deliver a single value added feature to the market. How do you reconcile that with a 7+-2 agile team construct?

[Mike Cottmeyer]

Thanks for the color Dean! I appreciate you replying to my post.

1.) Was not trying to characterize your entire point of view. You had 400 pages, I took two paragraphs ;-) You have the best articulation of the component team I have read so I wanted to let people know your book was out there... AND that the component team is a valid model. Most agilists I speak with totally disregard the component model as a valid agile approach.

2.) I can't say I have run anything close to 500, but I have done a significant project with 100+ folks. We used your feature team approach (actually were doing it when I read your book) and I think that at the kind of scale you are talking about, given the structure of existing organizations, the approach is a essential.

3.) Now a days... I mostly work with teams in the sub-100 range. Often they will want to go with a component approach when they don't need to. I look for any reason to keep a feature based team together. There are many valid reasons for taking a component approach... that is just not what I usually lead with.

Next post I am going to spend a little time on the service model you mentioned and on some simple scaling approaches using every day agile language.

Thanks for reading the VersionOne blog. I appreciate it and the time you took to leave a note.

[Bas Vpdde]

To Deans post:

1. ...

2. I'm all the time working with hundreds of developers and we do reorganize them toward feature teams. It didn't kill any initiative yet :)

3. Also common situation. Split it up and keep the splitting customer centric.

[Lee Henson]

I must admit I find this post most interesting! Most of my recent engagements with large organizations have been fading closer and closer to the Leffingwell Theory. Large organizations find is easier in my opinion to leverage their subject matter experts around the architecture in the form of component teams knowing that the projects they work on are HUGE and will continue to grow.

As a Certified Scrum Trainer I would be remiss if I did not mention that for most organizations that are small to medium in size, feature teams still make the most sense. As the Feature set grows and the scaling becomes more difficult, teams begin to transition toward a more component approach.

I have seen really large organizations use either approach and be successful.

I just REALLY appreciate Mike Cottmeyer bringing thoughts like this to the forefront. It really makes us a richer community!

GREAT post!