53003RE: [scrumdevelopment] Re:Scrum / Agile's inherit shortcomings? Uncle Bob Martin's 7 theses nailed to the door.
- Oct 17, 2011
Interesting observations. Guess I thought I would share my 2 cents regarding some of these.
Booz Allen Hamilton
I agree these are good things to talk about. I am not sure I would blame "Scrum" for any of them. Let me discuss in-line below...
And looking at Uncle Bob's ending comments.... I think he is really being slightly dramatic, in a way that helps and does not help.
It helps in that people discuss these issues more and think a bit more.
It does not help, because some people will dismiss Scrum with "..and even Bob Martin thinks Scrum has lots of problems. Let's just roll our own..." Speaking for myself, I have never seen a "roll our own" that was very good compared to a decent Scrum implementation.
--- In email@example.com, "ashish_wrt" <traderashish@...> wrote:
> Excellent thread.
> --- In firstname.lastname@example.org, Robert Martin <UncleBob@>
> > > Scrum / Agile's inherit shortcomings?
> > > Posted by: "Chris Brookins" chris@ shippingnews
> > > Wed Feb 3, 2010 7:32 am (PST)
> > >
> > > I was recently asked by my CEO to present Scrum's inherit
> shortcomings for
> > > discussion and how to mitigate them.
> > If we think about what scrum is as it comes out of the box, and not
> what scrum should evolve into as a team adopts it, then the hindsight of
> the last decade makes it pretty easy to spot some serious flaws.
> > 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.
Scrum is a framework, not a full methodology. I won't explain why here, but that is a feature, not a defect. One small reason: a team can do a decent implementation of "all" of Scrum after a 2-day course. That would not be true of a full methodology.
Speaking as a Scrum trainer, I love the XP engineering practices.
Scrum does assume that a team starts with decent professional engineering practices, that these are not perfect, and that the team will continuously improve them, eg, via removing impediments.
[MB] Agree that scrum is a project mgmt method. In fact it is not just a SW process/method. Our CSM teacher highlighted other uses including planning his family vacation. In SW, however, without good engineering practices and good engineers the process/method will not be very effective no matter what method you use. Not a knock on scrum just an observation. The people you are managing still have to perform and use good practices.
> > 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
I like 2 week sprints, and generally recommend them. Ken Schwaber (and others) make a great case for 4 week sprints. Scrum does not require that Sprints last as long as 4 weeks.
I agree that deciding the right Sprint length for a given team is an important discussion and decision.
[MB] We have used 15 day sprint durations. It seems long enough to get features complete, try new ideas and get feedback, and yet not so long that “keeping change out” is still possible. The downside to the smaller durations is that there are times when the sprints can blur together especially when several aggressive plans are strung together due to external scheduling.
> > 3. The tendency of the scrum master to arrogate project management
> powers. This is not a problem with Scrum out of the box so much as it
> is a problem with the way scrum sometimes evolves. Perhaps it is
> related to the unfortunate use of the word "master". Perhaps the XP
> term "Coach" might be a better word to use. In any case, good
> implementation of scrum do not necessarily correlate scrum masters and
> project managers.
Words, words, words. People, people, people.
As stated, this is not a problem with Scrum per se.
I agree this happens. Some reasons: (a) the specific person chosen to be SM is essentially a command-n-control type. (b) a manager tells the SM that he must "run" the team. And others too, of course.
Maybe useful to pause here and say this. I play "tennis". I used to play it better than I do today. Is it fair to blame tennis that I am a relatively weak player? Is it "tennis"'s fault that I am not Roger Federer? I don't think so. The rules of tennis are very simple. But it is a very very hard game to master. I think this applies to Scrum.
[MB] We have struggled with this area. What does the SM do (besides manage scrum process). We have had our SM be the tech lead/architect with effectiveness as well as be the PM also with effectiveness.
> > 4. The C in CSM is unfortunate. Again, this is not so much about
> scrum out of the box as it is about the scrum community. That letter C
> has gotten far too significant for it's intention. It is true that the
> people in a scrum team need to be trained. One of the things they
> should be trained about is the role of the scrum master. The problem
> with the C is that it changes the notion of scrum master from a role
> into a person. It is the person who has the C. In an ideal case, the
> members of the scrum team will rotate through the scrum master role the
> same way the members of an XP team rotate through the coach role. This
> rotation is never perfect, and sometimes the role sticks to one or two
> people more than others. But the idea was never to raise up a
> particular person with a rank. We never wanted that C emblazoned on
> their chests.
OK, the C in CSM is unfortunate. Words, words, words. No matter which words you use, and how often you say it, people will mis-understand.
I think most sensible people understand:
- A CSM per se guarantees nothing.
- Having done the CSM course is a good thing.
- There are some people who have not done the course who are better than a bunch a people who have done the course. Anyone surprised?
The SM is a role without any authority (at least as we teach it).
[MB] Don’t they need some level of “authority” to actually manage the process. Not necessarily as “over-lord” and certainly more “servant-leader” but at times someone has to push meetings to a close, force a decision etc. That word “authority” may not be the best since it has usually overtones of rank etc. But even in the NFL the coach has some authority. They can bench players, draft game plans, meet with mgmt to discuss objectives, impediments etc. This may be a factor of our SM being either tech lead or PM as well but still see facilitating, removing impediments, and managing the process as requiring some notion of “authority”.
[MB] I also do not agree with rotating SM through the team in most cases. The rationale is that not all team members have all the skills (or desire, or training) to perform the role. Do NFL coaches rotate during a season? Not unless they are doing poorly. That said we have let different team members facilitate various meetings but agree that SM is more than that.
I am not clear about what the problem he is really seeing. I don't see, in real life, persons who are raised up with a rank. Maybe it happens elsewhere.
I actually DON'T agree with the suggestion that everyone play SM. Having different people facilitate some meetings sounds like probably a good idea usually. But that's totally minor to the SM role. The SM's main job is to remove impediments (one of which is "we need a meeting facilitator"). Some impediments are big, some impediments require strong and numerous skills to "fix it". A person needs time and a consistent plan to work through some of these things (eg, implementing a series of the XP practices well).
> > 5. Scrum provides insufficient guidance regarding the structure of the
> backlog. We've learned, over the years, that backlogs are hierarchical
> entities consisting of epics, themes, stories, etc. We've learned how
> to estimate them statistically. We've learned how and when to break the
> higher level entities down into lower level entities.
Again, I think it is a big advantage to keep Scrum a simple basic framework, and NOT try to answer all these kinds of questions for "everyone".
I see his point, and personally for most clients I would use that kind of framework (lg epics, md epics, stories, tasks). AFAIK, all Scrum trainers talk in these terms in the CSM class, for example.
There are others who say that a backlog should NOT be viewed simply as a hierarchy. It should be mapped, based on one or two basic ideas (eg, how a user does his work). I think these ideas hold merit as well.
And probably others also. I think the usefulness of these "additional" ideas will depend on the situation.
[MB] I think grooming backlog is the key. If using themes or stories help get the team and PO together on the right vision great. Working these into the right grained features is always key. And helping people learn how estimation works so team can build accurate velocity and release plans. How this is done would seem to be a team / project driven thing that would be enhanced through retrospectives etc.
> > 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.
[MB] Without focusing on “anti-mgmt” currents I agree that there is a potential to over-emphasize self-X on scrum. This may depend on the team makeup and how committed they are to the project and process but we have found that there needs to be some PM and Tech Lead guidance for the team in addition to PO guidance.
Umm. This is an interesting one.
First there is a truth. There are many just plain bad managers out there. And, an additional set of managers who have no clue about self-organization and how their disruptions are destroying the team.
This is NOT to say all managers are this way...
Second, there are certainly agile people (some of them "scrum") who come off as anti-management as a broad brush. This is unfortunate.
I personally am pro-management. Pro-leadership. Pro-servant leadership. And in favor of understanding the problems of leadership. (Let us assume that Steve Jobs was a very very good leader (but not ideal). Just saying: I don't think there are many Steve Jobs out there. Just saying.)
Scrum never said that a manager should not "do something" about a team that is struggling (for some reasonable period) or just palin failing.
I am at a loss where "Scrum" said this (managers are evil) or "Scrum" could say this (better balance btw self-managing and management injection). Where?
I do think it is an issue. I do think it is talked about some in the community. And probably could be talked about more. There are many many many specific scenarios, for example.
> > 7. Automated Testing. Although this could be considered a derivative
> of point 1, I thought it worth calling out as a separate point because
> it is so fundamental. Scrum doesn't mention this, yet it is the
> foundation of every agile effort. Agile teams work in short cycles
> because feedback only works well in short cycles. But short cycles
> aren't enough. You also need objective measurement of progress. The
> most reliable way to know how much a team has gotten done is to run
> automated tests and count the tests that pass.
[MB] I agree that this is not so much scrum as it is an engineering practice (and a good one).
Umm. This is discussed quite a bit. I don't know anyone in the Scrum community who does not feel automated testing (with a software product) is essential.
Again, Scrum is a framework. You can start Scrum w/o automated testing (teams often start here, sad to say), and, over time, build up the team's automated testing. It is a good thing to go ahead and get started, almost always.
Scrum does have a Definition of Done, which at least makes it clearer: how done are we really.
> > 8. Multiple teams. Scrum has little to say about the coordination of
> multiple teams. This is not a failing unique to scrum. Agile itself is
> virtually silent on this issue. Scrum talked about the vague notion of
> a "Scrum of Scrums" but that idea really hasn't played out all that
> well. Scrum-in-the-large remains in the domain of certain consultants
> who claim to have an answer. There is no real consensus on the issue.
Good points. And? If there is no real consensus on the issue, why should "Scrum" declare a "winning" way of doing it.
I talk about scaling in my classes. But to be honest, scaling is by definition ugly. And, perhaps more to the point, the people need to master the basics more than learn the fancy plays.
I slightly disagree about Scrum of Scrums. I think it works well with good people. And if the right people are in the SOS. It works better with good continuous integration (including the automated testing).
The Chief Product Owner concept typically works well. The product owner group idea works well.
None of them keep scaling from being ugly. But then it can be said that all of our work is ugly, in a certain meaning of the word.
The problems of scaling are not unique to anything. Waterfall, scrum, xp, you-name-it, ... all have (and I think will have) problems scaling. Occasionally, a really good manager or team of managers comes along, and the whole group gets a BIG project done very successfully (in the opinions of most everyone), but it is relatively rare and fraught with problems. "OK" success is not so rare.
I think Scrum, with its core stuff, makes scaling somewhat easier or better, because it makes the problems more visible. But, of course, a lot of us need to turn our heads away from seeing such ugliness.
Enough for today...
> > > Things that come to mind are that
> > > Scrum is not well suited to projects that have well understood
> > > tasks/deadines/deliverables like manufacturing, and is not well
> suited to
> > > organizations that don't support the Scrum ideals, roles and
> > > responsibilities. Also I know there is definitely tension between UX
> > > designers and Scrum (e.g. breaking down epics into micro stories and
> > > the vision of what has to be delivered - not spending months on
> BUFD), and I
> > > have found the practices of Jeff Patton
> > > http://www.agileproductdesign.com/blog/ to help mitigate that.
> > >
> > > Anything else come to mind?
> > >
> > > From my perspective the majority of Scrum's inherit shortcomings
> > > revolve around how well the organization support's scrum and
> implements it.
> > > e.g. if the company doesn't support the resources and process
> necessary to
> > > properly fufill and hold accountable the PO roll, SM roll, things
> are going
> > > to go south.
> > >
> > > Background, I have been practicing Scrum for several years at a
> couple of
> > > companies and we seem to have a well functioning scrum here, but my
> CEO is
> > > more familiar with waterfall from his previous companies. He says he
> has no
> > > preconceived notions of what Scrum's shortcomings are, but just
> wants me to
> > > speak to them in order to make sure we are mitigating them
> appropriately. I
> > > don't want to just come back to him with a list of Scrum Smells (I
> will do
> > > that but want more from this group if possible).
> > ----
> > Robert C. Martin (Uncle Bob) | email: unclebob@
> > Object Mentor Inc. | blog: blog.objectmentor.com
> > The Agile Transition Experts | web: www.objectmentor.com
> > 800-338-6716 | twitter: unclebobmartin
- << Previous post in topic