I joined a project which was trying to use Scrum.

After a quick read of Agile Software Development with SCRUM by Ken Schwaber and Mike Beedle, I was intrigued. What Schwaber and Beedle had to say passed the “gut check” and I wanted to see it in practice. Their basic arguments which warrant exploring are:

• Software development is unpredictable. You need a project management/process control system which adapts as you learn, and you should evaluate and apply what you are learning on a regular (monthly) basis.
• Developers must be held accountable for delivering what they promise. Developers can only be held accountable if they are empowered to solve problems.

I’d like to share our success story, but what I do have to share is lessons in how to make sure Scrum fails:

1. Interpret “Scrum” to mean there is absolutely no overall project planning or vision. After all, Scrum isn’t an empirical process control model; it’s a license to start development without an end goal in mind.
2. No software architecture! We’re agile; we don’t need no stinkin’ architecture!
3. That thing about removing impediments—it doesn’t apply if it means organizational change, it only applies to the project team. Empower development teams? Well, not if it’s hard.
4. Expect to get it exactly right in the first few sprints. If Scrum really worked, we’d get it right the first time, correct? A shift in team and organizational thinking shouldn’t take any effort.
5. The test team should refuse to play. Moving fast isn’t necessary, testing everything at the end of all the sprints is fine, correct?
6. Interpret the potential for refactoring code to mean that there is absolutely no reason to write good code to begin with, because you can always refactor it!

I joined the project at the beginning of its 3rd sprint, and Scrum was dropped in the 4th sprint. I still think Scrum has a lot of promise, and would like to give it a real try one day.

Related Reading:

Scrum Devleopment Process by Ken Schwaber.

7 Ways to Fail with Scrum by Jeff Sutherland