--
________________________________________________________________
Much of the discussion in the group is predicated on several resources summarized on the wiki at http://www.agileskillsproject.org Please review this regularly. To request editing permissions for the wiki, send an email to either of these gmail addresses: richardjfoster or redhotglass .
________________________________________________________________
You received this message because you are subscribed to
the "Agile Developer Skills" group.
To unsubscribe from this group, send email to
agile-developer-s...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/agile-developer-skills?hl=en?hl=en
In many ways a maintenance project can apply Scrum easier than a green field or blue sky project because most of the start-up stuff has already been decided.
As you say, you typically have a list of bugs and enhancements that naturally form a good start for a product backlog.
All the usual key ideas and 'rules' of Scrum apply:
A product owner to prioritise the items on the backlog in terms of value to the business.
The team to estimate the size of the items.
A sprint planning meeting to decide and commit to what is going to be 'done' in the next iteration (sprint).
etc, etc.
Steve
Adding some test driven development principles into some of the code re-writing should also help provide metrics around the code quality, which will again boost the client's confidence.
I think you are over-thinking this. Agile and Scrum are easier to
explain and teach in the context of a greenfield project. That may be
the reason much of the literature presents them that way.
The hard part of a maintenance project is defining what needs to be
done, the business value of those things and the prioritizing them.
Help your Product Owner get a Product Backlog going, pull off the
highest priority items, Sprint plan and get going.
Yes, it is that simple to start. In a complex product with little team
knowledge, you will encounter problems and bumps. So it may not look
that easy and you won't know what you don't know until you get going!
I'd suggest short iterations to allow the team and focus to pivot
quickly on important discoveries and learning.
Alan
> Much of the discussion in the group is predicated on several resources summarized on the wiki at http://www.agileskillsproject.org Please review this regularly. To request editing permissions for the wiki, send an email to either of these gmail addresses: richardjfoster or redhotglass .