Henrik Kniberg: Kanban vs Scrum

http://www.infoq.com/minibooks/kanban-scrum-minibook

David Anderson intro

• Visual control mechanism tracks work flow through stages of value stream. 
• Whiteboard with sticky notes, or electronic card wall system
• Best practice == do both
• Generates transparency that contributes to cultural change
• Exposes bottlenecks/queues/variability/waste – which impact performance of organization in terms of quantity of work delivered and cycle time required
• Changes behavior and encourages greater collaboration within the workplace
• Encourages discussion about improvements, and teams quickly start implementing improvements to their process.

Kanban in a nutshell

1. Visualize the workflow
• Split the work into pieces, write each item on a card and put on the wall.
• Use named columns to illustrate where each item is in the workflow.
2. Limit WIP – assign explicit limits to how many items may be in progress at each workflow state.
3. Measure lead time & optimize process to make lead time as small and predictable as possible
• lead time == average time to complete one item (“cycle time”)

On sliding scale from prescriptive to adaptive:

• Scrum is more prescriptive (iterations, cross-functional teams) than Kanban.  
• Kanban is more adaptive than Scrum

Roles not prescribed

• Doesn't mean you shouldn't have them
• But make sure they add value and don't conflict with other elements of process
• In a small project, unnecessary roles could lead to waste (or sub-optimisation & micromanagement)
• Less is more - start with less
• E.g. "Product Owner" == sets priorites of team

Timeboxes not prescribed - can choose any cadences necessary

• E.g. Single Cadence (Scrumlike)
• Plan & Commit every second Monday
• Demo/release every second Friday
• Retrospective every second Friday
• E.g. Three Cadences
• Every week release whatever is ready for release. 
• Every second week planning meeting and update our priorities/release plans. 
• Every fourth week retrospective to tweak and improve our process
• E.g. Event-driven
• Trigger planning meeting whenever start running out of stuff to do. 
• Trigger release whenever set of Minimum Marketable Features (MMFs) ready for release.
• Trigger spontaneous quality circle whenever bump into same problem second time. 
• Do in-depth retrospective every fourth week

Kanban limits WIP per workflow state (Scrum limits per iteration)

• Scrum limits WIP indirectly (theoretical max per column is max of iteration driven by velocity)
• Kanban limits WIP per column directly
• Choose what limit to apply to which workflow states
• Limit WIP of all workflow states
• Starting as early as possible and ending as late as possible along value stream
• E.g. consider adding WIP limit to “To do” state as well
• Once WIP limits in place, can start measuring/predicting lead time
• Allows to commit to SLAs & make realistic plans
• If item sizes vary, consider defining WIP limits in terms of story points/whatever unit you use. 
• Some teams break down items to roughly same size to reduce time spent estimating (estimation can be waste). 
• Easier to create smooth-flowing system if items are roughly equal-sized

Both are empirical

