If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.
You already know Dokkio is an AI-powered assistant to organize & manage your digital files & messages. Very soon, Dokkio will support Outlook as well as One Drive. Check it out today!

Using Scrum or Agile Frameworks For Software Maintenance

Page history last edited by PBworks 15 years, 10 months ago

Moderator: John Hill

         Topic: Using Scrum or Agile Frameworks For Software Maintenance

          Date: May 10, 2007

Attendees:

Woody

Tod Gentry

Jodie

Rosie

Brian

Kelly W.

Annette

Gary

Andreas S

DEFINITIONS:

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)

CHALLENGES:

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)

ITERATION LENGHT:

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.

RECOMMENDED TECHNIQUES:

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.