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 development 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 boards.
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.
What is Scrumban? In short it is a workflow hybrid of Scrum and the Kanban system. If you have been wondering which agile methodology to adopt, either Scrum vs. Kanban boards then you might be surprised to learn there is a third option that combines the best of both methods, Scrumban. Originally Scrumban was designed to help transition developers from Scrum to kanban. Scrumban works by combining the best of both worlds of each methodology, and because it was so effective in supporting new product development workflow it became its own thing.
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 which interrupt the flow of work .
Without Scrum time-boxes, my anxiety is down. I also get back a couple of 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 cycle time 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:
- Pushback and agree to do that story next sprint
- The Scrumban team members agrees to add the story to the work in progress sprint, but a similar size, lower priority story drops into the backlog and out of the current sprint.
- On-demand planning where you stop the sprint and replan (the nuclear option).
But with Scrumban, I get continuous flow for work items. 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 user stories small, increment, and evolve — preventing us from doing more than is actually needed in specific roles. This helps reduce bottlenecks and provides continuous improvement. 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 to the next iteration 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 the development team. And usually that’s not a loss — they’re likely still valuable, though they might get tweaked based on the pivot.
I like Scrumban for its Agile Project Management and overall software development because it reduces overhead and enables rapid change and shorter lead times. We keep some of the Scrum rituals which reinforce adaptive planning, prioritization, visualization, collaboration, discipline, and rigor. Working in Scrumban has made me, my team, stakeholders, and my clients a little bit happier — which means a lot at a people-first place like Highland.