• You have to experiment with process and customize it to your environment.
• Scrum and Kanban just give you basic set of constraints to drive process improvement.
• Kanban says you should limit WIP. So what should the limit be? Don’t know, experiment
• Don't have knobs for Capacity/Lead Time/Quality/Predictability
• Do have indirect controls:
• Few people <-> Many people
• Few large teams <-> Many small teams
• Low WIP limits <-> High WIP limits
• No iterations <-> Long iterations
• Little planning <-> Lots of planning
• E.g. reduce WIP limit
• Then observe how Capacity/Lead Time/Quality/Predictability change
• Draw conclusions
• Change some more things
• Continuously improve
• CI = Kaizen, Inspect & Adapt, Empircal Process Control, Scientific Method
• Feedback loop == most critical element
• Scrum + XP loops: Sprint, Scrum, CI, UT, Pairing
• "Are we building the right stuff?" down to "are we building the stuff right?"
• Kanban: Should use all of the above
• Kanban adds useful real-time metrics:
• Average lead-time: Updated when item reaches "Done"
• Bottlenecks: E.g. Column X crammed with entries, X+1 empty
• With real-time metrics: Can choose length of feedback loops based on how often you want to analyse and make changes
• Too long: CI will be slow
• Too short: process might not have time to stabilise between each change == thrashing
• Can experiment with feedback loop itself (meta-feedback loop).
• E.g. Experimenting with WIP
• E.g. 4 person team, start with WIP of 1
• E.g. not feasible for all 4 to work on same item ==  people sitting idle (ok occasionally) == avg lead time increases
• items will get through “Ongoing” really fast once they get in, but they will be stuck in “To Do” longer than necessary, so the total lead time across the whole workflow will be unnecessarily high
• E.g. increase WIP to 8
• E.g. problems with integration server prevents cards from being "done"
• Cards start piling up in "Ongoing" as new work is taken on
• When WIP 8 is reached, must fix integration server - WIP limit prompted us to react and fix bottleneck instead of piling up unfinished work
• Good. But if WIP limit was 4 would have reacted earlier, giving better avg lead time. 
• It’s a balance. Measure avg lead time and keep optimizing WIP limits to optimize lead time
• Why need a "To-Do" column?
• Gives team a small buffer to pull work from in absence of customer
• Not needed if customer always available to tell team what to do

Kanban allows change within iteration

• Scrum wouldn't allow E to be added to A+B+C+D after committed to sprint.
• Kanban would allow it but say there's a limit to how many can be added to "To-Do" column so you have to choose to remove one
• E could be prioritised above other To-Do but work would only start on E once it can be pulled into "Ongoing" column
• Kanban reponse time (time to respond to a change of priorities) == however long takes for capacity to become available, “one item out = one item in” (driven by WIP limits).
• Scrum response time == avg half sprint length

Kanban board is persistent - doesn't need to be reset every iteration
Cross-functional teams are optional

• Board is related to workflow
• Board not necessarily owned by one team
• Establish some ground rules as to who uses the board and how then experiment to optimise flow
• E.g. Whole board served by one cross-functional team - like Scrum
• E.g. PO sets priorities in column 1
• Cross-functional dev team does dev (column 2) and test (column 3)
• Release (column 4) done by specialist team
• Slight overlap in competencies, so if release team becomes bottleneck one of the devs will help them

Items do not have to fit into a single iteration

• Kanban teams try to minimize lead time and level flow
• Indirectly creates incentive to break items into relatively small pieces
• No explicit rule stating that items must be small enough to fit into a specific time box
• Same board might have both items that take 1 month and 1 day

 Estimation is not prescribed

• If you need to make commitments you need to decide how to provide predictability
• Some teams make estimates and measure velocity just like Scrum
• Other teams skip estimation, but break each item into roughly same size pieces
• Can simply measure velocity in terms of how many items completed per unit of time (e.g. features per week)
• Some teams group items into MMFs (Minimum Marketable Features) and measure avg lead time per MMF, and use that to establish SLAs
• E.g. “when we commit to an MMF it will always be delivered within 15 days”
• Lots of interesting techniques for Kanban-style release planning and commitment management
• Best practices will emerge over time

Both allow working on multiple products simultaneously

• What if one team maintains multiple products? ("Team Backlog" instead of "Product Backlog")
• Merge both products into one list. 
• Forces us to prioritize between products, which is useful in some cases
• One strategy: focus on one product per sprint
• Other strategy: work on features from both products each sprint
• Distinguish with different colours
• Or separate horizontal swimlanes

Both are lean and agile

• Pull scheduling systems - JIT inventory management
• Based on continuous and empirical process improvement *
• Emphasize responding to change over following a plan (Kanban typically allows faster response than Scrum)

Kanban doesn't prescribe prioritised backlog

