Choose Feature Teams over Component Teams for Agility

Posted by Craig Larman & Bas Vodde on Jul 15, 2008

Sections

Process & Practices

Topics

Agile ,

Teamwork ,

Collaboration

Tags

Self-organizing Team ,

Collaborative Technologies ,

Introducing Agile ,

Scrum ,

Scaling Agile

Scrum and other agile methods recommend that requirements be delivered to customers in small, frequent deliveries of working software. This presents a challenge for teams used to developing in teams oriented along lines of technology layers or application components. In this excerpt from their upcoming book, Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum, Craig Larman and Bas Vodde explain how and why feature teams work, and make the case that this major organizational shift is worthwhile; in fact, it is of vital importance for scaling agile methods, increasing learning, being agile, and improving competitiveness and time to market. InfoQ is pleased to bring you a chapter excerpt [pdf] on Feature Teams from this upcoming book.

Feature teams are not a new or ‘agile’ idea; they have been applied to large software development for decades. They are a refinement of cross-functional teams, a well-researched proven practice to speed and improve development.

Fully agile teams are organized along the lines of customer-centric features. Teams generally struggle at first, to understand how to move from delivering broad, integrated feature sets after many months, to narrow "slices" of their applications every few weeks. Some teams compromise on this by making their component teams agile, delivering working software to other teams, which deliver working software to yet other teams - but they still struggle to deliver integrated, working software frequently.

In this 49-page chapter, Craig and Bas principally look at problems with component teams and single-function teams, and how these problems are alleviated through the proper adoption of feature teams. The chapter also takes a brief look at transition from traditional teams to feature teams, and the need for supporting communities of practice. The authors draw on their experience with large-scale agile adoptions at companies like Nokia Networks, NSN, and Xerox.

A team does not flip from one structure to another in a moment. To gain the full benefits of feature teams, adopters will need to address some new issues. The chapter looks at these challenges:

• developers now need broader skills and product knowledge
• discipline and technology required to support concurrent access to code
• a shift to shared responsibility for design
• different mechanism to ensure product stability
• questions around reuse and infrastructure work
• the need to adopt difficult-to-learn skills
• developing and coordinating common functional (for example, test) skills, that span members of many feature teams
• issues relating to organizational structure
• handling defects

The authors note that, while reorganizing to full-feature teams may be declared "too difficult", in fact the impediments are often mindset and political will. While the work goes on to transform these aspects, teams can still, as an alternative, take smaller steps toward Feature Teams. An example is given of gradually expand teams’ responsibility from component to “multi-component” teams to true feature teams.

Read the whole Feature Teams chapter [pdf] on InfoQ, from Scaling Lean and Agile Development by Craig Larman and Bas Vodde (to be published in late 2008). The full table of contents of the book follows.

Scaling Lean and Agile Development:
Thinking and Organizational Tools for Large-Scale Scrum

by Craig Larman and Bas Vodde

Table of Contents

 

About the Authors

Craig Larman serves as chief scientist at Valtech, and works worldwide, from Asia to Europe to the Americas, with multisite product groups adopting large-scale Scrum, and lean and agile principles. For several years he has focused on enterprise transformations and applying lean development to very large products (usually embedded systems, including telecommunication and printer products) at Nokia, Siemens, Xerox, NSN, and HP, and to agile offshore development at Valtech’s Bangalore center. Craig is also author of the popular texts Agile and Iterative Development: A Manager’s Guide and Applying UML and Patterns: Introduction to OOA/D & Iterative Development.

Bas Vodde is originally from Holland, however he has lived in China, Finland, China again and currently lives in Singapore. He led the Agile transformation project at Nokia Networks and later Nokia Siemens Networks, and currently works for his own company called Odd-e. He's been working with several large products and several large company change projects. He's still also developing software himself and is one of the authors of the C++ unit test framework CppUTest.
 

Watch for these upcoming books by Vodde and Larman, due out in late 2008:

• Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum
• Practices for Scaling Lean & Agile Development: Large, Multisite & Offshore Products with Large-Scale Scrum

 

1. Back to top

   The struggle.

   by Adron Hall

   This is something the team I'm working with is currently struggling with, to go from the broad features of the user requests to the functional and frequent deliveries.

   Reply

2. Back to top

   Re: The struggle.

   by Adron Hall

   I hit the button to fast... but was summarizing by simply stating thanks for the write up and I'll have to check out the material.

   Reply

• Older >