8 Shortcomings of Agile / Scrum

Scrum, like most things, has its short-comings (although the pros far outweigh the cons in our view). These 8 theses, according to Robert Martin, are some serious problems with Scrum out of the box:

• No Technical Practices: Scrum is a project management framework and doesn’t make any technical recommendations. Bob suggests that teams “need 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.”
• 30 Day Sprints are too long – most trainers now recommend 1-2 week sprints and the majority of teams settle at 2 weeks.
• Scrum Master sometimes turns into Project Manager: Some Scrum Masters use Scrum as a form of micro management and control. “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".”
• Certification in CSM: The Certificate that a Scrum Master, a trained CSM, holds means that on many teams only that person plays the role. Bob prefers the XP approach of rotating the Coach among members of the team.
• Insufficient Guidance Regarding the Product 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. Epics->Themes->Stories->Tasks.”
• Scrum carries an anti-management undercurrent: “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 … Scrum does not describe this with enough balance.”
• Automated Testing: without high quality automated tests it is difficult to work in short cycles and know that stories are really done.
• Multiple Teams: Scrum and generic Agile have little to say about how to scale, many practitioners have ideas but there doesn’t seem to be broad consensus yet.

Other related articles

5 Scrum Transition Anti-Patterns

When the Scrum Product Owner has to say 'No'

How to Implement Scrum

How to Successfully Combine Scrum and Project Governance

Comments

[Steve Kovacs]

This is great stuff. These should be discussion points in every new Agile implementation!

Not sure I agree with rotating scrummasters. As I think about it however, I wonder if that relates to the issue of scaling and Agile in large enterprise.

[Tiffany Jacob]

We're currently experiencing many of these - nice summary!

Would you please elaborate on "Insufficient Guidance Regarding the Product Backlog" ?

[Pratik]

"30 Day Sprints are too long – most trainers now recommend 1-2 week sprints and the majority of teams settle at 2 weeks. "

I would disagree with you on this. It is recommended to have 30-day sprint especially when the team is big and it needs weekly tracking on the progress. Generally speaking it so happens that team may not be able to pick up as soon as the sprint start. The sprint with longer duration helps the team to get settled with the new tasks and gain the speed progressing further on the sprint.

I have been working for more than 3 years in Agile and I always recommend 4wk sprint (3wk-development, 1wk-testing)

[Mark]

Thanks for your comment Steve.

I suspect 'rotating Scrum masters' has a scaling element to it. I wonder also if there's an element of keeping the management aspect as flat as possible in there?

[Mark]

Hi Pratik,

Thanks for your comment. I see your point on this - particularly in relation to helping the team get settled in early on in the Sprint.

[Mark]

Hey Tiffany - sounds like you're hitting a few of these bumps in the road. It would be useful to hear how you're managing to resolve them - from a real-time user perspective.

[David]

Excellent Points!

Regarding sprint duration, I believe it largely depends on team size (s Pratik said) and on the type of work. In many cases, a 4 week sprint IS too long, but it others it can be quite appropriate [btw: if TDD is being followed, there should not be a requirement of the last 25% of a sprint being dedicated to testing; it should be occuring continually during the sprint]

Regarding rotating Scrum Masters, It can work very well for certain circumatances: you have a small team of peers, or you have a vry large team where you rotate through a small pool. The biggest risk is itroducing inconsistancies as the SM changes.

[Henri]

Very good and recognisable. The sprint duration is a matter of a lot of combinations though, a mature team is one of them! I prefer 3 weeks cycles for new teams. One week to settle, one week to work and one week to close and rush. In mature teams we drop to two week cycles.

The part that I mostly disagree with is Automated Testing. Probably it is a matter of definition. As long as automated testing is initiated on unit test level (Test Driven Design) and purely supportive to the higher levels of integrations, system and acceptance. There is no danger. If automated testing is a target goal for these higher levels, then I agree with this statement.