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

44872Re: [scrumdevelopment] Re:Scrum / Agile's inherit shortcomings? Uncle Bob Martin's 7 theses nailed to the door.

Expand Messages
  • Ron Jeffries
    Feb 4 7:47 AM
    • 0 Attachment
      Hello, Mark. On Thursday, February 4, 2010, at 10:24:48 AM, you
      wrote:

      >> 1. No technical practices. Scrum is great at giving project
      >> management advice, but provides no technical help for the
      >> developer. Any good implementation of Scrum needs to borrow
      >> technical practices from some other method like XP. The suite of
      >> technical practices that should be added probably include: TDD,
      >> Continuous Integration, Acceptance Testing, Pair Programming,
      >> Refactoring.

      > Well, given that Scrum is a framework for managing projects, it
      > shouldn't come as a surprise that there's no discussion of
      > technical practices. As far as I'm aware, neither waterfall or RUP
      > detailed technical practices, either.

      Projects are foundering, Mark. //Most// of them, according to Ken.
      It strikes me as facile to dismiss this concern.

      >> 2. 30 day sprints are too long. Most scrum teams have either
      >> shrunk them to 2 weeks or perform some kind of midpoint check at
      >> the two week mark. I know of some teams that have two 2-week
      >> "iterations" inside a single 4-week "sprint". The difference
      >> being that they use the sprint for reporting upwards, but use the
      >> iterations for internal feedback and control.
      >
      > There are still plenty of teams that are successful with 30 day
      > Sprints. I don't see this as a shortcoming. If the team discovers
      > that 30 days are too long, it's well within the rules of Scrum to
      > shorten the timebox.

      Yes. However, it is very counterintuitive, when a team is having
      trouble getting done, to think that a SHORTER Sprint is the right
      thing to do. Yet, it almost invariably is the right thing to do.

      >> 6. Scrum carries an anti-management undercurrent that is
      >> counter-productive. Scrum over-emphasizes the role of the team as
      >> self-managing. Self-organizing and self-managing teams are a good
      >> thing. But there is a limit to how much a team can self-X. Teams
      >> still need to be managed by someone who is responsible to the
      >> business. Scrum does not describe this with enough balance.
      >
      > If the team is delivering quality product on a regular basis, and
      > satisfying the customer, where's the need for management? If the
      > team is not delivering, and attempts to self-correct are not
      > working, a team should seek outside help.

      There are two key issues with this.

      First, the point Bob raises is the anti-management style of speech.
      This is not likely to ingratiate Scrum to management, who must,
      after all, allow it and support it.

      Second, most Scrum teams are embedded in organizations that have
      managers and use them. The fact that Scrum not only does not help
      with this but often actively denigrates managers makes improper
      Scrum installations more likely.


      Scrum is by its inventor's own statement far less effective than it
      should be. This really ought to be a concern for CSMs and CSDs
      alike. Yet it is not. I find that interesting.

      Ron Jeffries
      www.XProgramming.com
      www.xprogramming.com/blog
      Will Turner: This is either madness or brilliance.
      Captain Jack Sparrow: It's remarkable how often those two traits coincide.
    • Show all 84 messages in this topic