Scrum and Kanban – the agile way

Within the umbrella of agile practices, people enquire about the Scrum methodology and the Kanban technique as regards their similarities, their differences and potential benefits using one over the other. This blog looks at the characteristics of each, potential scenarios where one or both could be used to best advantage and finishes with a video of Jean Tabaka providing her perspective on both methodologies.

Scrum – key features

In my use of scrum, here is my perspective;

• Scrum uses a release plan consisting of a series of sprints/iterations, each delivering working software leading to the final release. Each sprint provides a focus on a key set of user features, while retaining the overall perspective of a release plan
• Self organisation is a key principle with the delivery team committing to a set of deliverables for each sprint with the scrum master providing a facilitation role and the product owner providing the business prioritisation input
• Scrum has a dediciated process and quality improvement event – the retrospection – at the end of each sprint, with any lessons incorporated into subsequent sprints. In addition, according to the delivery team’s preferences, any quality issues that arise as part of the daily scrum, can be handled after the scrum and facilitated as necessary by the scrum master

Kanban – key features

In my reading of Kanban, it’s a technique as opposed to a broader methodology such as scrum;

• Kanban focuses on the process flows as opposed to iterations when a product is being developed. This derives from kanban principles in Lean manufacturing. A process flow can be as simple as three stages; development, test & release
• A kanban can be a feature, a bug or change request and the aim is to move the kanban through the process flow as quickly as possible so to start another kanban. Based on the number of resources on the delivery team, a kanban limit is agreed by the team as to how many kanbans will be allowed as work in progress
• With it’s focus on process flows and cycle times, if work in progress builds up beyond the agreed limit between stages due to any delay, action is taken immediately to resolve the delay and speed up the flow
• The delivery team is truly self-organising in that no scrummaster is present in the process

A difference

I believe that (one) key difference between Scrum and Kanban is in the definition of workload, with Kanban viewing the user features and change requests as one continuous stream of work, finish one, start the next. While Scrum also welcomes changing priorities as an agile principle, it segments the workload into sprints (1 to 4 weeks) with an interruption only allowed if the product owner wishes to make a major change to the prioritisation of features.

Combine or use separately

Rather than viewing them as two distinct approaches, I think it’s better to consider the proposition made by Henrik Kniberg where he suggested incorporating Kanban into Scrum to minimise work in progress during a sprint.

Another option to use Kanban in systems maintenance team or area of work where small chunks of work in the form of support requests can be readily assimilated as kanbans as suggested by the founder of Kanban – David Anderson. Scrum then can be used for delivering a large number of features to a new or upgraded product.

For me personally, I think I may have been using some Kanban principles unknowingly. When I find spare capacity towards the end of a sprint, together with the delivery team and product owner, we would hold an informal (short) planning meeting to decide on how best to use this spare capacity.
Finally, for a concise and insightful perspective on Scrum and Kanban, please view this video from Rally Software featuring Jean Tabaka.