Scrum? Kanban? Anyone for Scrumban?

If you're reasonably well acquainted with Agile methodology, you've most likely got a good understanding of Scrum, the project management method associated mostly with software development. It's very well established, has its typical roles, artifacts and ceremonies. But there is also Kanban, historically associated with industrial process management, perhaps less known among software developers, but much easier to apply and very useful for work based on operations more than run by projects completion schemes. But have you thought of the good that may come from joining the two together?

Kanban fits not just software development work, but all other kid of work too, from support tickets to strict office project management - things, which in Scrum there simply is no room for. With the way the two methodologies complement each other, it comes as no surprise that someone might have thought of combining the two! Christian Miles provides a few steps for starting a good Scrumban practice.

Divide the work into stages

As in Scrum and in Kanban, Scrumban will get visualized on a board. You should start as simple as possible, so split the board into your "to do", "doing" and "done". It's always advised to set a WIP limit right away (to both embed good practice and to eliminate multitasking straight from the beginning).

Keep the product backlog running

It shouldn't be as large as in Scrum, but it still serves the purpose of letting everyone know what will be worked on in the near future.

Meetings

When doing Scrum, the meetings are usually held at the beginning of the sprint, in Kanban they will often depend on the length of the cycle, so in Scrumban - the best approach would be to decide on doing a meeting when the number of tasks in the backlog runs down to a set quantity (dependable on your team's capacity).

The start of the Cycle

Once the backlog, the board and the work plan are set, it's suggested best to let the team pull their preferred tasks themselves. After all, you're meant to show trust in them, the WIP limits are set, so simply let the people do those jobs that they know and excel at.

Stick to the WIP limits

They are there to be obeyed, after all. They will only benefit the workflow if truly applied. Should a task get stuck, make sure to swipe it back to "to do", making sure there is no waste generated by someone sitting on it waiting.

Set up reviews

Involve the stakeholders in taking part in regular reviews of the work done ("demos"), to make sure the team is still on the right track and to strengthen the team's communication and understanding.

Look back

Just like Scrum and Kanban, Scrumban will benefit from taking a look back at what's been done and how, to set some standards as to what to do better and perhaps what not to do at all. Continuous improvement is a big part of Kanban and should be the same for Scrumban.

Daily Stand-Ups

As an inseparable part of Agile, it's best to carry on with these. In Scrum the 3 questions were: "what's there to do", "what have I done", "what are the problems", whereas Scrumban will demand altering them to be closely aligned with what's going on on the board, more than with what individual people are up to.

The Scrumban Analysis

According to Christian, it would be best to limit the metrics for Scrumban to the Cycle Time only. Providing a lot of statistical data can lead to wrong estimates, increased demand from the team and other unrealistic expectations. Keep it simple and effective with just the Cycle Time.

Scrumban is most suitable for teams, whose workload is fast-changing or involves a lot of service work. When compared to Scrum, it allows more precise planning, less management abuse and more efficiency, thanks to the WIP limits.

Unfortunately, this case study is no longer available online.

Read more about Scrumban »