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