• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • Whenever you search in PBworks, Dokkio Sidebar (from the makers of PBworks) will run the same search in your Drive, Dropbox, OneDrive, Gmail, and Slack. Now you can find what you're looking for wherever it lives. Try Dokkio Sidebar for free.


Using Scrum or Agile Frameworks For Software Maintenance

Page history last edited by PBworks 14 years, 5 months ago

 Moderator: John Hill

         Topic: Using Scrum or Agile Frameworks For Software Maintenance

          Date: May 10, 2007





Tod Gentry




Kelly W.



Andreas S




There are normally three levels of activity (performed by different staff) involved in the software maintenance process:


Level 1 (L1) – Client facing activities (Client Support)

Level 2 (L2) – Defect and resolution analysis (Engineering)

Level 3 (L3) – Engineering defect resolution and Fulfillment (Engineering)




1. Large Backlog of Software Defects

2. Unplanned Influx of High-Priority Software Defects

3. Potential Dilution of Team Resources (when resources are shared with standard Sotfware Development Organization)




Participants in this session had iteration lengths for software maintenance releases anywhere from once every three weeks to as seldom as four times per year.  Nearly everyone in this session used a pool of resources shared with the Software Development organization.




1. Meet daily to review/reprioritize existing defect backlog.

2, Identify impediments as soon as defect is reported:

    a. Verify that problem is in fact a software defect

    b. Obtain "steps to recreate" defects before accepting them into the defect backlog.

    c. Provide excellent "L2" analysis.

    d. Review available resources with ability to resolve the defect.

3. Remove defects from the backlog when there are unresolved impediments.

4. Resolve all "critical" defects within eight hours if at all possible (builds confidence and support from user community).

5. Ensure that there are always expert resources available for "critical" problems in every application area if at all possible (protected maintenance resources).

6. Cross-train resources to eliminate the problems associated with single bottleneck resources.

7. Allow maintenance developers to refactor code occassionally, preventing the code from becoming unmaintainable (empower developers to refactor and make time for occassional refactoring).

8. When refactoring by the maintenance organization is not possible, put poorly-written modules on the standard (i.e., "development") product backlog.

9. Obtain buy-in and full support from Senior Management for the software maintenance processes within the organization. 



Comments (0)

You don't have permission to comment on this page.