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

The Whole Enchilada

Expand Messages
  • Joshua Kerievsky
    Flaccid Scrum? The Decline and Fall of Agile? More evidence that organizations and development communities need a Whole Enchilada -- managerial and technical
    Message 1 of 87 , Jan 30, 2009
      Flaccid Scrum? The Decline and Fall of Agile?
      More evidence that organizations and development communities need a Whole
      Enchilada -- managerial and technical agility, not just one or the other.

      The idea that "they will just evolve to adopt the technical stuff" is, in my
      humble opinion and experience, a naive assumption. Most of the time, that
      adoption either doesn't happen or happens so haphazardly that it is as if it
      never happened at all.

      Scrum out of the box says nothing about technical agility. It is like
      selling a car without seat belts and other critical safety features. You
      need to be lucky enough to know the right Scrum people who will tell you
      that you need the technical stuff too (though even they make believe in this
      "later adoption phase" idea).

      XP (which, as we on this list know, is way more than just technical
      practices), Scurm+XP, IndustrialXP, etc., are examples of Whole Enchiladas.

      We find again and again that organizations and development communities are
      far better off beginning with Whole Enchiladas then waiting for them to
      discover how utterly insufficient their agile process is.

      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.

      So we need to acknowledge that good processes address critical things and
      technical agility is most definitely a critical thing in software
      development. It is ill-advised to defer it to a later adoption phase.

      best regards,

      Industrial Logic, Inc.
      Joshua Kerievsky
      Founder, Extreme Programmer & Coach
      Check out my latest albums on Design Patterns in Java & C++:

      [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
        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.