BT
x Your opinion matters! Please fill in the InfoQ Survey about your reading habits!

Choose Feature Teams over Component Teams for Agility

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

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

1. Introduction
 
Thinking Tools
 
2. False Dichotomies
3. Lean Thinking
4. Be Agile
5. Systems Thinking
6. Double-Loop Learning
 
Background
 

7. Evidence
8. Stories
9. Misconceptions
 
Action Tools
 
10. Large-Scale Scrum
11. Product Management
12. Portfolio Management
13. Requirement Areas
14. Requirements
          15. Design
16. Legacy Code
17. Continuous Integration
18. Test
19. Feature Teams
20. Teams
21. Coordination
22. Organization
23. Planning
24. Change
25. Tools
26. Documentation
27. Contracts
28. Sales & Marketing
29. Finance & Budgeting
30. Large
31. Multisite
32. Offshore
 
Miscellany
 

33. Death of Lean & Agile
34. Bibliography

 

About the Authors

CraigLarmanCraig 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.

BasVoddeBas 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:

 

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

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.

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.

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