BT

Five Benefits of Feature Teams

by Mike Bria on Dec 16, 2009 |

Mike Cohn and others present their case to why you should consider structuring your teams around software "features" rather than software "components".

Cohn recalls a past video game development client of his whose component team organization style led them to create "weapons too weak to kill the monsters, colors too dark to show secret passages, and obstacles that frustrated even the most patient player."

He uses this story to setup his advice for agile organizations to prefer "feature teams", teams responsible for the development of end-to-end features, as opposed to "software components". He goes on to outline the following five advantages of feature teams:

  • "Feature teams are better able to evaluate the impact of design decisions." Having built end-to-end functionality garners real feedback on how well user's desires/needs have been met; having worked across architectural layers informs about the outcomes of internal/technical decisions.
  • "Feature teams reduce waste created by hand-offs." Counting on handoffs creates risk of component teams not meeting the needs of other component teams and/or of going beyond what was actually needed.
  • "It ensures that the right people are talking." A feature team creates an environment for everybody in the value-chain to stay plugged in with each other.
  • "Component teams create risk to the schedule." Work of component teams must be integrated in order to obtain anything of tangible value; planning this activity is difficult as it depends on unknown information scattered across multiple teams.
  • "It keeps the focus on delivering features." At the heart of the agile mantra is for the team to deliver "working software" each iteration, feature teams help to keep this at the forefront of everyone's focus.

Probably the most notable source of recent support for feature teams comes from Bas Vodde and Craig Larmen in their book Scaling Lean & Agile Development. An article by Mike Cottmeyer said this:

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.

[Larmen and Vodde] 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.

In the same article Cottmeyer points to a contrasting message from Dean Leffingwell's Scaling Software Agility book that provides support for component teams:

The component team [suggested by Leffingwell] shares many of the same attributes of the feature team [suggested by Vodde/Larmen and Cohn] 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.

The comments to this article provide further insight by Leffingwell, Cottmeyer, and Vodde into the context of their views.

For some former discussion on team structuring, including other ideas on feature teams, check out this previous InfoQ article.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

I totally agree by Laran Evans

Customers only see deliverables in terms of features. As such, it only makes sense to make the focus of your effort on delivering features.

I resonate with these problems by David Allen

Our team suffers from each of the five problems listed above. I hope I can persuade our team to try features teams to see whether they will help us reduce these sources of friction.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

2 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT