BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Scrum/Agile Failings or the Theses of Uncle Bob Martin

Scrum/Agile Failings or the Theses of Uncle Bob Martin

Bookmarks

Handwriting on Old PaperIn 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

Rate this Article

Adoption
Style

BT