• Can choose any/none prioritisation scheme (don't need to prioritise in advance of timebox)
• Left-most column typically fills same purpose as backlog
• Need some kind of decision rule as to which to pull first:
• Top item
• Oldest item (each item needs timestamp)
• Any item
• 20% maintenance, 80% new features
• Split between product A and product B
• Red items first

Daily standups not prescribed

• Most Kanban teams do it anyway
• More board-oriented, focusing on bottlenecks/visible problems
• More scalable - can have 4 teams looking at same board - not everyone needs to speak as long as focus is on bottlenecks

Burndown charts not prescribed

• No charts prescribed but can use any you want
• Continuous Flow Diagram (CFD)
• Every day, total up items in each column and stack on Y axis
• E.g. day 4, there are 9 items == 1 Production, 1 Test, 2 Dev, and 5 Backlog
• Plot these points every day and connect the dots
• Vertical and horizontal arrows illustrate relationship between WIP and lead time. 
• Horizontal arrow shows that items added to backlog on day 4 took avg 6 days to reach production
• About half of that time was Test. 
• Can see that limiting WIP in Test and Backlog would significantly reduce total lead time
• Slope of dark-blue area shows velocity (i.e. number of items deployed per day). 
• Over time we can see how higher velocity reduces lead time, while higher WIP increases lead time.
• Most organizations want to get stuff done faster (= reduce lead time). 
• Many fall into trap of assuming this means getting more people in or working overtime. 
• Most effective way to get stuff done faster == smooth out flow and limit work to capacity, not add more people or work harder. 
• CFD shows why, and increases likelihood team & management will collaborate effectively
• Even more clear if distinguish between queuing states (such as “waiting for test”) and working states (such as “testing”). 
• Want to absolutely minimize number of items sitting around in queues, CFD helps provide right incentives for this

Scrum vs Kanban Example

• Sprint backlog == just one part of picture
• Why split “Dev” column into “Ongoing” and “Done”? 
• Gives production team chance to know which items they can pull into production.
• Why share "Dev" limit of 3 among the two sub-columns?
• Creates excess capacity
• Developers who could start a new item, but aren’t allowed to because of the Kanban limit.
• Gives strong incentive to focus efforts and help get stuff into production, to clear the “Done” column and maximize flow. 
• Nice and gradual effect – the more stuff in “Done”, the less stuff is allowed in “Ongoing” – helps the team focus on right things.
• One piece flow
• “perfect flow” scenario, where an item flows across the board without ever getting stuck in a queue. 
• At every moment there is somebody working on that item
• Can get rid of backlog and selected columns for a really short lead time
• Cory Ladas: “Ideal work planning process should always provide dev team with best thing to work on next, no more and no less”
• WIP limits are there to stop problems from getting out of hand - if things are flowing smoothly WIP limits aren’t really used

Questions

• Only thing that Kanban prescribes is that work flow is visual, and WIP is limited
• Purpose == create smooth flow through system and minimize lead time. 
• Need to regularly bring up questions such as:
• Which columns should we have?
• Each column represents:
• one workflow state
• a queue (buffer) between two workflow states
• Start simple and add columns as necessary
• What should the Kanban limits be?
• When the Kanban limit for “your” column has been reached and you don’t have anything to do, start looking for a bottleneck downstream (i.e. items piling up to the right on the board) and help fix the bottleneck. 
• No bottleneck == Kanban limit might be too low - reason for having limit was to reduce risk of feeding bottlenecks downstream. 
• Many items sit still for a long time without being worked on == Kanban limit might be too high
• Too low kanban limit => idle people => bad productivity 
• Too high kanban limit => idle tasks => bad lead time

* empirical process improvement 

• http://barryhawkins.com/blog/2012/04/13/empirical-process-control-why-scrum-works/
• Empirical process control provides and exercises control through frequent inspection and adaptation for processes that are imperfectly defined and generate unpredictable and unrepeatable outputs
• Requires three basic elements: 
• Transparency: ensures all elements in a process are openly observable
• Inspection: taking observation enabled by transparency and critically evaluating how work flows through the process (cross-functional team)
• Adaptation: takes insights gleaned from that inspection as basis for making incremental ongoing improvements to process