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

Re: [XP] The Whole Enchilada

Expand Messages
  • John Roth
    ... Chris, are you not paying attention? We ve got essentially every consultant on the list who usually posts saying Exactly The Same Thing. I m not a
    Message 1 of 87 , Feb 1, 2009
    • 0 Attachment
      Chris Wheeler said:


      > On Sun, Feb 1, 2009 at 9:59 AM, Mary Poppendieck
      > <maryp@...>wrote:
      >
      >> Hi Laurent,
      >>
      >> I'm with Josh on this. I see lots of floundering Scrum initiatives,
      >> typically due to the assumption that essential technical practices will
      >> be discovered by "the team" and they are not. Can you explain where the
      >> incentive would come from to write up the stories? Why bother?
      >>
      >
      > To be blunt, without the stories, this simply sounds like marketing
      > bullshit.
      >
      > "Scrum always fails, IndustrialLogic can help!"
      >
      > Chris.

      Chris, are you not paying attention?

      We've got essentially every consultant on the list who
      usually posts saying Exactly The Same Thing.

      I'm not a consultant. I'm retired. I have NO
      pecuniary interest in this whatsoever. And I
      see the same thing here in Albuquerque every
      month at the Agile group that meets after the
      monthly SPIN meetings.

      The reason that Scrum is failing all over the place
      ought to be obvious, but it apparently isn't. It's
      not the project management, and it's not the lack
      of engineering practices, although that contributes.
      It's the lack of a focus on team process improvement.

      And by team process I don't mean coding standards,
      shared code ownership and whatnot. I mean a team
      culture of inspecting their process, identifying problem
      areas or opportunities for improvement, creating
      measurements, doing research into alternatives
      and experimenting to see if different ways of doing
      things lead to improvement.

      Process improvement isn't something you do when
      you've got problems. Process improvement is
      something you live. It's not something that you can
      instill in a team via hit and run. I've heard the Lean
      people say that it takes as long as five years between
      when a company starts a transformation to Lean and
      when there are enough people who actually get it to
      become self sustaining.

      If you treat Scrum, or XP, or God knows what else
      like a silver bullet, it's going to fail. And that's what
      we're seeing.

      Why? It doesn't matter what you say, it's what the
      listener hears. And when the listener hears about
      Scrum, he hears project management. "Oh, yeah,
      I know about project management", sez he, and
      anything else that gets said about software engineering
      practices or team process improvement just goes in
      one ear and out the other without disturbing any
      neurons in the process.

      John Roth
    • Brad Appleton
      Thanks Charlie for the thoughts and advice!
      Message 87 of 87 , Feb 7, 2009
      • 0 Attachment
        Thanks Charlie for the thoughts and advice!

        Charlie Poole wrote:
        > You have to be careful there. Usually, coaches are people who
        > have been successful with teams in the past. So they have lots
        > of skills and ways of doing things learned in the past. The
        > major thing a new coach needs - what I needed to develop
        > when I first started - is a sense of humility. You don't know
        > what a given team (one you aren't part of) should do.
        >
        > IME, this is the hardest part of being a coach, and it's
        > even harder for coaches who have some standing in the
        > organization, since they have to bend over backwards to
        > avoid the appearance of setting rules.
        >
        >> The change-team also (with input from the practicing agile coaches &
        >> engineers) provides the mechanism to help identify projects
        >> that are good candidates to be agile, and the
        >> sponsorship/advocacy to approach their management and discuss
        >> if they'd be open to it and what the benefits (and
        >> consequences) are. We're actually having some pretty good
        >> successes there.
        >
        > Here, I'd say the risk is beginning to think of agile as
        > one Way of doing things - not that you're thinking that
        > way, but I've seen internal groups like this move from
        > encouragement to standardization a time or two.
        >
        >> Getting back to the original topic of this thread, our
        >> "starter kit" has a menu of practices on it. There is a set
        >> that we say are "required in order to be agile" (we say we
        >> think you cant be agile without it -- even tho we dont force
        >> it). There are some that are considered "scaling"
        >> practices (e.g., "Scrum of Scrums", "Joint Retrospectives",
        >> "Feature-Teams") and we say when we believe those are
        >> applicable and should be used. There are some "optional
        >> practices", meaning that they may not be absolutely necessary
        >> for agility, but they really enhance it a lot. (again we dont
        >> force any things, we recommend and provide support and guidance)
        >
        > To be clear, I too think there are some practices you just
        > have to do to be agile. I just don't think you should necessarily
        > give people lists of them. It works much better (for me anyway)
        > to start fresh with each team, work with them and guide them
        > to decide how they will be agile.
      Your message has been successfully submitted and would be delivered to recipients shortly.