The Root Of All Evil in Scrum


Update: this blog is no longer active. For new posts and RSS subscriptions, please go to http://saintgimp.org.

Sometimes the Scrum process kind of breaks down.  Maybe there’s confusion over backlog items, or some people end up with nothing to do, or there’s a general sense of spinning the wheels but not getting anywhere.  I’ve seen these kinds of symptoms in my own work and observed them in other teams.

Personally, I think the most common cause for general malaise in the Scrum process is a lack of clear, tight focus on delivering business value.  Whenever you let the team go off the rails and start building infrastructure components with no immediate consumer, or you invest a lot of effort into tracking hours spent on non-development tasks, or you find yourself at your end-of-sprint demo talking a lot about work you did but having nothing to actually, um, demo – pain is sure to follow.

If Scrum isn’t working for you, the first thing you should do is see if you can draw a clear line between every task on your sprint backlog and some concrete, deliverable feature that your customers(*) actually care about.  If you can’t, stop and clarify your goals until you can.  If there’s no believable rationale for a particular task that your customer would get excited about, just drop it.  It’s not important and it’s distracting you from your mission.  If you don’t have a plan for delivering something that’s done, demo-able, and potentially shippable at the end of the sprint, narrow the scope until you know how to do so.  If you have some kind of required process in place and you can’t succinctly explain exactly how that process enables you to deliver working software in a better, faster, and cheaper manner, then drop the process.  It’s not helping.

It’s not always easy to cast things in terms of measurable business value.  Sometimes it takes a lot of skill to do so in a meaningful way.  Thinking about narrow vertical feature slices helps, but sometimes it takes a lot of hard work to identify the appropriate slices.  In the end, though, it’s absolutely worth it.

(* Of course, you also need to keep a complete list of your customers in mind.  An end-user won’t directly care if your project has good diagnostic logging, but your Operations team definitely will.  They’re customers too!)

Comments (2)

  1. Mister scrum says:

    First of all: I really appreciate your blog!

    Next: We are struggeling on a customer project to get scrum working. I joined the team a couple of months back, when they had allready been scrumming for a while, but I found a SCRUM team in a big crises, where they were scrumming, but as I asked them, why?

    To quote you : "If you have some kind of required process in place and you can’t succinctly explain exactly how that process enables you to deliver working software in a better, faster, and cheaper manner, then drop the process.  It’s not helping."

    I guess one of the biggest problems in the team I joined, was directly related to what you said here. An old project and team, suddenly wanted to start using Scrum, but never spent the necessary time on the product back log, and where does that leave you? In the middle of nowhere! You have no plan, and you certainly don’t know where the product owner is headed! The product back log, and the focus on the direct business value is the achilles heel for Scrum!

  2. Eric Lee says:

    Thanks!

    It’s interesting that the message many people hear when they first learn about Scrum is, "Hey, there are no rules, just do whatever you feel like," when in actuality Scrum is extremely regimented and micromanaged.  There are many things you *must* do in order for the process to work.  The key, though, is that it’s the team that’s micromanaging itself which is an entirely different thing than being micromanaged from above.  Mike Cohn wrote about that here: http://blog.mountaingoatsoftware.com/ssssh-agile-is-all-about-micromanaging.