MTAT.03.243 / Lecture 12 / © Dietmar Pfahl 2015
MTAT.03.094
Software Engineering
Lecture 12:
Lean & Flow-based
(KANBAN) Principles and
Processe
Dietmar Pfahlemail: [email protected]
Structure of Lecture 12
• KANBAN
MTAT.03.243 / Lecture 12 / © Dietmar Pfahl 2015
Kanban (Jap.): literally ’signboard’ or ’billboard’
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
MTAT.03.243 / Lecture 12 / © Dietmar Pfahl 2015
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) =
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
MTAT.03.243 / Lecture 12 / © Dietmar Pfahl 2015
MTAT.03.243 / Lecture 12 / © Dietmar Pfahl 2015
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
process improvement.
-- Can be event-driven instead of time-boxed.
Commitment optional.
Uses Lead time as default
Differences between Scrum and Kanban
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)
Differences between Scrum and 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
MTAT.03.243 / Lecture 12 / © Dietmar Pfahl 2015
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)
MTAT.03.243 / Lecture 12 / © Dietmar Pfahl 2015
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
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:
MTAT.03.243 / Lecture 12 / © Dietmar Pfahl 2015
Structure of Lecture 12
• 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?
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
MTAT.03.243 / Lecture 12 / © Dietmar Pfahl 2015
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
MTAT.03.243 / Lecture 12 / © Dietmar Pfahl 2015
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
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 12 / © Dietmar Pfahl 2015
Bug
PBI
Bug
PBI
Lead Time (days)
?
MTAT.03.243 / Lecture 12 / © Dietmar Pfahl 2015
MTAT.03.243 / Lecture 12 / © Dietmar Pfahl 2015
Productivity 2
MTAT.03.243 / Lecture 12 / © Dietmar Pfahl 2015
Structure of Lecture 12
• KANBAN
MTAT.03.243 / Lecture 12 / © Dietmar Pfahl 2015
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.
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
MTAT.03.243 / Lecture 12 / © Dietmar Pfahl 2015
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
MTAT.03.243 / Lecture 12 / © Dietmar Pfahl 2015
