44872Re: [scrumdevelopment] Re:Scrum / Agile's inherit shortcomings? Uncle Bob Martin's 7 theses nailed to the door.
- Feb 4, 2010Hello, Mark. On Thursday, February 4, 2010, at 10:24:48 AM, you
>> 1. No technical practices. Scrum is great at giving projectProjects are foundering, Mark. //Most// of them, according to Ken.
>> 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,
> 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.
It strikes me as facile to dismiss this concern.
>> 2. 30 day sprints are too long. Most scrum teams have eitherYes. However, it is very counterintuitive, when a team is having
>> 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.
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 isThere are two key issues with this.
>> 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.
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.
Will Turner: This is either madness or brilliance.
Captain Jack Sparrow: It's remarkable how often those two traits coincide.
- << Previous post in topic Next post in topic >>