1. Distributed Agile
Issues & Challenges
Patterns and Anti-Patterns
Naresh Jain
Twitter: @nashjain
http://blogs.agilefaqs.com
Licensed Under Creative Commons by Naresh Jain
1

2. Why Distributed
Development?
Licensed Under Creative Commons by Naresh Jain
2

3. “right” people are distributed
3

4. Global Economy
4

5. Business are distributed
5

6. Power Centers
6

7. 7

8. Decrease in Communication Bandwidth
8

9. Lack of visibility into project status
9

10. Lack of visibility into project status
9

11. Lack of “remote” Control
10

12. 11

13. Cultural Differences
12

14. Configuration Management
13

15. Coordination is difficult
14

16. Coordination is difficult
14

17. Me
15

18. 16

19. Mumbai
17

20. Tech Talks!
18

21. FitNesse ProTest
DBFit FitDecorator ProFIT
La"u Patang QWick
19

22. 20

23. 21

24. 22

25. 23

26. 24

27. 25

28. 26

29. Root Cause
My Observations
Licensed Under Creative Commons by Naresh Jain
27

30. Lack of Trust
28

31. Loss of Context (biz & tech)
29

32. Delayed Feedback (distance & time)
30

33. Duplication of Effort
31

34. Change is Inevitable
32

35. What does this lead to?
Licensed Under Creative Commons by Naresh Jain
33

36. Heavyweight Process
34

37. More and more Upfront
35

38. Strict Change Control
36

39. Over-reliance on documentation
37

40. Inability to React
38

41. Communication Gaps
39

42. Frustration
40

43. Erosion of Trust
41

44. Distributed Agile?
Licensed Under Creative Commons by Naresh Jain
42

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

46. Case Studies
Licensed Under Creative Commons by Naresh Jain
44

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

48. 1 Account Manager
1 PM
1 BA
2 Tester
1DBA
1 Manager
1 BA
3 Dev
1Tester
46

49. We Faced Typical
Maintenance Project
Challenges
Licensed Under Creative Commons by Naresh Jain
47

50. Lack of Documentation
48

51. Lack of System Expert
49

52. Inexperienced Team Members
50

53. Lack of Test Safety Net
51

54. Legacy Code
52

55. Fluctuating Workload
53

56. Lack of Trust
54

57. Fear
55

58. Uncertainty
56

59. Frustration
57

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

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

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

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

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

65. 1 PM
1 Tester
2 Dev
1 Tester
63

66. Case Study 2
Licensed Under Creative Commons by Naresh Jain
64

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

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

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

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

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

72. Soon...Program Organization
Program Management
Scrum
Scrum Master Scrum of Scrum Tech Lead Scrum of
of Scrums Scrum of Scrums
App 1
App 2 Shared Services/
M1 M2 Arch/Infrastructure
Scrum M1 M2
Master
Scrum of Scrum
Scrums Master
Scrum of S1 S2
M4 Scrums
M5 M6
Tech Lead M8 Frameworks S3
Scrum of
Scrums Tech Lead
Scrum of
Scrums
M4 S4 S5
M3 M7 M3
M6
70

73. 4 Module Teams
Architecture Team
1 Config Mgmt Team
3 Enterprise Products
1 IQA Team
18 Module Teams
1 DB Team
1 IQA Team 4 Module Teams
1 IQA Team
4 Module Teams
71

74. Key Challenges We Faced
Licensed Under Creative Commons by Naresh Jain
72

75. Tools got in the Way
73

76. Death by Cross-Team Integration
74

77. End-to-End Delivery came to Grinding Halt
75

78. Confusion & Rework
76

79. Frustration
77

80. Summary
How Agile can help?
Licensed Under Creative Commons by Naresh Jain
78

81. Empowered Small Teams
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.
79

82. Small Frequent Releases
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
80

83. Puts the customer in the driving seat
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.
Customer == Product Owner
81

84. Adaptive Planning
Inspect and Adapt
Help responding to change
Teams communicate often, share information frequently
82

85. Feedback Driven
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.
83

86. Practices that make a
Difference
Licensed Under Creative Commons by Naresh Jain
84

87. Continuous Integration
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”
85

88. Test Driven Development
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
86

89. Collective Ownership
Cross Functional Pairing and Pair Programming
Single shared code repository per project
Mutually agreed coding standards and guidelines (Automated
Check)
Code Walk-through
87

90. Other Practices
Stand Up Meetings/Daily Scrum
Dev Hurdles
Retrospectives
Planning Game
88

91. Other Practices
Stand Up Meetings/Daily Scrum
Dev Hurdles
Retrospectives
Planning Game
88

92. Distributed Agile
Patterns
Licensed Under Creative Commons by Naresh Jain
89

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

94. Single Virtual Team
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
91

95. Cross Pollination
92

96. Cross Pollination
Seeding Visits
Start the project with a collocated team
Knowledge Transfer – People as carriers of knowledge
Build inter-personal relationships
92

97. Cross Pollination
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
92

98. Cross Pollination
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.
92

99. Cross Pollination - Offshore Model
Time
OnSite
Offshore
- Offshore Team Member
- Client-side Team Member - Swap Members
93

100. Cross Pollination - Offshore Model
Time
i 0 & i1
OnSite
Offshore
- Offshore Team Member
- Client-side Team Member - Swap Members
93

101. Cross Pollination - Offshore Model
Time
i 0 & i1 i2
OnSite
Offshore
- Offshore Team Member
- Client-side Team Member - Swap Members
93

102. Cross Pollination - Offshore Model
Time
i 0 & i1 i2 i3
OnSite
Offshore
- Offshore Team Member
- Client-side Team Member - Swap Members
93

103. Cross Pollination - Offshore Model
Time
i 0 & i1 i2 i3 i4
OnSite
Offshore
- Offshore Team Member
- Client-side Team Member - Swap Members
93

104. Cross Pollination - Distributed Model
Time
OnSite
Offshore
- Offshore Team Member
- Client-side Team Member - Swap Members
94

105. Cross Pollination - Distributed Model
Time
i 0 & i1
OnSite
Offshore
- Offshore Team Member
- Client-side Team Member - Swap Members
94

106. Cross Pollination - Distributed Model
Time
i 0 & i1 i2
OnSite
Offshore
- Offshore Team Member
- Client-side Team Member - Swap Members
94

107. Cross Pollination - Distributed Model
Time
i 0 & i1 i2 i3
OnSite
Offshore
- Offshore Team Member
- Client-side Team Member - Swap Members
94

108. Cross Pollination - Distributed Model
Time
i 0 & i1 i2 i3 i4
OnSite
Offshore
- Offshore Team Member
- Client-side Team Member - Swap Members
94

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

110. Source : ThoughtWorks
96

111. Massive over-communication
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
97

112. Local Standup meetings
Source : ThoughtWorks
98

113. Anti-Patterns
Licensed Under Creative Commons by Naresh Jain
99

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

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

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

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

118. Conclusion
Distributed Development is difficult in general!
Agile can help.
Strong Development practices very important!
104

119. References
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
105

120. Questions?
Thank you
Distributed Agile
Naresh Jain
naresh@agilefaqs.com
106