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

Re: [XP] The Whole Enchilada

Expand Messages
  • John Roth
    ... OK. Let s take the gloves off. First, how many teams have YOU worked with, and how much experience do YOU personally have with successful teams and failing
    Message 1 of 87 , Feb 1 3:35 PM
    • 0 Attachment
      Chris Wheeler said:


      > On Sun, Feb 1, 2009 at 4:54 PM, John Roth <JohnRoth1@...> wrote:
      >
      >>
      >> Chris, are you not paying attention?
      >>
      >
      > Ya. I keep hearing general statements like:
      >
      >
      >> The reason that Scrum is failing all over the place
      >> ought to be obvious, ...
      >> It's the lack of a focus on team process improvement.
      >>
      >
      > and:
      >
      >>
      >> 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.
      >
      >
      > ... with absolutely no tale to go along with it. Tell me stories about
      > conversations you've had with execs, managers, programmers, at companies
      > that were failing. Don't give me lectures about the importance of process
      > improvement, tell me how a specific team didn't 'do it right'. Give me the
      > results of you Readiness Assessments (I mean, there must be some useful
      > stuff in there, right?)
      >
      > Improvement happens in the details.
      >
      > Chris.

      OK. Let's take the gloves off. First, how many teams
      have YOU worked with, and how much experience do
      YOU personally have with successful teams and failing teams?
      How many teams have YOU coached from a standing start
      to where they were successful a year after you left?

      I don't want stories, I want numbers.

      Now, on my side. As I said, I'm retired. I don't do
      coaching for a living, and never did.

      However, way back in the '70s, I was involved with
      an Organizational Development effort, using a technique
      called Grid Organizational Development. This was at
      Continental Assurance in Chicago (see, I'm giving you
      the company name, not that it's going to do much for
      you.)


      Was it successful? Up to a point. It was beginning
      to founder when the holding company was bought
      out, and the purchaser decided to merge the two
      data processing efforts, leaving the larger of the two
      (Continental Casualty Company) in charge. He did
      it based on his in-house DP staff, who had maybe
      a tenth of the processing power of the smaller of the
      two companies.

      Anyway, we went offsite for a week of training, and
      at one point we had to go into groups and practice
      solving a problem. Well, the manager got the idea that
      our biggest problem was that the users hated us (sound
      familiar?) and that since we were obviously doing fine it
      was a perception problem on their part.

      I disagreed.

      We went round and round on that for two solid hours
      while he tried to get me to agree that we were doing
      an adequate job and it was a publicity problem.
      I told him any number of times I was quite willing to
      go with the program and see if it worked, but he
      wanted me to agree to his view of the problem.

      Needless to say, this didn't work. The view of two
      alpha males going at it head to head didn't do much
      for the other team member's conviction that they had
      a working process, either.

      In retrospect, I can see several things we could have
      done that were part of the course, like ask the users
      what they didn't like and do some measurement, but
      we didn't.

      John Roth
    • Brad Appleton
      Thanks Charlie for the thoughts and advice!
      Message 87 of 87 , Feb 7 10:51 PM
      • 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.