Agile Team Dynamics by Bhavin Chandulal Javia

Agile Team Dynamics

Bhavin Javia

ThoughtWorks, B’lore

[email protected]

© ThoughtWorks 2010

18th July 2010

Agenda

• How teams become “Agile” ?• Factors affecting Agile teams• Evolution of Team Dynamics • Q & A

© ThoughtWorks 2010 2

3

How teams become “Agile” ?



Agility

5

Manifesto of Agile Software Development


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


Customers

Distances

Time zones

Environment

Tools

People


People

• Most important factor• Skills• Collective responsibility• Self organizing team• Relationships• Aspirations


Customers

• Partners• Sponsors of innovation• Sponsors of growth• Relationship affects

team morale• Part of the team


Distances

• Create hurdles for– Communication– Collaboration– Feedback– Relationship– Team work


Time zones

• 24x7 work culture• Affects collaboration• Cultural issues


Tools

• Right tool for the job• Tools forced top down

– fail on the ground

• Let the team choose• Shared toolset


Environment

• Open work environment• No artificial barriers• Freedom of expression• Encourage innovation• Encourage “fail fast”• Positive energy

13

Evolution of Team Dynamics


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

Performing

Tuckman’s Group Development Model

Adjourning

15

Freelancer

• One man army• Collaborates only with customer • Independent decisions• Single point of failure


16

Freelancer


One man Army (must play all roles)

Takes up all roles,Learns from mistakes & failures

Independent Decisions (might remain unchallenged)

Takes opinion and support from the community

Single point of failure(increased risk to delivery)

Hires more freelancers or switches to a vendor

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


18

A Dev Pair


Must be multi functional Pair splits, takes up different roles

Scalability challenges Code generation, Test automation frameworks begin to emerge

Lack of certain skills Forced learning happens,Specialists are hired for specific tasks

19

Small Collocated Team

• Team Structure– 2 Dev pairs – 1 BA – 1 QA


20


• Collective ownership and responsibility• Direct collaboration with customer• Distribution of workload• No communication overheads• Immediate and direct feedback• Overlap of roles


21



Need for team space Team and customer move into an officeOpen, highly collaborative environment

Overlap of roles(confusion and conflicts)

Roles get defined and assigned

22

Small Distributed Team

• Team Structure– 1 Dev pair (onsite)– 1 BA (onsite)– 1 Dev pair (offshore)– 1 QA (offshore)


23


• 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


24



Collaboration challenges Collaboration tools emergeWorking hours adjusted to create overlap

Lack of context Rotation of people between locationsDaily stand-up meetings and calls

Larger feedback cycles Collective code ownership encouragedContinuous Integration is introduced

25

Large Collocated Team

• Team Structure– 8 Dev pairs– 2 BAs– 2 QAs– 1 IM/PM


26


• 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


27



Customer’s availability BAs become proxy customersUser stories get larger – well defined requirements

Collective ownership hurts Dev huddles, Dev lunches, Dev trainingIndividual BAs start owning features

Difficult to rollout changes(conflicts of opinion, lack of awareness)

Leadership from Tech leads/Sr Devs Technology/Process coaches called in

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)


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”


30

Challenges and Solutions


Collaboration becomes difficult Tracking and collaboration tools usedTime overlap b/w two teams increasedSeparation of responsibilitiesDaily hand off calls

Scaling challenges peakHigh expectations of customer

Specialized sub-teams createdShowcases, Daily updates, ReportsFrequent releases

People become emails/voices,Blame games

Video conferencing introducedGreater rotation between teams soughtTeam ambassadorsTeam building activities – Outings, Goodies


Q & A


[email protected]

Agile Team Dynamics by Bhavin Chandulal Javia

Technology

Transcript of Agile Team Dynamics by Bhavin Chandulal Javia