1 / 19

The Road to Agile From the Bottom Up

The Road to Agile From the Bottom Up. Kevin Malley Tracey Clark. TQ2012. April 23 rd , 2012. Agenda. Overview Why change and how What worked What had to change Signs of danger Summary of benefits Where we are headed Conclusion. TQ2012. Overview.

niveditha
Download Presentation

The Road to Agile From the Bottom Up

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The Road to Agile From the Bottom Up Kevin Malley Tracey Clark TQ2012 April 23rd, 2012

  2. Agenda • Overview • Why change and how • What worked • What had to change • Signs of danger • Summary of benefits • Where we are headed • Conclusion TQ2012

  3. Overview • Project was managed as Waterfall and wasn’t meeting customer expectations • Move to Agile was influenced by successes in other areas who were having the same issues • Internal Project • Stakeholders where accepting to change - opportunity for improvement TQ2012

  4. Why change • What we delivered late was: • Not what the customer wanted • Not what we had promised • Not something we where happy with • Full of unresolved defects • Same old project failure TQ2012

  5. Change #1 – Customer Involvement • Release Train • What’s ready goes what isn’t catches the next train • Product Owner (representing Customer) drives work • Involved in sprint planning • Sprint Demo • Testing Methods • Greater emphasis on exploratory testing. Run more often and earlier in the product life cycle TQ2012

  6. Change #1 – Continued • Dev and SV&V offset by one sprint • Strong collaboration between developers and testers Dev Sprint 1 Test Sprint 1 Dev Sprint 2 Test Sprint 2 Dev Sprint 3 Regression Sprint TQ2012

  7. Lessons learned change #1 • Benefits • Customer happier (Involved in sprint planning and demo) • Less margin of error in release dates • Closer relationship between Dev and Test • Exploratory tests yield quick results and could form basis for regression test scripts • Pitfalls • Defects could take 4 weeks to see a resolution • Rapid maintenance turn around • Testing reliving design weeks later TQ2012

  8. Change #2 - Design • Why: • Reduce relearning of design • How: • Tester deployed into Dev Sprint • Build test cases • Run Exploratory Tests on dev builds • Tester then transitions to offset sprint to conduct formal tests Dev Sprint 1 Tester A Test Sprint 1 Tester A Dev Sprint 2 Tester B Test Sprint 2 Tester B Dev Sprint 3 Tester A Regression Sprint TQ2012

  9. Lessons learned change #2 • Benefits • Caught some issues earlier • Less rehashing of design • Pitfalls • Still unable to resolve lengthy defect turn around • Length of time to deployment not addressed TQ2012

  10. Change #3 - Time • What: • Time to release • Defect turn around • How: • Testing as part of the definition of done • Removal of offset sprints • Testing tasks tracked within User Stories • Exploratory Tests used almost exclusively during development --> Drive scripted regression tests Sprint 1 Sprint 2 Regression Sprint TQ2012

  11. Lessons learned change #3 • Benefits • Monthly releases now possible • Pitfalls • Defect metrics mean far less TQ2012

  12. What had to change • Removal of Test Plan (Emphasis on Strategy) • Adoption of Exploratory Testing • How and when we log defects • Customer commitment • Segregation of duties • Requirements and design docs became living documents within agile tools and wiki’s • Relationship between dev and test TQ2012

  13. Signs of danger – Stakeholders (Chickens) • Unclear Product Owner (Customer) • Product Owner not Engaged • Product Owner doesn’t take ownership getting necessary requirements from multiple business groups and maintaining communication throughout project with all groups • Timely decision making • Some stakeholders become over committed TQ2012

  14. Signs of danger – Core team (Pigs) • Development moves forward while impediments block testing • Development and testing can’t agree • Don’t test everything • Scrum Master not understanding their role • When is it time to make the decision to move to next release • Improper Sprint Planning – Not learning from previous sprint • Demo TQ2012

  15. Summary of benefits after changes • Customer Satisfaction • Less rework • Less variance in committed production dates • Cleaner regression runs • Quicker turn around on defects • Less defects • Stronger relationship between developers and testers TQ2012

  16. Where we are headed • Further support and understanding from Senior Management • Socialize benefits – encourage the chickens • Refining the use of Exploratory Testing • Automation • Training testers as Scrum Masters • Working out an offshore model TQ2012

  17. Conclusion • You won’t get it right the first time • The value of applying lessons learned • One size doesn’t fit all – multiple adjustments may be required • Major adjustment to normal practices and processes • Importance of roles and responsibilities TQ2012

  18. Questions TQ2012

  19. Contact Info • Kevin Malley : kmalley@rim.com • Tracey Clark : trclark@rim.com TQ2012

More Related