Skip to content

Scrumban: An Experience Report

I’ve been delivering software solutions as a project manager, ScrumMaster, Agile-type role, for quite a while now, using Scrum as the main method.

I’ve used Scrum in lots of different flavors, trials and, yes, tribulations. I’ve been on Death Marches and Scrummerfall. I’ve had my fair share of celebrations, too. And as an agile coach, I think I helped avoid some nasty project pitfalls.

  • I joined Highland a few years ago for several reasons:

  • Great people to work with (not just sayin’ and didn’t get paid in money or beer to say that),

  • Interesting work that I haven’t been exposed to before,

  • Openness to challenge standards and paradigms,

  • And finally, they were using Scrumban.

After two years of being knee deep in it, here’s my take on Scrumban:

Tl;dr — I dig it.

If that’s all you came looking for, that’s it. Go read Reddit or code or something.

But if you want know more about what I like about Scrumban and why it works, read on.

Scrumban Strength #1: Fewer worries and more time

When I used Scrum, I never liked the arbitrary time-box increment. It induced anxiety and created the overhead of sprint planning meetings.

Without Scrum time-boxes, my anxiety is down. I also get back a couple hours a week since there’s no sprint planning. And yet, there’s still accountability.

Scrumban Strength #2: Continuous flow

Sometimes in Scrum, my client or project pivoted faster than the duration of a sprint or iteration.

What do you do if the PO needs a new story in the current Sprint? The traditional Scrum options are:

  1. Pushback and agree to do that story next sprint

  2. The team agrees to add the story to the sprint, but a similar size, lower priority story drops out of the current sprint.

  3. Stop the sprint and replan (the nuclear option).

But with Scrumban, I get continuous flow. In some ways, I get back even more time because I really don’t need the team to estimate every story in story points (or whatever). But I still ask for a size as a reality check that the story isn’t too big, not to know when it will be done.

We keep stories small, increment, and evolve — preventing us from doing more than is actually needed. User testing and metrics collection after the production deploy can help teams gauge how well the new feature or increment is received. (At Highland, we also do user testing on clickable prototypes before we implement, meaning that new idea we thought was cool gets proved before we invest time and effort in implementing. And we measure behaviors of the built features after implementing. But that’s a topic for another post.)

My clients love being able to pivot without waiting for the arbitrary time box to end. And if it’s a big pivot that kills my sprint, I didn’t lose any time planning the sprint — just the time I spent getting the next stories teed up for development. And usually that’s not a loss — they’re likely still valuable, though they might get tweaked based on the pivot.

I like Scrumban because it reduces overhead and enables rapid change. We keep some of the Scrum rituals which reinforce adaptive planning, collaboration, discipline, and rigor. Working in Scrumban has made me, my team, and my clients a little bit happier — which means a lot at a people-first place like Highland.

You might also like