MTAT.03.243 Software Engineering Management · MTAT.03.243 / Lecture 10 / © Dietmar Pfahl 2013 SCRUM vs. KANBAN Time-Boxing Task-Boxing

MTAT.03.243 / Lecture 10 / © Dietmar Pfahl 2013

MTAT.03.243

Software Engineering Management

Lecture 10:

Flow-based (KANBAN)

Principles and Processes

Dietmar Pfahl

email: [email protected] Spring 2013


Structure of Lecture 10

• Flow-based agile development (Kanban)

• A study of Scrum versus Kanban in a software company


SCRUM KANBAN vs.

Time-Boxing Task-Boxing


Time-boxing versus Task-boxing

• Scrum has sprints

(iterations) of 2-4 weeks.

But it is not always easy to

divide the tasks or features of

the systems to fit into such

time intervals

• What about instead

defining a set of tasks or

features and deliver when

finished?

SCRUM KANBAN vs.


Kanban –

a technique based on Lean Production

• Kanban focuses on:

– Flow of work items (throughput/velocity)

• that is, the number of features (user stories) implemented

per unit of time

– Lead-time (cycle time) = the time it takes to finish a user

story (work item)

KANBAN


From: Kanban and Scrum - making the most of both by Henrik Kniberg and Mattias Skarin on Dec 21, 2009

Kanban Board A Work Item represents a unit of work to be carried out by the development team

Describe a Work item on a post-it sheet and put it on a board in one of the

categories : ”To do”, ”In progress” or more detailed states. ”Done” shows the Work

Items that are finished


Scrum Board versus Kanban Board

From: Kanban and Scrum - making the most of both by Henrik Kniberg and Mattias Skarin on Dec 21, 2009

http://www.crisp.se/file-uploads/Kanban-vs-Scrum.pdf

Max WIP









What is the right WIP limit?


What’s the right WIP limit?

4


Differences between Scrum and Kanban (1)

• Time-boxed iterations

prescribed.

• Team commits to a specific

amount of work for this iteration.

• Uses Velocity as default metric

for planning and process

improvement.

• Time-boxed iterations

optional.

– Can have separate cadences

for planning, release, and

process improvement.

– Can be event-driven instead of

time-boxed.

• Commitment optional.

• Uses Lead time as default

metric for planning and process

improvement.


Team #1: (1 cadence) ”We do Scrum”

Team #2: (3 cadences) ”Every week, we release whatever is ready for release, every two weeks we have a planning meeting , ...”

Team #3: (event-driven) ”We trigger a planning meeting whenever we start running out of stuff to do. We trigger a release whenever there is a MMF (minimum marketable feature set) ready for release. We trigger a spontaneous quality circle whenever we bump into the same problem the second time. We also do a more in-depth retrospective every fourth week.”



• Cross-functional teams

prescribed. Cross-functional

teams optional.

• Items must be broken down so

they can be completed within 1

sprint.

• Burndown chart prescribed

• WIP limited indirectly (per

sprint)

• Estimation prescribed

• Cross-functional teams optional.

Specialist teams allowed

• No particular item size is

prescribed.

• No particular type of diagram is

prescribed

• WIP limited directly (per

workflow state)

• Estimation optional


Scrum

Kanban



• Cannot add items to ongoing

iteration.

• A sprint backlog is owned by

one specific team

• Prescribes 3 roles

(PO/SM/Team)

• A Scrum board is reset

between each sprint

• Prescribes a prioritized

product backlog

• Can add new items whenever

capacity is available

• A Kanban board may be

shared by multiple teams or

individuals

• Doesn’t prescribe any roles

• A Kanban board is persistent

• Prioritization is optional.


Similarities between Scrum and Kanban

• Both are Lean and Agile

• Both use pull scheduling

• Both limit WIP (but in different ways)

• Both use transparency to drive process improvement

• Both focus on delivering releasable software early and often

