Agile Maintenance A Case Study ShriKant Vashishtha [email_address] http://svashishtha.wordpress.com/about/

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) Definition

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)

What is Agile Maintenance all about? Share learning of Xebia Application Lifecycle Management approach Agenda

What is Agile Maintenance all about?

Share learning of Xebia Application Lifecycle Management approach

Support team wait for issues to come Customer communicates bugs through Manager using Bugzila, Excel or email Support team simulates the bug and fix it Update the test case document and design document and traceability matrix Testing team tests the issue and runs regression tests After acceptance test, patch is deployed in the production A Snapshot of Traditional Maintenance

Support team wait for issues to come

Customer communicates bugs through Manager using Bugzila, Excel or email

Support team simulates the bug and fix it

Update the test case document and design document and traceability matrix

Testing team tests the issue and runs regression tests

After acceptance test, patch is deployed in the production

No transparency in: Estimation and time to deliver What team does and doesn’t Manual tests and a lot of focus on unnecessary documentation Passive approach. No focus on reducing technical debt Demotivated team Issues in Traditional Approach

No transparency in:

Estimation and time to deliver

What team does and doesn’t

Manual tests and a lot of focus on unnecessary documentation

Passive approach. No focus on reducing technical debt

Demotivated team

A bug reported and added into product backlog Team estimates the bug Bug added to Sprint backlog Developer begins the work with definition of READY and agrees on definition of DONE Write test case and reproduce bug Fix the bug and run test cases as part of CI. Ready for automated acceptance testing (Fitnesse) Lifecycle of a Bug in Agile Maintenance

A bug reported and added into product backlog

Team estimates the bug

Bug added to Sprint backlog

Developer begins the work with definition of READY and agrees on definition of DONE

Write test case and reproduce bug

Fix the bug and run test cases as part of CI.

Ready for automated acceptance testing (Fitnesse)

Test Cases Bug to be fixed or code to be refactored Tests as Vise

Bug is logged in issue tracking tool (JIRA/ScrumWorks) Developers estimate and Product Owner prioritizes the issues. Pro-active instead of Reactive Pay off technical debt Fixing the leaks Improving quality of existing software Focus on automated testing (unit/integration/acceptance) Test coverage more than 85% Adhere to standards through automated code review A Snapshot of Agile Maintenance

Bug is logged in issue tracking tool (JIRA/ScrumWorks)

Developers estimate and Product Owner prioritizes the issues.

Pro-active instead of Reactive

Pay off technical debt

Fixing the leaks

Improving quality of existing software

Focus on automated testing (unit/integration/acceptance)

Test coverage more than 85%

Adhere to standards through automated code review

Agile Maintenance

No transparency in: Estimation and time to deliver What team does and doesn’t Manual tests and a lot of focus on unnecessary documentation Passive approach. No focus on reducing technical debt Demotivated team Traditional Maintenance Issues Revisited

No transparency in:

Estimation and time to deliver

What team does and doesn’t

Manual tests and a lot of focus on unnecessary documentation

Passive approach. No focus on reducing technical debt

Demotivated team

Maintenance is unpredictable. Sometimes you get a lot of issues, sometimes not One Team Multiple Projects – Forces

Maintenance is unpredictable. Sometimes you get a lot of issues, sometimes not

You may want to safeguard the project from any knowledge-base loss in case of any illness/vacations Human resources go waste if maintenance team doesn’t have any issues in hand One Team Multiple Projects – Forces

You may want to safeguard the project from any knowledge-base loss in case of any illness/vacations

Human resources go waste if maintenance team doesn’t have any issues in hand

One single consolidated list of issues from multiple projects handled in a Scrum sprint Proxy product-owner (PPO) from Xebia talks to product-owners, understand priority and define product backlog PPO then has a planning meeting with team and define Sprint backlog Team handles the issues of multiple projects mentioned in the sprint backlog One Team Multiple Projects – The Concept

One single consolidated list of issues from multiple projects handled in a Scrum sprint

Proxy product-owner (PPO) from Xebia talks to product-owners, understand priority and define product backlog

PPO then has a planning meeting with team and define Sprint backlog

Team handles the issues of multiple projects mentioned in the sprint backlog

One Team Multiple Projects Common Sprint Backlog

One Team Multiple Projects Scrum Board and Burndown Chart

Good value of money. Comparatively smaller team handles multiple projects Good team spirit. Self-organizing team handles multiple projects Developers have a lot of choice to work and experiment with 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 One Team Multiple Projects Advantages

Good value of money. Comparatively smaller team handles multiple projects

Good team spirit. Self-organizing team handles multiple projects

Developers have a lot of choice to work and experiment with

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

No transparency in: Estimation and time to deliver What team does and doesn’t Manual tests and a lot of focus on unnecessary documentation Passive approach. No focus on reducing technical debt Demotivated team Traditional Maintenance Issues Revisited Yet Again

No transparency in:

Estimation and time to deliver

What team does and doesn’t

Manual tests and a lot of focus on unnecessary documentation

Passive approach. No focus on reducing technical debt

Demotivated team

A maintenance Sprint may consist: Priority 1 bug (show-stoppers) Priority 2 bug (major) Priority 3 bug (low) Priority 4 bug (improvements) Refactoring for design improvements Enhancement required in the functionality Product owner decides the priority of the issues and defines the Sprint backlog with the help of team and Scrum Master A Sprint in Maintenance Project

A maintenance Sprint may consist:

Priority 1 bug (show-stoppers)

Priority 2 bug (major)

Priority 3 bug (low)

Priority 4 bug (improvements)

Refactoring for design improvements

Enhancement required in the functionality

Product owner decides the priority of the issues and defines the Sprint backlog with the help of team and Scrum Master

Estimate a part of Sprint (for instance 20%) to work on production issues Stop a sprint if you find Priority 1 issue and plan accordingly Allocate a part of team to work dedicatedly on Priority 1 issue Use Kanban Follow Type C Scrum Dealing with Priority 1 Issues in Agile Sprint - Approaches

Estimate a part of Sprint (for instance 20%) to work on production issues

Stop a sprint if you find Priority 1 issue and plan accordingly

Allocate a part of team to work dedicatedly on Priority 1 issue

Use Kanban

Follow Type C Scrum

Type A - Isolated cycles of work Type B - Overlapping iterations Type C – All at Once Type C Scrum

Type C Scrum Explained

Don't Let Short-Term Agile Create Long-Term Pain – Gartner Preparing for Agile Maintenance – Knowledge Management – Xebia Blog Knowledge Transfer in Agile Maintenance Projects – Xebia Blog Agile Maintenance – One Team Multiple Projects – Xebia Blog Type C Scrum Explained – Xebia Blog Agile Way of Documentation – Xebia Blog Working Effectively with Legacy Code – Michael Feathers The definition of READY – Xebia Blog References

Don't Let Short-Term Agile Create Long-Term Pain – Gartner

Preparing for Agile Maintenance – Knowledge Management – Xebia Blog

Knowledge Transfer in Agile Maintenance Projects – Xebia Blog

Agile Maintenance – One Team Multiple Projects – Xebia Blog

Type C Scrum Explained – Xebia Blog

Agile Way of Documentation – Xebia Blog

Working Effectively with Legacy Code – Michael Feathers

The definition of READY – Xebia Blog

Questions