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

  • Finally, you can manage your Google Docs, uploads, and email attachments (plus Dropbox and Slack files) in one convenient place. Claim a free account, and in less than 2 minutes, Dokkio (from the makers of PBworks) can automatically organize your content for you.

View
 

Using Scrum or Agile Frameworks For Software Maintenance

Page history last edited by PBworks 12 years, 8 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. 

 

 

Comments (0)

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