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
47. Offshore Agile Maintenance Project
Background
EAI project for back ofļ¬ce 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
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
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 ļ¬rst 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 Conļ¬g 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
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 conļ¬dence 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
speciļ¬cations
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
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
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
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
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-deļ¬ned process across all locations. Instead let
people deļ¬ne 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
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/ļ¬le
Using an Agile Software Process with Offshore Development
http://www.martinfowler.com/articles/agileOffshore.html
105