MTAT.03.094 Software Engineering - ut...• By replacing Scrum with Kanban, SI – almost halved the...

MTAT.03.243 / Lecture 12 / © Dietmar Pfahl 2015

MTAT.03.094

Software Engineering

Lecture 12:

Lean & Flow-based

(KANBAN) Principles and

Processe Dietmar Pfahl

email: [email protected] Fall 2015


Structure of Lecture 12

• KANBAN

• Case Study: Scrum vs. KANBAN

• Lean Processes/Methods


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

Velocity Lead-Time


Time-boxing vs. Task-boxing

Scrum has sprints (iterations)

of 2-4 weeks (= time box)

But: it is not always easy to

divide the tasks or features of

the systems to fit into such

time intervals

What about instead limiting the

amount of tasks or features (=

task box) that can be worked

on concurrently and deliver

when finished?


Velocity vs. Lead-time

SCRUM focuses on:

• Flow of work items

(throughput/velocity) =

the number of features (user

stories, tasks, etc.)

implemented per unit of time

(with given workforce)

KANBAN focuses on:

• Lead-time (cycle time) =

the average time it takes to

finish a work item (from start to

end)


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”, ”Ongoing” or more detailed states. ”Done” shows the Work Items that are finished


Scrum Board versus Kanban Board


What is the right WIP limit?


Differences between Scrum and Kanban

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


-- Can be event-driven instead of

time-boxed.

Commitment optional.

Uses Lead time as default

metric for planning and




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



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, work flow is continuously optimized based on

empirical data (velocity / lead time)

• Both are Lean


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



• KANBAN




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



• KANBAN




Origins of

Lean Software Development

• Originates from Toyota Production System (TPS)

• Also called Just-In-Time system

• Post WWII Japanese automobile industry could not compete with U.S.

mass production systems

• Inspiration for TPS found in the 1950’s from U.S. supermarkets

• Customers could get what they wanted, when they wanted it and

shelves were refilled when items were about to run out.

• The concepts transferred to the domain of software engineering by

Mary and Tom Poppendieck (2003, 2007).


Main Goals of LEAN

1. All processes shall give value

• Remove everything that does not create value

2. Ensure good flow in the processes to avoid bottlenecks

and queues (-> work not piling up and waiting)

3. All activity shall be based on need (-> Pull)

• If there is no demand for a product or service, the related task is

unnecessary

4. Become a learning organization with focus on continuous

stepwise improvement

• Kaizen (= small change for the better)


Focus on reducing the activities that do not

create value

The approach to continuous improvement Focus on removing/reducing the activities that do not create value for our customers

Traditional approach Focus on the efficiency of the activities that create value for the customers


Seven Wastes of Software Development

• Handoffs. Passing the information/work to someone else, getting

information/work from someone else.

• Partially done work. Something that is not done. E.g. untested code,

undocumented or not maintained code.

• Task switching. How many other tasks people need to do. E.g. the amount of

projects done simultaneously.

• Delays. Waiting for something.

• Extra features. Something that is not really needed.

• Defects. Something that does not meet the targets, or is not what it is

supposed to be. E.g. software bugs, incorrectly implemented business

requirements.

• Relearning (waste of knowledge). E.g. forgetting decisions, re-trying

solutions already tried, the inability to utilize the knowledge of other people.


Next Week

• No Lectures

• Next lecture on Monday, April 13:

SPI & Empirical Methods - Part A

• For you to do:

• Finish and submit Homework 3 on time!

• WORK ON PROJECT!

MTAT.03.094 Software Engineering - ut...• By replacing Scrum with Kanban, SI – almost halved the...

Documents

Transcript of MTAT.03.094 Software Engineering - ut...• By replacing Scrum with Kanban, SI – almost halved the...