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

Re: [XP] The Whole Enchilada

Expand Messages
  • Joshua Kerievsky
    On Sat, Jan 31, 2009 at 12:26 AM, Charlie Poole
    Message 1 of 87 , Jan 31, 2009
    • 0 Attachment
      On Sat, Jan 31, 2009 at 12:26 AM, Charlie Poole <charlie@...
      > wrote:

      > There are lots of opinions on this, many of which sound a
      > bit absolute to me.


      My original email said:

      "Of course, not every organization and development community needs a Whole
      Enchilada or could succeed with it. Yet many do need it and can succeed
      with it. A decade of experience has shown us that."

      I'm not seeing anything "absolute" in that. What I am seeing, again and
      again and again, is very poor quality software and very high technical debt
      at company after company after company. These problems are rampant. XP
      addresses them head on.


      > I've seen management-first, technical-
      > first and both together work in various organizations. To
      > me, that's proof that they can all work.


      Charlie, there are many, many Scrum projects that are floundering. It seems
      to take most of these companies 1-3 years to realize that. That's proof to
      me that the wrong process was introduced. If this was only happening with
      a few companies, there wouldn't be much to say. But when we see it over and
      over again and our colleagues see it over and over again, well then gee, one
      has to conclude that something ain't quite right.


      > The more interesting
      > question for me is how to decide what to introduce first
      > in an individual situation. And then, how fast to move
      > to the next thing.


      We call that the Readiness Assessment. I just got through doing two of
      them. Guess what? Huge quality issues and growing technical debt are
      crippling both companies. Are the developers interested in technical
      agility? My interviews with them yielded this conclusion: Hell Yes!
      They've love the opportunity to attack the quality issues and they are
      really hoping management will allow for this change to occur. Since I also
      talk to management, we're gonna see if they will allow for this.

      Solving hard problems requires a community effort -- managerial and
      technical people, collaborating to bring about lasting change.

      With incremental approaches, it seems to me that the risk
      > is stopping for too long at an intermediate stage. If
      > you start with the technical, you can end up with a group
      > that maintains a fa├žade so it can fit in with the management
      > culture of the organization. If you start with management,
      > you can end up with a group that doesn't know how to
      > accomplish what is expected of it.
      >
      > So whether you want to do it all at once, or technical-first
      > or management-first, I think you have to move along with
      > the introduction fairly quickly to have a lasting effect.


      Speed may not be as important as understanding. When a company understands
      why they aren't doing so well, they can become receptive to a correction.
      We like to help them get to an understanding during a Readiness Assessment,
      part of which involves figuring out how fast they can make the needed
      changes.


      > In terms of where to start, I lean toward figuring out
      > what the biggest problem is.


      Yeah, it is not recommended to begin without an inquiry into where the
      problems are. And the best way we've seen to do that is conduct a Readiness
      Assessment.

      --
      best regards,
      jk

      Industrial Logic, Inc.
      Joshua Kerievsky
      Founder, Extreme Programmer & Coach
      http://industriallogic.com
      866-540-8336 (toll free)
      510-540-8336 (phone)
      Berkeley, California

      Learn Code Smells, Refactoring and TDD at
      http://industriallogic.com/elearning


      [Non-text portions of this message have been removed]
    • 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.