Team structure

6,838 views
6,420 views

Published on

Published in: Technology, Business

Team structure

  1. 1. CH10 TEAMSTRUCTURE- SUCCEEDING WITH AGILE: SOFTWAREDEVELOPMENT USING SCRUMDavid Ko
  2. 2. Agenda Team Size Feature Team How to Assemble Self-Organizing Team Put People on One Project
  3. 3. Conway’s Law“The system being produced will tend tohave a structure that mirrors the structureof the group that is producing it …”
  4. 4. Team Size
  5. 5. Team Size: Two Pizzas
  6. 6. Why Two Pizzas Are Enough Less social loafing More constructive interaction Less coordinating effort More satisfying to other members Less over-specialization
  7. 7. Team Size v.s. Productivity PerPerson Source:
  8. 8. Schedule for the Similar Project
  9. 9. Development Effort
  10. 10. Feature Team
  11. 11. How to Assemble Teams
  12. 12. Feature Team
  13. 13. Advantages of Feature Teams Better evaluate the impact of design decisions Reduce waste created by hand-offs Ensures that the right people are talking Keep the focus on delivering features
  14. 14. Obstacle of Feature Teams How to identify small pieces of functionality
  15. 15. Component Team Develop software to another team on the project rather than directly to users
  16. 16. Use Component Teams Sparingly  Build components only as feature teams ask for them  PO of the component team comes from feature team  Staff the component team temporarily withFeature Team A from the feature teams people Component Team C POFeature Team B
  17. 17. When a Component Team isAppropriate
  18. 18. Build something that will be used by multiple feature teams  One feature team build the functionality it needs  Subsequent teams refactor and generalize the functionality as their needs ariseFeature Team A Feature Team B Component Create it Refactor and generalize
  19. 19. Using a Component Team will Reduce the sharing of specialists  Specialist’s time becomes too fragmented if he joins too many teams  Consider to build a component team for these specialistsFeature Team A DBA teamFeature Team B Encryption team
  20. 20. The Risk of Multiple Approaches>> Disadv of a Component Team If you want to avoid  Different team implement a different team to the same problem  Feature teams each build on the top of what prior feature teams have done but do so without a cohesive vision
  21. 21. What’s Right Today May Be WrongTomorrow No team structure is forever Please raise your issues and improve during retrospective
  22. 22. How to Assemble Self-Organizing Team
  23. 23. Two Heads Are Better ThanOne Collective wisdom of the team is better than the wisdom of one personnel manager
  24. 24. Include All Needed Disciplines All skills necessary to go from idea to implemented feature be represented on the team Over time, individuals will learn some of the skills possessed by another members
  25. 25. Balance Technical Skill Levels Need all skill levels on the team Seniors feel boring if they do low criticality features Juniors hope they can benefit from seniors
  26. 26. Balance Domain Knowledge Build up of domain knowledge throughout the organization Not to say that we need to assemble a team entirely of domain experts
  27. 27. Seek Diversity Different …  gender, race and culture  how individuals think about problems  how they make decisions
  28. 28. Consider Persistence It takes time for tam members to learn to work tell together Keep team members together who have worked well together in the past
  29. 29. Put People on One Project
  30. 30. Time on Task Decreases with TooMany Tasks
  31. 31. When Multitasking is OK If a person cannot be fully or nearby fully utilized on a single project Rather than have everyone multitask a little, it’s better to have a few people multitask a lot.
  32. 32. Other Things You Can Try Don’t start a new project until it can be fully staffed Include ramp-up and wind-down time in enterprise plan Institute simple rules Go slow but go

×