My presentation on Agile Team Dynamics given at Agile NCR 2010 conference at Gurgaon, India

1. Agile Team Dynamics BhavinJavia ThoughtWorks, B’lore bhavin@thoughtworks.com © ThoughtWorks 2010 18th July 2010

2. Agenda How teams become “Agile” ? Factors affecting Agile teams Evolution of Team Dynamics Q & A © ThoughtWorks 2010 2

3. How teams become “Agile” ? © ThoughtWorks 2010 3

4. Agility © ThoughtWorks 2010 4

5. Manifesto of Agile Software Development © ThoughtWorks 2010 5 Individuals and Interactions over Processes and Tools Working Software over Comprehensive Documentation Customer Collaboration over Contract Negotiation Responding to Change over Following a Plan “ while there is value in the items on the right, we value the items to the left more ”

6. Factors affecting Agile teams © ThoughtWorks 2010 6 People Customers Environment Tools Distances Time zones

7. People Most important factor Skills Collective responsibility Self organizing team Relationships Aspirations © ThoughtWorks 2010 7

8. Customers Partners Sponsors of innovation Sponsors of growth Relationship affects team morale Part of the team © ThoughtWorks 2010 8

9. Distances Create hurdles for Communication Collaboration Feedback Relationship Team work © ThoughtWorks 2010 9

10. Time zones 24x7 work culture Affects collaboration Cultural issues © ThoughtWorks 2010 10

11. Tools Right tool for the job Tools forced top down fail on the ground Let the team choose Shared toolset © ThoughtWorks 2010 11

12. Environment Open work environment No artificial barriers Freedom of expression Encourage innovation Encourage “fail fast” Positive energy © ThoughtWorks 2010 12

13. Evolution of Team Dynamics © ThoughtWorks 2010 13

14. Agile Team Dynamics ? Challenges faced by the team Practices and Processes evolved to solve challenges Just “ the way an agile team works ” Forming Storming Norming Tuckman’s Group Development Model Performing Adjourning © ThoughtWorks 2010 14

15. Freelancer One man army Collaborates only with customer Independent decisions Single point of failure © ThoughtWorks 2010 15

16. Freelancer © ThoughtWorks 2010 16

17. A Dev Pair Must be multi talented and multi functional Team building starts Easy collaboration with Customer Introduction of Agile practices starts e.g. Pair Programming Decisions get discussed/challenged Sense of collective responsibility Scaling issues begin to surface © ThoughtWorks 2010 17

18. A Dev Pair © ThoughtWorks 2010 18

19. Small Collocated Team Team Structure 2 Dev pairs 1 BA 1 QA © ThoughtWorks 2010 19

20. Small Collocated Team Collective ownership and responsibility Direct collaboration with customer Distribution of workload No communication overheads Immediate and direct feedback Overlap of roles © ThoughtWorks 2010 20

21. Small Collocated Team © ThoughtWorks 2010 21

22. Small Distributed Team Team Structure 1 Dev pair (onsite) 1 BA (onsite) 1 Dev pair (offshore) 1 QA (offshore) © ThoughtWorks 2010 22

23. Small Distributed Team Onsite team collaborates directly with Customer Offshore team collaborates indirectly with Customer Work gets done 24x7 Collaboration challenges surface Division of responsibilities Lack of context begins to hurt Communication overheads due to distance/time differences Feedback cycles become larger Cultural issues surface © ThoughtWorks 2010 23

24. Small Distributed Team © ThoughtWorks 2010 24

25. Large Collocated Team Team Structure 8 Dev pairs 2 BAs 2 QAs 1 IM/PM © ThoughtWorks 2010 25

26. Large Collocated Team Higher capacity to deliver Collaboration with Customer gets indirect Collective ownership begins to hurt Difficult to roll out technical and process changes Need for Managers become apparent Need for Tracking tools felt © ThoughtWorks 2010 26

27. Large Collocated Team © ThoughtWorks 2010 27

28. Large Distributed Team Team Structure 2 Dev pairs (onsite) 1 BA (onsite) 1 PM (onsite) 6 Dev pairs (offshore) 2 BAs (offshore) 2 QAs (offshore) 1 IM (offshore) © ThoughtWorks 2010 28

29. Large Distributed Team Collaboration becomes difficult Customer availability and feedback becomes scarce Collective ownership hurts more Scaling challenges peak High expectations from offshore team Customers may not realize all the challenges Localized groups of expertise begin to form Difficult situations turn into ugly Blame Games People become “email addresses” or “voices over phone” © ThoughtWorks 2010 29

30. Challenges and Solutions © ThoughtWorks 2010 30

31. Q & A © ThoughtWorks 2010 31

32. © ThoughtWorks 2010 32 bhavin@thoughtworks.com