"Agile" Change Management
- I recently emailed the XP mailing list on this subject. I'd
be interested in the SCRUM perspective and responses. How
do you do this in your SCRUM projects and how do you use the
product and sprint backlogs to manage it? WHich people/roles
are trusted to mach which kinds of decisions, and when would
the issues typically eb raised for a decision?
> On Tue, Jul 08, 2003 at 11:01:53AM -0600, Grady Booch wrote:Very interesting synchronicity, as I was just pondering about
> > As for change management - that's a general term encompassing
> > controlling and tracing change. Change management may be
> > very low ceremony (developers handle physical cards) or
> > high ceremony (change is allowed only through formal change
> > control boards), but should be set to the appropriate level
> > for the given development domain and culture.
some of the "formal" change management I've seen, and what
is so un-agile about it. Change management in SCRUM seems
to be concerned with managing the backlog and working on the
highest-priority stuff in "each sprint" (the product backlog
and the sprint backlog).
Both SCRUM and XP limit scope of changes in a iteration to
make only those changes needed to deliver the stories for the
current iteration. There is formal customer approval/agreement
on which "requests" (stories) are to be worked during an
iteration. I don't see much written in XP or SCRUM about
accepting new stories (or removing or replacing stories)
during an iteration. I assume it is strongly deprecated tho
I imagine it may happen from time to time. If so, then XP and
SCRUM actually have very "strict" change management during an
iteration (but not completely).
Most heavyweight change-mgmt approaches would require formal
project mgmt approval (and possibly even customer approval)
before fixing a bug that escaped unit-testing (or effecting a
coding convention compliance, or refactoring change anytime
AFTER the code in question completed its unit-tests and was
integrated into a build). Some would say this is merely
enforcing "YAGNI" and preventing overengineering and
scope-creep. And maybe what "I know for sure" isn't the same
as what the project mgr thinks.
So how should a "suitably agile" methodology decide when to
be strict over the course of a given iteration? When is it
okay to add/remove/replace stories for an iteration during
that iteration? Are there ever times when a refactoring change
should be made a story instead of letting the developer "just
do it"? When are those times? When should a bugfix be a story
instead of me just fixing it? If I find a problem I didn't have
a test for, should it be a story? Under what circumstances
should an agile method make a developer wait for a "green light"
from project mgmt or customer before making what they feel is
a desirable change?
Brad Appleton <brad@...> www.bradapp.net
Software CM Patterns (www.scmpatterns.com)
Effective Teamwork, Practical Integration
"And miles to go before I sleep." -- Robert Frost