Monday, November 21, 2016

Subject: Agile for Maintenance Projects

Problems / Challenges

Direct Solutions to Listed Problems / Challenges

General Solutions

Developer Enthusiasm

 

The work is boring

(find out why it's boring and discover what holds interest … )

Even the term "Technical Debt" is negative

(don't call it that … )

It seems like a marathon of never ending tasks

(see "innovation Sprint" … )

For backend fixes, a lot of what the team works on can't be easily demo'd 

 

Developers can't see the shiny new thing they just built

 

The organization can't see it as well as a new feature build 

 

The organization thinks of the developers as "Resources" and treats them as such, rather than as "People"

Let teams be more empowered, and let them make some more of their own decisions

Quarterly "Innovation Sprint"

Team Ownership -- they get to decide what to work on

Development team gets to provide creative input

Depends on which of the two kinds of Maintenance work you are talking about: 

 

1. Here and Now Bugs Fixes

Use Kanban

2. Planned Maintenance

Use Scrum (teams can commit and deliver increments)

Example of something that works for one organization: the developers who maintain the system use Kanban, along with a Scrum (Scrumban). They plan 2-week Sprints with all the normal Scrum ceremonies including Retrospective. They also plan a % of capacity within the Sprint to be used for "unplanned work" (e.g., bugs). The Scrum part is for the planned maintenance. The Kanban board is for unplanned work. New bugs come in and team members pull in whatever work they want. They limit to the capacity that was planned for that Sprint.

Switching Resources from one project to another

It's about how well the PEOPLE work together (to be successful)

 

Every time you swap out peope from one team to another, the new team has to go through "storming, norming, forming" cycle again

 

Don't call them "Resources"

The Core System is out of our control

Embedding -- Have the Vendor work on-site with you

Example: a vendor system needs integration, but there are dependencies, and delays while waiting for components to be ready

 

Example: a vendor system has a bug that impacts a system we need to maintain, and it's not easy to determine the source

 

Re-work due to delay, and slow progress (need to re-test)

 

No comments:

Post a Comment