1. CH10 TEAM
STRUCTURE
- SUCCEEDING WITH AGILE: SOFTWARE
DEVELOPMENT USING SCRUM
David Ko

2. Agenda
 Team Size
 Feature Team
 How to Assemble Self-Organizing Team
 Put People on One Project

3. Conway’s Law
“The system being produced will tend to
have a structure that mirrors the structure
of the group that is producing it …”

5. Team Size

6. Team Size: Two Pizzas

7. Why Two Pizzas Are Enough
 Less social loafing
 More constructive interaction
 Less coordinating effort
 More satisfying to other members
 Less over-specialization

8. Team Size v.s. Productivity Per
Person
Source:

9. Schedule for the Similar Project

10. Development Effort

11. Feature Team

12. How to Assemble Teams

13. Feature Team

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

15. Obstacle of Feature Teams
 How to identify small pieces of functionality

16. Component Team
 Develop software to another team on the project
rather than directly to users

17. 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 with
Feature Team A from the feature teams
people Component Team C
PO
Feature Team B

18. When a Component Team is
Appropriate

19. 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 arise
Feature Team A Feature Team B
Component
Create it Refactor and generalize

20. 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
specialists
Feature Team A DBA team
Feature Team B Encryption team

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

22. What’s Right Today May Be Wrong
Tomorrow
 No team structure is forever
 Please raise your issues and improve during
retrospective

23. How to Assemble Self-
Organizing Team

24. Two Heads Are Better Than
One
 Collective wisdom of the team is better than
the wisdom of one personnel manager

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

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

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

28. Seek Diversity
 Different …
 gender, race and culture
 how individuals think about problems
 how they make decisions

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

30. Put People on One Project

31. Time on Task Decreases with Too
Many Tasks

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

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