Scrum/Agile Failings or the Theses of Uncle Bob Martin

Posted by Mark Levison on Feb 11, 2010

Sections

Process & Practices

Topics

Agile Techniques ,

Adopting Agile ,

Agile

Tags

Certification ,

Self-organizing Team ,

Failure ,

Scrum

In response to a question asking about the inherent shortcomings of Scrum/Agile, Uncle Bob, wrote his “7 theses”. He says that out of the box Scrum has some serious flaws also noting that most teams adapt Scrum to avoid these problems:

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

Steve Ropa, Director of Software Development at MX Logic, commented: “My personal experience has been that at some level, teams and their members want some leadership.  Sometimes that leadership emerges from the team, but sometimes it does not.  I read Uncle Bob to be saying that the limit seems to emerge regarding the interactions of the team with the business, which has definitely been my experience.”

Mark Woyna counters “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.”

Ron Jeffries, author of Extreme Programming Adventures in C#, says that “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.”

Matt Heusser, craftsman and tester, suggests: “You know, it might be more accurate to describe CSM as 'an introduction to new product development.' That would help expand the class out of software development and appeal to the whole team, not just one or two people on the team. You would give a certificate away at the end of it, but not use rhetoric like 'certified'”

Bas Vodde, co-author of Scaling Lean & Agile Development, reframes the discussion, he: “wouldn't call it shortcomings and instead point out that Scrum by itself needs to be supported by other practices”. In addition he doesn’t see Scrum as having anti management undercurrent, instead:

I think one struggle that many people have when adopting Scrum is to deal with the changing role of management. Self-managing teams does push responsibility down to teams and therefore the role of management will change. Too often, management thinks of Scrum as a framework that "they" do without needing to change (instead of ordering..." you do scrum!" which means its already likely to fail).

I don't think this is unique to Scrum, if you dive into the self-management team history and literature then the change in the role of management is a common topic. However, like any other role, when told that the current activities are not needed as such anymore, its easy to interpret that as being "anti".

What failings do you see Scrum and Agile having?

Previously on InfoQ: Failures in Agile Development, 12 Agile Adoption Failure Modes, Why Agile Adoption Fails in Some Organizations

1. Back to top

   Really 8 Theses

   by Mark Levison

   Just to be clear - there are 8 theses but since Uncle Bob called it seven when he originally wrote it, I stuck to 7. I assume that the implication is that "Automated Testing" is really just a technical practice.
   
   Cheers
   Mark Levison
   Agile Pain Relief Consulting

   Reply

2. Back to top

   Re: Really 8 Theses

   by Daniel Ribeiro

   Martin Fowler also tackled bits of this topic on his great Flaccid Scrum article.

   Reply

3. Back to top

   Re: Really 8 Theses

   by Wes Williams

   I generally agree though I do not think it is a scrum problem, as Fowler's article points out. I really like the recent interview with Mary P. on InfoQ where she spends a good deal of time talking about the same issue. Lean itself does not give specific technical practices either but it does not mean there is something wrong with it. The issue is with selling/promoting them as a complete development process with all the practices you need. Even Kent Beck states that XP has to be a combination of the values, principles and practices in order to adjust the practices for a specific context.

   Reply

4. Back to top

   Lack of technical direction is Scrum's greatest shortcoming

   by Gary Rowe

   When viewed from a developer's point of view, Scrum relies on the fact that there are technical measures in place already to allow for sprints to take place. In many places I have worked (as a contract developer) the code base is definitely legacy (using the Martin C Feathers definition).
   
   There is always the initial enthusiasm from the management team to see some new silver bullet that will whip the developers into shape and start delivering features, and this quickly fades when sprint targets are more about paying off the existing technical debt than delivering the shiny new desire from marketing.
   
   However, with careful preparation and an explanation to the management team (along with a strong buy in from upper management to smooth any feathers), the legacy code base turns into something an XP'er can be proud of. I've overseen this process myself in several sites and the positive effect on developers morale is great to see. Management is also able to relax a little because developers are able to predict with reasonable accuracy that code will be delivered to a schedule.
   
   So a combination of Scrum and XP works wonders. I cannot say the same for just Scrum on it's own.

   Reply

5. Back to top

   Re: Really 8 Theses

   by Mark Levison

   I don't think anyone tries to sell Scrum as a complete package with all you need to do software development. In fact I see Scrum as just as a useful set of practices to organize a team towards producing a common goal. I've seen it applied in a number of non-software settings and in fact I'm trying to line up articles for InfoQ that show it being taken beyond its software roots.
   
   Cheers
   Mark Levison
   Agile Pain Relief Consulting

   Reply

6. Back to top

   Re: Really 8 Theses

   by Jeff Anderson

   I think scrum needs to evolve from what I see as an entry level offering...
   agileconsulting.blogspot.com/2010/02/it-time-fo...

   Reply

• Older >