p. 1

[close]

p. 2

free online edition if you like the book please support the authors and infoq by purchasing the printed book http www.lulu.com/content/7731694 only $22.95 brought to you courtesy of this book is distributed for free on infoq.com if you have received this book from any other source then please support the authors and the publisher by registering on infoq.com visit the homepage for this book at http www.infoq.com/minibooks/kanbanscrum-minibook

[close]

p. 3

kanban and scrum making the most of both henrik kniberg mattias skarin forewords by mary poppendieck david anderson free online version support this work buy the print copy http www.infoq.com/minibooks/kanbanscrum-minibook

[close]

p. 4

© 2010 c4media inc all rights reserved c4media publisher of infoq.com this book is part of the infoq enterprise software development series of books for information or ordering of this or other infoq books please contact books@c4media.com no part of this publication may be reproduced stored in a retrieval system or transmitted in any form or by any means electronic mechanical photocopying recoding scanning or otherwise except as permitted under sections 107 or 108 of the 1976 united states copyright act without either the prior written permission of the publisher designations used by companies to distinguish their products are often claimed as trademarks in all instances where c4media inc is aware of a claim the product names appear in initial capital or all capital letters readers however should contact the appropriate companies for more complete information regarding trademarks and registration managing editor diana plesa cover art bistrian iosip composition accurance library of congress cataloguing-in-publication data isbn 978-0-557-13832-6 printed in the united states of america

[close]

p. 5

contents foreword by mary poppendieck v foreword by david anderson vii introduction xi part i ­ comparison 1 1 so what is scrum and kanban anyway 3 2 so how do scrum and kanban relate to each other 7 3 scrum prescribes roles 11 4 scrum prescribes timeboxed iterations 13 5 kanban limits wip per workflow state scrum limits wip per iteration 15 6 both are empirical 17 7 scrum resists change within an iteration 23 8 scrum board is reset between each iteration 25 9 scrum prescribes cross-functional teams 27 10 scrum backlog items must fit in a sprint 29 11 scrum prescribes estimation and velocity 31 12 both allow working on multiple products simultaneously 33 13 both are lean and agile 35 14 minor differences 37 15 scrum board vs kanban board ­ a less trivial example 41 16 summary of scrum vs kanban 49 part ii ­ case study 53 17 the nature of technical operations 55 18 why on earth change 57 19 where do we start 59 20 getting going 61 21 starting up the teams 63 22 addressing stakeholders 65 23 constructing the first board 67 24 setting the first work in progress limit 71 iii

[close]

p. 6

iv kanban and scrum making the most of both 25 honoring the wip limit 73 26 which tasks get on the board 75 27 how to estimate 77 28 so how did we work really 79 29 finding a planning concept that worked 83 30 what to measure 87 31 how things started to change 91 32 general lessons learned 97 final take-away points 101 about the authors 103 iv

[close]

p. 7

foreword by mary poppendieck henrik kniberg is one of those rare people who can extract the essence of a complicated situation sort out the core ideas from the incidental distractions and provide a crystal clear explanation that is incredibly easy to understand in this book henrik does a brilliant job of explaining the difference between scrum and kanban he makes it clear that these are just tools and what you really want to do is have a full toolkit understand the strengths and limitations of each tool and how to use them all in this book you will learn what kanban is all about its strengths and limitations and when to use it you will also get a good lesson on how and when to improve upon scrum or any other tool you may happen to be using henrik makes it clear that the important thing is not the tool you start with but the way you constantly improve your use of that tool and expand your toolset over time the second part of this book by mattias skarin makes the book even more effective by walking you through the application of scrum and kanban in a real life situation here you will see an example of how the tools were used both separately and in combination to improve a software development process you will notice that there isn t a single best way to do things you have to think for yourself and figure out ­ based on your situation ­ your next step toward better software development mary poppendieck v

[close]

p. 8

[close]

p. 9

