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

Re: [XP] The Whole Enchilada

Expand Messages
  • George Dinwiddie
    ... Would you offer this advice in all contexts? Or just in the one in which you find yourself now? More specifically, if you were called in because a
    Message 1 of 87 , Feb 1, 2009
    • 0 Attachment
      Adam Sroka wrote:
      > On Sun, Feb 1, 2009 at 11:46 AM, George Dinwiddie
      > <lists@...> wrote:
      >> Adam Sroka wrote:
      >>> On Sat, Jan 31, 2009 at 9:17 AM, George Dinwiddie
      >>> <lists@...> wrote:
      >>>> Adam Sroka wrote:
      >>>>> However, the idea that we can start
      >>>>> with Scrum at the organizational level and project teams will
      >>>>> magically become more Agile (with or without coaching) is
      >>>>> fundamentally flawed. Most teams that try to adopt an Agile approach
      >>>>> from within the structure of an existing project fail. Even if they
      >>>>> don't fail the existence of legacy code makes it difficult to
      >>>>> introduce new practices and gain any momentum.
      >>>> Yes, expecting teams to "magically become more Agile" is fundamentally
      >>>> flawed, but coaching teams working on legacy code or an existing project
      >>>> to become more agile is not. Yes, it's difficult. But I'm not sure
      >>>> where you get the data that "most teams" fail when they try this.
      >>>> That's not been my experience in coaching collocated teams. (Agile
      >>>> adoption by existing distributed teams seems to be another kettle of
      >>>> fish.)
      >>> We might be working from slightly different definitions of "fail."
      >>> Mine includes the aforementioned "continuing to suck indefinitely."
      >> Hmmm... Define "suck" in this context.
      >> If "suck" means something like "not in the top 10% in terms of
      >> productivity of clean code" then it is, by definition, not something
      >> that 90% of the teams will reach.
      >> If "suck" means "not as good as possible" then probably every team fails.
      >> If "suck" means "not as good as I am" then it seems to say more about
      >> the person making the judgment than the team being judged. The word,
      >> itself, seems to be making a value statement about more than just the code.
      >> I'm not sure what /you/ mean when you say "suck."
      >> If a team becomes twice as good as they were (whatever that means), and
      >> then levels off on a plateau and doesn't continue to improve, does that
      >> mean they failed?
      >> Is "suck" an absolute level of quality? Is "sucks a little" a failure
      >> and "doesn't quite suck" a success?
      > First of all, I think "suck" is a know-it-when-you-see-it kind of
      > thing. Principally, I am referring to teams who slowly produce poorly
      > written code with poor quality. Agile practices are introduced and
      > they continue to write poor code with poor quality at about the same
      > speed.
      > Also, generally, yes, I am making a value judgment about more than
      > just code. There is a lot of institutionalized mediocrity out there.
      > It is difficult to start from mediocrity and achieve something great.
      > It does happen, but there isn't a formula for it - not even XP.
      > Mostly, those who achieve greatness from mediocrity were
      > underachieving to begin with.
      > So, I am suggesting that we build a great team and start out doing the
      > Agile practices to the best of our ability, learning as we go. I think
      > this is a better idea that trying to take something broken and fix it.

      Would you offer this advice in all contexts? Or just in the one in
      which you find yourself now?

      More specifically, if you were called in because a mediocre team was
      writing poor code with poor quality at a slow pace, what would you do?
      Would you immediately fire all of those people and set out to hire a
      great team?

      - George

      * George Dinwiddie * http://blog.gdinwiddie.com
      Software Development http://www.idiacomputing.com
      Consultant and Coach http://www.agilemaryland.org
    • 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.