mtat.03.243 software engineering management...from: kanban and scrum - making the most of both by...

MTAT.03.243 / Lecture 11 / © Dietmar Pfahl 2014

MTAT.03.243

Software Engineering Management

Lecture 11:

Flow-based (KANBAN)

Principles and Processes

Dietmar Pfahl

email: [email protected] Spring 2014


Structure of Lecture 11

• Flow-based agile development (Kanban)

• A study of Scrum versus Kanban in a software company


Kanban (Jap.): literally ’signboard’ or ’billboard’


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.

• 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 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)

• Both are Lean and Agile


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 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 11

• 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


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

Let’s check again the data to see whether the conclusions are justified!


Bug PBI

Lead Time (days)


Bug PBI

Lead Time (days)

?

Has the improvement already happened in quarter 2009.4 (while scrum was used) and not only when Kanban was introduced?


# 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 ...


Next Lecture

• Topic:

– SPI & Empirical Methods - Part A

– Guest Lecture on Wednesday, April 2:

• Challenges of Implementing SCRUM in a Large Scale

Public Sector Project by Alar Huul (Nortal)

• For you to do:

– Finish Homework 3 – Submission Deadline is Monday,

March 31, at 17:00 (sharp)

– Work on Project

mtat.03.243 software engineering management...from: kanban and scrum - making the most of both by...

Documents