in Agile

Scrumban: The Unofficial Agile ‘Maintenance’ Framework

Constantly disrupting your sprint? Don’t have enough time to meet changing priorities? Then maybe Scrumban is for you.

What is Scrumban?

What is Scrumban

Deloitte Digital explains:

“Scrumban is a pull-based system, where the team no longer plans out the work that is committed to during the planning meeting, and instead continually grooms the backlog. The same Scrum meetings (planning, review, and retrospective) can and should still take place, but the cadence of them can be more context-driven. The real key to moving to Scrumban, though, is ensuring that work in progress (WIP) is still limited.”

Since Kanban has been claimed as “the unofficial preferred framework for maintenance staff“, why choose Scrumban?

When to use Scrumban

Solutions IQ has suggested that Scrumban is suited to several situations, mainly:

Scrumban

Scrumban makes sense in these fast paced situations, because planning and committing to tasks in a sprint doesn’t work with live issues that require an immediate response – even 1 week is too long.

Scrumban helps teams maintain the “state of Zen” they find when using Kanban but couples this with some of Scrum’s structures around planning, reviewing and improving.

Why not Scrum?

Using Scrumban over Scrum is a logical choice for reaction-based teams. That’s not to say Scrum isn’t useful at all , Thomas Schranz of Blossom.io explains that Scrum is beneficial when:

  • Your team’s performance doesn’t change
  • What you’re working on is highly predicable
  • Nothing else important comes up

Unfortunately, in saying that, with Scrum there is always a temptation to cut-corners and accrue technical debt . Pushing a user story to ‘done’ (but accruing said technical debt) is easy to do and makes reports look ‘good’. This can be common practice in teams that get bombarded with tasks mid-sprint, making their (vanity) metric of velocity meaningless.

Why Scrumban?

Here are a few reasons:

It’s pretty simple stuff. Do Scrum, but get rid of Sprints. Enforce a WIP limit so your team have to swarm on tasks. This allows your team to finish what they are working on but also allows ‘the business’ to make changes with a relatively short turn around. Everyone wins and the Sprint clock stops ticking.

That’s why I think Scrum ban should become the unofficial Agile framework for maintenance work.