Kanban for skeptics


Published on

1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Kanban for skeptics

  1. 1. Kanban for skepticsClear answers to Kanban in softwaredevelopment©2012 Nick OostvogelsThis version was published on 2012-08-25This is a Leanpub book, for sale at:http://leanpub.com/kanbanforskepticsLeanpub helps authors to self-publish in-progress ebooks.We call this idea Lean Publishing. To learn more aboutLean Publishing, go to: http://leanpub.com/manifestoTo learn more about Leanpub, go to: http://leanpub.com
  2. 2. Tweet This Book!Please help Nick Oostvogels by spreading the word aboutthis book on Twitter!The suggested hashtag for this book is #kanbanforskeptics.Find out what other people are saying about the book byclicking on this link to search for this hashtag on Twitter:https://twitter.com/search/#kanbanforskeptics
  3. 3. ContentsAcknowledgments iIntroduction ii1 What is Kanban? 12 We lose our ability to plan 4 2.1 Release planning . . . . . . . . . . . . . . 5 2.2 Re-planning . . . . . . . . . . . . . . . . 21 2.3 Summary . . . . . . . . . . . . . . . . . . 243 It will take longer 26 3.1 Parkinson’s law . . . . . . . . . . . . . . 26 3.2 A healthy balance in Kanban . . . . . . . 28 3.3 Theory of constraints for process improve- ment . . . . . . . . . . . . . . . . . . . . 29 3.4 Flow . . . . . . . . . . . . . . . . . . . . 31 3.5 One continuous sprint . . . . . . . . . . . 34 3.6 Summary . . . . . . . . . . . . . . . . . . 354 Things will get stuck, we can’t keep WIP limits 36 4.1 End to end flow efficiency . . . . . . . . . 36 4.2 WIP limits will always cause bottlenecks . 39 4.3 Collaboration - daily stand-up . . . . . . . 47 4.4 Summary . . . . . . . . . . . . . . . . . . 485 Stakeholders don’t care about feeding the flow 49 5.1 Ordering triggers business value . . . . . 49
  4. 4. CONTENTS 5.2 Building an MVP . . . . . . . . . . . . . . 51 5.3 Stakeholder collaboration . . . . . . . . . 53 5.4 Expectation management . . . . . . . . . 55 5.5 Summary . . . . . . . . . . . . . . . . . . 566 We will lose team cohesion 58 6.1 Tearing down walls . . . . . . . . . . . . 58 6.2 Finding a bigger purpose . . . . . . . . . . 60 6.3 Creative thinking . . . . . . . . . . . . . . 62 6.4 Participatory decision making . . . . . . . 63 6.5 Achievable goals . . . . . . . . . . . . . . 65 6.6 Summary . . . . . . . . . . . . . . . . . . 667 Summary 688 Extras 699 Software development is not manufacturing 70 9.1 Support teams . . . . . . . . . . . . . . . 71 9.2 Development teams . . . . . . . . . . . . 72 9.3 Summary . . . . . . . . . . . . . . . . . . 7510 Bibliography 76
  5. 5. AcknowledgmentsA special thanks goes to my wife, who makes it possiblefor me to spend all those long days learning and writing.That’s not easy, when you have three energetic kids run-ning around the house. The one thing that annoys me about most acknowledg-ments chapters is the long list of names which the authorswant to thank. Luckily, I wanted to publish the first version of thisbook fast, so I only have a few names to mention. A big thank you to Marcin Floryan and Jørn Hunskaarfor reviewing the book so quickly in an amazing level ofdetail! I felt it increased the quality significantly. Thanksto all others who are still reviewing at this moment: BarryO’Reilly, Daði Ingólfsson, Jef Cumps, Jørn Hunskaar, KrisPhilippaerts, Maarten Volders, Olaf Lewitz, Patrick Debois,Patrick Steyaert, Paul Klipp, Pawel Brodzinski and YvesHanoulle. I’m sure with your reviews, the next version willbe even better. Two names keep popping up when I think about thepeople who influenced me to start writing: Scott Berkunand Jurgen Appelo. The stories on their blogs and in theirbooks got me enthusiastic to start my own blog in 2009. Itwas scary at first, but has given me so much satisfaction inthe past years, I can’t even start to explain. Thanks for theinspiration! The cover image¹ is taken by Jacob Bøtter and pub-lished under the Creative Commons license. ¹http://www.flickr.com/photos/jakecaptive/3205277810/ i
  6. 6. IntroductionIn my daily job as a change agent, I constantly need toreassure people that the path we follow is worthwhile trav-eling. This need is often expressed in the form of critiqueand difficult questions. When I coach Agile teams, this isoften the case. The same thing happens when introducingKanban. However, I noticed that Kanban raises muchharder questions on a management and leadership level,once people are introduced to the basics and start to explorethe subject on their own. The type of questions Kanban raises, seem to be hardto answer without lapsing into an hour long discussion.I guess this is normal because Kanban is much less pre-scriptive than Scrum, for instance. In order to providereassurance, as a coach, you need to trace the questionsall the way back to the principles of Kanban, which aregrounded in Lean thinking. By listing the 5 most common arguments against Kan-ban and my response to them, I hope to help people intheir Kanban journey and build great organizations thatcreate amazing products. These answers are based on myown perspective and experience. It would be great to hearyour answers and improve the book while more people areintroduced to Kanban. The goal is not to explain Kanbanscientifically, but provide insights why these argumentsdon’t stand, in a language that is understandable by all. ii
  7. 7. 1 What is Kanban?If you mention the term kanban in an industrial setting,people will explain that it’s a signboard which helps tofacilitate a Just In Time production process. A kanban cardis a token that is used to order a new part as soon as oneis used in the process step. This creates a pull requestthat will ripple all the way up trough the process. Theeasiest example can be seen in a department store, wherethe purchase of a carton of milk can lead to a signal toorder a new one. The major difference lies in the fact thatcustomer demand is triggering the process (pull), instead ofrunning it by forecasting (push). When Kanban (with a “K”) is used in the field ofsoftware engineering, it is used in a much broader sense.Kanban is a change management approach that employs aWIP limited pull system. For me it is an approach to changeyour process into one that focuses on end to end value andreliably delivering stuff, with high quality. The limited setof rules and principles help people focus on customer valueand avoid building up half finished work, which is still acommon issue in the software industry. LimiteWipSociety.org has a nice description of Kanban:first follow the foundational principles • Start with what you do now • Agree to pursue incremental, evolutionary change • Initially, respect current roles, responsibilities & job titles 1
  8. 8. What is Kanban? 2 then adopt the core practices 1. Visualize workflow 2. Limit Work In Progress 3. Manage Flow 4. Make Process Policies Explicit 5. Improve Collaboratively (using models/scientific method) These few principles prove to be a very powerful foun-dation for an organization that drastically wants to im-prove its value stream. Why is Kanban a change management approach andnot a process? Simply because it doesn’t prescribe howyou manage your process in practice. All it does is changethe rules that help your teams to focus more on end toend efficiency and quality. Because in the end, the onlything that defines success at an organizational level is yourcustomer base. They don’t care about your highly skilledroles, all they want is a quality product that is delivered intime. Roles or practices lead to change in the organization,no matter how broad their impact is. But because Kanbanis not a process, people will perceive the change differently.In practice, the way they work won’t change much in thebeginning. The only thing they will feel in their day today job are the principles that employ a WIP limited pullsystem. This will slowly introduce different behavior andcontinuous improvement.So think of Kanban as much more than a task board with
  9. 9. What is Kanban? 3cards and WIP limits. It facilitates organizational changein order to better satisfy your customers. This is veryambitious, but something most of us care about and canbring up the energy for!
  10. 10. 2 We lose our ability to planThe most popular criticism on Kanban is that it makesthings impossible to plan. It is a natural argument to make,when you discover that features entering a Kanban floware not estimated, but measured. Think about the shock for a moment! For years wehave managed our projects and people with the use ofestimates. We have spent ages detailing out requirementsand estimating them. There are people who specializedin estimating software features. Entire books have beenwritten on how to do this better and faster. And nowthis Kanban thing is telling me it’s no longer necessary!Yeah right, this must be another process created by lazydevelopers who refuse to estimate and take accountability.Why don’t we just let them do whatever they like! You see, planning serves two purposes. First of all,most customers need a date on which they can expect theproduct to be delivered. In some businesses, this date hasto be more accurate than others. For instance, a car will bedelivered near the end of april, but a tunnel repair must befinished at June the 5th. Secondly, a plan is a tool for managing people. It mightnot be the best tool, but managers have used plans for agesto control their employees. “You said it would be finishedby June the 5th, you’d better crank it up a notch if youwant to make it.” In combination with extrinsic motivators(like bonuses or fear of unemployment) a plan has been 4
  11. 11. We lose our ability to plan 5the central project management tool for centuries. Let itcome as no surprise that Kanban faces huge obstacles inmainstream management thinking. Let’s take a look ifKanban actually does make it impossible for us to plan. 2.1 Release planningA typical software development release plan is created atthe start of project. The most senior people of the team takethe time to carefully examine the specifications which havebeen sent to them through mail, by a potential customer.These folks have done this exercise a lot of times, but stillit feels awkward every time. They start categorizing the requirements and splittingthem into smaller chunks. At the same time, a technicalarchitecture is created which matches the demands of thesystem. The analysts start translating the customer re-quirements into a format that is understood by developers.A couple of weeks later the entire specification set is beingtransformed into formal requirements and sent to a seniordeveloper who estimates the entire collection. Off course summing up the estimates is quite discom-forting, when they realize their potential customer willnever agree on such a big price. So they gather aroundthe table once more and try to find ways to cut down theestimates. The senior developer argues that the estimateswere already optimistic, but he folds under pressure of hissuperiors and reduces the estimates. After some final com-mercial negotiations, both parties agree on the contract.
  12. 12. We lose our ability to plan 6 At this point we have a release plan, based on estimates,which will become the focus of a lot of people, in the nottoo distant future. This seems like a normal approach. Thecustomer wants something from you, you ask him aboutthe details, he asks you how much it costs and when hewill get it. Supply and demand in its most basic form, right?This works quite well when you can rely on a repeatableprocess, like building a car. At the point when you order anew one, the car company has already produced thousandsof them. They have tuned their assembly lines and can giveyou a pretty decent estimate of the delivery date. This isbecause they know how many cars are being produced atthe moment, how long it will take until your car gets onthe assembly line and because they know how long it takesto produce one car. It is repeated over and over again untilthat line is retired. When we try to do this with a custom piece of software,things are quite different. At the point when you order anew system, the development company, in most cases, hasnever built a similar system. But still they treat it like acar manufacturer would. However, instead of estimatingthe work based on measurements, it’s based on guesses.You might argue that experienced developers are good atestimating, because they have many years of experience inthe trade. Maybe, but it remains a guess because they donot have any knowledge about the future. Their experiencecan only make it a more educated guess. To make it even more depressing, software develop-ment is a human trade, a creative process, which makes iteven harder to predict. We’ve all been part of a team where
  13. 13. We lose our ability to plan 7small variations in behavior cause unpredicted results. Forinstance, when a conflict between two team memberscause them to stop speaking to each other resulting in lesscooperation and a delay in schedule. Your plan is thatfragile! A sneeze could theoretically (and physically) messup your entire project. MeasuringLet’s forget about this release plan for a moment and tryto look at things bottom up. A car manufacturer can tellme with good accuracy when my new car will be ready.Remember that they can give this information only becausethey measure how long it takes to produce a car. Thanks tothe repeatable nature of car assembly, these measurementsare an effective tool to provide fairly good estimates. The Kanban method starts from that angle as well.Instead of trying to build a release plan top down basedon estimates, Kanban teams base their plans and actionson measurements. Like measuring the construction timeof a car, the time it takes a feature to move trough the flowis measured in Kanban.
  14. 14. We lose our ability to plan 8 Measuring flow from point A to B If we can measure how long it takes for a feature tomove from point A to point B, we can use that informationto provide good estimates to our customers. The calculation is simple. How many features arewaiting in front of it in the queue? Multiply that by thetime a feature takes to get from point A to point B andyou’ve got yourself an estimate. Here we are calculatingthe lead time of my new feature. But if our Kanban flowhas a throughput of 2 features, then our lead time will onlybe half that long, since our queue will empty twice as fast. Sounds too good to be true, right? I hear you thinking : “How can I work on an order frommy customer and give him an offer by using measurements,when the project has not even started?” Well that’s easy,you can’t! You can’t without estimating your features.And we’re back to square one…. Not completely! Thereare 2 easy ways to do this without falling into the trap of
  15. 15. We lose our ability to plan 9estimating and using the power of measuring. 1. Use a scale 2. Keep your features small Using a scaleHumans are quite bad in coming up with precise estima-tions, but we are pretty good at comparing one thing toanother. I always use the following example: When I haveto drive to a new place for the first time, I have to guesshow long it would take me. Coming up with this numberfrom the top of my head is impossible, even if I know thedistance. So I start looking for references. Is there anythingsimilar I’ve already driven too? Let’s say I had to drive toMechelen, which is further than Antwerp, but closer thanBrussels. Lucky for me I’ve driven thousands of times toAntwerp and Brussels, so I have some points of referenceto start my comparison. Mechelen happens to be half waybetween Antwerp and Brussels.
  16. 16. We lose our ability to plan 10 Estimating a drive from home to Mechelen At that point I’ve placed Mechelen on my experience(or measurements) based scale. Today an Antwerp point onmy scale equals 45 minutes. It used to be less when trafficwas still ok, but that’s the beauty of measuring, it’s alwaysreflecting reality. Without having ever driven to Mechelen,I can now come up with a relative estimate, just by puttingit on my scale. A scale that makes sure my estimate is basedon reality, and will therefore be quite accurate. Now what
  17. 17. We lose our ability to plan 11kind of scale could we use for software features? It doesn’treally matter. Whether you use t-shirt sizes, story points,letters or fruit types, the point is that a scale helps you tosize features without having to care about the amount ittakes to deliver them. This keeps you away from the releaseplanning issues we’ve seen before. Everybody can comparefeatures, right? Some are smaller or easier than others, youmight have big features, or medium ones. Once you’ve placed your features on a scale, you cancalculate the time it will take to deliver them, if you havemeasurements. You can pretty easily come up with anaverage time it will take for each point on your scale tomove through the flow. Just be aware that you’re stillmaneuvering in the dark, until you have your first set ofmeasurements. And of course building software featuresis much more variable by nature than building cars. We’llsee later how to address this. In an environment where you have mutual trust be-tween you and the customer, it’s in both parties bestinterest to wait for the first measurements. We both knowthat in software development, reality is always differentthan what we expected. If you’re in fixed price setting,you might want to start with a first short term contract inwhich the goal is to get a set of measurements. Both partiescan then decide whether the project is still interesting. Ifthe outcome looks bad, at least you know fast enough tostop wasting any more budget.
  18. 18. We lose our ability to plan 12 Keeping your features smallBy splitting your features until they all fit a certain size,you can benefit from statistics. Let’s say we pick one feature as a reference point andwe try to size all other features in a way that they are neverbigger than our reference. This is even easier than puttingthem on a scale. The result is you end up with a goodnumber of features. And this is where you will benefit fromstatistics, more specifically the law of large numbers. Let’slook at an example. Suppose the yellow post-its are featureswe have distilled from our customer’s requirements. Large features waiting We feel there is a lot of difference in size & complexityof these features. Our next step is to split them up until theyfeel like they could fit into ‘a couple days of work’ (don’tjust think of this as a day of programming, also includeother steps you need to perform to deliver the feature). Useyour gut feeling during this exercise. There’s no point in
  19. 19. We lose our ability to plan 13discussing how the features will be implemented, right nowyou’re just sizing the list of user needs. This is what we endup with, almost 3 times the number of features. Splitting features Planning with measurementsYou can now create a release plan based on the lengthof your flow, the number of features and the throughput.How the hell can this be accurate, you ask?Well, lets look at what the law of large numbers tells us. In probability theory, the law of large numbers is atheorem that describes the result of performing the sameexperiment a large number of times. According to the law,the average of the results obtained from a large number oftrials should be close to the expected value, and will tendto become closer as more trials are performed. When youdo the exercise by rolling a dice, the more time you roll it,the closer the average will get to the average of the pointson the dice (which is 3.5). If you keep your features under
  20. 20. We lose our ability to plan 14a certain average, the more features that pass trough theflow, the closer you will come to that average. Would we see this behavior with our initial set offeatures? What’s the point of splitting them into smallerpieces? There are two reasons. The exercise of splitting them up forces you to get betterinformed about the content of the feature.You need to get a little deeper into the needs of the userto be able to find a way to split it. This increases yourknowledge and reduces errors in judgement without goingall the way into an up-front detailed analysis. You end up with more features which is important forthe law of large numbers to have an effect.The more points to measure, the better the law of largenumbers will average your results. By keeping the upperlimit low, the variation in lead times of different featureswon’t annoy anyone and you can just use the average toplan. When you think about this, Kanban is even moreappropriate to manage large projects. Remember thoseprojects that make the news because budgets trippled andget delayed by years? The size of their scope is so largethat they often work with large teams and vast timings.Remember that a sneeze can theoretically mess up yourproject, then risk gets exponentially higher because ofthe larger number of people involved and the multi-yearplanning. Instead you could try another approach. Leavethe master-plan behind, split a first set of your features andmeasure the flow. Chances are much better you will soonreach a point where a first version can be released, and
  21. 21. We lose our ability to plan 15you’re able to tell your stakeholders when! Reduce variationA critical success factor for Kanban which many tend toforget is reducing variation. Implementing a pull systemwill lead to a continuous flow. And this means that it needsto provide value in a regular cadence, for these reasons: 1. Working with averages is only comfortable with lim- ited variation. If you’re keeping features small, you have to reduce the number of times a feature takes much longer than the average to travel through the system. Otherwise, even if it’s only psychological, you will be pulled back to the estimation game, solely because a perception grows that the system in not reliable and estimations are needed to assess the difference. 2. The benefit of a continuous flow for many stakehold- ers is its fast response. You’re able to re-prioritize the queue at any time. Whenever an urgent request gets in, you can consider moving it to the top position of the queue. The natural reaction would be to get hold of a team member, make him stop whatever he’s working on and give him the new assignment. But we know that this carries a great cost. Con- text switching, parking half finished work, lack of personal motivation,… all lead to waste. In Kanban we respect rules that prevent this behavior, but only when we can rely on its promises. When I come with
  22. 22. We lose our ability to plan 16 an urgent request, and I know the team takes a new feature from the queue every 4 hours, I can make a conscious decision about prioritization. If I cannot rely on this, because of variation, the system will not hold and you will quickly fall back into old habits. 3. Big variation in lead and cycle times indicates a flow that is not under control. It’s easy to feed a flow and measure the outcomes. Any team is able to switch to this model without big effort. But then the only thing you’ve done is visualizing your process and defined some extra rules, like work in progress limits. The point of introducing WIP limits is to start the evolution to a continuous flow that is consistent and delivers value on a regular basis at a speed that matches the needs of your organization. To be able to do this, your flow needs to be continuous. It needs to be reliable with limited variation (I’m not saying NO variation) because that’s one of the indicators that you’ve improved your process and have it under control. 4. Continuous improvement is only effective in a stable process. The strength of Kanban lies in it’s focus on evolution. There is no manual you can use to get started. There are only a few ground rules that help you evolve your own Kanban system, in your own organization, with it’s own difficulties and culture. These ground rules stimulate everybody involved inthe process to think about improvement. In order to be able
  23. 23. We lose our ability to plan 17to evaluate process improvements, you need to comparemeasurements. Ex. “What effect did the lower WIP limitshave on our cycle time?”. It is hard to draw any conclusionsif your flow behaves like a crazy rabbit. Any change yousee in the new measurements can be a coincidence. Youmight even see the opposite to what you were expectingwhich make you draw the wrong conclusions. That’s whya first step in continuous improvement should be to reducevariation. As soon as your flow is delivering consistently,you can start to initiate improvements and work towardsa Kanban system that matches the expectations of theorganization and customers. Small releasesMany people think Kanban goes hand in hand with con-tinuous deployment. It doesn’t! Continuous deploymentwill lead to a Kanban-like process, due to the nature of it’srhythm. If you’re deploying one feature at a time, workingwith large batches makes no sense. It might be that themiddle part of your flow contains batch-like stages due tobottlenecks, but the input and output will come close to aone piece flow.
  24. 24. We lose our ability to plan 18 One piece flow at input and output A Kanban flow doesn’t necessarily need continuousdeployment. In many organizations, this is a model theyare not able to achieve yet. Others don’t see the benefit.They need a full set of features before they can releasesomething to their users. It’s not an easy task, finding theright set of features that need to be in your first release.Product managers often get tempted to include a few toomany. This is related to the uncertainty of a productlaunch. “Will people like our new product? Maybe weshould include these 5 features too, just to be sure.” Fact isthat increasing the size of your first version carries a greatrisk. The risk of spending too much resources on the wrongthing. You can test your product with 1000 people in focusgroups, distribute surveys, etc, but still fail to gain marketshare when you go live. Why not keep your first versionsmall, spend a modest amount of resources and find outquickly if your product has a future? Eric Ries explainsthis concept in his book ‘The Lean Startup’.
  25. 25. We lose our ability to plan 19 This is where Kanban is a great match. Pull yourfeatures one at a time and release your first minimal set.If the reaction of your users is promising, continue to addfeatures on a regular basis, by pulling them into the Kanbanflow. This way your return on investment starts wayearlier, which will catch the interest of your CFO. Minimal versions moving through the flow “But won’t this annoy our customers? Having toupdate every couple of days?” I think we can all relate tothis. Getting these bloody updates imposed, which messup your entire system… In recent years, another type of update approach hasappeared. Hip new online applications releasing newversions each day, often without the knowledge of theirusers. I believe this is an approach that has great potential,
  26. 26. We lose our ability to plan 20for these reasons: 1. It doesn’t annoy your users. These update are so small, that you hardly even notice them. Each day a small part of the application changes, which you probably notice, but never think about. You are actually changing with the application and start using new features without even realizing it. 2. The risk of bugs is lower. By keeping releases small, they can be easily tested. You can do an impact analysis and focus on the impacted areas of the application and test them thoroughly while the rest of the application is tested by a set of standard regression tests. 3. Releasing early creates a sense of urgency. As long as the product is in development, you’re living in a safe little cloud. Exposure to the outside world is limited in the form of occasional demo’s and maybe some marketing material. Your biggest concerns are com- pany related, in the form of internal politics, team dysfunctions, budget wars,… As long as your product hasn’t been launched, these are serious threats to a successful release. A lot of projects get cancelled after having spent a considerable amount of time and budget. This threat disappears almost entirely when the first release is on the market. Suddenly other concerns start to surface instead of internal company issues. Things like bug-fixing, support, customization, professional services and sales swipe
  27. 27. We lose our ability to plan 21 the old concerns right off the table. To summarize it, you can finally start the real work! 2.2 Re-planningWe’ve seen how you can plan a release in Kanban, butplanning doesn’t stop there. Once things are moving, weneed to continuously re-plan, whether we’re doing Agile,Waterfall or Kanban. Agile has its iteration planning,Waterfall has its status meetings and change control pro-cedures, how does this work in Kanban? Well actually, it’s entirely your choice. You can decidewhich approach works best in your organization. Here area few examples. Re-prioritizing the input queueIt’s the input queue that’s feeding the process. Prioritiesset in the input queue determine how quickly a feature willbe delivered to the customer. So suppose you have a newfeature that needs to be delivered as fast as possible, whatdo you do? It’s important to look at the input queue and not blindlyinsert the new feature at the top. Prioritization in Kanbanlooks easy, but can have serious consequences when donewithout serious thought. If urgent requests always getinserted at the top of the queue, you are endangering yourproduct vision and constantly changing course. You’ll endup with happy customers in the short term but limitedfuture for your product in the long term.
  28. 28. We lose our ability to plan 22 That’s why it’s important to create prioritization ruleson which you can rely when pressure is high. There areseveral questions your prioritization rules must be able toanswer: 1. How much % of our capacity do we want to invest in development of the product? 2. How much % do we want to invest in specific cus- tomer requests? 3. How much % do we want to invest in technical requests? 4. What priority get the different categories of bugs? I’m sure you have some other, specific to your situation.Think about the tension between short and long term. Bycomparing the current reality and the road ahead, you canmake a conscious decision on how you want to use yourpeople and find the right balance.Without a clear set of rules on which all stakeholders canagree, prioritization will lead to many discussions in whichthe loudest voice will often determine the result. CadenceKanban is based on continuous flow, but this doesn’t meanyou can’t have iterations. If we think about an iteration asa heartbeat, a synchronization moment, then this can beapplied to a continuous flow as well.
  29. 29. We lose our ability to plan 23 Many organizations find it useful to have a fixed mo-ment every x weeks to demo the new features that havebeen developed. Most of the times, this is related topractical issues, when not all stakeholders are flexibleenough to evaluate each individual feature that is waitingfor feedback. Together with the demo cadence, they take this oppor-tunity to evaluate the remaining items in the queue, sinceall stakeholders are present anyway. Because prioritization is really important, and featureshave different requesters, they must reach an agreement onpriority together. This is also the moment when feedbackfrom the demo gets its way into the queue.Be aware that this will introduce a larger batch size intoyour Kanban flow, since features are queueing in one of thelast workflow stages waiting for a demo and acceptance.The same remark applies to the prioritization of the inputqueue which no longer happens each day, but every xweeks. Pulling a planning meetingSome teams prefer to plan a number of features togetherinstead of doing them one by one. Reasons are often relatedto knowledge sharing, where the input of the entire teamhas higher value than they would get if planning a featurewith a limited number of people. Sometimes it’s a first stepto move from an iterative process to a continuous flow. The process goes as follows. A queue has been intro-duced right after the input queue for development. This
  30. 30. We lose our ability to plan 24ready queue has a limit, depending on the size of thedevelopment team. Whenever the ready queue gets empty,they pull a planning meeting with the entire team. This iswhere they take the next items of the input queue and talkthem over with the team. You can compare this with anaverage sprint planning meeting, where a product ownerexplains the next set of features. The team discusses andasks questions until they are comfortable to start breakingthem up into tasks. Complex features may require somedesign decisions, others don’t. At the end of the meetingthe team has filled their ready queue, which becomes theirfocus for a next period in time, until it empties, after whichthey pull another planning meeting. 2.3 SummaryAs you notice by the length of this chapter, there is noeasy answer to the argument ‘We lose our ability to plan”.Remember the main points, classified in 2 parts, releaseplanning and re-planning. This gives you two big parts inyour answer. Release planning is still possible by measuring insteadof estimating. You get the ability to pursue small releasesthat can have major advantages by reducing risk and get-ting faster feedback. By reducing variation and continuousimprovement, release planning will become easier andmore reliable. Instead of drawing a perfect world, we usereality to make better decisions. Re-planning is wide openin Kanban. You can choose to work with a cadence or be
  31. 31. We lose our ability to plan 25even more adaptable by constantly reevaluating the orderof the input queue. But remember, with great flexibilitycomes great responsibility. Re-arranging needs to be doneconsciously, in agreement with all stakeholders, by usinga clear set of rules which are distilled by the needs of theorganization and its customers.
  32. 32. 3 It will take longerA second popular argument against Kanban is that it willtake longer to create the product. This reasoning is deeplyentrenched in our everyday life. It is related to our edu-cation and how business have been managed for centuries.We’ve seen that Kanban focuses on using real data to makedecisions. By measuring flow we manage our people andproduct. This is completely upside down to what we’re usedto. Managers have learned to control their workers byassigning work and monitoring their performance. You geta task and get it finished on time or you have to justifywhy you didn’t make it on time. The same approachis taught in schools. Students get an assignment with adeadline, which needs to be finished on time or they’llfeel the consequences through punishment in the form oflower grades. How many times did you get an assignmentwithout a deadline? “This is what I’d like you to do,don’t worry about the timing, we’ll measure afterwards.”Let’s find out how Kanban uses measurements as a coremanagement tool without losing focus. 3.1 Parkinson’s law“The amount of time which one has to perform a taskis the amount of time it will take to complete the task.”Many people act by this simple definition. If we don’tset any deadlines, a worker will take much more timeto complete the task. He will relax and start working 26
  33. 33. It will take longer 27whenever he feels like it. Time is money, so we can’t allowthis, right? It has been done like this for decades in theworld of project management. A project plan is createdby the project manager and senior developer. Based onestimates, a schedule and timing is created which becomesthe target for a development team, whether realistic or not.The reasoning is quite simple, the team needs a deadlineto keep focused. The project manager will add some bufferin his own plan, just in case the team doesn’t make it. Butthen at least they will make it for 90 percent. Without thisfocus they might not even reach 50 percent… Simply from a cost perspective, this is a good approach.From a value perspective, this is a bad approach. Becausewhat happens when people get stressed? They cut corners,try to do more in less time and introduce malfunctionsby sloppy work. From an HR perspective this is also abad approach. People get overworked, stressed out andleave the company if the external pressure is too high. Yourealize that there needs to be a balance between freedomand control. A first step in project management was toinclude the team in estimating the project plan. This gavethem a first voice in the management side of the project andresulted in an increase in intrinsic motivation. Later withagile development, a next step was taken by measuringwhat a team could deliver in an iteration and using thosenumbers to plan instead of pushing for an initial estimate.This led to a significant increase in value creation andquality. How does Kanban deal with keeping a healthyfocus between control and freedom?
  34. 34. It will take longer 28 3.2 A healthy balance in KanbanIn a Kanban flow, team members pull new features froman ordered input queue. In many cases these features arenot estimated up front. At most they are sized on a scale.Measuring flow is the main management tool that is usedto control efficiency. By continuously monitoring lead andcycle time, we get a good idea about the progress of theteam. These numbers become a target for each contributorto the flow. If the average cycle time is 5 days at a certainpoint in time, the team will indirectly focus on this numberwhen starting on a new feature. The beauty in this approach is that it’s founded on realdata, not wishful thinking. If it takes 5 days to deliver a newfeature, chances are high that it will take approximately 5days for another feature. The focus is not created externallyby management, but it has evolved from within the team.Therefore they will be more intrinsically motivated topursue it. People will have to cut less corners and willdeliver more valuable and high quality features. From a management point of view, the style changesfrom command and control to helping the team to improve.Accepting that the system can deliver a new feature in5 days is accepting reality. From that point all involvedin the Kanban flow can start the process of continuousimprovement. Everybody is responsible to think about howwe can improve flow, reduce bottlenecks and variation.Soon your average lead & cycle times will change, alongwith the focus of the team. Their new focus will be arealistic one since it is based on real measurements on an
  35. 35. It will take longer 29improved flow. I found it very useful to keep the theory of constraintsin mind when trying to improve your Kanban flow. 3.3 Theory of constraints for process improvementThe theory of constraints (TOC) is a management philoso-phy introduced by Eliyahu Goldratt in his 1984 book¹ titled“The Goal”. It is based on the idea that “A chain is nostronger than its weakest link”. If we project this to Kanban,this means that the weakest stage in the flow will determinethe rate of value creation of the entire system. For instance, if we notice that the user acceptancetesting stage can’t keep up with the preceding stages, it willslow down output of the entire Kanban flow to it’s owncapability. ¹http://www.amazon.com/The-Goal-Process-Ongoing-Improvement/dp/0884270610
  36. 36. It will take longer 30 The Acceptance stage as a constraint By visualizing work on a Kanban board, the TOC willbecome visible in the form of bottlenecks that block thesystem. During the course of their work the team will alsofeel the TOC trough the use of WIP limits. For instanceif we’ve decide to start with a WIP limit of 3 on the UATcolumn, this means that no more features can be startedin the preceding stages if the UAT column if full. You canimagine that this can become quite frustrating. Most of usare eager to start a new task, especially when we’re tryingto get a release out of the door! People feel uncomfortabledoing nothing, because we think it gives a bad impression.We must be busy all the time! It won’t take long before asituation like this is escalated. But that’s a good thing, wewant to find bottlenecks as soon as possible. This is usually the moment when an improvement ses-
  37. 37. It will take longer 31sion is triggered. How can we prevent this from happeningagain? Are our WIP limits not set accordingly? What is theroot cause of this bottleneck, how can we unclog it? Thissession resembles a retrospective, but with a wider focus.Most retrospectives are held within the development team,with an occasional participation from a product owner.In Kanban, improvement sessions typically include manymore different roles of the organization because of thefocus on the entire flow, from idea till installation on pro-duction. This causes business analysts, system engineersand sometimes even sales people to be included. The continuous improvement focus of all the differentroles from the organization creates a healthy peer pressureand more opportunities to share knowledge. WIP limitswill reveal bottlenecks quickly and create momentum tohelp others and start the continuous improvement cycle.The power of continuous improvement in Kanban will helpyou improve flow, which will tilt the perception that it willtake longer into a feeling of greater efficiency. And youwill have the measurements to prove it! 3.4 FlowKanban is based on the principles of a pull system, pio-neered in Lean manufacturing. The goal is to get as closea possible to a single piece flow, where the organization isonly working on products that are ordered by a customer.Why is this, and what does this have to do with softwaredevelopment?
  38. 38. It will take longer 32 The reason we only want to be working on customerrequests is because we want to eliminate waste. Forgetabout innovation for a moment, because there’s no cus-tomer order is triggering the pull system. Working notonly on customer requests means you’re guessing whatthe customer will order in the future, and therefore youare building up inventory, a stock of products waiting tobe purchased. This is waste because of two reasons. It iscapital spent on items that are not bringing in revenue andtherefore costing us money. Also, these items contain abig risk of not being sold or not complying to customer’swishes, leading to costing us money. In software devel-opment the same issues apply. Features waiting monthsto be released are costing money and contain a risk. Youmight argue that most work in software development isn’tordered by a customer, for instance when you’re stillworking a first version. Even then, those features have acustomer, being a product owner, a business analyst, seniormanagement, a potential customer segment, … WIP limits reduce inventory and create a pull systemupstream. If you have finished a task, you pull a new onefrom the preceding stage, freeing up capacity there, givingan opportunity for the preceding stage to pull on its own.This keeps going all the way up to the input queue.
  39. 39. It will take longer 33 Features getting pulled through the Kanban flow The most common critique on WIP limits is that itwill cause a drop in efficiency. Off course, people willbe idle once in a while because of WIP limits that arereached. What would happen if they would ignore the WIPlimits? The organization would gradually start building upinventory, more than the flow can handle. People can’tbe 100% busy. The perception that they should can betraced all the way back to the start of industrial times whenfactories started to grow and expensive machines wereintroduced to increase capacity. Off course these machineswere so expensive that they had to run continuously inorder to keep the unit cost low. This led to large unevennessin the production line and a growth of inventories. Inthose times, a product was not customized to the user, sothe risk of not complying to it’s wishes was none existingsimply because they had no choice. The company just hadto make sure they sold the inventory. Today, for manyorganizations products are customized by the end users,
  40. 40. It will take longer 34causing inventory to be a major risk. This applies for ITas well, since the majority of systems are customized for aclient, a customer segment, … 3.5 One continuous sprintKanban being a continuous flow leads to the perceptionthat teams get no more chance to pause and reflect. It is anever ending sprint where team members are pushed todeliver faster and faster. As we all know, a sustainablepace is important for the quality of the end product andthe health of the team. Some slack is needed to get yoursenses together or reflect on the future of the product whichallows the team to take better decisions during the courseof delivery. Measuring flow makes it easy to fall into the trapof micromanagement. Pushing the team to work harder,feature by feature. This is where a coach has an importantrole to play. He must help all team members to understandthat in order to go faster, they must take the time to reflecton the process, not on the speed of development. Kanbanfocuses on the end to end flow. Pushing one step in theflow to go faster, will often cause problems for the restof the flow in the form of defects, bottlenecks and swiftdecisions. This is again the Theory of Constraints whichtells us that problems will appear downstream if we pushone step in the process to go faster. A new Kanban team starts with their current efficiencyand continuously inspects its collaboration in order to
  41. 41. It will take longer 35perform. Not by working faster, but by optimizing theflow. This makes it easier to guarantee a continuous flow,since we all agree that the system is more important thanthe individual, and we can achieve more by improvingtogether. 3.6 SummaryIt is a strange idea that by measuring flow instead of settingdeadlines, work will be done efficiently. Kanban createsawareness on the importance of every phase in the process.Instead of pushing each individual phase to go faster, weoptimize the whole. Again, because this is what matters tothe end users. They don’t care how well our developersare meeting their deadlines, they need the order to bedelivered. As soon as the process is under control, the teamcan start trying to improve their efficiency. Not locally, butend to end. Not by pushing individuals to work harder,but by reducing bottlenecks and optimizing the flow. Thecircumstances in which people work are tuned to better suiteveryone’s needs. A sustainable pace for the employees, areliable relationship for the client and a profitable businessfor the owners.
  42. 42. 4 Things will get stuck, we can’t keep WIP limitsWhen people hear about the concept of Work In Progresslimits, their first reaction is that it will not work in theirorganization. They expect a major efficiency drop if theywould apply it to the different work flow stages. “Ourtesters can never keep up with the pace of our developerswhen testing the features. Developers would be idle forhalf of the time”. This is applicable to all different rolesin the organization all the way up from sales to operationsdownstream. The way most organizations fix this, is byworking asynchronously. When testers are looking at thefeatures, development is starting to work on new requests,to maximize their efficiency. Remember that Kanban doesn’t focus on maximizingresource utilization. Instead it focuses on maximizing endto end flow efficiency, which is a completely different goal. 4.1 End to end flow efficiencyEfficiency has been a management obsession for centuries.This is based on basic economics such as supply anddemand. I look for extra manpower, you offer your servicesat a monthly price in the form of a wage. As soon asservices or products are purchased at a price, the naturalreflex of negotiation starts. Both parties want to get the 36
  43. 43. Things will get stuck, we can’t keep WIP limits 37most for their money. It is normal that an employer wantsas much produced for the wage he pays. So keeping theemployee busy is the aim, because otherwise he would bepaid to do nothing. The employee wants to get the best benefits he canget for the job. So he will negotiate new terms on aregular basis, driving his cost for the employer up. Froma cost perspective, the employer is motivated to drive upefficiency, making sure the worker spends as little timeidle as possible. This has serious consequences on end toend efficiency. Imagine a shoe factory worker producingas much shoelaces as possible. Each day he works for 8straight hours, producing a huge pile of shoelaces. Chancesare high that he produces a different amount of shoelacesthan required for customer orders. No problem, these canbe stored in a warehouse and used later, when sales goup. Remember that this increases inventory, and thereforecost, in the sense of no return and extra storage capacityinvestments. These issues can be dealt with, for sure. Thinkabout this scenario. What if he produces different colors ofshoelaces? His increased efficiency causes the company topredict colors of shoelaces because of the 100 he producesper day, only 80 are linked to a customer order. In the bestcase these 20 extra shoelaces get linked to a customer orderlater. If not, you ‘re ending up with a stock that is causingmoney and cannot be sold at regular prices. Driving efficiency from a cost perspective will makeit impossible to run your business as a pull system, thatworks on customer request and reduces waste. It will shiftan organization into forecasting and predicting sales. As
  44. 44. Things will get stuck, we can’t keep WIP limits 38we all know, predictions seldom come true, no matter howadvanced your forecasting techniques are. This is evenmore troublesome in software development. Analysts whoare forced to maximize their time on analysis from a costperspective, will start making assumptions about usefulfeatures for customers. They build up an inventory offeatures that may or may not cover their customers inter-ests. Unlike in manufacturing, features are intangible andsubject to changes in the market. An interesting featuretoday can become obsolete overnight, creating waste ofinventory and inefficiency. The focus of Kanban on end to end efficiency allpoints towards pulling value from the customer with asmuch added value as possible. So instead of maximizingutilization rates, the team focuses on getting value throughthe flow as quickly as possible. In some cases this maycause people to be idle, making sure they are not workingon things that cause an increase in work in progress andthe risk of a value mismatch. As you can imagine, the pullsystem is also subjected to change. A change in sales candemand extra capacity from the system. But instead of allblindly starting to produce as much as possible, the teamfocuses on improving the flow by removing bottlenecksand redesigning the flow in order to keep up with the newstream of demand. This is an exercise that never stops, dueto the variability in the consumer market. Thanks to theclear focus on end to end flow, the team makes sure theykeep working in a pull system, driven by customer demand. If we’re honest, we all know that it’s in our nature tostart looking for new challenges when the major problem
  45. 45. Things will get stuck, we can’t keep WIP limits 39solving of a task is done. This leads to a huge pile of tasksthat are only 90% finished. The end to end focus of Kanbanwill push you to finish the remaining 10%. 4.2 WIP limits will always cause bottlenecksThere is no exact science on determining WIP limits. Assoon as they are chosen, bottlenecks will appear. Thisdoesn’t have to be a disaster. When the organizationembraces the idea of a pull system, they will understandthat WIP limits help to improve end to end efficiency. Thefirst signs of a bottleneck appearing will drive continuousimprovement. People will start to get nervous becausethey can’t pull a new feature to work on. This is avery uncomfortable feeling, not being able to work dueto another stage that can’t keep up. It will drive teammembers to collaborate on 2 levels. A first reaction willbe to go out and check what the problem is. Why areyou stuck? Can I help you to get going again? This willeventually get the flow going again, but soon things willget stuck again, leading to the second reaction. How canwe solve this bottleneck? Is it just a matter of unevencapacity between stages? Do we need to correct the WIPLimits? Can we add extra people or do we need to look forother options? The team starts the improvement cycle andtogether they try to agree on actions. If you think about it,the WIP limits cause the team to self adjust to changes thataffect the end to end flow.
  46. 46. Things will get stuck, we can’t keep WIP limits 40 Let’s look at the most common botllenecks that surfacein software development thanks to the new WIP limits. Requirements aren’t readyA Kanban flow generally starts with the steps needed totransform an idea into features that are ready to be created,just like any other traditional process. If we introduce WIPlimits on these stages, often the upstream stages can’t keepup with the down stream stages. Developers are finishingfeatures, and eager to pull new features. Requirements aren’t ready to be pulled Why is this happening? Is it just a matter of a mis-match in capacity? That’s possible, but it is something
  47. 47. Things will get stuck, we can’t keep WIP limits 41for the team to find out in their improvement sessions.The analysts may just be adding too much detail to afeature. This is something the team can evaluate duringthe improvement session. Which actions are taken in thebottleneck stage? Is there any waste we can reduce? Forinstance by providing less detailed information and workout the details via communication when a feature is pulledinto development. Another cause is often an outside dependency that isnot visible in the flow. The analysts may need to go troughan approval board that only meets once a week, causingthem not to be able to guarantee a smooth flow down-stream. It is by tracing the different steps in a bottleneckflow that the team discovers room for improvement. Bugs cause features to be stuckQuality control is an important aspect in product devel-opment. Customers demand a working product withoutany malfunctions. Teams that switch to Kanban often seea big risk in quality control as a blocker for continuousflow. They know from experience that the test team willalways find an issue, causing a feature to move back intodevelopment for a fix. This will cause the WIP limit to bebroken, because of course the developer has already pulleda new feature to work on.
  48. 48. Things will get stuck, we can’t keep WIP limits 42 bugs cause rework This doesn’t have to be a drama. As soon as this hap-pens, the team should have a natural reflex to drop whatthey started on and fix the feature immediately. Removingthe WIP limit violation as quickly as possible and get thefeature flowing again. Flow can go both ways in Kanban,there’s no rule against it, but this often indicates there’s anopportunity to improve. Why do features flow in circles?If the team can work out an way to reduce the amount ofreturning features, flow will improve dramatically. The WIP limits turn quality issues into an uncomfort-able experience. In the old days, bugs were just listedand prioritized, but often people just carried on with thenext task, fixing bugs only every couple of weeks, or (evenworse) at the end of the project. In Kanban bugs cause theflow to be interrupted and people to get stuck because ofWIP limits that are reached. It’s no longer possible to sweep
  49. 49. Things will get stuck, we can’t keep WIP limits 43this under the carpet. If quality is not reaching our definedstandards, it must be fixed immediately. Think of the change for a minute. Where in the past,quality standards lingered in the back of our head, theynow kick us in the face, for each feature if we’re toostubborn to learn. Again Kanban proves to be a greatchange management enabler. No coach is telling us to focusmore on quality, the system is showing us the issues andlets us experience the consequences. This is much morepowerful, as you can imagine. Because the team drives itsown improvement, they have the space to do somethingabout it. That’s why its so important to be strict about WIPlimits and quality standards. They will help the team to seeand improve. Long deployment cycleSome teams have the Kanban flow well under control.They are able to pull requests on a reliable cadence, keepingwork in progress limited and being reactive to change.However, what really counts to the customer is the end toend flow. From the time of the request, until the time it isdelivered. In many new Kanban teams, the last stages of theflow, being installation into the production environment,soon become a bottleneck.
  50. 50. Things will get stuck, we can’t keep WIP limits 44 Features waiting to be deployed Removing this bottleneck will require bringing opera-tions and development closer together. How can we releasemore often with high confidence? Are we technicallyable to release fast? Can we evolve towards a model ofcontinuous deployment? Otherwise increasing the numberof releases will bring extra overhead to the operations team.The devops movement tries to address these issues on atechnical and organisational level. EmergenciesAnother common question is “We’re not able to keep WIPlimits because of emergencies that pop up from time totime”. In a well balanced flow, all stages in the Kanbanflow are close to their WIP limits. This means that whenan emergency pops up, the team won’t be able to start
  51. 51. Things will get stuck, we can’t keep WIP limits 45solving it until new capacity becomes available. This is notacceptable because an emergency can’t wait for half a daybefore someone starts working on it. An emergency that can’t wait Reality proves to be different, even in Kanban land.When an emergency arrives, it needs to be dealt with,immediately! This means WIP limits can be broken. How-ever, the decision needs to be made very consciouslybecause of the impact. Introducing an emergency intothe flow, causes people to drop what they’re doing andswitch context. This comes with a cost. The flow will beinterrupted and lead times will be impacted. You probablyunderstand that it’s important to reduce these interruptionsto a minimum. Otherwise variability of the Kanban flow
  52. 52. Things will get stuck, we can’t keep WIP limits 46will increase, tearing down its reliability and frequentdelivery of value. It doesn’t take long before you fall backinto estimating and planning. One way to reduce the number of emergencies thatinterrupt the flow, is by making sure new items are pulledfrom the queue on a regular basis. When on average, ittakes only 2 hours for a feature at the top of the queue toget pulled, far fewer emergencies need to be pushed intothe flow. When you can rely on the pull frequency of theKanban flow, it’s much easier to just prioritize it in thequeue instead of interrupting every body’s work. An emergency that can wait to be pulled Off course there will always be emergencies that needto be dealt with immediately. This is where the concept
  53. 53. Things will get stuck, we can’t keep WIP limits 47of Classes of Service¹ can offer you some flexibility. Bycategorizing the type of work that enters the Kanban flow,we agree to the service levels that apply to these differentcategories. Some categories have much higher due dateperformance than others. This gives you some room toabsorb variation because of emergencies that disrupt theflow. Many Kanban implementations use an expedite laneto deal with emergencies. This is a horizontal lane thatspreads across all workflow stages and has a WIP limit ofit’s own. When an emergency arrives, it is pulled throughthe expedite lane with priority over all other work items. 4.3 Collaboration - daily stand-upA common practice in agile teams is the daily stand-up.Each day, the team gathers in front of the task board andplans its next day. What have we worked on, what are wegoing to do, and are there any impediments? The dailystand-up is adopted by many Kanban teams, and proves toadd a lot of value. By gathering around the Kanban board,the team gets the opportunity to inspect the flow and helpeach other to keep it going. This is often the time when the team makes decisionson how to prevent upcoming bottlenecks. It doesn’t takea genius to see where the flow will get obstructed. Theteam will often feel in advance when WIP limits will be ¹http://www.amazon.com/Kanban-Successful-Evolutionary-Technology-Business/dp/0984521402
  54. 54. Things will get stuck, we can’t keep WIP limits 48reached. By synchronizing on a regular basis they canmake decisions on how to help each other and reducethe number of bottlenecks that cause people to be idle.For instance, when the development sees that nothing ismoving in the next stage, which often is testing, theywill raise this in the daily standup as a concern. Why?Because they know it will impact them later. This worksdownstream as well as upstream. A bottleneck will makeit impossible for downstream stages to pull new items, andprevent upstream stages to pull new items because WIPlimits are reached due to the bottleneck stage not freeingup capacity by pulling its items. In a waterfall process, the development team doesn’tcare about the work of the test team. If they can’t keepup, that’s not their problem. The development team canjust start working on the next feature. This is much harderin Kanban due to the WIP limits. The egocentric focus isreduced by the simple introduction of WIP limits. It doesn’tmatter how many features you can finish, if the next stagein the flow is not able to follow. 4.4 SummaryOff course introducing WIP limits is going to cause prob-lems! The question is, why is that bothering you? Thepurpose of WIP limits is to make it easier to work in a pullsystem that is more effective from start to end. The WIPlimits will signal an uneven balance in your flow. Fromthat point, you can start working on improving it.
  55. 55. 5 Stakeholders don’t care about feeding the flowOrdering the input queue is what determines which fea-tures get delivered to our customers, and which aren’t.One of the most important aspects of Kanban is to makegood decisions when it comes to prioritization. A commonargument against Kanban is that stakeholders will neverwant to order the input queue on a regular basis. Theydon’t want to get involved so closely since their time isprecious and they can’t commit to being available whenneeded. Even worse, stakeholders in general want all thefeatures as fast as possible, so why bother ordering the list? 5.1 Ordering triggers business valueHow many projects have you been part of, where half ofthe features had no clear definition of why they should bedelivered? Sadly, this is sometimes the case even for theproject itself. Stakeholders prioritizing the input queue,doesn’t necessarily mean they are working on a featurelevel. In most cases it’s on a higher level like a cluster offeatures that provide a cohesive set of added value to theircustomers. 49
  56. 56. Stakeholders don’t care about feeding the flow 50 Stakeholders prioritize big requests that get split up In order to get the most out of your Kanban flow, itmust be clear which rules apply when prioritizing features.These rules will lead to a definition of ready for featureswaiting to be ordered in the input queue. Without thenecessary data, it is impossible to determine which prioritya new feature will get in the input queue. For stakeholdersthis is a major incentive to do their homework. Theirfeatures won’t get a place on the input queue, unless theycan provide the necessary data. Kanban doesn’t prescribewhich data to collect for a feature. There are several in-teresting questions to ask depending on the organizationalcontext. • What is the type of feature? (new, bug, enhance- ment, …) • What is the business value?
  57. 57. Stakeholders don’t care about feeding the flow 51 • What is the cost of delay and which type? (insert reference) • Any dependencies on other features? • … These are all important factors to consider when de-termining the order of the input queue. They will helpyour stakeholders manage scope in a much more aggressivemanner, allowing much less work on useless functionalitythat used to sneak into projects from all directions. Thisis important for both, the cost and value, two things allstakeholders are extremely interested in. 5.2 Building an MVPThe one thing stakeholders care most about is return oninvestment. What will this new product or feature bringto the company? Will we attract more customers? Will ithelp customer retention? Does it increase revenue and/orprofit? How quickly will we reach our sales forecast? These will all remain questions as long as the producthasn’t shipped. In this day and age, these questions aremajor risks. The sooner we can get an answer, the better.The last thing we want is to spend months of work andbudget on something that doesn’t deliver what we initiallythought it would. This is where the concept of a Minimum Viable Product(MVP) can offer a solution.An MVP is not a minimal product, it is a strategy for
  58. 58. Stakeholders don’t care about feeding the flow 52creating and selling a product to customers. It is an iterativelearning process until the product fits the market, or iscancelled. The Lean Startup¹ movement offers great adviceand examples on how to approach this. If it’s applicable toyour type of business, check it out! Kanban makes it easier to build a MVP in the truesense of the term. We’ve known MVP’s for a long time insoftware development under the term 1 version. Howeverthis is pursued as a minimal viable product, it often con-tains much more features than needed, due to scope creepand an upfront selection of features that continues to bechased even when some of them might no longer be the bestchoice. The single piece ordering of the input queue makesit easier to prevent this from happening. Stakeholders geta chance to critically review the scope on a continuousbasis and apply the learning of a system in development.In many cases, experiencing delivered features gives themnew ideas and insights, resulting in a better understandingof what the MVP should contain. That’s when the reallearning can begin, when you release a version to thepublic. However, the barrier to draw a line for a first releaseis easier because no major investments have been madeupfront to detail out the features that are waiting in thequeue. ¹http://www.amazon.com/The-Lean-Startup-Entrepreneurs-Continuous/dp/0307887898/
  59. 59. Stakeholders don’t care about feeding the flow 53 5.3 Stakeholder collaborationAs a stakeholder you’re seldom in a position where youget to use the full capacity of a product development team.Capacity is often shared amongst different stakeholders,often with something in common. A team can be workingon multiple products or modules at a time. In that case,you need to agree with other stakeholders on the order ofthe input queue because it contains requests from differentstakeholders. A Kanban flow serving 3 products In the past, when people had to work on differentprojects at the same time, this created a complex plan-ning issue. People needed to be scheduled in advance toprojects that were in the pipeline, keeping into account
  60. 60. Stakeholders don’t care about feeding the flow 54their estimated free capacity. Due to unforeseen delays orextensions, this proved to be very inadequate and peoplewere often transferred between projects to get one certainspecialist on the new project. It was mostly the projectmanager who had to negotiate with department managersto get the people he needed. Politics were the key to successin this game, as you can imagine. You give some, youtake some, leading to other projects losing important teammembers due to reassignments. Kanban simplifies this issue significantly. By letting ateam work on one continuous flow, they don’t need to bereassigned over and over again. The focus has shifted to theinput queue. Remember that the order of the features in theinput queue determines what the team will be working on,in the near future. To simplify it, we have one factory thatworks on an order list for multiple clients. This impliesthat team members need to be multi disciplinary to acertain degree. They need to be able to work at differentproducts, one request after another, while they used tospecialize in one domain. Of course there needs to be agood balance, where you have a good mix of generalistsand specialists. A strong argument to tilt this balancetowards multi discipline is flexibility. When one specialistfalls sick for a month, others can jump in and secure thecontinuation of the work. If stakeholders can focus on the product, and not onresource planning, they can make better economical deci-sions for the company. While politics used to determinewhich project got priority, it is now a business decision,based on the needs of the customers and the organization.
  61. 61. Stakeholders don’t care about feeding the flow 55Stakeholders can persuade each other why their featuresneed to be high on the input queue because of the ruleswe all agreed on and the data that has been collected toprove it. Do you feel the shift from a silo focus towardsan organizational and customer focus? It may sound naiveto think that senior management will trust each other andstop playing the political games. That’s why it’s importantthat company leadership give full support and makes surethese rules are followed by all. Just like in a factory,capacity is a given, and all stakeholders have a right toa piece of it. Software development being an intangiblebusiness makes it much more needed to set clear rules toavoid abuse. 5.4 Expectation managementStakeholders need regular status updates from the teamsworking on their requests. In many organizations this isdone by steering committees on a monthly basis, whereproject managers of different teams elaborate on progressof their teams. These are meetings with a high politicalcontent. More than half the time of these meetings isspent on trying to get extra capacity or priority over otherprojects. Simply because stakeholders know the game. Ifthey don’t do it, others will steal capacity from them. The rules on the Kanban input queue completely changethese status meetings. The focus changes to the featuresmoving through the flow, instead of the fight to get asmany people as possible. Expectations are clear from the
  62. 62. Stakeholders don’t care about feeding the flow 56start. Your product gets 20% of the flow capacity, whichyou can see each day on the Kanban board with yourown eyes, together with the capacity other products areusing. It is a very transparent way of tracking progress.The beauty of this approach is that it will create trust,which is one of the hardest things to achieve on a seniormanagement level. By using simple rules and completetransparency, suspiciousness will start to disappear. Thiscreates an opening for stakeholders to work more cooper-atively. When one product has a need for extra capacity,another stakeholder will much more quickly offer a piece ofhis capacity because he knows the system is treating everystockholder fairly, and he can do the same thing later. Expectations towards release scheduling is much morecomforting. While stakeholders used to get progress up-dates during steering committee meetings where no realcommitments to release dates could be given, they can nowrely on the Kanban flow and their allocated capacity. Bymonitoring the measurements on a regular basis, they get agood idea about the release schedule which is based on realdata instead of status updates that are given in a politicallycharged meeting. 5.5 SummaryStakeholders might not care about prioritizing the featuresin the input queue, but they certainly care about their ca-pacity of the Kanban flow. The transparency of the Kanbanflow is attractive for stakeholders who are suspicious by
  63. 63. Stakeholders don’t care about feeding the flow 57nature. The information they used to get second hand isnow visible on the Kanban board and offers them a greattool to focus on economic decisions instead of companypolitics. By collaborating with other stakeholders andworking on a great feature composition, they can returnto what’s most important, creating customer value. Whensomething as trivial as setting priorities can change thefocus of senior management proves that Kanban is indeeda powerful change management approach.
  64. 64. 6 We will lose team cohesionThis argument comes in many cases from a project man-ager or a team leader. They have heard that there are nolimits to the size of a Kanban team and are worried that theteams they have worked so hard to create, will fall apart.People will basically become factory line workers, who’sonly job is to keep up with the conveyor belt. How are wesupposed to keep them motivated in this environment? If there is one thing we learned over the years it’sthat the key to project success is communication. Withteams of more than 10 people, we will lose the powerof close collaboration and need to move back to moreformal knowledge sharing through documentation. Whatabout multi-disciplinary teams? By creating a team ofbusiness, technical and support roles, people got a chanceto look across their borders and learn about the entireorganization. If we divide them into separate specialitieswith the Kanban flow, won’t we lose this? 6.1 Tearing down wallsAs soon as a team gets involved in a Kanban flow, theircooperation mode starts to change. While they used tocollaborate mostly inside the safety of their own team, theyare suddenly depending on many other roles in the organi-zation. A pull system with WIP limits makes dependencieson upstream and downstream stages more visible. When 58
  65. 65. We will lose team cohesion 59your tasks is finished, you can only pull a new one whenthere is free capacity. When the WIP limit is reached, nomore tasks can be pulled.The Install stage can’t pull new work due to a downstream bottle-neck Situations like these automatically lead to cross bound-ary communication. The person who is stuck due toanother stage’s WIP limit will go and check out what theproblem is. Slowly but surely, the people who used to workin isolated teams will get to know the others who are alsoinvolved in the development of the end product. This leads to another type of team feeling. One thatincludes all roles in the organization who are involved inthe Kanban flow. IT teams in many organizations are stillperceived as islands on their own, which is why business
  66. 66. We will lose team cohesion 60analysts are introduced to bridge the gap between businessand IT, a workaround to the actual problem. By introducing Kanban, isolated teams fall apart andbigger teams start to emerge. Teams that contain a di-versity of roles and personalities, each with their ownknowledge to spread. You don’t lose team cohesion, youget a new team composition that will build bridges in theorganization. 6.2 Finding a bigger purposeOne of the prerequisites for building a great team is tofind a common purpose. The team needs to be able tocommit to the same goal which is the target for themto reach together. In vertically organized organizations,where silo’s hand over work to each other, the purposeis internally oriented. The common purpose is stronglyaligned with the goals of the department. IT cares aboutdelivering what is requested by the different business units.The business units care about delivering what is requestedby management. Sales cares about reaching sales targets,and so on… The problem about these purposes is that they arenot necessarily aligned. Sales might be doing a greatjob selling according to their targets, but not taking intoaccount the capability of the other silo’s that are involved indelivering the orders. The answer to mediate this mismatchis to create cross silo functions who’s task lies in creatingalignment and controlling the end to end process.
  67. 67. We will lose team cohesion 61 This is were Kanban strikes a chord. Teams get bustedout of their silo thinking by becoming part of an end toend process where measurements and targets are set fromcustomer request to product delivery. The focus on flowand continuous improvement will slowly but surely raiseawareness of a bigger purpose, namely customer value. Nomatter how efficient you work, if the other parties involvedin the system are not following along, little value is created.The visual aspect of Kanban plays an important part inthis awareness. Many Kanban teams gather around theKanban board on a daily basis to synchronize. How aretasks moving through the flow? Are there any bottleneckspresent, and what can we do to exploit them? From a change management perspective this has provento be a very effective approach. People are naturallyskeptical about new processes or changes in their workhabits. Who can blame them? Most of us can’t countthe number of change initiatives they’ve been through onboth hands. Many of them never resulted in anythingsubstantial. Kanban doesn’t enforce any theoretical frameworks,training initiatives or redefinition of job descriptions. Thejob content of most people will stay exactly the same, onlyapplied within a certain set of rules. Generally, there’s verylimited resistance in a Kanban adoption, which makes it abetter candidate for sustainable change.
  68. 68. We will lose team cohesion 62 6.3 Creative thinkingIn order for a team to grow, they need room to be creativeand build solutions on their own, so they can take pridein their work. Without it, the team will lose motivationand start acting as a machine which will only produceaccording to what it is designed to create. Agile methods have this aspect well covered. Insteadof specifying each detail of the system to be implemented,each role interacts with the others in order to create a bettersolution together. No matter how hard we wish, peoplewill always have certain competences in which they arebetter than others. But even the most senior architect willhave a hard time to design the perfect system. So instead oftrying to create this design to perfection up front, he willdo this cooperatively with the team. This creates majoropportunities for teams to be creative and share knowledge,two of the top ten most important job satisfaction criteria. While Kanban doesn’t prescribe this, its continuousflow stimulates strong collaboration. Remember the focuson reducing waste, which in many organizations comesin the form of outdated or misaligned requirement spec-ifications. Kanban also focuses on improving lead andcycle time, which pushes the team to reduce the amount ofisolated work and start with faster collaborative work. Thefocus on added value is the driver, where only the workthat brings value to the customer is pursued. When a team starts to investigate why the current flowis suboptimal, they often come to realize that it is becauseof a feedback loop that is too slow. An optimal flow has
  69. 69. We will lose team cohesion 63limited returning cycles, where work is rejected becauseof a mismatch. This can be a bug, a missing piece offunctionality, a missing scenario, … Either way, the featurecan’t flow further because something is missing. There aretwo ways to try and fix this. By expanding the degreeof up front analysis and design, or by improving feedbackloops. Because the first option has failed for centuries andwill have a dramatic impact on our lead and cycle time,the second one is preferred. Better collaboration and fasterfeedback cycles will have a positive effect on flow and willnot introduce extra waste into the flow. All these effects of Kanban make it challenging andrewarding from a personal and team perspective. The teamgets plenty of opportunities to be creative, collaborate andshare knowledge on a continuous basis. 6.4 Participatory decision makingIn a real team, decisions are made together. Each person’sopinion is valued and heard. What happens when we movefrom a small specialized team to a larger Kanban teamwhere much more roles are present? This is an important concern, which needs to be ad-dressed right from the start. When a Kanban team ofsales, product management, development, testing, etc isassembled, there is a natural grasp for power, right fromthe start, where often the role with the most senior positionin the organization will take control. This is a huge risk forthe Kanban team as it will demotivate people and block
  70. 70. We will lose team cohesion 64collaboration. A Kanban team, like an agile team, needs to worktogether as one team. Otherwise they will just be a coupleof sequenced specialists working a conveyor belt. Togetherthey can reach so much more by starting the journey toimprove flow and reduce waste by continuously improvingtheir process. This gap can be filled by a leader or coach, someonewho will help the team on the process level. He will notbe involved in the work, but help facilitate the team intheir Kanban journey. His first task is to help the teamto understand the principles of Kanban and learn what thismeans in their everyday job. This goes a long way, fromworking with product managers to system engineers. Hissecond job is to facilitate participatory decision making.When the team gathers around the Kanban board or holdsan improvement session, the coach helps the team to makedecisions together. This is not an easy task, because evenmore people of different characters are present than in atypical specialized team. The focus on reducing waste and improving flow helpsto settle arguments. Even more effective is assessingmeasurements after improvement initiatives. This proveswith hard data the effect of an improvement. Continuousimprovement sessions can be held on a regular basis oron demand when the team notices need for improvement.These sessions are a great moment for a coach to help theteam to grow in making decisions together and learn tounderstand why each opinion is valuable because in theend they all pursue the same goal which is to create value
  71. 71. We will lose team cohesion 65to customers. 6.5 Achievable goalsOne thing to keep motivation is to have goals, another thingis to have achievable goals. An illness of this age is theever increasing pressure to deliver more and faster. We’veall been part of projects where estimations where frownedupon and management pushed to commit to more.In many cases, teams agree to lower their estimates, be-cause they don’t want to limit their career options in thecompany. Everybody knows this backfires pretty hard inthe end. It is proven that people are bad at estimating,especially in knowledge work domains, such as softwaredevelopment. And we all know from experience that asequence project plan gets delayed exponentially as soonas the slightest task gets overdue. It doesn’t take long for a team to get demotivated in thissituation. Management keeps pushing the original deadlinewhile the team knows there’s no way they can ever live upto it without working 24/7. This is a killer for building greatteams. Being on a death march like this will cause people tolook for other opportunities, get sick, start the blame game,etc. There’s nothing wrong with ambitious goals, as long asthey are achievable. This means the average peak of work,but with a general normal pace. In Kanban teams don’t start with the estimation fallacy,they start with a first version of their process flow and
  72. 72. We will lose team cohesion 66collect measurements. This data gives an idea of the teamcapacity after a short period of time. Lead and cycle timeaverages give a clear idea about the real capabilities of theteam in the current conditions. Management can prettysoon get an idea of the chances of success of their preferredrelease date. This doesn’t mean the team cannot boost it’sperformance. A first version of their Kanban flow can beimproved significantly. The big difference is that we’re notpushing people to go faster, we’re improving the conditionsas a team, resulting in a more efficient end to end flow. Thepace can remain the same, with occasional peaks instead ofa continuous pressure which will burn out the team. 6.6 SummaryThe last decades have had a strong emphasize on teambuilding. We have all been on a day away from the officeto do outdoor exercises with our colleagues. It appearsthat Kanban moves in the other direction, one with morehand-offs and less collaboration. This is a false perception,because it will create the opposite effect. People willtear down the walls between different stages in the flow.Simply because they focus on improving lead times. It givespeople the opportunity to broaden their horizon, by helpingother roles to get things flowing. Kanban, with it’s strongfocus on delivering end to end value, makes it easier forpeople to focus on what truly matters, a happy client. Itwill reduce silo thinking in the long run. Teams will get plenty of opportunities to be creative.
  73. 73. We will lose team cohesion 67They have the freedom to decide together on how theyattack work and continuously improve their workflow.They are encouraged to do this together, since once changein the flow will impact all the others. Finally, work will become realistic again because Kan-ban starts from reality by measuring instead of estimating.From that point, improvements can be made on the entireflow, without wasting time on isolated parts of the process.
  74. 74. 7 SummaryI hope this book got you excited about Kanban and gaveyou insights why many arguments against it are invalid. But beware that the difference between theory andpractice is significant. Kanban will not suit every organiza-tions or team. If you start from the fundamental question‘Why do we need a change management approach?’, youwill quickly get a feeling whether introducing Kanban willhelp the organization. When your organizational modeldoesn’t align with the foundations of Kanban, you mightwant to consider other options first. Nevertheless, Kanban is an exciting new approachworth studying and practicing. I expect it to gain evenmore traction in the combination with the Lean Startupidea’s. How lucky are we, to be working in a field that has somany new interesting evolutions? 68
  75. 75. 8 ExtrasMy goal of this book was to provide clear answers toarguments against Kanban in software development. Istarted out with answering the 5 most common arguments,but soon enough I discovered more. In the next chaptersyou will find the arguments that didn’t make it to the firstcut, or new ones I documented after getting feedback fromreaders. Enjoy reading and don’t hesitate to contact meif you have a new argument or wish to write a chapteryourself. 69
  76. 76. 9 Software development is not manufacturingThis statement typically doesn’t come from management,but from software developers. They know from experiencethat in software development, work is highly variable. Notmany have developed the same system over and over again.Each new assignment requires them to start from scratch,on a technical as well as on a functional level. What kind oftechnology is appropriate? What is a proper architecture?What exactly do our end-users need? Damn right if they are skeptical when managementconsultants compare software development with car man-ufacturing. It doesn’t matter how successful Toyota hasbecome with their Lean ideas, we’re just not doing the sametype of work! As soon as they have designed a car, it’s massproduction. Creating the same car over and over again. Butprior to this, the company has spent a significant amountof money and time on R&D, car design and prototyping,building a plant, … Maybe that’s why they call it leanmanufacturing, because it only focuses on production… If we would apply this to building a new softwaresystem, wouldn’t we need to make the same distinction?Invest in a good preparation where you create an architec-ture, design and prototype the specification, create a soliddevelopment process. After it has been approved, startthe mass production? But wait, we will only produce onesystem, right? So these lean principles are not applicable,because they are meant to optimize the production flow 70
  77. 77. Software development is not manufacturing 71of many identical products? Yes indeed, but that doesn’tmean they are not applicable to software development. 9.1 Support teamsWhy does Kanban feels like such a good fit for supportteams? Because their situation comes closest to manu-facturing. They already have a running system, whichmeans their preparation phase has already passed andthey’re working in production mode. Most often, theyare continuously working on requests in the form of bugfixes, improvements or new features. They are in factpulling tasks from a prioritized input queue, just like acar assembly line is pulling new cars from a prioritizedorder list. Limiting WIP, enables a support team to remainresponsive and deliver solutions to the users in a constantstream according to the service level agreement. Theyfocus on efficiency and reliability. In many organizations, support teams are managedas a capacity to process request, much like an assemblyline is managed as a capacity to produce cars. Kanbanfeels like a next step to improve efficiency by optimizingcapacity through evolutionary change caused by the in-troduction of a few basic rules. Limit work in progress,remove bottlenecks, visualize and continuously improveflow. Also effectiveness is increased by making processpolicies explicit. By studying demand and implementingproper classes of service, we can better meet our customers’expectations.