Licensed Under Creative Commons by Naresh Jain
Distributed AgileIssues & Challenges
Patterns and Anti-Patterns
Naresh JainTwitter: @nashjain
http://blogs.agilefaqs.com 1
Licensed Under Creative Commons by Naresh Jain
Why Distributed Development?
2
“right” people are distributed
3
Global Economy
4
Business are distributed
5
Power Centers
6
7
Decrease in Communication Bandwidth
8
Lack of visibility into project status
9
Lack of visibility into project status
9
Lack of “remote” Control
10
11
Cultural Differences
12
Configuration Management
13
Coordination is difficult
14
Coordination is difficult
14
Me
15
16
Mumbai17
Tech Talks!
18
FitNesse ProTest
PatangLa"u
FitDecoratorDBFit
QWick
ProFIT
19
20
21
22
23
24
25
26
Licensed Under Creative Commons by Naresh Jain
Root CauseMy Observations
27
Lack of Trust
28
Loss of Context (biz & tech)
29
Delayed Feedback (distance & time)
30
Duplication of Effort
31
Change is Inevitable
32
Licensed Under Creative Commons by Naresh Jain
What does this lead to?
33
Heavyweight Process
34
More and more Upfront
35
Strict Change Control
36
Over-reliance on documentation
37
Inability to React
38
Communication Gaps
39
Frustration
40
Erosion of Trust
41
Licensed Under Creative Commons by Naresh Jain
Distributed Agile?
42
Agile Manifesto
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and Interactions OVER Processes and Tools. Working Software OVER Comprehensive Documentation.
Customer Collaboration OVER Contract Negotiation. Responding to Change OVER following a Plan.
That is, while there is value in the items on the right, we value the items on the left more.”
43
Licensed Under Creative Commons by Naresh Jain
Case Studies
44
Offshore Agile Maintenance Project
Background
EAI project for back office data validation and billing system for a pay-per-view cable company in New York
2 years later, lack of funds to maintain the app
Decision to offshore the project
Ended up with one year maintenance contract.
45
1 Account Manager1 PM1 BA
2 Tester1DBA
1 Manager1 BA3 Dev
1Tester
46
Licensed Under Creative Commons by Naresh Jain
We Faced Typical Maintenance Project
Challenges
47
Lack of Documentation
48
Lack of System Expert
49
Inexperienced Team Members
50
Lack of Test Safety Net
51
Legacy Code
52
Fluctuating Workload
53
Lack of Trust
54
Fear
55
Uncertainty
56
Frustration
57
XP Practices we started of with
Planning game – 2 week iterations, story cards, Iteration Planning Meetings
Small releases – 2 to 3 months
Collective code ownership
Continuous integration & Automated Release
Standup meetings
Coding standards
58
What we did not have/could not do?
Onsite Client
System Metaphor
Simple Design
Automated Testing
User Stories (instead we had CR or Bugs)
40 hour week / sustainable pace
59
Evolved Agile Practices
Kanban - Priority Log
Micro releases – 2 to 3 days
Refactoring (completely changed the Architecture)
Pair Programming
Collective code ownership
Continuous integration & One click Release
Test Driven Development
60
Evolved Agile Practices...
Retrospectives
Daily client driven demo on Dev env
EOD Status mail
Cross functional Pairing
Demos and functional walk thru by Client
Automated Acceptance Test
61
Results
Product performs 3 times faster than before
Huge increase in customer satisfaction
More interesting work with increase per hour rate
Great relationship and happy team
Great platform to experiment with new process ideas
Massive reduction in operating cost of the project
62
1 PM1 Tester
2 Dev1 Tester
63
Licensed Under Creative Commons by Naresh Jain
Case Study 2
64
Large Healthcare Enterprise System
SAP like Healthcare suite for medium to large-scale hospitals and institutes
Large Re-architecture effort (Across 3 different Product Lines)
400+ team size across 3 different continents
Multiple Organizations involved for Training and Coaching Teams
65
Started Off with...
Pilot Project (1 Module of the entire application)
1 PM, 1 Scrum Master, 1 Architect/TL, 6 Dev, 1 BA and 1 Tester
100% Collocated Team
Offshore members were onsite for 3 months (3 Sprints)
66
Started off with Scrum/XP Practice
2 Week Project Inception
Prioritized Backlog with WAGs
1 Month Sprints
User Stories
Stand-up Meetings
Sprint Review and Retrospectives
Automated Builds
67
In the first 2 months
1 Month Sprint
User Stories
Automated Acceptance Tests
Test First Development
Collective Code Ownership
Continuous Integration
Sprint Review and Retrospectives
68
End of 3 Months
2 Week Sprints
Distributed Teams
Evolutionary Design
TDD
Build Promotion and Single Click Release
Automated UI Tests
Brand Ambassadors/Cross Pollination
69
Soon...Program Organization
Tech Lead Scrum of Scrums
App 1
M3
Scrum Master
Scrum of Scrums
M2M1
M7M6
M4
M5
Tech Lead Scrum of Scrums
App 2
M3
Scrum Master
Scrum of Scrums
M2M1
M6
M4
Tech Lead Scrum of Scrum of Scrums
Shared Services/Arch/Infrastructure
S4
S2S1
S5
S3Frameworks
Scrum Master Scrum of Scrum of Scrums
Program Management Scrum
M8
70
Architecture Team3 Enterprise Products
18 Module Teams1 DB Team
1 IQA Team
4 Module Teams
4 Module Teams1 Config Mgmt Team
1 IQA Team
4 Module Teams1 IQA Team
71
Licensed Under Creative Commons by Naresh Jain
Key Challenges We Faced
72
Tools got in the Way
73
Death by Cross-Team Integration
74
End-to-End Delivery came to Grinding Halt
75
Confusion & Rework
76
Frustration
77
Licensed Under Creative Commons by Naresh Jain
SummaryHow Agile can help?
78
Its the people Duh!
Build teams around motivated and passionate individuals
Build a team environment where people are not afraid to try new things and fail (fail fast)
Make work a fun place.
Empowered Small Teams
79
Increase visibility and enable early feedback.
A weekly software showcase gives more confidence than a weekly status report.
Fail fast, recover quickly and at lower cost
Small Frequent Releases
80
Customer does Feature prioritization
Customer uses early feedback to elaborate on and develop the requirements. Eliminates the need to articulate requirements in detailed documentation
Customer makes business decision and development team makes technical decisions in collaboration with each other.
Puts the customer in the driving seat
Customer == Product Owner
81
Adaptive Planning
Inspect and Adapt
Help responding to change
Teams communicate often, share information frequently
82
Testing centric
Test early, Test often and Test continuously
Continuous integration
Integrate with every checkin and avoid Integration Nightmares
Automated Acceptance Tests
Let acceptance criteria drive your development
Team tastes success every time an iteration successfully passes customer’s test.
Feedback Driven
83
Licensed Under Creative Commons by Naresh Jain
Practices that make a Difference
84
Constant integration, building & testing of system with each change
Set up a build promotion process and reduces on-site deployment risk.
“The last person doesn’t go home until the build is clean”
Continuous Integration
85
Reduces ambiguity around requirements by having executable specifications
Acceptance Criteria per story
Acceptance Tests are written before coding starts
Use Unit Tests to drive your design
Build a safety net to prevent regression bugs
Test Driven Development
86
Cross Functional Pairing and Pair Programming
Single shared code repository per project
Mutually agreed coding standards and guidelines (Automated Check)
Code Walk-through
Collective Ownership
87
Other Practices
Stand Up Meetings/Daily Scrum
Dev Hurdles
Retrospectives
Planning Game
88
Other Practices
Stand Up Meetings/Daily Scrum
Dev Hurdles
Retrospectives
Planning Game
88
Licensed Under Creative Commons by Naresh Jain
Distributed AgilePatterns
89
Shared Workload
Work split
Divide work by functionality (stories), not by technical layers (horizontally). Otherwise, you create an interdependence that makes the dependent sub-team less productive
Collective Ownership
Each team is capable of demonstrating end-to-end functionality
Capacity surpluses/shortages can be balanced through active management of work load distribution
90
Everyone works on the same release/iteration cycle drumbeats
Shared code base fosters collective ownership of the source code
Shared build environments allow teams to collaborate and integrate continuously
Developing in “End-to-end” functional slices rather than layers allows teams to build upon each other’s work and reduces dependencies between locations
Single Virtual Team
91
Cross Pollination
92
Seeding Visits
Start the project with a collocated team
Knowledge Transfer – People as carriers of knowledge
Build inter-personal relationships
Cross Pollination
92
Seeding Visits
Start the project with a collocated team
Knowledge Transfer – People as carriers of knowledge
Build inter-personal relationships
“Maintenance” Visits
Ongoing
Bi-directional and multifunctional
Cultural Ambassadors
Cross Pollination
92
Seeding Visits
Start the project with a collocated team
Knowledge Transfer – People as carriers of knowledge
Build inter-personal relationships
“Maintenance” Visits
Ongoing
Bi-directional and multifunctional
Cultural Ambassadors
Establish a Travel budget. Often it is a very small percentage of total project cost.
Cross Pollination
92
Cross Pollination - Offshore ModelTime
OnSite
Offshore
- Offshore Team Member
- Client-side Team Member - Swap Members
93
Cross Pollination - Offshore ModelTime
OnSite
Offshore
- Offshore Team Member
- Client-side Team Member - Swap Members
i 0 & i1
93
Cross Pollination - Offshore ModelTime
OnSite
Offshore
- Offshore Team Member
- Client-side Team Member - Swap Members
i 0 & i1 i 2
93
Cross Pollination - Offshore ModelTime
OnSite
Offshore
- Offshore Team Member
- Client-side Team Member - Swap Members
i 0 & i1 i 2 i 3
93
Cross Pollination - Offshore ModelTime
OnSite
Offshore
- Offshore Team Member
- Client-side Team Member - Swap Members
i 0 & i1 i 2 i 3 i 4
93
Cross Pollination - Distributed ModelTime
OnSite
Offshore
- Offshore Team Member
- Client-side Team Member - Swap Members
94
Cross Pollination - Distributed ModelTime
OnSite
Offshore
- Offshore Team Member
- Client-side Team Member - Swap Members
i 0 & i1
94
Cross Pollination - Distributed ModelTime
OnSite
Offshore
- Offshore Team Member
- Client-side Team Member - Swap Members
i 0 & i1 i 2
94
Cross Pollination - Distributed ModelTime
OnSite
Offshore
- Offshore Team Member
- Client-side Team Member - Swap Members
i 0 & i1 i 2 i 3
94
Cross Pollination - Distributed ModelTime
OnSite
Offshore
- Offshore Team Member
- Client-side Team Member - Swap Members
i 0 & i1 i 2 i 3 i 4
94
Simple Tools take you a long way
Physical Story walls with pictures on Wikis can be quite powerful
Good version control system like SVN
Online collaboration tools like Google Docs, Card Meeting, Forums, etc
5-10 min video recording using simple cameras
95
Source : ThoughtWorks
96
Infrastructure
High availability, high speed networks
High-quality speakerphones, webcams
Informative Workspaces and Information Radiators
Communications Plans
Standing calls
Overlapping hours
Instant Messaging, VoIP, NetMeeting, Webex etc.
Wikis
Team member photos on the wall
Massive over-communication
97
Local Standup meetings
Source : ThoughtWorks
98
Licensed Under Creative Commons by Naresh Jain
Anti-Patterns
99
Communication Anti-Patterns
Single Point of Failure - Resist single person communicating with the on-site team. Unless the team has language barriers
Hide real issues - Embrace transparency, honesty and openness
One liner emails - You need to set context in each mail.
Using Wikis to Dump information and not collaborate
100
Expectations Anti-Patterns
50% cost saving - Don’t sell Distributed Development purely as a cost saving scheme
Unrealistic expectations about productivity - there will be communication overhead, there will be rework and there will be misunderstandings
Wrongly try to please the customer/onsite team - Learn to say “No”
101
Focus related Anti-patterns
Tool Driven - Don’t be a tool slave. Choose the right tool for the right job.
Process OVER People - Don’t focus too much on a consistent, well-defined process across all locations. Instead let people define what works for them in their location.
102
Work Allocation Anti-Patterns
Slice work such that the two teams have to interact very little - They will drift away.
Occasional involvement - You don’t swing a huge requirement document and expect things to come back the way you wanted them
Change Control Boards - Collaborate with the customer to provide them competitive advantage
103
Conclusion
Distributed Development is difficult in general!
Agile can help.
Strong Development practices very important!
104
Most of this is based on my 5 years of experience at ThoughtWorks
Distributed Agile Development and the Death of Distance
http://www.thoughtworks.com/press-releases/Distributed-Agile-Development-and-the-Death-of-Distance.html
Case Study: Distributed Agile Development
http://www.pivolis.com/pdf/Distributed_Agile_V1.0.pdf
Distributed Agile
http://www.agilealliance.com/articles/steindlchristophdistr/file
Using an Agile Software Process with Offshore Development
http://www.martinfowler.com/articles/agileOffshore.html
References
105
Top Related