MTAT.03.094 Software Engineering Lecture 12: Lean & Flow-based (KANBAN) Principles and Processe Fall 2015 Dietmar Pfahl email: dietmar.pfahl@ut.ee
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?
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 process improvement. -- Can be event-driven instead of time-boxed. Commitment optional. Uses Lead time as default metric for planning and process improvement.
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) Estimation optional
Differences between Scrum and Kanban Cannot add items to ongoing iteration. A sprint backlog is owned by one specific team Can add new items whenever capacity is available A Kanban board may be shared by multiple teams or individuals Prescribes 3 roles (PO/SM/Team) A Scrum board is reset between each sprint Prescribes a prioritized product backlog 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 leadtime, 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 12 KANBAN Case Study: Scrum vs. KANBAN Lean Processes/Methods
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 Let s check again the data to see whether the conclusions are justified! Interruptions due to ad hoc-bug fixing, support and maintenance tasks
Lead Time (days) Bug PBI
? Lead Time (days) Bug Has the improvement already PBI happened in quarter 2009.4 (while scrum was used) and not only when Kanban was introduced?
# of weighted bugs # of blocking bugs
Productivity Bugs per developer PBIs per developer
Churn of bugs Churn of PBIs
Productivity 2 Churn (of Bugs) per developer Churn (of PBIs) per developer
Keep the following in mind...
Structure of Lecture 12 KANBAN Case Study: Scrum vs. KANBAN Lean Processes/Methods
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!