By February 23, 2010

Scrum Will Die

I have a prediction…

I'm becoming more and more confident of it everyday…

When I shake the magic 8 ball, it consistently says…


Now, don't get me wrong here.  I like Scrum.  I think it is a good thing.  I think it changed the way many organizations think about software development, but I also think it is not so good.

I remember when Scrum was first gaining traction.  I thought to myself, is Scrum a fad?  I knew Agile was around to stay because the amorphous thing that is Agile is a bundle of good practices that really make sense, but I often wondered about Scrum.  I wondered if Scrum was over hyped by consultants trying to make money coaching people and trainers trying to make money training people to be certified ScrumMasters.  I especially questioned it when I noticed that the only requirement of becoming a ScrumMaster was to breathe the air of a ScrumMaster trainer for two days.  (I know there is a trivial test now.)

The failings of Scrum

Scrum addresses many problems of a development team, but it also tends to create problems.  After being in Scrum environments for several years and talking to many other people in organizations doing Scrum, I've identified what I think are the main failings of Scrum.


Planning is a total waste of time.  It provides no benefit to the bottom line.  The supposed benefit of planning is to be able to identify how much work a team can do in a sprint and use those metrics to plan releases and schedules.

The concept seems solid.  It seems to make sense, but the problem is we are devoting one day of a two week sprint to an activity that basically gathers metrics.  That is a 10% overhead if your planning session doesn't go over a single day.  Essentially, planning's primary purpose is to chart velocity and commit to some amount of work.  Let's break some of this down.


Velocity is the amount of work a team can get done on average based on how much work they have been able to get done in the past.  What comes out of planning is based on estimates teams give to backlog items during planning.

Again, seems like a solid concept, but here are some of the problems.  First of all, estimation is almost always wrong.  The only way to get a real accurate estimation is to talk about the backlog item until you have squeezed all the requirements out of it up front.  And if you do that, then your planning will probably take two days.

Even if you manage to get accurate estimates, if your team is not stable and your sprint length is not stable it won't really matter, because you will be taking the average out of something that itself is not stable.


One central unspoken theme of Scrum is commitment.  The team commits to get a certain amount of work done in a sprint.  The business commits to not change the work the team is working on.  These commitments are critical, because without them time boxing fails, velocity metrics fail, and trust is lost in both directions.

So, what is wrong with commitments?  They cannot be followed.  Everyone means well, at least I hope they do.  The problem is, like a fat kid in a candy store, they just can't help themselves.  The business doesn't want to change priorities, but a critical issue comes up.  The development team wants to commit to the sprint, but the development team can't make more code get done faster simply by wanting to.  They can add more hours to the sprint, but then they are skewing the velocity.  The only way the development team can realistically commit to the sprint is to ‘pad', and that is a very bad word.  Don't ever say ‘pad' in a development shop.


I've tried to fight it.  I have closed my eyes and said “NO! NO! NO!  There is a proper way to do tasks without copying and pasting,” but it's simply not true.  I have tried many different techniques, have asked many other Scrum teams, but everyone essentially copy and pastes the same set of tasks.  The problem is, you don't know the tasks for most backlog items until you have had some kind of design session to decide how you are going to implement the solution.  I just cannot see a way around that simple plain fact.  So, what we end up doing is making up templates and tasks that are generic.

Product Ownership

Scrum says there should be one product owner.  I agree with this point.  In theory it works great.  In practice it ends up putting a whole product's life into the hands of one person.  Which person?  Well, if you make that person someone high up in the organization, they won't be the product owner for the team, but rather the boss.  The team will just do whatever the product owner says and stop being autonomous and self-managing.  If you choose someone lower in the organization, you end up having someone who cannot make decisions, and now you have all these high up business people, who are basically worthless, trying to find ways to be worthwhile (which usually results in them abusing the poor product owner.)  I like to call this the “product renter.”

Scrum Meetings

These seem like a really good idea on the surface level.  As a ScrumMaster, I tried to make these work correctly.  15 minute stand up meetings, you say what you did, what you will do, and what's impeding you.  The problem is, if you are working together doing pair programming, and “swarming” on backlogs, you already know what is going on and you are just repeating some rhetoric.  If you are not working together on backlogs and are working in isolation, 15 minutes is not enough time.  So what ends up happening is you either have a 1 hour long meeting where everyone talks about technical details of issues they are having, or you have a 15 minutes meeting where everyone repeats the same stuff everyone already knows.

What next then?

I don't think Scrum is particularly bad.  I actually like Scrum and think it can be a great process for a team that can help them to learn to use Agile techniques and vertically slice the system instead of trying to horizontally slice it.  The best parts of Scrum are really Agile.  Scrum is kind of forcing you to be Agile and do things like creating user stories, test driven development,  having always releasable code, etc.

I wrote about the Kanban before, and I am still thinking that it is the next evolution of Scrum, but I can't say because I haven't actually done a project using Kanban.  It seems to be the way that the Scrum project I am working on wants to evolve on its own.

So, why even use a process at all, or why not make our own?  Rules and process are important because they keep us from arguing about how things should be done, and they keep us from wasting time reinventing the wheel.  The trick is in having your process lightweight enough that it is not burdensome, but constraining enough that you can enforce good patterns and principles without having to argue about and debate them each time.

So my advice is to learn what you can from Scrum, but don't think it is the “be all end all.”  Scrum is a fad, it cannot last, at least not in the form it is now, because it has problems.  But hold onto those Agile principles you learn from using Scrum; those principles will last much longer, if not indefinitely.

About the author

John Sonmez

John Sonmez is the founder of Simple Programmer and a life coach for software developers. He is the best selling author of the book "Soft Skills: The Software Developer's Life Manual."