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

RE: [scrumdevelopment] Digest Number 652

Expand Messages
  • Stephen Haberman
    ... is ... though ... My two cents is to make a Scrum variant and don t bother publishing a whole book on it. Assuming your variant is popular, I d rather see
    Message 1 of 2 , Jul 11, 2004
    • 0 Attachment
      > I'm seriously debating if I should tweak our Agile process to be SCRUM
      > compliant and switch to SCRUM instead of releasing yet another book. What
      is
      > lacking as far as I can tell is the dedication to Risk Management we have
      > (ala 'Waltzing with Bears') and Metrics (ala Putnam) which we produce
      though
      > our web based SDLC tool.

      My two cents is to make a Scrum variant and don't bother publishing a whole
      book on it. Assuming your variant is popular, I'd rather see it get a
      chapter in a future Scrum book, or perhaps a chapter in the next edition of
      the current books.

      This is assuming you really do have a variant, e.g. you just add, say "risk
      level" or "estimate ranges" to product backlog items or what not.

      I've already picked up there seems be to a Beedle variant (not XBreed, but
      just adding actuals for business purposes...though Sutherland may do that as
      well...), a Cohn variant (I seem to remember Mike saying something about
      getting two estimates per backlog item and then ...averaging... them or
      something). Please correct me if I'm wrong guys.

      So customization is definitely done in practice, its just not written up
      much.

      I think no-nonsense, 1-3 page write-ups of the Beedle, Cohn, and perhaps
      your AgileFactor variants would be great content for the
      definitive/ScrumAlliance/etc. site.

      The variants have been written up before, but unfortunately right now they
      are buried somewhere in the archives.

      ----

      Note: I hope/am sure in practice everyone implements a "variant" of Scrum,
      e.g. it adapts to their environment, their boss, their team, etc., and so
      documenting every single variant/implementation would be a bit silly. But I
      think still higher-level/generic variants that aren't just per-project but
      could sensibly be used across many projects (e.g. risk management) would
      make good candidates for being written up.

      I'm not sure how we'd decide what are "official" variants and such. I
      suppose it depends the community vs. product issues raised in the other
      discussion. If it's a product, Ken could "bless" each variation, but if it
      stays a community, we could have a vote, maybe Apache style, or something.

      - Stephen
    Your message has been successfully submitted and would be delivered to recipients shortly.