Post on 27-Apr-2020
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: dietmar.pfahl@ut.ee Spring 2014
MTAT.03.243 / Lecture 11 / © Dietmar Pfahl 2014
Structure of Lecture 11
• Flow-based agile development (Kanban)
• A study of Scrum versus Kanban in a software company
MTAT.03.243 / Lecture 11 / © Dietmar Pfahl 2014
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.
MTAT.03.243 / Lecture 11 / © Dietmar Pfahl 2014
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
MTAT.03.243 / Lecture 11 / © Dietmar Pfahl 2014
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
MTAT.03.243 / Lecture 11 / © Dietmar Pfahl 2014
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
MTAT.03.243 / Lecture 11 / © Dietmar Pfahl 2014
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.
MTAT.03.243 / Lecture 11 / © Dietmar Pfahl 2014
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.”
MTAT.03.243 / Lecture 11 / © Dietmar Pfahl 2014
Differences between Scrum and Kanban (2)
• 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
MTAT.03.243 / Lecture 11 / © Dietmar Pfahl 2014
Differences between Scrum and Kanban (3)
• 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.
MTAT.03.243 / Lecture 11 / © Dietmar Pfahl 2014
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
MTAT.03.243 / Lecture 11 / © Dietmar Pfahl 2014
RUP has over 30 roles, over 20 activities, and over 70 artifacts.
Visualize Your Workflow Limit Your WIP Use Lead-Time as default metric
MTAT.03.243 / Lecture 11 / © Dietmar Pfahl 2014
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
MTAT.03.243 / Lecture 11 / © Dietmar Pfahl 2014
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
MTAT.03.243 / Lecture 11 / © Dietmar Pfahl 2014
Structure of Lecture 11
• Flow-based agile development (Kanban)
• A study of Scrum versus Kanban in a software company
MTAT.03.243 / Lecture 11 / © Dietmar Pfahl 2014
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)
MTAT.03.243 / Lecture 11 / © Dietmar Pfahl 2014
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
MTAT.03.243 / Lecture 11 / © Dietmar Pfahl 2014
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
MTAT.03.243 / Lecture 11 / © Dietmar Pfahl 2014
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
MTAT.03.243 / Lecture 11 / © Dietmar Pfahl 2014
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!
MTAT.03.243 / Lecture 11 / © Dietmar Pfahl 2014
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?
MTAT.03.243 / Lecture 11 / © Dietmar Pfahl 2014
Productivity 2
Churn (of Bugs) per developer Churn (of PBIs) per developer
MTAT.03.243 / Lecture 11 / © Dietmar Pfahl 2014
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