Adp scrum multiple product logs

3,008 views

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
3,008
On SlideShare
0
From Embeds
0
Number of Embeds
2,039
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • 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
  • Adp scrum multiple product logs

    1. 1. Scrum - Maintenance Projects - Multiple Product Backlogs Akkiraju Bhattiprolu (Akki) akkirajub@gmail.com http://www.after3beers.com/ Facebook : akkirajub Twitter : akkirajub Linkedin : akkiraju +91 98665 51263 Akkiraju Bhattiprolu (Akki) Senior Manager ADP Private Ltd. Hyderabad akkiraju_bhattiprolu@adp.com http://www.adp.com/ +91 (40) 66378073
    2. 2. 2 Agenda  About ADP  Maintenance  Traditional Working Model  Extended Team In India  Agile In ADP India  Multiple Product Back Logs  Results
    3. 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. 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 ??>
    5. 5. 5 Maintenance New Feature New Regulation Integrations A Hosted ADP App Non Functional (Scalability etc)  Multiple Sub Projects  Projects Vary Significantly In Size, Complexity & Priority  Multiple Releases  Business Prioritizes And Development Delivers Production / Support Incidents Defects
    6. 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. 7 Extended Team In India India TeamModule 1 Expert Module 2 Expert Module 3 Expert Module ‘n’ Expert
    8. 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. 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. 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 
    11. 11. 11 Agile In ADP India
    12. 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. 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. 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. 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. 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
    17. 17. 17 Bouquets And Brickbats

    ×