I wouldn’t recommend Scrum

I wouldn’t recommend Scrum. Scrum is a software development process, and in order to “use Scrum” you have to adopt all of it. The process has a lot of good ideas, like daily standup meetings. It is possible to practice Extreme Programming (XP) without the pair programming, but it is not possible to practice Scrum without locked iterations.

Some companies (or, rather, people in companies) see the instruction to “use Scrum” as an instruction to focus on process. When using Scrum it is impossible to not focus – at least a little – on process, and it is hard to not go overboard. Companies end up valuing the process of Scrum higher than the communication it should facilitate.

The “Are we Agile yet?”-crowd[1] use Scrum as an excuse to not really be agile, but still label themselves as such. I have witnessed representatives from big companies discussing tiny details in the process, and which is generally better, rather than accepting that each situation requires a different (or at least slightly differing) solution.

With Scrum, it’s easy to forget that very important tenet, “Individuals and interactions over processes and tools”.[2] It’s right there, in the Agile Manifesto.

Let’s take a positive example: We don’t use Scrum, but some of the positive ideas have inspired us.

We have daily standup meetings, but the important part is not standing up. It is important that we get an idea of what is going on in the department, and that we get an opportunity to communicate present challenges and discuss present issues.

We don’t have locked iterations, but continuously pull from our backlog of stories. We constantly work on what is most important, not what was most important a week ago. This will not work for all people, but it works for us, because our team leaders act professionally and shield the team members from volatile and changing business decisions. We have replaced process (locked iterations, agreements) with people (team leaders, discussions). If we are taken off a task before finishing it, we know it is urgent.

Image: "A daily standup with the team"

Extreme Programming gives you a toolbox, but doesn’t tell you to blindly use them. You are not supposed to hammer at a screw, or try to screw in a nail. XP tells you to find the right tool for the job. Scrum is presented as much more of a package, and if you don’t want the whole package, well, then you can’t have any of it.

I think that all companies should look into what kind of company they are and find the processes that fit. If those processes equal Scrum, then that’s great. But for people looking to define or redefine their development processes, I would never directly recommend Scrum.

Update: I wrote a comment on this blog post in one I call I wouldn’t recommend process.

When I write more, filling out this form will let you know.


[1] “Are we Agile yet?” is a known phenomenon.

[2] The Agile Manifesto is where the whole Agile thing started. Some tools are taught without the context of the manifesto and that’s where it goes wrong.


Now read this

Group Flow in Software Development

In The Clean Coder, Robert C Martin writes about being in the Zone: Let me be clear about this. You will write more code in the Zone. If you are practicing TDD, you will go around the red/green/refactor loop more quickly. And you will... Continue →