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…
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 be 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 systems of systems.
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 a 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 (9)
Derick Bailey
Can you describe (or link to your existing description), in no ambiguous terms, ‘Component’ and ‘Feature’ to make sure I understand where you’re coming from?
when you start talking about scale, i get an idea of what you mean by component and feature, but i want to make sure i have a clear understanding before i really dive into my own head for thoughts on this subject.
thanks.
Mike Cottmeyer
When you think feature… think user story. You might scale this up to a collection of user stories (an Epic?) or a feature group. Teams are organized to deliver a set of end user functionality.
When you think component… think big block architecture. Enterprise Architecture maybe.
When I describe this to people I usually draw a system that has a significant mainframe processing engine… a web services product… a Tibco connector… a very large data warehouse… and business objects layer… and a presentation layer. You might also have third party services you are calling… and maybe even changing as part of delivering your product.
If people have not worked in this large an environment before, they usually think I mean the presentation guy… the API guy… and the database guy. In that kind of environment, again situationally specific… I would start off looking for was for folks to work across the architecture.
Make sense? That is as unambiguous as I can get ;-)
Derick Bailey
yeah, that makes sense, and is what I thought you were referring to. thanks for the clarification!
Jeremy Kriegel
At my last startup, we were organized around features, but at the epic level. Two teams supported the primary community app in general, another a major part of that app, a third supported the client app. Overall, it worked well enough.
The interesting element to me was that the two teams with the overlapping support essentially shared a backlog. I’ve always wondered what it would be like to have multiple teams driven from the same backlog, able to move to whatever has the highest priority. Would that be adaptive or chaotic?
Mike Cottmeyer
This is a note from Dean Leffingwell. He posted his comment on blog.versionone.com.
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?
Posted by: Dean Leffingwell | Wednesday, March 11, 2009 at 07:24 PM
Here is my response….
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.
Dennis Stevens
Mike,
Nice post. It is really interesting and increasingly important to discuss the alignment between the organization of the business, the technology, and the development and support teams. An approach I have been working with involves the concepts of Business Capabilities.
A Business Capability is “what” the business does to create value for its customers. You can read about this in detail in the June 2008 Harvard Business Review article “The Next Revolution in Productivity”. Ric Merrifield at Microsoft has a book coming out in May called “ReThink” that talks about understanding the “WHAT” of the business.
In a large scale agile implementation there would be teams organized around capabilities. One or more teams would be defined around the Business Infrastructure capabilities. These would provide the plumbing, security services, etc. Then there would be customer facing teams and business facing teams. The business facing team(s) are supporting internal features for accounting, sales and marketing, technical support, customer service, etc. The customer facing team(s) are putting together the offering for the customer.
This arrangement does several things. First, it decouples a lot of the complexity that arises when there is a mismatch between the organization of the business, the technology, and the development and support teams. Second, it creates flow through the development teams. Work can be prioritized around customer value. Third, there just aren’t enough generalized specialists that can competently address all layers of a complex technology environment. Finally, and importantly, this approach allows us to leverage our ability at the business outcome level to rapidly deliver software.
This realignment looks challenging. This isn’t a business re-engineering play though. The reality is that it only needs to occur around about 20% of the capabilities in the business. These are the capabilities where rapid response helps a business execute on its strategy.
It is great that we are truly learning how to rapidly and predictably deliver software. We should be able to leverage this ability to create new value for our customers and the business. However, without the alignment of the business model, the technology itself, and the development and support teams, we are limited in our opportunities to respond to changing customer needs, leverage outside services, and modify the operating model in response to the market.
Dennis
V. 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!
Mike Cottmeyer
Thanks for the comment Lee.
I agree that starting with Feature Teams is the way to go. We need to have the component team, or the service team (to Dennis Stevens point) in our hip pocket as an option when the Feature Team doesn’t scale.
Jeff Anderson
the largest agile team I never had to work with had approximately 30 resources working on multiple components for multiple projects within a specific program in parallel.
My personal experience was that organizing teams around features was crucial to ensure accountability for specific functions/stories.
That being said, it was also equally crucial to have a core “SWAT-component” team that was possible for putting the other some of the crosscutting components (e.g. DAL, web navigation, etc.)
This SWAT team would spend half their time putting some of the common reusable pieces together, and the other half moving from team to team teaching and integrating…
This component team basically treated the development leads in other teams as their product owners, meaning that architecture was not mandated top-down, but treated as a supplier service to the rest of the delivery organization
On even larger projects I can imagine multiple “component teams” playing the same role…
Hope that made sense
regards
Jeff
http://agileconsulting.blogspot.com