@"Tired of Scrum"

I got a comment here that deserved more than just a comment response. It is an interesting comment and I wish I could sit down with whoever wrote that and discuss that comment. But I guess that will never happen so here it goes. First of all I feel sorry for whoever made that comment and everybody else that have had a bad experience with Scrum. Scrum is by far the most abused and misused agile practice there is out there I think. Way too many organizations have tried to implement Scrum "because it makes all projects successful" without knowing what they're getting themselves into. Scrum is a tool that may kick-start a team into being more agile. But the team has to be open to embrace agile rather than scrum. Teams can be very agile without scrum. A very good team can probably be agile with a waterfall type of process too. Scrum has a tendency to focus on sprints and planning while the most important concept is hidden in the retrospect; the ability (and will) to improve the team's productivity. A team that is "happy with how things are" will in my opinion sooner or later experience an utter failure or just be unhappy. A team that continuously looks for ways to improve will more likely avoid big failures but more importantly; everybody on the team will be much more happy.

The second part of the comment intrigues me. I agree that most of the bad attempts at implementing Scrum have been initiated by managers. But I think that is just bad copy cats... And I've seen Scrum being used for an excuse to micro manage. That does not make it right nor does it make Scrum beign a nice experience for anybody involved. All good implementations I've seen however have typically started with a team that decides they want to improve their situation and then supported by management since good management will see (or already knows) that happy teams are productive teams and micromanagement doesn't make anybody happy.

One thing that I'm still wondering is; if you're a person who have been forced to try Scrum and it didn't work out well; what would you like to do? What does your perfect way of working look like?

So while this is merely more than a long comment I would like to recommend some reading:

• Don't focus on arguing if Scrum is bad or not. Focus on values that will help any team be successful such as the agile manifesto.
• Read a little about what Henrik Kniberg has written about when Scrum doesn't work and how to fail with Scrum.
• If you are really "stuck" with Scrum you should read this book.

Comments

• Anonymous
  January 31, 2011
  Well said. Scrum isn't the issue, business people with lack of understanding (that it's a framework) is the issue.

• Anonymous
  February 02, 2011
  "the most important concept is hidden in the retrospect; the ability (and will) to improve the team's productivity. A team that is "happy with how things are" will in my opinion sooner or later experience an utter failure or just be unhappy. " Spot on. With all due respect to Agile Scout above, it's time to stop blaming "management" OR "developers" for failure.  It's really the desire of individuals, a dev team, or the larger organization to stay the same.  The status quo is safe and comfortable, but ultimately leads to unhappiness.  As Maslow says: "what one can be, one must be." Embrace change and you embrace growth.

• Anonymous
  February 04, 2011
  The comment has been removed

• Anonymous
  February 06, 2011
  @and bod: I can actually agree that the Scrum alliance have failed since all the Scrum certifications have lead to way too many organizations implementing their own misunderstood version of Scrum. And the most misunderstood part of Scrum is probably that the purpose of the daily stand-up is to report status while the truth is that the daily stand-up was supposed to encourage communication within the team. Second I think you mean TDD and not unit testing since you refer to writing tests first. Once again the T in TDD has caused confusion. The purpose of TDD is not to write tests! The purpose is to write code that follows some simple principles such as loose coupling and code that is testable typically (but not always) follow these principles. Since the T in TDD is so confusing that is also why Behavior DD and Example DD have been used to better describe what you're supposed to do. That all said; one thing that intrigues me more is what in your opinion is the right way to do things?