foreword by david anderson kanban is based on a very simple idea work-in-progress should be limited and something new should be started only when an existing piece of work is delivered or pulled by a downstream function the kanban or signal card implies that a visual signal is produced to indicated that new work can be pulled because current work does not equal the agreed limit this doesn t sound very revolutionary nor does it sound like it would profoundly affect the performance culture capability and maturity of a team and its surrounding organization what s amazing is that it does kanban seems like such a small change and yet it changes everything about a business what we ve come to realize about kanban is that is an approach to change management it isn t an software development or project management lifecycle or process kanban is an approach to introducing change to an existing software development lifecycle or project management methodology the principle of kanban is that you start with whatever you are doing now you understand your current process by mapping the value stream and then you agree work-in-progress wip limits for each stage in that process you then start to flow work through the system by pulling it when kanban signals are generated kanban is proving useful to teams doing agile software development but equally it is gaining traction with teams taking a more traditional approach kanban is being introduced as part of a lean initiative to morph the culture of organizations and encourage continuous improvement because wip is limited in a kanban system anything that becomes blocked for any reason tends to clog up the system if enough work items become blocked the whole process grinds to a halt this has the effect of focusing the whole team and the wider organization on solving the problem unblocking the item and restoring flow vii

[close]

p. 10

viii kanban and scrum making the most of both kanban uses a visual control mechanism to track work as it flows through the various stages of the value stream typically a white board with sticky notes or an electronic card wall system is used the best practice is probably to do both the transparency that this generates also contributes to cultural change agile methods have been good about providing transparency into the work-in-progress and completed and reporting metrics such as velocity the quantity of work done in an iteration however kanban goes a step further and provides transparency into the process and its flow kanban exposes bottlenecks queues variability and waste all things which impact the performance of the organization in terms of the quantity of valuable work delivered and the cycle time required delivering it kanban provides team members and external stakeholders with visibility into the effect of their actions or inactions as such early case studies are showing that kanban changes behavior and encourages greater collaboration within the workplace the visibility into bottlenecks waste and variability and their impact also encourages discussion about improvements and teams quickly start implementing improvements to their process as a result kanban encourages incremental evolution of existing processes and evolution that is generally aligned with agile and lean values kanban does not ask for a sweeping revolution of how people work rather it encourages gradual change it s change that is understood and agreed by consensus amongst the workers and their collaborators kanban through the nature of the pull system also encourages delayed commitment on both prioritization of new work and delivery of existing work typically teams will agree a prioritization cadence to meet with upstream stakeholders and decide what to work on next these meetings can be held often because they are usually very short a very simple question has to be answered something like since our last meeting two slots have become free our current cycle time is 6 weeks to delivery which 2 things would you most like delivered 6 weeks from now this has a two-fold affect asking a simple question generally results in a good quality answer derived quickly and keeps the meeting short the nature of question means that commitment on what to work on is delayed until the last responsible moment this improves agility by managing expectations shortening cycle times from commitment to deliver and eliminating rework as the chance that priorities will change is minimized viii

[close]

p. 11

introduction ix one final word on kanban is that the effect of limiting wip provides predictability of cycle time and makes deliverables more reliable the stop the line approach to impediments and bugs also appears to encourage very high levels of quality and a rapid drop in rework while all of this will become evident from the wonderfully clear explanations in this book how we got here will remain opaque kanban was not conceived in a single afternoon through some incredible epiphany instead it emerged over several years many of the profound psychological and sociological affects that change the culture capability and maturity or organizations were never imagined rather they were discovered many of the results with kanban are counter-intuitive what appears to be a very mechanical approach ­ limit wip and pull work ­ actually has profound effects on people and how they interact and collaborate with one another i nor anyone else involved with kanban in the early days anticipated this i pursued what became kanban as an approach to change that would meet with minimal resistance this was clear to me as early as 2003 i also pursued it for the mechanical benefits as i was discovering through application of lean techniques around that time that if managing wip made sense then limiting it made more sense it took the management overhead out of managing it so in 2004 i decided to try implementing a pull system from first principles i got the opportunity when a manager at microsoft approached me and asked me to help him manage change on his team doing maintenance upgrades on internal it applications the first implementation was based on the theory of constraints pull system solution known as drum-buffer-rope it was a huge success cycle time dropped by 92 throughput increased by more than 3 times and predictability due date performance was a very acceptable 98 in 2005 donald reinertsen persuaded me to implement a full blown kanban system i got the opportunity in 2006 when i took charge of the software engineering department at corbis in seattle in 2007 i began to report the results the first presentation was at the lean new product development summit in chicago in may 2007 i followed this with an open space at agile 2007 in washington dc in august that year 25 people attended 3 of them were from yahoo aaron sanders karl scotland and joe arnold they went home to california india and the uk ix

