Migrating from share point to a better scrum tool 8 1-08

542 views

Published on

Agile2008 Conference Presentation, Edward Uy & Rene Rosendahl, Version One vs. Rally Dev Scrum tool evaluation.

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

  • Be the first to like this

No Downloads
Views
Total views
542
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Why training through professional services?Not complicated tool, but…Ensure no impact on team productivityMake trial successfulRecommended by reference companiesTrain the trainerConfirm settings and configuration prior to trial
  • Assessment: team structure, members, roles, practices, backlog Preparation: kick off with team, suggest webinars, public VersionOne siteTraining: team (3 hrs), Scrum master (1 hr), POBacklog mapping and cut-over: understand structure, data cleansing
  • Rich Scrum functionalityVelocity-based sprint planningSplitting of storiesInteractive task boardBuilt-in discussionsMyHome sectionTime SavingsScrum master: no more export/import, graphics, manual manipulations, prep for reviewTeam members: marginal
  • Idiosyncrasies8:00 per dayDelays in data captureLack of use of burndown chartGaps between sprintsAdjustmentsTreatment of unplanned work to be consistentTreatment of shared resourcesCapture slightly different data than beforeLog hours in the evening vs. in the morning
  • Migrating from share point to a better scrum tool 8 1-08

    1. 1. Migrating From SharePoint to a Better Scrum Tool<br />Edward Uy & René Rosendahl<br />Kelley Blue Book<br />
    2. 2. Agenda<br />Background<br />Selection<br />Evaluation & Trial<br />Implementation<br />Guidance for Others <br />Q & A<br />2<br />
    3. 3. 3<br />Background<br />
    4. 4. Introduction<br />KBB has been working with Scrum since 2005<br />Began expansion to all development teams in 2007<br />Moderate Scrum experience level<br />Currently 18 teams/200 users<br />Primary development efforts<br />KBB.com<br />Dealer Products<br />Some internal tools and systems<br />4<br />
    5. 5. Why Did We Need A Scrum Tool?<br />Issues With Excel and SharePoint<br />Inconsistent Scrum implementations<br />Data validation missing<br />Team members move to new teams<br />Multiple products for some product owners<br />Manual report and metrics generation <br />For teams<br />For departments<br />No easy enterprise/senior management visibility<br />5<br />
    6. 6. 6<br />Selection <br />
    7. 7. Tool Selection<br />Key Considerations: <br />Limited selection resources and time<br />Did not want bleeding edge technology<br />Network and Infrastructure<br />Focused On:<br />Usability for the teams<br />Functionality (reporting in particular)<br />Configuration<br />Based on teams and departmental roll-ups<br />7<br />
    8. 8. Selection Methodologies<br />Customer Reviews <br />30 of 33 people found the following review helpful: <br />          Morons take advice from a plastic object, September 23, 2005 <br />
    9. 9. Selection Methodologies<br />Ouija Board<br />Customer Reviews <br />18 of 24 people found the following review helpful: <br />          Any Ouija equals a big no-no, October 22, 2001<br />… Ouija board may be fun to play around with, but it is NOT A TOY!!! This instrument should be used by only the advanced sorcerer or witch or higher... <br />
    10. 10. Methodology<br />Standard vendor selection approach<br />In-depth research and discussions w/ short-listed vendors<br />On-site demonstrations w/ key individuals – technical team, product team, and infrastructure<br />Quantitative and qualitative input<br />Reference calls<br />Communications<br />SharePoint site<br />Road-show for Sr. Management<br />Scrum Master and Product Owner forums<br />1:1 meetings with key individuals as needed<br />Decision Making for Evaluation Vendor<br />Senior management team using input from demonstrations<br />10<br />
    11. 11. Quantitative Results<br />Usability for the teams<br />Functionality (reporting)<br /> Configuration<br />11<br />
    12. 12. Quantitative Results<br />Version One was the closest to meeting <br />KBB’s Scrum Requirements and we moved forward with them for the Evaluation period<br />12<br />
    13. 13. Goal: Quickly confirm our initial impression<br />13<br />Evaluation <br />
    14. 14. The Evaluation Approach<br />Trial: 4 weeks, 2 teams, 2 sprints per team<br />Hope: stay on VersionOne after trial, avoid “roll-back”<br />Open process: visibility<br />Project SharePoint site<br />Communication<br />Preparation<br />Kick-off meetings with teams<br />Pre-training through recommended reading, recorded webinars, online tutorials, etc.<br />VersionOne professional services<br />Set up and configuration<br />Training <br />14<br />
    15. 15. Sample Screenshot from Project Site<br />Announcements<br />Links<br />Calendar<br />Team schedule<br />Important docs<br />Contact info<br />
    16. 16. The Teams<br />Criteria<br />Non-critical product delivery during evaluation phase<br />At least 6 months Scrum experience<br />On-shore and off-shore team representation<br />External product preferred<br />1 on-shore, 1 off-shore team selected<br />16<br />
    17. 17. The Evaluation Process<br /><ul><li>Prepare & configure environment
    18. 18. Map & import teams’ backlogs
    19. 19. Team training </li></ul>On site<br />Remotely (India) <br /><ul><li>Start with Sprint planning </li></ul>With VersionOne trainer on site<br />Without changing mechanics<br /><ul><li>Stay with teams through sprints, Q&A and coaching
    20. 20. Weekly, open touchpoint meetings
    21. 21. Check point with sr. managementhalf-way through trial </li></ul>Results:<br /><ul><li>Teams comfortable
    22. 22. No significant impact on teams and their productivity
    23. 23. Addressed questions around reporting</li></ul>Green light to proceed<br />17<br />
    24. 24. Goal: Roll out VersionOne to all teams in an efficient and repeatable manner<br />18<br />Implementation <br />
    25. 25. The ImplementationApproach<br />18 teams requiring<br />Repeatable approach<br />Consistent implementation <br />In-house training<br />Roll-out from team to team, except…<br />Interrelated teams implemented at the same time <br />Same product backlog<br />Shared resources (virtual teams)<br />Same Scrum Master and/or Product Owner<br />Visibility & communication<br />Yadayada<br />19<br />
    26. 26. The Implementation Process<br /><ul><li>Assessment
    27. 27. Preparation
    28. 28. Training
    29. 29. Product Backlog </li></ul>Mapping <br />Cut-over<br /><ul><li>1st sprint: coaching and observing</li></ul>Sprint planning in VersionOne<br />Sprint execution and monitoring<br />Sprint closure<br /><ul><li>2nd sprint: light touch</li></ul>20<br />
    30. 30. The Initial Results<br />12 teams out of 18 implemented (on schedule)<br />Single system for all Scrum data<br />Consistent implementation<br />Rich Scrum-specific functionality<br />Time savings<br />Norming and convergence of Scrum practices<br />Use of story points<br />Treatment of unplanned tasks and production support<br />Approach for dealing with shared resources<br />Improvement of general discipline with data capture<br />21<br />
    31. 31. Samples of VersionOne Functionality<br />
    32. 32. Lessons Learned<br />Preparation and training are critical<br />No negative impact on productivity during transition<br />Only 1-2 sprint cycles needed to get fully comfortable<br />Every team is unique and has its own idiosyncrasies<br />Teams will need to make adjustments<br />An Agile tool does not solve team or process issues. It uncoversand magnifies them.<br />Diverging practices<br />Lack of discipline<br />23<br />
    33. 33. Next Steps<br />Complete roll-out<br />Expand use of the tool<br />Investigate integration with development tools, defect tracking or test automation tools<br />Evaluate add-on/plug-in tools and system extensions<br />Gather Agile metrics in a systematic fashion company-wide<br />24<br />
    34. 34. 25<br />Guidance for Others<br />
    35. 35. Guidance for Others<br />Plan an evaluation period to work out the kinks<br />Use Professional Services to address configuration, training, and roll-out approach in the beginning<br />Create a multi-level support structure to make it easy for everyone to get information<br />Capture feedback and apply for each team being spun-up<br />Use the roll-out period to tighten up Scrum process improvements organization wide<br />Don’t throw SharePoint away!<br />A Scrum Tool is not a “silver bullet” <br />Whatever issues you have in the organization or with your Scrum implementation, they will only be highlighted<br />26<br />
    36. 36. 27<br />Q & A<br />
    37. 37. Contact Info<br />Edward Uy – euy@kbb.com<br />René Rosendahl – rrosendahl@kbb.com<br />28<br />

    ×