Scrum vs Scrumban

I wonder how many companies out there genuinely believe that they’re “Agile” because they have daily standups? I’m also curious how many people could explain the difference between Scrum and Agile? Before talking about all the merits of Scrum vs Scrumban I’m just going to reiterate a few of the basics.

Agile is a set of principles and ideas which signatories of the manifesto believe will help development of software (or actually almost businesses but for the sake of simplicity I’m going to stick to development teams).

Scrum is a process teams can follow to help them follow these principles.

Scrumban is another process which aims to uphold the Agile principles but in a slightly different way.

Most people are familiar with Scrum’s iterative approach. Software is completed every Sprint (usually every two weeks) and the upcoming work is ranked in order of priority and the team commits to delivering a certain number of those tasks in their next Sprint.

Scrumban is a little different, upcoming work is continuously reprioritised and team members pick items off the top of the list. There are no planning meetings because there’s no sprint commitment.

A few years ago we were struggling with the amount of support time our customers required. Ticket priorities were constantly changing and expecting the operations side of the business to wait for the next sprint planning session was unreasonable.

I wrote about our two team system a few weeks ago. Once we were free of trying to design a process to accommodate both Planned and Unplanned work we realised that for a ticket driven environment Scrum was no longer the approach for us.

Using Scrumban for our Support Developers means the operations team can continuously repriorise tickets in our queue as customer’s priorities change. As soon as a problem is escalated it moves to the top of the prioritised list, can you imagine the benefits after continuously breaking sprint?

We have a Kanban board in Trello, on the left are the prioritised tickets, next we have tickets a developer is actively working on, next are tickets ready to test, and finally a list of recently solved ones.

At any point I can send out the board and say “this is what we’re looking at, this is where your problem is”. Various stakeholders can negotiate with the PO to adjust priorities as required.

What’s key here is visibility, when your stakeholders can see the ordered list and can negotiate their position on it they feel far more empowered than sitting waiting for an endless queue. However in my experience it’s worth triaging this list as issues come in and letting quick win issues jump the queue to avoid long, pointless wait times.

We believe that this approach makes our Support Developers far more flexible and (hopefully) helps us provide a better customer service – that’s certainly what our numbers imply!

Have you tried Scrumban? How do you plan your Support Developers work?