Kanban vs Scrum

Many Scotch whiskey connoisseurs insist that a blended whiskey is superior to a single malt. “Why?”, because combining the best of two or more products often has a better result than merely selecting one. After an examination of the differences between Kanban and Scrum in agile methodology you may well end up with a similar belief.

What is Kanban and What is Scrum?

If you’re able to get your hands on a copy of the Agile Practice Guide, first turn to the alphabetical list of definitions on page 150:

Kanban – “An agile method inspired by the original Kanban inventory control system and used specifically for knowledge work.”

Scrum – “An agile framework for developing and sustaining complex products, with specific roles, events, and artifacts.”

Basic differences are already there to be seen but a deeper investigation is needed:

The People Involved in Kanban and Scrum

In Kanban, no defined roles exist. There will probably be a Project Manager but everyone in the process is openly encouraged to collaborate and get involved to deliver the tasks on the board. Should one team member face difficulties, others can and should help out. Although there is no real “controller”, as in Scrum’s necessity to engage a trained and certified Scrum Master who ensures that the team lives by the standards set by Scrum, Kanban teams will often employ an agile coach to assist. Kanban lives by the idea that roles evolve with the needs of the project and the organization and that a team need not be cross-functional. It is acceptable that, for example, a team of specialists and a different team of generalists, may be working on the same item from the same project.

Scrum is an agile framework which provides an inveterate way to get work completed. For the personnel involved, it has clearly defined roles with different responsibilities and these individuals make up the Scrum Team; The Product Owner, the aforementioned Scrum Master and the team members. The scrum team commits to shipping working software through sprints or set periods of time with the aim of creating learning loops gathering and integrating customer feedback. The team also holds regular meetings, such as the Daily Stand-Up and the Sprint Review, in order to aid the smooth-running and the fulfillment of the objectives set in their work.

When work is delegated, Kanban utilizes systematic workflow, a pull system that does not allow team members to take aboard new tasks unless the previous one is completed. Scrum follows the pull system but in each iteration an entire batch is pulled.

Time and Productivity in Kanban and Scrum

The rhythm of work and production, or “cadence” as it is called in agile circles, is quite obviously a key element in any project. Where Kanban limits the amount of work in any one condition, Scrum limits the amount of time allowed to accomplish a particular amount of work. In Kanban, products and processes are being continually delivered as needed based on due dates determined by the business. This is seen as continuous flow and means teams are flexible and adaptable to changing priorities. It should also be noted that Kanban does not operate within fixed time frames to deliver or does it use specific review policies. If a task has been completed, it can be released.   

On the other hand, in Scrum greater emphasis is placed on scheduling. Products are delivered and determined by sprints in which a set of work needs to be completed and ready for the sprint review. Scrum teams commit to a sprint, which can be any length of time, though 2-4 weeks are most common. This short time frame means that complex projects can be split into smaller stories. This all operates within the overall project plan which is a positive, but should there be a delay, the entire project could grind to a halt.  

As a measurement of productivity, Kanban uses cycle time, namely how long it takes to fully complete a project. Velocity in Scrum, using the metric of story points, is measured in sprints and each is concurrent with the success of the previous one. Besides cycle times, Kanban also uses the Cumulative Flow Diagram (CFD) which identifies the number of work items in each state whilst simultaneously highlighting any bottlenecks in the project. Similarly, Work In Progress (WIP) limits can be set and these cap the number of items, or cards, being dealt with. These cards may also be blocked or removed completely or new work items added based on prioritization and the capacity and ability of the team involved.        

Work Board Systems in Kanban and Scrum

On the Kanban Board, columns are labeled to display the workflow and progression of a project or user story from the very beginning up to the team’s definition of done. Using columns traditionally marked: TO DO/DOING/DONE/IN DEVELOPMENT/IN REVISION, this approach focuses on visualizing and limiting the work in progress thus reducing the time it takes to move quickly from the state of doing to the state of done. The Kanban Board also publishes the maximum number of stories allowed in each column at any one time, limiting the amount of work allowed to be in an ongoing state. It particularly suits multiple projects, which have variances in priority and size, being undertaken by different teams.

Scrum Boards are labeled similarly in order to divide up tasks and depict workflow states. However, because Scrum works in sprints the board is labeled to show the flow of work from the beginning, with the sprint backlog, until the end, with the team’s Definition of Done. Every story initially put on the board will be found at the end whether successful or not. Following the Sprint Retrospective, the board is cleared and prepared for the next sprint.

As regards modifications within a project, Kanban allows and encourages changes to be made at any time whilst it is in progress. This provides iterations and continuous improvement prior to its completion. In Scrum, changes during the sprint are discouraged and should not occur.  

Scrumban – Blending the Products

So, the differences between Kanban and Scrum are there to be seen but just like that golden nectar called blended whiskey from the Highlands of Scotland, mixing them together should be done carefully to give you something you can really appreciate.

What is the best way to achieve this blend in your project development? Well, think first about what projects your business are involved in and thus what mix you need. It is argued that whereas Kanban is preferable for those with widely varying priorities, Scrum suits those with relatively stable ones which are less likely to alter over time.

Think too about the people you’ve got working in your organization. Kanban in certain projects has a major advantage over Scrum in that it is quite easy to learn and understand, not requiring the training and experience of Scrum and not running the risk of leaning heavily on one person, the Scrum Master, who could end up being quite ineffective at his job. In contrast, the structured nature of Scrum is of benefit to an organization working on a project with more specific roles and procedures and with a certain accumulation of experience via past project development. Similarly, on the human side, the regularity and structure of meetings makes the whole process more transparent and keeps team members more accountable for their contribution and, debatably, more closely involved in everything that is going on. But, although those Daily Stand-Up Meetings and the other get-togethers in Scrum seem perfect, how easily can you make them work in your business?  

Kanban methods can and are used in many areas within Scrum environments to improve productivity, efficiency, cycle time and quality. Their application and customization help visualization and the flow of work particularly with tools such as the Kanban board. Scrum teams can use this tool, in particular, to complete prioritized tasks first because they can collectively decide on what is best from the visual cues it provides. It, in effect, adds another layer of visibility to a project.

One last point. To bring out the real aroma and flavor of a glass of Scotch whiskey, the experts don’t drink it neat or add ice rocks but pour in a tiny amount of cold mountain spring water. Think of what could be that final touch in the process if you decide to blend the best of Kanban and Scrum in your project. Which of the different elements will perfect the same result as that little bit of water?