Six Sure-Fire Ways to Make Scrum Fail
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:
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
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.
- 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.
- No software architecture! We’re agile; we don’t need no stinkin’ architecture!
- 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.
- 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.
- The test team should refuse to play. Moving fast isn’t necessary, testing everything at the end of all the sprints is fine, correct?
- 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
Labels: agile, scrum, scrum product management, software requirements
0 Comments:
Post a Comment
<< Home