Feature Team vs. Component Team: 摘要

　

http://www.infoq.com/articles/scaling-lean-agile-feature-teams

Feature Team

1. long-lived—the team stays together so they can ‘jell’ for higher performance; they take on new features over time

2. cross-functional and cross-component

3. co-located

4. work on a complete customer-centric feature, across all components and disciplines (analysis, programming, testing, …)

5. composed of generalizing specialists

　

Feature teams work independently by being empowered and given the responsibility for a whole feature. Advantages include:

1. increased value throughput —focus on delivering what the customer or market values most

2. increased learning —individual and team learning increases because of broader responsibility and because of co-location with colleagues who are specialists in a variety of areas – critical for long-term improvement and acceleration; reduces the waste of underutilized people

3. simplified planning —by giving a whole feature to the team, organizing and planning become easier – for example, it is no longer necessary to coordinate between single-specialist functional and component teams

4. reduced waste of handoff —since the entire co-located feature team does all work (analysis, design, code, test), handoff is dramatically reduced

5. less waiting; faster cycle time —the waste of waiting is reduced because handoff is eliminated and because completing a customer feature does not have to wait on multiple parties each doing part of the work serially

6. self-managing; improved cost and efficiency —feature teams (and Scrum) do not require a project manager or matrix management for feature delivery, because coordination is trivial.The team has responsibility for end-to-end completion and for coordinating their work with others. Data shows an inverse relationship between the number of managers and development productivity, and also that teams with both an internal and external focus are more likely to be successful [AB07]. Feature teams are less expensive—there isn’t the need for extra overhead such as project managers.– For example [Jones01]: “ The matrix structure tends to raise the management head count for larger projects. Because software productivity declines as the management count goes up, this form of organization can be hazardous for software. ”

7. better code/design quality —multiple feature teams working on shared components creates pressure to keep the code clean, formatted to standards, constantly refactored, and surrounded by many unit tests—as otherwise it won’t be possible to work with. On the other hand, due to long familiarity, component teams live with obfuscated code only they can understand.

8. better motivation —research [HO80, Hackman02] shows that if a team feels they have complete end-to-end responsibility for a work item, and when the goal is customer-directed, then there is higher motivation and job satisfaction—important factors in productivity and success.

9. simple interface and module coordination —one person or team updates both sides of an interface (caller and called) and updates code in all modules; because the feature team works across all components; no need for inter-team coordination.

10. change is easier —changes in requirements or design ( we know it’s rare, but we heard it happened somewhere once ) are absorbed by one team; multi-team re-coordination and re-planning are not necessary.

Component Team

Summary of Disadvantages:

1. promotes sequential life cycle development and mindset

2. limits learning by people working only on the same components for a long time—the waste of underutilized people

3. encourages doing easier work rather than most valuable work

4. promotes some component teams to do “artificial work”

5. causes long delays due to major waiting and handoff wastes

6. encourages code duplication

7. unnecessarily promotes an evergrowing number of developers

8. complicates planning and synchronization

9. increases bottlenecks—single points of success are also single points of failure

10. fosters more poor code/design

Transition

There are several tactics for transitioning to feature teams:

1. reorganize into broad cross-component feature teams

2. gradually expand team responsibility