Agile Maintenance 1.0

6,607 views

Published on

This ppt is presented by Shrikant Vashishtha (Principle Consultant @Xebia) at Agile NCR 2009 Conference held on 18th July at Park Premier Hotel.

Published in: Technology, Business
  • Be the first to comment

Agile Maintenance 1.0

  1. 1. Agile Maintenance A Case Study ShriKant Vashishtha [email_address] http://svashishtha.wordpress.com/about/
  2. 2. <ul><li>Software maintenance in software engineering is the modification of a software product after delivery to correct faults, to improve performance or other attributes, or to adapt the product to a modified environment (ISO/IEC 14764) </li></ul>Definition
  3. 3. <ul><li>What is Agile Maintenance all about? </li></ul><ul><li>Share learning of Xebia Application Lifecycle Management approach </li></ul>Agenda
  4. 4. <ul><li>Support team wait for issues to come </li></ul><ul><li>Customer communicates bugs through Manager using Bugzila, Excel or email </li></ul><ul><li>Support team simulates the bug and fix it </li></ul><ul><li>Update the test case document and design document and traceability matrix </li></ul><ul><li>Testing team tests the issue and runs regression tests </li></ul><ul><li>After acceptance test, patch is deployed in the production </li></ul>A Snapshot of Traditional Maintenance
  5. 5. <ul><li>No transparency in: </li></ul><ul><ul><li>Estimation and time to deliver </li></ul></ul><ul><ul><li>What team does and doesn’t </li></ul></ul><ul><li>Manual tests and a lot of focus on unnecessary documentation </li></ul><ul><li>Passive approach. No focus on reducing technical debt </li></ul><ul><li>Demotivated team </li></ul>Issues in Traditional Approach
  6. 6. <ul><li>A bug reported and added into product backlog </li></ul><ul><li>Team estimates the bug </li></ul><ul><li>Bug added to Sprint backlog </li></ul><ul><li>Developer begins the work with definition of READY and agrees on definition of DONE </li></ul><ul><li>Write test case and reproduce bug </li></ul><ul><li>Fix the bug and run test cases as part of CI. </li></ul><ul><li>Ready for automated acceptance testing (Fitnesse) </li></ul>Lifecycle of a Bug in Agile Maintenance
  7. 7. Test Cases Bug to be fixed or code to be refactored Tests as Vise
  8. 8. <ul><li>Bug is logged in issue tracking tool (JIRA/ScrumWorks) </li></ul><ul><li>Developers estimate and Product Owner prioritizes the issues. </li></ul><ul><li>Pro-active instead of Reactive </li></ul><ul><ul><li>Pay off technical debt </li></ul></ul><ul><ul><li>Fixing the leaks </li></ul></ul><ul><li>Improving quality of existing software </li></ul><ul><ul><li>Focus on automated testing (unit/integration/acceptance) </li></ul></ul><ul><ul><li>Test coverage more than 85% </li></ul></ul><ul><ul><li>Adhere to standards through automated code review </li></ul></ul>A Snapshot of Agile Maintenance
  9. 9. Agile Maintenance
  10. 10. <ul><li>No transparency in: </li></ul><ul><ul><li>Estimation and time to deliver </li></ul></ul><ul><ul><li>What team does and doesn’t </li></ul></ul><ul><li>Manual tests and a lot of focus on unnecessary documentation </li></ul><ul><li>Passive approach. No focus on reducing technical debt </li></ul><ul><li>Demotivated team </li></ul>Traditional Maintenance Issues Revisited
  11. 11. <ul><li>Maintenance is unpredictable. Sometimes you get a lot of issues, sometimes not </li></ul>One Team Multiple Projects – Forces
  12. 12. <ul><li>You may want to safeguard the project from any knowledge-base loss in case of any illness/vacations </li></ul><ul><li>Human resources go waste if maintenance team doesn’t have any issues in hand </li></ul>One Team Multiple Projects – Forces
  13. 13. <ul><li>One single consolidated list of issues from multiple projects handled in a Scrum sprint </li></ul><ul><li>Proxy product-owner (PPO) from Xebia talks to product-owners, understand priority and define product backlog </li></ul><ul><li>PPO then has a planning meeting with team and define Sprint backlog </li></ul><ul><li>Team handles the issues of multiple projects mentioned in the sprint backlog </li></ul>One Team Multiple Projects – The Concept
  14. 14. One Team Multiple Projects Common Sprint Backlog
  15. 15. One Team Multiple Projects Scrum Board and Burndown Chart
  16. 16. <ul><li>Good value of money. Comparatively smaller team handles multiple projects </li></ul><ul><li>Good team spirit. Self-organizing team handles multiple projects </li></ul><ul><li>Developers have a lot of choice to work and experiment with </li></ul><ul><li>Knowledge base stays with the whole team instead of one single individual. It provides better results in handling critical issues as knowledge base is bigger now </li></ul>One Team Multiple Projects Advantages
  17. 17. <ul><li>No transparency in: </li></ul><ul><ul><li>Estimation and time to deliver </li></ul></ul><ul><ul><li>What team does and doesn’t </li></ul></ul><ul><li>Manual tests and a lot of focus on unnecessary documentation </li></ul><ul><li>Passive approach. No focus on reducing technical debt </li></ul><ul><li>Demotivated team </li></ul>Traditional Maintenance Issues Revisited Yet Again
  18. 18. <ul><li>A maintenance Sprint may consist: </li></ul><ul><ul><li>Priority 1 bug (show-stoppers) </li></ul></ul><ul><ul><li>Priority 2 bug (major) </li></ul></ul><ul><ul><li>Priority 3 bug (low) </li></ul></ul><ul><ul><li>Priority 4 bug (improvements) </li></ul></ul><ul><ul><li>Refactoring for design improvements </li></ul></ul><ul><ul><li>Enhancement required in the functionality </li></ul></ul><ul><li>Product owner decides the priority of the issues and defines the Sprint backlog with the help of team and Scrum Master </li></ul>A Sprint in Maintenance Project
  19. 19. <ul><li>Estimate a part of Sprint (for instance 20%) to work on production issues </li></ul><ul><li>Stop a sprint if you find Priority 1 issue and plan accordingly </li></ul><ul><li>Allocate a part of team to work dedicatedly on Priority 1 issue </li></ul><ul><li>Use Kanban </li></ul><ul><li>Follow Type C Scrum </li></ul>Dealing with Priority 1 Issues in Agile Sprint - Approaches
  20. 20. Type A - Isolated cycles of work Type B - Overlapping iterations Type C – All at Once Type C Scrum
  21. 21. Type C Scrum Explained
  22. 22. <ul><li>Don't Let Short-Term Agile Create Long-Term Pain – Gartner </li></ul><ul><li>Preparing for Agile Maintenance – Knowledge Management – Xebia Blog </li></ul><ul><li>Knowledge Transfer in Agile Maintenance Projects – Xebia Blog </li></ul><ul><li>Agile Maintenance – One Team Multiple Projects – Xebia Blog </li></ul><ul><li>Type C Scrum Explained – Xebia Blog </li></ul><ul><li>Agile Way of Documentation – Xebia Blog </li></ul><ul><li>Working Effectively with Legacy Code – Michael Feathers </li></ul><ul><li>The definition of READY – Xebia Blog </li></ul>References
  23. 23. Questions

×