Wham! Bam! Scrumban you m’am!
Christmas edition
You know all about Scrum, you’ve used backlogs, whether product or sprint, you’ve brought around Sprint Planning and Daily Scrums (also known as stand-ups), and you’ve made up funny formats for the Retrospective.
You’re about as Agile as you can be without having it tattooed to your forehead. But what happens when the nature of the sprint changes?
The Scrum framework focuses on delivering increments within time-boxed sprints with the intention of delivering value to users at the end of the sprint.
You work in cross-functional teams and pick up “Product Backlog Items”, which are often, though not exclusively, represented as high-level functional requirements in the format of user stories.
You start work on them during the sprint with the intent of finishing them in accordance with your team’s Definition of Done (DoD).
A central tenet of the Scrum framework, time-boxing can be beneficial in that it means you don’t just keep building and building and adding and adding — you call it done and deliver before the end of the time-boxed period.
But in dark implementations, it can also provide an additional benefit for rigid project managers and the PMO — once you’ve begun a sprint, its contents don’t change.
One of the challenges of Scrum however, is that pesky bugs and user need don’t care about your time-boxed sprint.
That Sev-1 bug that brought down a core component doesn’t care that you don’t like being interrupted.
That not mission-critical, but high volume issue that users are seeing every single time they use your product doesn’t care that you’ve already agreed the content of the sprint.
This is one of the things that I’ve found most difficult with dark Scrum.
It assumes a perfect world without change.
Woah!
This may seem like an incredibly contradictory comment considering Scrum’s existence is, in part, specifically designed to incorporate change!
Hear me out.
No matter the length of your sprint time box, you’re inherently removing the opportunity for change.
There’s a few things that mitigate this issue:
- Your product team has enough capacity to handle live support and ongoing iteration and maybe even handle these on separate boards
- Your backlog is known and rarely changes
- Your backlog does change, but you’re able to comfortably manage that change within the constraints of the sprint time box
- Your work is perfect and you don’t get bugs
The majority of products will probably fall into the first three points, whereby the fortnightly or so sprint is just fine and you’re comfortably able to recalibrate without it being detrimental to your users.
But here’s a story of volatility, lack of use, and low capacity, that combined to bring about a perfect storm of WTF!
When volatility is high, response time needs to be quick
My product has had many challenges over its lifespan to date:
- lack of capacity (the double-edged sword of a development team made up predominantly of contractors who find better rates);
- lack of use (the business readiness and rollout has been slow meaning user feedback was slow in coming);
- the complexity of the product was underestimated while simultaneously being under-resourced and more complex requirements being added to the backlog.
Essentially, since users didn’t use the system, and we were getting more complex requirements for a system we didn’t know wasn’t working in the first place, we got a big surprise throughout the year when users started to pick the system up.
First, we got bugs — these were simple, easily identifiable, and usually quick to resolve.
Then we got questions — these were getting tougher, but usually we were able to refer to how we thought the system worked and explain this to our users.
Then we got investigations — these were tough, we just didn’t know why the system was doing what it was doing, but we knew that it shouldn’t be doing it.
This was exacerbated by our lack of capacity — the investigations just piled up but left out in the cold since the business wanted new functionality or to fix known issues instead of spending time on non-development work.
And further pronounced by our lack of knowledge — the original team that built the MVP had been turned over about three times by the time we got to a stable core team to work on the system.
Eventually, I convinced the sponsor to take a full sprint of just investigation work — no build at all.
We raised 30 tickets, bugs and stories.
I was simultaneously elated and felt absolutely ashamed.
Here was a system in my charge that, due to a myriad confluent issues, was haemorrhaging but we didn’t even know why.
Well, now we did.
But until we stabilise the behaviour, a two-week sprint is just too long a wait given the volatility and uncertainty in our backlog.
Enter: Scrumban.
When people talk about Scrum and Kanban, one of the most common differentiators I hear them refer to is that Scrum is great for feature and product work while Kanban is great for support.
Almost seems like a no-brainer that combining the two would be perfect given the volatility of our backlog!
So, we’ve slightly recalibrated our definition of sprints — they’re still two-weekly time-boxed events, but instead of being push (our implementation of Scrum had sprint planning that committed work into a sprint), they’re now pull (whereby our backlog is prioritised and developers pick up the next item of work when ready).
The sprint still closes at the end of the two weeks and whatever work has complied with our definition of done goes into the path to live.
This means that we’re only ever one item of work away from the next highest priority should that priority change.
But, in doing a hybrid approach, we have the opportunity to leverage the benefits of both — the next large feature that we will undertake, we’ll revert to a push method and plan the sprint(s) up front, ensuring we’re all aligned on how to tackle the work.
So, what?
Don’t stick with a way of doing things just because it’s the way it’s done or that’s how you’ve been taught.
Respond to the needs of your users, product, business, and team, and create ways of working that works for them.
