When I first began to consult for a certain California-based game studio, its teams were organized around the specific elements and objects that would exist in the video game it was developing. There was a separate team for each character. There were weapons teams, a vehicle team, and so on. This led to problems, such as weapons too weak to kill the monsters, colors too dark to show secret passages, and obstacles that frustrated even the most patient player.
On more traditional, corporate projects, we see equivalent problems when teams organize around the layers of an application, including
- Reduced communication across the layers
- A feeling that design by contract is sufficient
- Ending sprints without a potentially shippable product increment
If structuring teams around the layers of an architecture is the wrong approach, what’s better? Rather than organizing around components, each team on a project can ideally be responsible for end-to-end delivery of working (tested) features. There are many advantages to organizing multiteam projects into feature teams:
- Feature teams are better able to evaluate the impact of design decisions. At the end of a sprint, a feature team will have built end-to-end functionality, traversing all levels of the technology stack of the application. This maximizes members’ learning about the product design decisions they made (Do users like the functionality as developed?) and about technical design decisions (How well did this implementation approach work for us?)
- Feature teams reduce waste created by hand-offs. Handing work from one group or individual to another is wasteful. In the case of a component team, there is the risk that too much or too little functionality will have been developed, that the wrong functionality has been developed, that some of the functionality is no longer needed, and so on.
- It ensures that the right people are talking. Because a feature team includes all skills needed to go from idea to running, tested feature, it ensures that the individuals with those skills communicate at least daily.
- Component teams create risk to the schedule. The work of a component team is valuable only after it has been integrated into the product by a feature team. The effort to integrate the component team’s work must be estimated by the feature team, whether it will occur in the same sprint during which it is developed (as is best) or in a later sprint. Estimating this type of effort is difficult because it requires the feature team to estimate the integration work without knowing the quality of the component.
- It keeps the focus on delivering features. It can be tempting for a team to fall back into its pre-Scrum habits. Organizing teams around the delivery of features, rather than around architectural elements or technologies, serves as a constant reminder of Scrum’s focus on delivering features in each sprint.
Of course, there will be occasions when creating a component team is still appropriate, for example when a new capability will be used by multiple teams or when the risk of multiple solutions being developed for the same problem is high. Overall, however, the vast majority of teams on a large project should be feature teams.
Additional advice on feature and component teams can be found in Chapter 10, “Team Structure,” of Succeeding with Agile.
Tags: agile teams
“Of course, there will be occasions when creating a component team is still appropriate”
I’d be interested in your thoughts on how to manage them when they are appropriate. Thanks!
So, knowing what you know now, how would you have organized the teams at that gaming company? Where would you have drawn the “feature” lines in that specific case?
Very cool !!!
I suppose features should be independent just like stories should be ?
Hi Mike–
More information on component teams is in the Succeeding with Agile book. Unfortunately I haven’t had time to write any more blog posts yet on the subject.
Hi Chris–
The teams were organized that way when I arrived. I helped them reorganize around elements of the game play–e.g., a team focused on hand-to-hand fighting, another on driving, for example. Most Triple-A games will have a mix of feature and component teams. Clinton Keith is writing a book on agile for video game development.
Hi Rajiv–
I was just using “feature” as a generic term for any bit of functionality. A feature description could be a user story, of course. And yes we’d like to have our feature teams be independent from one another. I have an interesting article coming up somewhere which discusses this. It’s a set of 9 questions to ask about your current team structure to see if it is effectively designed. I don’t recall if that’s a blog post or something I sent to another website. Either way, I’ll announce it here when it’s published.
We have just started to work with two scrum teams working on different features for the same software product. We like the idea of feature teams. The teams are motivated to bring their features to an end. We have also seen that their is some need for inter-team communication. Therefore the scrum master of team A works as a programmer in team B and vice versa. Since the scrum master of team A moderates the daily scrum of team A he knows what they are doing and can inform his own team B. We’ll see how this behaves. Do you have some experiences with scrum masters managing one team and working in another?
Our company has a major technological release coming up, one which will lift the quality of the customer/order system to a more stable platform/framework. However, only the last 2-3 months or so have been using Scrum to any great extent. Before that, it was a mixup – or I should say, messup – of project management techniques (or in some instances, lack thereof).
Needless to say, the project was delayed – more than once.
One of the things which improved the project progress, was to include non-developer resources in the Daily Scrum – people working on the same project, but in a different department. So, instead of communicating via mail and occational meetings, we now get better communication and fewer (if any) misunderstandings (i.e. the usual Scrum Benefits
).
Establishing this cross-functional team (as we call it) isn’t the only measure that was taken, of course, but I think it is the one with the clearest colleration between cause and effect.
Hi Ådne–
Great story; thanks for sharing it. Just about anything we can do to help people work more cross-functionally will be a good thing. Scrum gets its very name from the idea of cross-functional teams.
Hi Christian–
I think it is really hard for a person to make and honor commitments. Saying “I will achieve this in the next few weeks,” and actually doing so is hard with all the swirl of activities that compete for our time in today’s workplace. When someone is put on two teams (ScrumMaster on one; team member on another), that person can commit at best to one of those two teams. To the other, he says, “I commit to doing this unless my other team needs me more.”
So, I’m not a huge fan of this model. Yes, I’ve seen it work. And I do like how it gives the ScrumMaster a dual incentive (one on each team). I’d encourage you to keep trying it and then discuss it in the retrospective. For some teams it works very well and it is one of the patterns (“Share a team member”) I describe in the Succeeding with Agile book.
One favor: After you’ve tried it a bit longer, please post back here and let us know what the team concluded. Thanks.
[...] The Benefits of Feature Teams – more on teams, this time from Mike Cohn, and why traditional component teams are risky. [...]
[...] you have feature teams it’s easier for development teams to implement feature specific operations in a service. They [...]
“Feature Scrum teams” is the way to achieve consistency in Scrum’s potentially deliverable targets.
But there are times when it is necessary to create Component teams (due to organizational and political resistance). Mostly during the start of a product development cycle when you have requirements for many infrastructure components (created or assembled from existing systems) for end to end feature creation. Also, there are those “Experts” in the development teams who posses deep knowledge of the specific components design and development and it is difficult to have them full time on early scrum teams. “Design by Contract” is the more productive way to go during that time.
HI Tribhuwan–
Yes, there are times when a project can benefit from component teams. I always want to be careful in saying that, though, because what I’ve found is that if I open the door that such teams can be used *occasionally* there are some who will use that to justify such teams in all cases. Use them cautiously and try not to institutionalize one (i.e., have it live forever).
Mike,
What about the need for some stewardship in each component/layer of the product architecture? My experience has been that unless each part of the software system is owned by a team that takes pride in it and responsibility for it, technical debt builds up very quickly. While I can see where feature teams might be great for time to market of short-lived products, I question the suitability for products that will be actively developed over many years. I’d really appreciate your thoughts on this.
Hi Jay–
Absolutely. There is occasionally the need for a component or layer to come under the stewardship of a particular team. That’s an occasion when I would use a component team. However, there are fewer of those occasions than most teams think. In other words, it is very rare that I consult to an organization and tell them they need more component teams. I often tell them they need fewer. (And of course sometimes they’ve got it right.)
Mike:
I’m a frequent lurker in your blog; this is the first time I’m posting.
I’m new to a distributed team who’s having a very hard time with their delivery. At the time of creation, the team was divided by components and there have been several large misfires regarding the design and architecture (note: there is not yet an enterprise architecture framework). The end product is due at the beginning of Q3 and I’m wondering if it’s too late to reorganize them into feature teams. What do you recommend?
Hi Lanooba–
Thanks for joining the discussion. We all appreciate it.
Without visiting your company and learning a lot about the project I can’t really say exactly how *your* teams should be structured. But, September is a long time away and I wouldn’t hesitate at all to change to what I thought a better team structure with that much time left on the project. Good luck with it.
Thanks Mike. We’re taking up your recommendation and looking at ways to restructure the team.