MTAT.03.243 Software Engineering Management Lecture 11: Flow-based (KANBAN) Principles and Processes Dietmar Pfahl Spring 2014 email: dietmar.pfahl@ut.ee
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 vs. KANBAN
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
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 From: Kanban and Scrum - making the most of both by Henrik Kniberg and Mattias Skarin on Dec 21, 2009
Scrum Board versus Kanban Board Max WIP 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
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.
Differences between Scrum and Kanban (2) Cross-functional teams prescribed. Cross-functional teams optional. Specialist teams allowed Items must be broken down so they can be completed within 1 sprint. Burndown chart prescribed WIP limited indirectly (per sprint) Estimation prescribed No particular item size is prescribed. No particular type of diagram is prescribed WIP limited directly (per workflow state) Estimation optional
Scrum Kanban
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.
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
Visualize Your Workflow Limit Your WIP Use Lead-Time as default metric RUP has over 30 roles, over 20 activities, and over 70 artifacts.
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 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 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...
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