Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Like this presentation? Why not share!

Adp scrum multiple product logs

on

  • 2,974 views

 

Statistics

Views

Total Views
2,974
Views on SlideShare
1,004
Embed Views
1,970

Actions

Likes
0
Downloads
6
Comments
0

4 Embeds 1,970

http://www.after3beers.com 1962
http://translate.googleusercontent.com 5
http://www.after3icecreams.com 2
http://webcache.googleusercontent.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • The Billable HC Forecast is as of lsat month as the latest one is not yet finalized
  • The Billable HC Forecast is as of lsat month as the latest one is not yet finalized
  • The Billable HC Forecast is as of lsat month as the latest one is not yet finalized
  • The Billable HC Forecast is as of lsat month as the latest one is not yet finalized
  • The Billable HC Forecast is as of lsat month as the latest one is not yet finalized 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.
  • The Billable HC Forecast is as of lsat month as the latest one is not yet finalized 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
  • The Billable HC Forecast is as of lsat month as the latest one is not yet finalized 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
  • The Billable HC Forecast is as of lsat month as the latest one is not yet finalized
  • The Billable HC Forecast is as of lsat month as the latest one is not yet finalized 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.
  • The Billable HC Forecast is as of lsat month as the latest one is not yet finalized 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
  • The Billable HC Forecast is as of lsat month as the latest one is not yet finalized
  • The Billable HC Forecast is as of lsat month as the latest one is not yet finalized 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
  • The Billable HC Forecast is as of lsat month as the latest one is not yet finalized 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.
  • The Billable HC Forecast is as of lsat month as the latest one is not yet finalized 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
  • The Billable HC Forecast is as of lsat month as the latest one is not yet finalized 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
  • The Billable HC Forecast is as of lsat month as the latest one is not yet finalized
  • The Billable HC Forecast is as of lsat month as the latest one is not yet finalized

Adp scrum multiple product logs Adp scrum multiple product logs Presentation Transcript

  • Scrum - Maintenance Projects - Multiple Product Backlogs Akkiraju Bhattiprolu (Akki) [email_address] http://www.after3beers.com/ Facebook : akkirajub Twitter : akkirajub Linkedin : akkiraju +91 98665 51263 Akkiraju Bhattiprolu (Akki) Senior Manager ADP Private Ltd. Hyderabad [email_address] http://www.adp.com/ +91 (40) 66378073
  • Agenda
    • About ADP
    • Maintenance
    • Traditional Working Model
    • Extended Team In India
    • Agile In ADP India
    • Multiple Product Back Logs
    • Results
  • 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
  • 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 ??>
  • 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
  • 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
  • Extended Team In India India Team Module 1 Expert Module 2 Expert Module 3 Expert Module ‘n’ Expert
  • 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 Team Module 1 Expert Module 2 Expert Module 3 Expert Module ‘n’ Expert
  • 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 Product Backlog 7 8 9 10 11 12 1 2 3 4 5 6 13
  • 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 Product Backlog * Production/Support Incidents are a different beast  7 8 9 10 11 12 1 2 3 4 5 6 13
  • Agile In ADP India
  • Multiple Product Backlogs
    • 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?
    Scrum Master Product Owner PB R100 8/25/10 PB R200 9/15/10 PB R300 9/23/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 7 8 9 10 11 12 1 2 3 4 5 6 13
  • Multiple Product Backlogs
    • R100 “Deliverable Velocity” : 18 SP
    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 India Team Scrum Master Product Owner 7 8 9 10 11 12 1 2 3 4 5 6 13 Product Backlog
  • Multiple Product Backlogs Can We Deliver All?
    • R100 Deliverable Velocity : 18 SP
    • R200 Deliverable Velocity : 7 SP
    • R300 Deliverable Velocity : 14 SP
    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
    • 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 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
  • 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 7 8 9 10 11 12 1 2 3 4 5 6 13 Product Backlog
  • Bouquets And Brickbats