Loading ...
Sorry, an error occurred while loading the content.

"Agile" Change Management

Expand Messages
  • Brad Appleton
    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
    Message 1 of 1 , Jul 12, 2003
    • 0 Attachment
      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:
      > > 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.

      Very interesting synchronicity, as I was just pondering about
      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
    Your message has been successfully submitted and would be delivered to recipients shortly.