[close]

p. 12

x kanban and scrum making the most of both and implemented kanban with their teams already struggling with scrum they also started a yahoo discussion group which at the time of writing has almost 800 members kanban was beginning to spread and early adopters were talking about their experiences now in 2009 kanban is really growing in adoption and more and more field reports are coming in we ve learned a lot about kanban in the past 5 years and we all continue to learn more every day i ve focused my own work on doing kanban writing about kanban speaking about kanban and thinking about kanban in order to better understand it and explain it to others i ve deliberately stepped back from comparing kanban to existing agile methods though some effort was spent in 2008 explaining why kanban deserved to be considered an agile compatible approach i ve left it to others with a wider experience to answer questions like how does kanban compare to scrum i am so glad that henrik kniberg and mattias skarin have emerged as leaders in this regard you the knowledge worker in the field need information in order to make informed decisions and move forward with your work henrik and mattias are serving your needs in a way that i never could i am particularly impressed with henrik s thoughtful approach to comparison and his factual and un-opinionated balanced delivery his cartoons and illustrations are particularly insightful and often save you reading many pages of text mattias field case study is important because it demonstrates that kanban is much more than theory and it shows you by example how it might be useful for you in your organization i hope that you enjoy this book comparing kanban with scrum and that it gives you greater insight into agile in general and both kanban and scrum in particular if you would like to learn more about kanban please visit our community web site the limited wip society http www.limitedwipsociety.org david j anderson sequim washington usa july 8th 2009 x

[close]

p. 13

introduction we don t normally write books we prefer spending our time deep in the trenches helping clients optimize debug and refactor their development process and organization we ve noticed a clear trend lately though and would like to share some thoughts on that here s a typical case · · · · · · · jim now we ve finally gone all-out scrum fred so how s it going jim well it s a lot better than what we had before fred but jim but you see we are a support maintenance team fred yes and jim well we love the whole thing about sorting priorities in a product backlog self-organizing teams daily scrums retrospectives etc · · · · fred so what s the problem jim we keep failing our sprints fred why jim because we find it hard to commit to a 2 week plan iterations don t make to much sense to us we just work on whatever is most urgent for today should we do 1 week iterations perhaps · fred could you commit to 1 week of work will you be allowed to focus and work in peace for 1 week xi

[close]

p. 14

xii kanban and scrum making the most of both · · · · · · · · · · · · · · jim not really we get issues popping up on a daily basis maybe if we did 1 day sprints fred do your issues take less than a day to fix jim no they sometimes take several days fred so 1-day sprints wouldn t work either have you considered ditching sprints entirely jim well frankly we would like that but isn t that against scrum fred scrum is just a tool you choose when and how to use it don t be a slave to it jim so what should we do then fred have you heard of kanban jim what s that what s the difference between that and scrum fred here read this book jim but i really like the rest of scrum though do i have to switch now fred no you can combine the techniques jim what how fred just read on xii

[close]

p. 15

introduction xiii purpose of this book if you re interested in agile software development you ve probably heard about scrum and you may also have heard about kanban a question that we hear more and more often is so what is kanban and how does it compare to scrum where do they complement each other are there any potential conflicts the purpose of this book is to clear up the fog so you can figure out how kanban and scrum might be useful in your environment let us know if we succeed xiii

[close]