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

Re: [XP] The Whole Enchilada

Expand Messages
  • Steven Gordon
    ... Furthermore, most people on most failing projects do not know why they are having problems (otherwise, they would have been fixing them). Many are probably
    Message 1 of 87 , Feb 1, 2009
    • 0 Attachment
      On Sun, Feb 1, 2009 at 9:38 AM, Ilja Preuß <iljapreuss@...> wrote:
      > 2009/2/1 Laurent Bossavit <laurent@...>:
      >
      >> Hi Mary,
      >>
      >>> 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?
      >>
      >>
      >> For the same reason you'd bother to record precise observations of
      >> anything: research. Making hypotheses and breaking them.
      >
      > I'd assume that most people on failing projects don't have research on
      > their mind as a high priority activity.
      >

      Furthermore, most people on most failing projects do not know why they
      are having problems (otherwise, they would have been fixing them).
      Many are probably in denial as well. Their observations are probably
      not of much use.

      Of more use is the observations of people who come to the rescue (like Joshua).

      We still have to bear in mind that we would only get a accounting of
      Scrum projects that turned to people like Joshua for resueing. We
      will not have counts of Scrum projects that inspected and adapted
      their way to XP-like engineering practices (no doubt with the help of
      team members researching what known practices would help with the
      problems being observed). We will also not have a count of Scrum and
      XP projects that backslid into ad hoc or waterfall because the product
      management and management practices were misunderstood or misapplied
      (despite the engineering practices perhaps being properly understood).

      Steve


      > Cheers, Ilja
    • 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.