2. 2
Agenda
About ADP
Maintenance
Traditional Working Model
Extended Team In India
Agile In ADP India
Multiple Product Back Logs
Results
3. 3
About ADP
World’s leading provider of Outsourced HR and Auto
Dealership Services
Brief Profile
Established in 1949 and Headquartered in NJ
Revenues of about $9 billion
Operates in more than 50 Countries with 46,000 Associates
90% of revenue is recurring with an average client tenure of
over 9 years
Electronically moved over $1 trillion in client tax, direct deposit,
and related client funds in fiscal 2008
Pay 30% of the employees of medium-sized businesses in the U.S.
ADP India
Fully Owned Subsidiary of ADP Inc.
Established in July 1999 with 102 Associates
Currently 3900+ and growing
Involved in R&D, BPO and RIM
Offices in Hyderabad and Pune
Works on an Extended Team Model
4. 4
ADP India R&D
India R&D Head
Prod1 Dev Team
Roseland NJ
15Yrs in Market
Mainframe
Team Size 100
Prod2 Test Team
Pleasanton CA
5Yrs In Market
.Net
Team Size 50
Prod3 Dev Team
Alpharetta GA
To Be Release
J2EE
Team Size 25
Prod4
Dev & Test Team
Canada
1 Yr
Web 2.0
Team Size 10
…….
???
Prod ‘n’ Team
<Function ??>
<Location??>
<Maturity??>
<Technology?>
<Team Size ??>
6. 6
Traditional Working Model
Collocated
Specialists By Modules
Captive Ownerships
Releases Plans Module By Module
Module 1 Expert
Module 2 Expert
Module 3 Expert
Module ‘n’ Expert
7. 7
Extended Team In India
India TeamModule 1 Expert
Module 2 Expert
Module 3 Expert
Module ‘n’ Expert
8. 8
Extended Team In India
New “Specialists” Created In India
Many Sub Groups
Capacity Planning Still Module By Module
Varying Utilization
Predominantly Waterfall At Both Ends
More Challenges On India Side To “Click” As One Team
India TeamModule 1 Expert
Module 2 Expert
Module 3 Expert
Module ‘n’ Expert
9. 9
Agile In ADP India
Agile Objectives
Increase Capacity – More Utilization
Reduce Individual Dependencies
Reduce Onsite Dependencies
Bring In The “Team” Spirit
Bring Common Commitment
US Team India Team
Scrum Master
Product Owner
789101112
123456
13
Product Backlog
10. 10
Agile In ADP India
India Team Gets Deliverables*
R100 : New Requirement In Batch Process 8/25/10
R200 : Add New Feature In UI Screen 9/15/10
R300 : Develop New Report 9/23/10
Product Owner Breaks Deliverable Into Stories
R100–8 Stories R200–5 Stories R300–13 Stories
2 Week Sprints
Stories In Sprint From Any Deliverable
PO Decides The Sequence Of The Stories
Everyone Is Responsible For Every Deliverable
Pair Programming
Normal Sprint Practices
India Team
Scrum Master
Product Owner
789101112
123456
13
Product Backlog
* Production/Support Incidents are a different beast
12. 12
Multiple Product Backlogs
Scrum Master
Product Owner
7
8
9
10
11
12
1
2
3
4
5
6
13
PB R100
8/25/10
7
8
9
10
11
12
1
2
3
4
5
6
13
7
8
9
10
11
12
1
2
3
4
5
6
13
PB R200
9/15/10
PB R300
9/23/10
Textbook SCRUM
One Product Backlog
One Release Plan
One Priority
Adaptive Plan Is Easy To Manage
Our Context
Multiple Backlogs
Each Deliverable Is Different
Size – Number Of Stories
Release Date
Priority
Have To Make Parallel Progress
Customized SCRUM – Agility!
How Can We Plan?
13. 13
Deliverable R100
Story Story Points
Story 101 2
Story 102 4
Story 103 4
Story 104 8
Story 105 4
Story 106 8
Story 107 1
Story 108 4
Total Size 35
Date 8/25/2010
Available Sprints 2
Team Velocity 28
Doable ? YES
Multiple Product Backlogs
India Team
Scrum Master
Product Owner
789101112
123456
13
Product Backlog
R100 “Deliverable Velocity” : 18 SP
14. 14
Deliverable R100
Story
Story
Points
Story 101 2
Story 102 4
Story 103 4
Story 104 8
Story 105 4
Story 106 8
Story 107 1
Story 108 4
Total Size 35
Date 8/25/2010
Available
Sprints 2
Team
Velocity 28
Deliverable R200
Story
Story
Points
Story 201 2
Story 202 4
Story 203 8
Story 204 2
Story 205 4
Total Size 20
Date 9/15/10
Available
Sprints 3
Team
Velocity 28
Deliverable R300
Story
Story
Points
Story 301 1
Story 302 2
Story 303 8
Story 304 4
.. ..
…. …
Story 313 2
Total Size 53
Date 9/23/10
Available
Sprints 4
Team
Velocity 28
Can We Deliver All?
Multiple Product Backlogs
R100 Deliverable Velocity : 18 SP R200 Deliverable Velocity : 7 SP R300 Deliverable Velocity : 14 SP
15. 15
Deliverable
Size
SP
Release
Date
Available
Sprints
Deliverable
Velocity
R100 35 8/25/2010 3 18
R200 20 9/15/2010 2 7
R300 53 11/05/2010 4 14
Total 108 39
Team Velocity (SP) 28
What Are Average SP To Be Developed For Each Deliverable?
What Are The Total Average SP To Be Developed Per Sprint ? (39)
What Is Team Velocity? (28)
In Control If Velocity Is Less Than Average Deliverable Velocity
Deliverable Velocity : The average SPs that need to be delivered in
each available sprint before its release date
Multiple Product Backlogs
16. 16
Results
On Average Team Utilization Has Moved Up From 60% To 90%
Every Module Has More Than One Specialist
Team Level Ownership. Everyone Responsible For Success Of
Every Deliverable or Otherwise.
Team Confidence On Rise To Stake Claim For Bigger Projects
US Team India Team
Scrum Master
Product Owner
789101112
123456
13
Product Backlog
ADP R&D teams in India handle multiple functions. Participate in entire life cycle of s/w development. The current scope of this presentation is however limited to a team that is predominantly working on a maintenance of an legacy application
The application has been originally developed close to 10 years back. A hosted solution offering solutions to the client base in US
A lot of new features were added ever since it was originally built. Regulatory changes by US govt may also result in changes needed in the application suite
Business has grown multifold ever since the application is built. A need to integrate multiple applications also has emerged
All these needs result in multiple projects of varying size that development has to deliver in multiple releases.
New feature development, integrating to another solution, improving the look and feel, increasing the performance, bug fixes etc., are all the never ending tasks
Production incidents are however dealt separately given their urgency. They are not part of this presentation.
Everyone Co-located
The entire team is in one location in US.
Specialists by modules and/or technical skill
Full ownership of modules. They own the projects, issues and responsibility to deliver
Added India team. Created module by module specialists. Capacity planning is still done by module by module. It is possible that one module team is extremely busy and another module team is not fully engaged
This is great model to start the operations quickly. However, it starts to become inefficient
Agile has been introduced after a long deliberation. Agile is not introduced for typical objectives like “continuous refinement”, “Quick Time To Market” etc.. More focused objectives are to break down the silos within the team that have become too inefficient. Few people busy on one module and few others are not too busy.
Product owner gets the requirements in usual functional specification documents.
Product owner breaks the FSD into stories
Product owner prioritizes stories within deliverables and across deliverables
R100 : New Requirement In Batch Process 8/25/10
R200 : Add New Feature In UI Screen 9/15/10
R300 : Develop New Report 11/5/10
When there is only one product backlog, it is easy to check the current size of the total deliverable. Depending on the available sprints, we know if we are on track or not.
With the Agile spirit, we can change, add, remove stories from the deliverable at anytime as long as they are not in the current sprint.
That may change the overall size of the deliverable. The minute we see we need an extra sprint than what we have, we go back to customer/business for either scope reduction or date change or extra resources. That is what is adaptive planning in Agile.
When there is only one product backlog, it is easy to check the current size of the total deliverable. Depending on the available sprints, we know if we are on track or not.
With the Agile spirit, we can change, add, remove stories from the deliverable at anytime as long as they are not in the current sprint. That may change the overall size of the deliverable. The minute we see we need an extra sprint than what we have, we go back to customer/business for either scope reduction or date change or extra resources. That is what is adaptive planning in Agile.
With multiple deliverable all with their own changing sizes, how can we assess if we got everything under team’s control? We want to make…
Parallel progress on each deliverable (based on the priority set by the product owner)
Don’t want to miss any deliverable OR raise the alarm as soon as we know we may not be able to make it with current scope.
R100 : New Requirement In Batch Process 8/25/10
R200 : Add New Feature In UI Screen 9/15/10
R300 : Develop New Report 11/5/10
We devised our own model for Adaptive Planning. Total number of available story points doesn’t help us determine our confidence of delivery. What we need to do is to find how many story points of a every deliverable on average we must deliver in each sprint. As long as the total of the average SP are less than the team velocity, we are perfectly fine!
Every time a change happens in any deliverable, we got to revisit this table to see if we are still within the limits.
Product owner introduces stories based on the deliverable priority and priority within the deliverable
