I’d like to summarize several patterns where Scrum (a well known Agile process) combines with Kanban (an evolutionary improvement method). These patters are pretty obvious to many agile coaches and people in the Lean-Kanban community. But I feel I need to outline them for a wide audience of practitioners “in the trenches” – especially those who say “we’re sticking with Scrum for now” or “we’ve invested in Scrum and are not yet ready to try a new process.” The important thing that all these patters have in common is that they are options for improvement – just options, no commitment to substitute them for something else – and all of them involve some proficiency or understanding of Kanban.

Combo #1: Scrum with Lean Workflow

So you’re doing Scrum. Now, although the Scrum framework doesn’t prescribe it, do this: map the value stream of a delivered user story (what would count as “done” at the end of the iteration under the team’s definition of done). Establish an end-to-end pull system with a work-in-progress (WIP) limit at every step (design, development, testing, demo, etc.) This type of pull systems are known as kanban systems. Use tight WIP limits (encouraging pair programming and developer-tester pairing) and the stop-starting-start-finishing mentality to cut the cycle time of each story. This reduces the risk of missing the sprint forecast badly or having many unfinished stories at the end of the sprint. This is the most obvious combination.

Combo #2: Scrum with Personal Kanban

You’re doing Scrum. After the iteration planning, you know what stories have been selected and how they break down into tasks. The scrum board shows who is working on what. But that is not all they’re working on! A team member may have 2 or 3 tasks they’re working on right now plus, perhaps an improvement task from the last retrospective. Also, this week he has to take a training class and file some administrative reports. Oh, and we forgot two interviews of job candidates are coming up. And that’s before production issues that will inevitably show up and cause an interruption.

It is very easy to get a killer dose of multitasking, even if the team board shows you’re working on two stories. It is very easy to make sub-optimal decisions when most work items are hidden. Invisible inventory and not limiting work in progress lead to poor flow for the individual and affect the whole team. Personal Kanban brings the invisible inventory back into the open. It limits work-in-progress to establish good flow and to spark improvement on the personal level. That helps the whole team.

Combo #3: Scrum with Portfolio Kanban

This pattern is the opposite of the previous one. You still do Scrum on the team level. As you scale up, apply Kanban to the higher-tier flow: epic stories, large features, and projects. It is those high-level items that break down into user stories delivered in each sprint on the team level. At higher levels, executives scrumming over epic projects in three-month iterations – that doesn’t work very well.

Combo #4: Scrumban

Kanban itself is not a process. As an evolutionary change method, it applies to an existing process with the goal to improve this process. What if the starting process is Scrum? Then you have a special case of Kanban implementation known as Scrumban.

The relationship between Scrum, Kanban, and Scrumban.

Since Kanban does not prescribe the target process (that is, the process you arrive after improving the starting process with Kanban), there is no prescribed target process in Scrumban. The starting process, Scrum, has synchronized cadences: scheduling, delivery, retrospective. It may happen that the target process still has synchronized cadences, like in this example – in this case you’re still doing Scrum, only it’s a better instance of Scrum. Or it may happen that you arrive at a flow-based process with decoupled cadences.

Conclusion

The above are four popular combinations. You can probably come up with more. The important thing they all have in common they help you improve your Agile process and teamwork and they all require some knowledge of Kanban. You can use one or several of these options at the same time, without a risky commitment to a substitution of your existing process.