• Both are based on self-organizing teams

• Both require breaking the work into pieces

• In both, release plan is continuously optimized based on

empirical data (velocity / lead time)


RUP has over 30 roles, over 20 activities, and over 70 artifacts.

Visualize Your Workflow Limit Your WIP Use Lead-Time as default metric


Claimed Advantages of Kanban

• Process element becomes more visible

– Bottlenecks

– Queues

– Variability

• Then it becomes easier to focus on finishing tasks that hamper

the total flow instead of starting on new tasks that will pile up

• Can do agile development without focusing on time-boxing.

– Particularly suited for tasks regarding technical and user

support, where well-defined “sprints” may not be

appropriate


Questions

• Kanban claim: A fixed WIP (Work In Progress) will improve the

process quality.

– Will it help to reduce the number of active WIs in total or by

state?

• What’s the mutual relationship between lead-time, productivity

and quality?

• How does Kanban vs. Scrum perform with respect to lead-

time, productivity and quality?

• To get more insight, Sjøberg et al. ran a study at Software

Innovation:

Dag I.K. Sjøberg, Anders Johnsen and Jørgen Solberg: Quantifying the Effect of Using Kanban versus

Scrum: A Case Study. IEEE Software, Vol. 29, Nr. 5, side 47–53, Sep./Oct. 2012


Structure of Lecture 10

• Flow-based agile development (Kanban)

• A study of Scrum versus Kanban in a software company


From Scrum to Kanban in

Software Innovation (SI)

• Scrum from 2007

• Kanban from 2010 ->

• Why change to Kanban?

– Increase production

– Improve project and product quality

• Were the expectations met?

• Analysis of 12 000 work items over 3.5 years recorded in

Team Foundation Server (TFS)



Implementation of Scrum at SI

• Cross-functional teams

– the team contains all the skills needed to complete all the items in

the iteration

• Sprint planning meetings that included estimation of work

items using planning poker

• Daily standup meetings

• Sprints of three weeks

– shippable increments of code (fully tested) at the end of each sprint

– demos in the review meetings

• Status visible through automated reports and task boards for

all of the teams


Implementation of Kanban at SI

• When started on an item, attempt to let it flow until it is ready for release

at a satisfactory quality as soon as possible (fast delivery without

timeboxes)

• Limited number of work items in progress at the same time (WIP limit)

• If WIP limit reached, work will not start on a new item before another

one is finished (just-in-time)

• No cross-functional teams

• Abandoned start-up meetings with estimation of work items

• Still daily stand-up meetings

• Demos once or twice a week, regardless of the progress of the work

items being discussed


Variables in the study


Conclusions (as stated in paper)

• By replacing Scrum with Kanban, SI

– almost halved the lead time

– reduced the number of bugs by 10%

– improved productivity

• SI appears to benefit from using Kanban over Scrum

• Kanban should be considered by other companies that

have

– Difficulties with estimation

– Interruptions due to ad hoc-bug fixing, support and

maintenance tasks


Bug PBI

Lead Time (days)


# of weighted bugs # of blocking bugs


Bugs per developer PBIs per developer

Productivity


Churn of bugs Churn of PBIs


Productivity 2

Churn (of Bugs) per developer Churn (of PBIs) per developer


Keep the following in mind ...


Acknowledgements

Parts of this lecture are based on material from Dag Sjøberg’s

Lecture on KANBAN presented in September 2012 at the

University of Oslo


Next Lecture

• Topic:

– Start of Project Block – Lecture on Monday,

March 18, is mandatory

• For you to do:

– Finish Homework 3 – Submission Deadline is

tomorrow at 17:00 (sharp)

I will be traveling on March 14, thus won’t be able to access e-mail or Message Board!

Documents

MTAT.03.243 Software Engineering Management · MTAT.03.243 / Lecture 10 / © Dietmar Pfahl 2013 SCRUM vs. KANBAN Time-Boxing Task-Boxing