Scrum: What is it Good For?
A Response to Ditching Scrum for Kanban
I read Grant Ammons’ post about transitioning from Scrum to Kanban with great interest, since I’ve also used Scrum as a kind of “gateway drug” from one process to another. Full disclosure: I am a certified Scrum Master, have been a Product Owner, and co-created a free resource called Scrum Your Wedding. But I’m really not religious about Scrum (as evidenced by the liberties my partner and I took with Scrum Your Wedding). We don’t use Scrum where I currently work, and I honestly don’t think we need it. We follow a sprint-like rhythm — we call them “heartbeats” — but otherwise we don’t make use of the roles, rituals, or artifacts.
The Scrum framework has always felt arbitrary to me. The rituals and artifacts can be incredibly useful, but I’ve seen lots of different methodologies work just as well. I think of Scrum as one of several processes I can make use of when I need one.
When to Use Scrum
The most typical case where I recommend turning to Scrum is, as in Ammons’ example, when you need to clean house. The rituals — especially a regular sprint — can help force a kind of order, and define a workflow. The artifacts solve many intra-org communication challenges. The clear role definitions can help to resolve interpersonal issues.
However, when Scrum gets treated as simply a process, one that can be discarded, we’re missing a larger point. We’re forgetting that Scrum is meant to be an Agile methodology. Not just a lowercase agile one, though of course you can tweak the Scrum framework if you’d like. But we often forget that Scrum is an uppercase-Agile methodology, too. It’s meant to align with the principles in the Agile Manifesto. Unfortunately, I’ve seen that it’s easy to have a perfect Scrum installation without actually having an iterative, Agile approach. All the Scrum Masters, daily stand-ups, and product backlogs in the world won’t help you build the right product if you aren’t nailing the MVPs, the customer feedback, and a commitment to genuine iteration.
Good For Planning
I do take slight issue with one part of Ammons’ post. Scrum often gets blamed for the challenges of estimating, as if that’s somehow specific to this particular methodology. Scrum actually offers a pretty good alternative to traditional estimating — tracking velocity.
I wonder if Ammons’ team used user stories and story points to track their velocity over time. I wonder, were they using a burndown chart to surface problems as early as possible? Were they making use of the daily stand-up to identify obstacles to finishing the sprint? (One hack to the daily stand-up that I recommend is to not just ask “What’s blocking you?” but to also ask the more pointed, “Based on what we know today, what could prevent us from finishing the sprint?”) Did they have a Scrum Master dedicated to removing those obstacles? Did their retrospectives include honest conversations about why they weren’t finishing? Did they design experiments to stabilize their velocity? (Maybe so. Like I said, Scrum isn’t perfect. But it does have some pretty nice features when it comes to estimating and planning — though, ahem, “planning” takes on a different meaning in an Agile shop.)
Making Work Visible
As several commenters pointed out, Kanban is not actually an alternative to Scrum. I like the way someone once described Kanban to me — it’s a way to discover whatever your process is. You configure a Kanban board to match the workflows you use, and once you’ve articulated it visually, you’ll likely see areas where your workflow could be improved. Both Scrum and Kanban emphasize making work visible, and this is perhaps their most valuable feature.
Scrum is not a magic bullet. It is a well-known, somewhat-proven method that helps create some order out of chaos. But if all you’re seeing is a process, you might be missing out on Scrum’s more significant aim — to help you be Agile.
