Lean and-kanban-final


Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

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

No notes for slide

Lean and-kanban-final

  1. 1. Applying Lean Thinking to Software Development Lean’s major concept is about reducing waste, meaning anything in your production cycle that is not adding value to the customer is considered waste and should therefore be removed from the process. PAGE 4 Lean & Kanban eMag Issue 10 - March 2014 FACILITATING THE SPREAD OF KNOWLEDGE AND INNOVATION IN ENTERPRISE SOFTWARE DEVELOPMENT QUEUES – THE TRUE ENEMY OF FLOW P. 9 KANBAN PIONEER: INTERVIEW WITH DAVID J. ANDERSON P. 13 IMPLEMENTING KANBAN IN PRACTICE P. 17 USING KANBAN TO TURN AROUND DISTRESSED PROJECTS P. 22 THE EVILS OF MULTI-TASKING AND HOW PERSONAL KANBAN CAN HELP YOU P. 29
  2. 2. Contents Applying Lean Thinking to Software Development Page 4 Lean’s major concept is about reducing waste, meaning anything in your production cycle that isnotaddingvaluetothecustomerisconsideredwasteandshouldthereforeberemovedfrom the process. Steven Peeters explains how you can apply Lean principles in an IT environment. Queues – the true enemy of flow Page 9 No-one wants IT projects to be late. But when they are, it’s rarely because of how long the actual work takes. Tasks and projects spend more time inactive, sitting in a queue, than being worked on. Despite this, most project management offices measure activity, not queues. This article examines why we should track queues and quantify their cost in order to make meaningful gains in speed of delivery. Kanban Pioneer: Interview with David J. Anderson Page 13 Kanban pioneer David J. Anderson recently went to Brazil to present a course on Kanban, and gave a wide-ranging interview to InfoQ Brasil editors. Implementing Kanban in Practice Page 17 AttheLeanKanbanconference,InfoQaskedDr.ArneRoockhowateamcanevaluatewhether Kanban is the right tool, and how to kick it off. Dr. Roock offers some prescriptive advice. Using Kanban to Turn Around Distressed Projects Page 22 This case study describes how Kanban and lean development techniques were used to rescue a distressed project that had violated its budget, schedule, and quality constraints. The article presents a detailed account of how the techniques were introduced mid-project to establish control over a chaotic project environment, and is supported with several charts that show the team’s progress. The Evils of Multi-tasking and How Personal Kanban Can Help You Page 29 Sandy Mamoli explains how to avoid multi-tasking by using personal Kanban and other Agile practices applied at the individual level.
  3. 3. YOU CAN’T MANAGE WHAT YOU CAN’T SEE Your team has complex processes. Hidden within each process are subprocesses that are hard to map—and even harder to visualize—without the right tool. Visualizing your workflow can help you: • Easily see multiple teams working together • Make handoffs clear and efficient • Eliminate work from falling between the cracks LeanKit is the only tool that helps you visualize your entire workflow in one view. As your processes evolve, easily reflect the changes and instantly communicate the updates to your team. Try it FREE FOR 30 DAYS at LEANKIT.COM/ONEVIEW Integrations available for MS TFS, JIRA, GitHub, BuildMaster and other tools you use.
  4. 4. Contents Page 4 Lean & Kanban / eMag Issue 10 - March 2014 Applying Lean Thinking to Software Development by Steven Peeters Lean thinking has been around for a very long time. The basics were laid out at the beginning of the 20th  century. Taking a few minor modifications into account, Toyota originally created this system in the mid ‘70s (then called the Toyota Production System). Lean is also often used in combination with six- sigma techniques for statistical control and has been widely accepted as a standard in the manufacturing industry. But it is only in the past few years that lean has gained some popularity in the service industry, such as in hospitals, banking, and software factories. What exactly is lean thinking? Some of you may already know what lean thinking is all about but some of you won’t, so let me clarify a few things here. Lean’s major concept is about reducing waste, meaning anything in your production cycle that is not adding value to the customer is considered waste and should therefore be removed from the process. Now, some waste is necessary to keep your business running, such as certain approval cycles, additional quality-assurance validations, etc. But most of the so-called waste is actual waste of time and effort and should be removed altogether. Ideally, you would end up with a 100% waste-free production process, but we’re not living in a perfect world, so that’s going to prove to be pretty damned impossible. Detecting waste in a production environment is relatively easy (if any manufacturing people are reading this, I know that isn’t always the case, but the concept of waste is much simpler to picture in a manufacturing environment), Imagine you have a production process that creates cardboard boxes. To create those boxes, you have to cut away some of the cardboard. The pieces you cut away can’t be used in the final product; they are, in fact, waste. A solution such as choosing a different box shape or layout may reduce such waste or eliminate it all together. In a pharmacy company, on the other hand, there is a lot of waste in the approval process for a new medicine, but would you want to take the medication if the FDA or equivalent agency in other countries didn’t approve it? That, therefore, is considered to be necessary waste.  Use the scrum board So how do you apply these lean principles in an IT environment? Well, most of the IT teams out there are already using lean in their daily routines. The widely accepted scrum board is actually a kanban, a tool that scrum has borrowed from lean. That means that our starting point is that lean is not a replacement for scrum (although it can be) but rather a complementary methodology. Scrum was created to help control a software-development cycle; lean looks at the entire process and includes more beyond the development cycle alone. However, you can use scrum as a tool in any lean project if you really want to.
  5. 5. Contents Page 5 Lean & Kanban / eMag Issue 10 - March 2014 Set up a pull system Another tool from lean that I’m quite fond of and which has proven to be very effective in my current project is a pull system. In short, a pull system is a system wherein you only start the next task when a previous task has been finished. This is meant to reduce the amount of work In progress (WIP). Little’s law, which I’ll discuss in detail further on, is a valuable formula to use to determine you optimal WIP count. A pull system might seem quite the opposite from scrum at first, since scrum advocates committing to a certain number of tasks to be delivered in a sprint. But if you look deeper, you will discover that promising those tasks to upper management doesn’t mean you have to put all of them on the board at once! In fact, reducing the number of tasks at hand will help your team to focus on specific tasks and not run from one task to another without adding any value and thus adding to the amount of waste (I’ll come back to this later, too). And, of course, your team doesn’t stress out at the beginning, seeing the huge amount of work that needs to be done. There’s a psychological factor in here as well, which should not be underestimated.  Reduce the setup time In the previous paragraph, I wrote briefly about unfocused developers not contributing to any tasks but still spending time on them. This is one of the wastes you have to be aware of and it’s called setup time. The best way to describe setup time in IT development is to describe the actions a developer has to take when (re)commencing work on a certain task. First, he has to clear the previous task from his mind. (Yes, this might seem like some Bruce Lee talk, but it is true.) Next, he probably needs to start logging his time in some kind of time-tracking system. He needs to read up on the new task. He might have to pull the code in question from the GIT server, find the proper file, and then get cracking at it. That is a lot of work to get set up for the task and of course takes time, which we appropriately call setup time. Now, imagine that a developer has to do this every time he is asked to quickly look at another issue or to stop working on a certain task in favor of a new one. That is a lot of time to lose in a day! Reducing setup time is one of the most effective measures you can take when applying lean thinking in an IT- development environment. It’s low-hanging fruit, a thing that gives many benefits with the least amount of effort. But, of course, the system in place has to work with you. Having sluggish time-tracking systems or no way to see what has been done and what needs to be done will work against you and will increase the setup time. If that is the case, you’ve already found you first improvement project!  Lean helps you get the job done! All of these techniques (setup-time reduction, a pull system, etc.) help your team to focus on getting the job done and to avoid distraction by things they should not be focusing on. That means that the so- called process lead time (PLT) will shrink. PLT is the time a task takes to get through the entire process, from request to production. Little’s law defines your process throughput by dividing the WIP by the PLT. That means that if you shorten the PLT by reducing waste, you increase the throughput. But this also happens when you reduce the amount of work in progress. That’s exactly where the pull system comes to life.  The seven wastes of IT Many circumstances can increase setup time. Constantly switching tasks is not something you’d do naturally, so some other forms of waste are often responsible. In a manufacturing environment, these are considered to be the seven wastes: 1. Transport 2. Inventory 3. Motion 4. Waiting 5. Overproduction 6. Overprocessing 7. Defects While some of these may sound obvious in your development environment, others may require you to change the way you look at things to see them. To help you change your point of view, allow me to clarify how these manufacturing wastes translate to a software factory. Waste #1: Transport Transport is probably the hardest waste to detect in a software-development environment. The end
  6. 6. Contents Page 6 Lean & Kanban / eMag Issue 10 - March 2014 product of an IT department is a virtual thing. It’s a piece of software that resides on some server. How on earth will this be transported? Will it be copied to a CD/DVD and shipped it to the customer? Possibly, but that is the dead-last step in your process – and most of the time, this has nothing to do with the IT department itself. So how exactly can tasks or bug fixes be transported during the development process? Instead of physical transport, think about how tasks get from one developer to the next, from designer to developer, from analyst to designer, etc. A practical example of transport waste is when a developer has finished a task and hands the code over to a tester. Let’s assume the tester has just finished another task and can pick up this new task immediately. The tester first has to look at the task to understand what it is supposed to do or fix. Then he has to start the application and get to the proper step in the application to test what has been programmed. I’m sure you can imagine that it takes some time to get to that point (and I’m still leaving out the possibility that the task needs to be deployed in a test environment). The handover generates this setup time for the tester. Of course, many other situations bring setup time into play, but this example demonstrates the point. Another source of transport waste is that when you hand over a certain task, the next person in the process chain does not usually treat it immediately. Transport, in a way, also introduces additional waiting time, which I’ll discuss in detail later. Waste #2: Inventory Inventory is another form of software waste that might not seem obvious at first. It’s software! You don’t stack it in a warehouse where it can result in overstock, right? Actually, you kind of do – but you call it a backlog. The more items you have waiting to be tackled, the more stock or inventory you’re building. Now, backlog isn’t the only type of inventory you have in your software-development environment. How many items, tickets, feature requests have you begun working on, only to have to put them on hold because you have a higher priority or you are waiting for another piece of software to be installed or you have to wait for a customer’s response, etc.? Starting a task and not finishing it straight away for whatever reason – the other six wastes can also cause this to happen – also results in inventory building up. Waste #3: Motion Motion and transport are the wastes hardest to discover at first. You really need to start thinking about the tasks and processes differently. When you talk about motion in a software environment, you automatically start thinking about how a task, which is a virtual item, can actually move. But that’s just a wrong point of view. Motion is all about physical motion: people or objects that are moving. And when they are moving, they are not spending time adding value. However, not all motion can be considered waste. In manufacturing, motion can be easily identified as people who must get materials from different locations, or as the product moving to a storage room or even to the client. Movement is logical and easy to understand in that kind of environment. But what about in a software environment? One of the motion wastes you might not consider at all is the motion the end user has to perform to work with your software. They may have to perform numerous keystrokes or mouse movements to fulfill a task. For example, think of what you need to do in Word to copy and paste between two documents when you only use the menus. Don’t you love those little icons and, even better, the shortcut keys? Also, people don’t sit at their desks all day long (some of you might think they do, specifically in the software industry). People are actually moving around the office quite a bit. A couple of examples: • Getting and updating tasks on the scrum board • Unavoidable meetings • Talking to other developers/testers/managers • … You would be amazed at the distances your team members actually walk each and every day. How do you eliminate the waste of motion as much as possible? Well, you probably know this instinctively, but putting people that are working on the same project in the same room works more effectively than when they are separated by a wall, floor, or building. Why is that? One reason is simply that communication is a big factor in performance optimization, and with (literally) shorter communication lines, communication comes more
  7. 7. Contents Page 7 Lean & Kanban / eMag Issue 10 - March 2014 naturally, more directly, and more instantaneously – which brings us automatically to our next waste: waiting Waste #4: Waiting If WIP is waiting for the next step in the process, it is not being handled efficiently. Tasks that are waiting accumulate non-value-added (NVA) time in your process, delaying the delivery of not only that item itself but of other items, because this task eventually will have to be picked up again. NVA time can best be described as the time you spend on a task for which the customer is not willing to pay. Examples are bug fixes, quality-control steps (e.g. testing), etc. Some of this NVA time should be eliminated all together, but some of it can be classified as business-value-added (BVA) time, meaning it is time the client isn’t willing to pay for but is necessary to keep the system running at a certain quality level. Examples in software development are the creation of release notes, maintaining the task-management system, implementing changes throughout the company to create a better service, etc. Waste #5: Overproduction Overproduction is a typical waste within a software- development environment. In my opinion, it exists on two levels. The first is scope creep. Scope creep happens when you set off with a defined set of features, but in the course of development you need to implement additional features or the features change. This will result in additional work that was not foreseen at the start, which in turn leads to longer PLT and longer delivery cycles. The second level of overproduction can be revealed by applying the Pareto principle. Applying this principle, we can say that 80% of your target audience will use only 20% of the features. You will probably spend a lot of time developing features that will hardly ever be used. Does that mean you should not develop them at all? Definitely not! These bells and whistles are often delighters, things that make clients happy. They may result in an advantage over the competition, attracting more clients. And since you’re in business to earn money, attracting more clients is always a good thing. Waste #6: Overprocessing Every software-development department has some kind of process that describes and guides the way tasks, feature requests, or bug fixes are handled. Having this documentation readily available and understood by the team is necessary to keep the workflow moving. However, despite good intentions in breaking up the process into many different steps for clarity and to strictly define responsibilities, you run the risk of overprocessing the entire development process. A process flow needs to be defined, but too many sub-processes or steps within your process will only make it more complex. Increasing complexity causes confusion and sometimes frustration amongst the people that have to follow the process. Everybody hates the government’s red tape, but overprocessing introduces your own red tape to your working environment! This adds waste to your process as people spend time on things like figuring out the next step, get all worked up because a colleague responsible for a certain subtask is not available at the moment, etc. A complex process flow will also lead to overlapping tasks or responsibilities. Sometimes two people will undertake the same action in different steps of the process. Is that really necessary? Can’t you simply eliminate one of those tasks? Sometimes you can’t, because they are an additional quality-control step, but I’m pretty sure that you usually can eliminate one of the tasks in a software-development environment, avoiding duplicate work and speeding up your process. The best way to determine overlapping responsibilities is using a value-stream map (VSM). For a VSM, you draw the different process steps and add each individual’s responsibilities for each of these steps. When doing this, it is imperative that you create this map with the entire team. That is the only way you can be sure you are drawing the actual process and not what you think the process is. Thinking the process is exactly the way you think it is is one of the most common mistakes in creating the VSM. Waste #7: Defects Defects are probably the easiest to recognize as a waste. The defects concept is well known in the software-development business and is easy to explain. A defect occurs when the software product, patch, or feature request does not perform as it should. The phrase “as it should” is defined buy
  8. 8. Contents Page 8 Lean & Kanban / eMag Issue 10 - March 2014 the customer. If the customer isn’t happy with the solution you’re offering, you have a defect. As you can deduce from the previous sentence, a defect isn’t necessarily a bug. If the client orders or buys a product and it doesn’t fully meet his expectations, you have a defect. If you’re talking about an actual critical bug, then it should definitely be fixed. But not all defects can be fixed. Sometimes you run into limitations that don’t allow you to completely satisfy the customer. In other cases, it’s just not economical or even financially feasible to satisfy all the customer’s needs, and you have to make some tough choices about what to implement and what to scrap. The cost of satisfying a specific need may be higher than the return on investment. And if you have multiple clients (which I hope you have), you can’t satisfy each and every one of them to the same extent. This brings me neatly to the last point I want to convey in this article: cost of poor quality (COPQ).  COPQ COPQ is the cost that would disappear if all processes, systems, products, and people were absolutely perfect. It is a substantial cost you inherit from all sorts of problems. It is usually compared to an iceberg: you only see about 10% of it, but it is the other 90% that lies at the base of your additional cost. Let me give you a manufacturing example first. Assume you have a defect rate of 10% in your production cycle. That means that to sell 1000 items, you actually have to produce 1100 items. And that means that you’re making 100 items on which you make no money whatsoever. The cost of making those 100 extra items is your COPQ. The origin of these defects can lie in a lot of places: defective base components; bad machinery; etc. Where do we find COPQ in software development? Well, the defects are obvious by now, as we’ve discussed them above. However, the source of those defects can be found in faulty tracking systems, bad management, poorly trained developers, not using the technology as it should be used, lack of documentation, too many system failures, etc. If you see an issue that can be ascribed to COPQ, you should dig further and really get to the bottom of it to find the source of the cost. And then you must act upon it and not just leave it as a known issue. If you really want to improve something, you should grasp every chance you have, because the cost of improving things will earn itself back in virtually no time at all. Conclusion Mario Andretti, a former F1 world champion, once said, “If you feel like you have things under control, you’re just not going fast enough!” This is a motto by which I try to live by and which also applies to lean thinking in my opinion. Because I believe that if you feel comfortable in your situation, it means you have room for improvement. When it comes to continuous improvement, you should always step outside your comfort zone and find new or better ways to improve what it is you’re doing. After all, it’s called “continuous” for a reason! About the Author Steven Peeters is a freelance consultant with an extensive background in both application and web development. As an Adobe Certified Instructor he has also given trainings to various people and institutions in the BeLux region. In 2012 he started his own company, Silver Lining, with the intention to combine the training aspect with consultancy in project, change, and process management. With this goal in mind, he started focusing on lean six sigma, becoming a lean six-sigma black belt and applying these techniques to an IT environment. READ THIS ARTICLE ONLINE ON InfoQ http://www.infoq.com/articles/applying-lean- thinking-to-software-development Take the GUESSWORK out of TEAMWORK Try it FREE FOR 30 DAYS at LEANKIT.COM/TEAMWORK
  9. 9. Contents Page 9 Lean & Kanban / eMag Issue 10 - March 2014 Queues: the True Enemy of Flow by Paul Dolman-Darrall When a project is late, it’s rarely because of how long the actual work has taken us. It’s more often connected to how long our tasks have spent inactive, sitting in a queue. And yet project-management offices tend to focus on activity time, not queuing time. The only queue most IT departments measure is the backlog, but there are hundreds of others. This article examines why we ought to track them and how much they cost us. Why is it taking so long? Discovering the true enemy of flow A watched kettle never boils. If we’re longing for a cup of tea, we complain about how long the kettle takes to boil. But boiling a given amount of water is an activity you can do very little to speed up. It’s only your desperation for tea – symbolised by your anxious attention on the kettle – that makes it seem slow. Let’s imagine you thought about having a cup of tea half an hour ago. If you don’t yet have one, the issue is unlikely to be the kettle malfunctioning. It’s far more likely that other things have gotten in the way. Perhaps the phone rang. Maybe you and your partner needed to have a long row about whose turn it was to make the tea. Perhaps you had to tackle the mound of dirty dishes before you could fill the kettle! These non-value-added activities are the true cause of delay between wanting a cup of tea and getting one. All that time, the “boil water for tea” task is essentially sitting in a queue behind other tasks. It’s a proverb, and a situation, that ought to ring bells for most software development teams – yet worryingly, it doesn’t. That’s because we’re so blind to these queues that we don’t even consider them. Rather than asking why it took us so long to put the kettle on in the first place, we stare angrily at the kettle, willing it to boil and muttering about how long it takes. Queues are everywhere All of our working life is filled with queues. Because we are so busy, we find it odd to realise that of a project’s total length, very little is actually work. A project spends most of its time in a series of queues. The queues range from big and obvious delays (waiting to have a team assigned to the project) to minor and almost untraceable ones (a request for information in an email sitting unanswered in a colleague’s inbox). Why don’t we see them? We tend to respond very well to visible queues. We can avoid them (big queue at the bank, I’ll come back later), we can get angry with them (complain to the manager and threaten to move your account elsewhere), and we can manage them (invest in automated pay-in machines to try to reduce queues at the bank).
  10. 10. Contents Page 10 Lean & Kanban / eMag Issue 10 - March 2014 In manufacturing, where queues are large piles of inventory on the factory floor and thus present on the balance sheet as unrealized assets, management will expend a lot of effort to reduce them. But inventory that queues up in software development is invisible. Most of our work is made up of information: ideas, design, and lines of code. The impact is just as severe for us as for the manufacturer, however. The longer that partially completed work sits there gathering metaphorical dust, the greater the danger that the value could disappear altogether. The opportunity could pass, a customer might walk away, technology or the environment might change... The sunk cost would be irretrievably lost, the hours of time invested to date, wasted. Because our queues are invisible, we find it easy to ignore them. If we double the number of requirements in a project, no warning bell sounds. Developers in the department might look slightly more stressed, but there is no real way of knowing what the change has done to their work or to how quickly they will complete it. Now imagine we double the number of developers on the project. Everyone would notice that! Not only is there a sudden scuffling for desk space, but managers would be in crisis meetings trying to find extra budget to pay their wages. Queues have a major effect on our cycle time In a system that had no queues at all, the cycle time (the time taken on average to deliver a single set of requirements) would be the sum of all the activities. That means decision gates wouldn’t take the week marked out for them in the project plan, or even a day, they’d take the two hours actually spent in discussion. Researching an idea for development (maybe a daring new user interface) wouldn’t take four weeks, it would take the actual five days of prototyping potential layouts (four prototyping teams would run concurrently) plus the actual time to collate and analyse the results – an extra day, perhaps. A project run with zero queues takes an extremely short amount of time. It is also, of course, very costly. To have zero queues, you need to keep your people free from other work: your tester needs to be on standby, ready to jump in whenever required; you need a stable of consumers ready to answer questions on your latest idea whenever you want feedback; the CEO must be willing to immediately receive your calls whenever you require CEO approval on something. If the fastest cycle time means zero queues, then long queues mean the opposite: the longer the queue, the slower the cycle time. We understand this – we look for short queues at supermarkets because we expect to be served faster. Work in a queue is doing nothing, and each day in a queue is an extra day added to total cycle time. In short, queues have a direct economic impact on the business. They increase inventory and stall valuable projects. They increase the risk of loss, delay feedback, and affect motivation and quality. Yet in spite of this, they are rarely tracked or targeted. A company that carefully keeps account of every hour of overtime is quite likely to be blissfully unaware of the cost of delay to a project caused by long queues. Long queues cost more Faced with a long queue, we tend to react with optimism. True, we say, I just had a big rush of work, but now things will calm down and I can get through my list of things to do (a queue). But our optimism is misplaced. As soon as any single task takes longer than we expected, a queue begins to form. It is unlikely that this will correct itself through lots of quick and easy tasks arriving in the queue. Instead, as the queue gets longer and further out of control, the probability we will be able to get the queue back under control greatly decreases. It’s known as the “diffusion principle” and there’s quite a neat mathematical proof for it. As soon as a trend moves in one direction, the less likely it is that we will return to our original starting point. Our inability to intuitively grasp this probability issue is one reason that so many investors hold onto falling shares, stubbornly hoping they will go back up. In actual fact, when it comes to queues of work, the principle is even further weighted against us. Experience shows that even with honest planning, most of us tend to underestimate how long tasks will take – so most tasks take longer than expected, making the rate at which long queues get longer even faster. If the first task takes longer than expected, then all the tasks behind it will be delayed. If each of these has a cost of delay then you will pay the cost
  11. 11. Contents Page 11 Lean & Kanban / eMag Issue 10 - March 2014 on all of them (even though only one task actually overran). This is why long queues have a much more devastating economic impact – and when really long queues have formed, catching up with them becomes increasingly unlikely. The UK Border Agency is a famous example. In 2006, the government ordered the agency to deal with 450,000 unresolved asylum cases within five years. By the summer of 2011, the agency still had 147,000 unresolved cases. There were 150 boxes of unopened mail from asylum applicants, their lawyers, and constituency MPs stored in the office. As each case was delayed it became harder to trace applicants. Often circumstances had changed – having had a child in the intervening years, for example, often meant applicants now had a right to remain. Such cases blocked all the cases queued behind them, meaning that they too would suffer the same problems. Politicians remained focused on the activity – how fast and accurately staff were processing cases – rather than the true block defeating them, the length of the queue. Reducing the queue meant accepting unpopular decisions, like granting amnesty to anyone whose case spent longer than five years in the queue. Without that, the queue continued, spreading its economic, and human, damage. So what action should we take? 1. Measure our queues. If we only look at output (the stream of asylum cases being resolved), or activity (the agency staff looking busy), there will be a long delay before noticing a problem. When we measure queues, we receive an early warning. At the simplest level, we can simply measure how long work takes to pass through the queue. This could be overall cycle time from concept to cash or it could be through specific processes. Start by recording the moment a task enters development. Measuring the exact amount of time the task takes in each process. Record the moment the task is finished and deployed. By subtracting the work time from the total time, you will get an idea of how long a task spends in queues. 2. Make queues visible A helpful visual depiction of the queue is the cumulative flow diagram (CFD), which tells you not only the size of the queue but whether it is exacerbated by a large number of arrivals or a lengthy service time that results in few departures. It is particularly helpful for spotting emerging queues. Many teams depict queues as sticky notes or cards stuck on a board in swim lanes that represent processes or individual developers. Almost immediately, it becomes clear when a particular process is in danger of being overwhelmed as a queue begins to form. 3. Estimate our queues We can estimate queues using Little’s law. It equates average waiting time with queue size and processing rate. It is very robust, applicable to everything from the overall system to the individual product queue and it is also simple to explain compared to other queuing-theory concepts. Average waiting time = queue size/ average processing rate This is the function being used to determine how long it should take to answer a phone call or how long it should take to go from a given point to the front of the queue for a rollercoaster. It means we can work out how long it will take to get to any individual task. It’s a piece of information that can really help product owners decide whether they need to reprioritise. 4. Sequence our queues Once our queues are visible and measureable, we can start to prioritise or sequence them so as to maximise value and minimise pain. We can do this pretty quickly and know that we’ve got a good approximation. We begin with tasks for projects with the highest value. Where the value is equal, the shorter task should take priority, since it blocks the resource for a shorter time and by completing it we can realise its value. 5. Purge our queues If a job has not been worked on for a certain length of time, perhaps because other tasks have moved ahead of it in the queue, then it’s time to purge the job. If people object, it means the purge has acted to focus their attention, and we can assign a new priority to the purged feature or task and resubmit it.
  12. 12. Contents Page 12 Lean & Kanban / eMag Issue 10 - March 2014 Where should we hunt for queues in IT? The fuzzy front end Reinertsen and Smith memorably described the period in a project before the development build begins as the fuzzy front end, which consists of approvals, exploration, capability studies, etc. Companies invest a great deal of time in ensuring that they only devote resources to the “right” idea. This causes a big queue at the very start, as each idea needs a project plan that details cost and expected return on investment (none of which can exist without prior investigation). It is ironic that companies do this in order to minimise their risk, but in the process cause such long delays to overall cycle time that they actually increase the risk of the ideas they select becoming obsolete. What can we do? If you can quantify the cost of delay for each project or idea, you can help focus management attention on making faster decisions or testing ideas out to gain funding incrementally. Specialists We tend to manage specialists for maximum efficiency. Because they are often expensive, we like to keep specialists fully utilised. This is the recipe for a queue. Employing more specialists is expensive and companies are often reluctant to invest a specialist’s time to train others. What can we do? Having generalised specialists – such as developers who can test or statistical modellers who are happy to pair – can be a fantastic way to add temporary spare capacity when required. The team can also provide support to help work flow as smoothly as possible through the bottleneck. This can range from offering secretarial support (you want specialists working, not booking train tickets) to doing as much advance preparation as possible. Environments Big queues in software are not always about people. They are as likely to be caused by hardware and environments. Hardware is frequently a constrained resource, either in itself or because of how it is set up. What can we do? Sharing an expensive resource makes complete sense to those considering efficiency, but efficiency must also factor in the cost of delay. Teams themselves must also work to manage the bottleneck – preparing setup instances in advance, for example. Conclusion Queues are a fact of life. We are not trying to present them as the embodiment of business evil, but they lead to delays and delays usually have an associated cost. In many cases, this cost may be worth bearing compared to the cost of eradicating the queue. National Health Service GP surgeries tend to happily function with long queues, for example. They are more concerned with the capacity utilization of the doctor than the cumulative delay to patients. Private healthcare clinics will have a very different attitude to queues and may be prepared to run with lower efficiency in order to ensure patients don’t wait. A blindness to queues means you are unable to make such decisions. It means that your business could be suffering huge bottlenecks and incurring a heavy cost of delay in complete ignorance. A company that is worried about delivery times but looks only at activity and not queues is watching a kettle when the fire has gone out. About the author Paul Dolman-Darrall is an IT director known for developing people and successfully leading large global teams across various change programs for some of the largest companies in the world and contributed to strategy of government. At Emergn, in his role of executive vice-president, he has helped launch value, flow, quality (VFQ) education, a work-based learning program to help practitioners achieve immediate business results through the application of skills in practice. The program is designed to help IT departments and business leaders who rely on technology to put in place smarter, more effective work practices to facilitate change, generate significant return on investment, and inspire innovation in practice. READ THIS ARTICLE ONLINE ON InfoQ http://www.infoq.com/articles/queues-enemy-of- flow
  13. 13. Contents Page 13 Lean & Kanban / eMag Issue 10 - March 2014 Kanban Pioneer: Interview with David J. Anderson David J. Anderson, a pioneer in the application of kanban for software development, recently came to Brazil. A group of InfoQ Brasil editors interviewed David about lean, agile, and kanban. Here are the highlights. InfoQ Brasil: How would you relate the lean and agile philosophies? David: There’s obviously a lot of similarity. One of the differences lies in the fact that lean has a philosophy of pursuing perfection and yet agile has this underlying idea that you make progress with imperfect information and you course-correct later as you learn more. A lot of lean thinkers would struggle with that; they would struggle with the idea that you should move forward with incomplete information. They would think of the rework as waste. Agile isn’t about the pursuit of perfection. So that’s one key difference. Another difference that I believe exists between lean and agile is how people are considered in the two philosophies. In lean, there is a system-thinking view. The idea is that people’s performance is largely influenced by the system they are part of, and the way you respect people is to design a system that allows them to work effectively. Agile has more of a humanist approach to people and respects them as individuals. The philosophy is an anarchist/ libertarian view that people should be left alone to do the right thing and that best results come from self-organization. With respect to people, lean and agile are very different. And within the agile community, particularly in the U.S., there is a lot of political influence; some people are very humanist or they are very libertarian or quite anarchist in their philosophy. The idea that everyone should be allowed to do whatever they want because people are inherently good (and therefore we can just trust them) is strong in the agile community. Personally, I think it is wishful thinking. Historically, there has been some pure communist influence on the agile community. This manifests itself with ideas like: all managers are bad; any attempt to control people is bad; any attempt to assert authority over people is bad. I’m not convinced that this is true, and I think that lean-thinking people have a different view. They believe in building systems and that there is a class of people who do that and who operate the system. Kaizen culture is not self-organization. So there’s a very different approach to people and organization between agile and lean. For me, it is perfectly okay if somebody wants to come to work, do their job, collect their paycheck, and go home and get on with the rest of their life - to worry about their family. It’s okay if their passions lie outside work. I believe a lot of agile people think everyone on a team should be deeply passionate
  14. 14. Contents Page 14 Lean & Kanban / eMag Issue 10 - March 2014 about their profession. I don’t think that’s practical or realistic or pragmatic for large-scale implementations and for bigger companies. This idea of depending on profound passion for the profession may work for a six-person startup company, but not for a 300-person business unit at a big company. InfoQ Brasil: What about empowering the team? Doesn’t it go against this idea? David: Empowerment isn’t about letting people do whatever they want, or assuming they’ll somehow self organize to produce the right outcome. Empowerment is about defining boundaries, and we do the same with children when bringing them up; we tell them things like when their bedtime is, where they’re allowed to play, whether they’re allowed to go outside the yard of the house, they’re allowed to swim at the shallow end of the pool, they aren’t allowed to jump from the diving board... all these things. So empowerment is about giving people clear boundaries, and then letting them use their initiatives inside the boundaries. InfoQ Brasil: You recently added an additional core practice to kanban: implement organizational feedback. Why did you feel the need to do that? David: I didn’t really add the practice, I’ve just made it explicit. In my book, Kanban: Successful Evolutionary Change for Your Technology Business, there was always an entire chapter on that topic; I just didn’t enumerate that as one of the core practices. I realize that was a mistake because we were not seeing enough adoption of organizational-level feedback loops. Sometimes, if something is not happening, you need to make it more obvious, and adding it to the list of the core practices had this objective. So it’s not new, I’ve just highlighted it. InfoQ Brasil: You say kanban is a way to level demand with capacity. Could you tell us the advantages, and how should we try to convince business people this is important? David: We want to balance the demand against the capacity and against our capability, and it’s clearly important that we avoid overburdening our capability. If we overburden ourselves, we actually produce less, with poor quality, and it usually takes longer. By creating a balance we can actually improve the capability and see things happening faster. We will get more done. Quality will be better. In regards to the business people, they need to be able to understand what it means to limit demand against capability. It means that we have to ration demand against our capability to supply, because there will always be more demand than we are capable of supplying. There is no limit to human ingenuity. What’s really important is to be able to accurately assess the risks, reward, and benefits of all these ideas for new software that people will have. So, there is great value in helping the business to analyze the risks and understand the benefits of their ideas, and to help them focus on providing the best ones with some balanced portfolio of demand against our capability. While we may try to improve our capability to supply, they also need to learn how to choose the best options from the available set of ideas. If we can do both of those things (increase our capability and limit/improve the risk management of demand), then we can live with a lot more harmony. One of the reasons we see more and more demand is that there’s uncertainty in the future and business people can hedge their bets by saying, “Just build everything.” Clearly that is not practical, so we need to help them to better assess risks and to understand the uncertainty that they are facing. That way they can have a greater confidence in the choices they are making. InfoQ Brasil: Are there any myths and misconceptions about kanban? If so, which would you say are the most frequent or important? David: Alan Shallaway has published an article on myths of kanban; it may be a good reference. I think there are a number of myths. One of them is about the board. In fact the Agile Alliance has a web page about the kanban board as an agile practice. The kanban method is not called “kanban” because there is a board, it’s called kanban because it implements a virtual kanban system, a pull system for limiting the work in progress and deferring commitment until what lean people would call the “last responsible moment”. The board is just a way of visualizing what is going on there. The board was added later; the kanban system came first. Boards were just known as “card walls” back then, and they were common enough within the agile community. The board wasn’t novel; it didn’t
  15. 15. Contents Page 15 Lean & Kanban / eMag Issue 10 - March 2014 represent an innovation. The use of virtual kanban systems was the innovation. There are a number of other recurring myths. One of them is that kanban is only for maintenance and IT operations and you shouldn’t use it on big projects. That’s clearly just disinformation. In 2007, for instance, we did an $11-million project with more than 50 people using kanban. So we’ve being doing it on big projects since the very early days, and you would choose to do kanban because it helps to improve your predictability and your risk management. These are clearly important things when it comes to project management and governance – having some certainty over delivery schedules. Unfortunately, the myth that kanban is only for maintenance and IT operations and that you shouldn’t use it on big projects is common and recurring amongst those in the agile community. InfoQ Brasil: What about the myth that kanban would bring us back to waterfall? Is this one still around? David: The waterfall myth was very common from 2007 to 2009, but we don’t hear that so much anymore. That was primarily because a lot of early examples were done with teams using traditional SDLCs or methods that are not recognized as agile, like the Personal Software Process and Team Software Process. So the early kanban examples were all non-agile examples. This was natural because I introduced kanban as a way to improve teams that were rejecting agile methods. It’s natural that, if that was the case, all the early examples are non-agile examples. However, nowadays it’s very common; in maybe more than 50% of cases, people add kanban on top of scrum, so I think that myth has largely gone away. InfoQ Brasil: You have recently considered adding the practice of “giving permission for ideas and encouraging process innovation”. Would you tell us why you didn’t do it? Do you see the need for a “kanban master”? David: Actually, I added the idea that you have to encourage leadership and get people to recognize that leadership and management are different things in the principles of the kanban method. Managers are responsible for the system they’re operating, the design of that system, all the policies, and the decisions that get made to change a policy or override it. So that’s all very well, but truly we want anyone who’s involved in doing the work, whether they are individual contributors, or managers, to show acts of leadership. An act of leadership is to say that whatever’s happening now is not good enough and suggest or show that we can do better. If you don’t have that, then you don’t have the catalyst for continuous improvement. Everyone could shrug their shoulders and say, “Oh, well, that’s the way it is. Back to work!” Nothing would ever get any better. So leadership is the magic ingredient. It’s the catalyst. Recently there’s another similar example: Håkan Forss, who’s a kanban consultant from Sweden, has been reading Mike Rother’s book, Toyota Kata, and this led him to suggest that kanban has three kata. One is the daily standup meeting that provokes local kaizen events. Another one is the operations review that provokes those inter-workflow, inter- Kanban system improvements. And the third one is the relationship between the superior and the subordinate, the first-line management and the second-tier manager, where the more senior one is coaching the less senior one on “How well is our system operating?”, “Do we have the right policies?”, “Are we gathering the right metrics?”, “Are we visualizing the right things?” So we can understand the world we are living in and make changes to improve it. InfoQ: Is the community getting used to the term “kanban master”? David: No! We are really discouraging the idea of a kanban master (as a direct comparison to the scrum- master role). I do think there is value in using a coach. It is a different role typically from what we see in agile coaching. When I look at agile coaches, they are often embedded with teams and they are there every day of the week. We see that kanban coaches are typically only there two or three days a month and are usually talking to people about policies and visualization and metrics, and they are helping them understand capability and
  16. 16. Contents Page 16 Lean & Kanban / eMag Issue 10 - March 2014 think about improvements. In order to do that, they don’t need to be there every day of the month. InfoQ Brasil: InfoQ has recently published an article about kanban being the next step after scrum. What do you think about this? David: If they are talking about market development, that we see kanban becoming the next significant thing in the software-process market, I think that’s correct. There’s a lot of evidence that we have real momentum for kanban training, coaching, consulting, kanban software, simulation, games – all sort of things – so I think from a market perspective, kanban is developing as the next thing. If you think that there was CMMI, there was RUP, there was XP, and there was scrum, kanban is the next thing in that succession. But if they meant that people should do scrum before they do kanban… I think that’s completely wrong. Scrum is difficult to adopt for a lot of organizations. It’s culturally the wrong fit for many companies and people resist adoption of it. Kanban, on the other hand, is designed for easy adoption. It’s designed as a way to start with what you do now. It’s an alternative to scrum. If we waited for people to overcome their resistance [to scrum], they would have lost a great opportunity to make improvements much quicker by adopting kanban earlier. If people are already doing scrum and they feel the need to improve even further, then maybe adding kanban later is a good idea. But if they are not currently doing scrum, they should think about kanban as an approach that they can start immediately. InfoQ: In Jurgen Appelo’s book, Management 3.0, he talks about “memeplex”. Appelo argues that it is a reason scrum was so successful in its adoption is that scrum replaces the current memeplex with a new one. What’s your take on this? David: I’m not going to argue with that suggestion; the challenge is, can you do that complete removal and replacement of the memeplex? While we can say it’s been successful, there has also been a tremendous amount of resistance. There are a lot of either challenged or failed scrum adoptions. One relatively recent piece of trustworthy market research I saw said scrum had about 15% market adoption. That’s better than RUP has ever achieved; the best RUP got was about 11%. So 15% is good, and you have to ask how many out of that 15% are challenged implementations. But let’s be generous and say all 15% are working wonderfully. That leaves the other 85% of the market. I think that’s the problem I want to solve. What’s better, to help people do scrum better and focus on 15% of the market or try and help the other 85% of the market? I wouldn’t doubt that many of these things Jurgen has said about scrum are correct and accurate. However, there are many other more interesting problems to be solved in the universe and in the world of management and software process and I’m more interested in the rest of the space. I’m sure there are plenty of people in the scrum community that are interested in improving scrum. About the Interviewee David J. Anderson has 30 years experience in the high-technology industry, and has led software teams delivering superior productivity and quality using innovative agile methods at large companies such as Sprint, Motorola, and Microsoft. David is the author of three books, Agile Management for Software Engineering – Applying the Theory of Constraints for Business Results; Kanban – Successful Evolutionary Change for your Technology Business; and Lessons in Agile Management: On the Road to Kanban. READ THIS ARTICLE ONLINE ON InfoQ http://www.infoq.com/articles/David-Anderson- Kanban Take the GUESSWORK out of TEAMWORK Try it FREE FOR 30 DAYS at LEANKIT.COM/TEAMWORK
  17. 17. Contents Page 17 Lean & Kanban / eMag Issue 10 - March 2014 During our conversations with David J. Anderson, kanban pioneer, at the Lean Kanban Conference in Chicago, we asked if there was any kanban quick-start guide that might demystify things. David recommended we speak to Dr. Arne Roock of it-agile, author of the 30-page kanban booklet Stop Starting, Start Finishing. Dr. Roock is a speaker and chair of the Scaling Kanban track at the conference, and also works as an agile consultant and trainer in Germany. InfoQ: Based on the current literature, kanban seems to be somewhat philosophical. How can a team evaluate whether it is the right tool, and what is required to kick it off? Dr. Roock: The most important thing is to agree whether we want to change at all. If we don’t want to change, then kanban is not for us, because kanban first and foremost is a change method. Often people mix it up with project-management methods or development methods, but it’s not; it’s a change method. There is just one prerequisite for change: there needs to be what leadership authority John Kotter calls in his book by the same title “a sense of urgency”. The second thing is, if we agree we want to change, there are two main strategies. The first one is revolutionary. It means turning the organization upside down and inside out and making a huge change, which causes a lot of pain, but we are hoping that after this change we are a lot better off than before. That is not the kanban approach. Kanban is a method for evolutionary change. InfoQ: Let’s say we agree we are ready for change. We want to do the right thing. If it takes a revolutionary change, we are prepared to do that, but if we can realize significant improvements with an evolutionary change, we prefer that. We want to see results in terms of improved delivery and improved predictability and transparency. In my experience, before we start introducing kanban, we need to agree on the major goals. That means we need to have management support. You might try to introduce a grass-roots, stealth approach, hiding it from management, doing it in just one team. There can be some limited success with this approach but you will hit your limit very soon. If you want it to be really successful company-wide, you will need management support. It’s important to talk to the management and understand what they Implementing Kanban in Practice
  18. 18. Contents Page 18 Lean & Kanban / eMag Issue 10 - March 2014 are trying to achieve, their pain points, and the goals they want to achieve. In your example, the goal is “We want predictability and improved delivery.” So the first thing I would do is create visibility for the end-to-end flow. A huge problem in knowledge work is that we cannot see or touch our work. If you go to a factory, you would see a lot of raw materials and unfinished goods on the shop floor. But if you look in any random office, they all look the same; you have the desk, you have the keyboard, computer, telephone, a lot of paper, and that’s it. We cannot see our work, and that means it is very hard to improve things. So the first thing we do when we start with kanban is a visualization of our work. How many tasks have we started and what stage are they at? How much work do we have in development, how much do we have in analysis, in testing, and so on? This should be insightful. In many cases, people are not aware that they had so much work in progress (which means work that has been started but not finished). The next thing is to create a feedback loop. Observe our flow and our work on a regular basis, and agree on things we want to do to improve our flow. Now we have this transparency, and let’s say we see things are piling up in the testing column. We are faster in developing things than in testing and deploying them. So let’s come together, have an improvement workshop to see what we can do to smooth out our flow. What can we do to work on this bottleneck? The thing that comes to mind first might be to hire additional testers. But very often, that is not the right solution. Perhaps we could improve the quality of the work that goes into the testing stage, or automate things, or move developers into testing because very often developers can do this. So, transparency comes first. Feedback loops are very important. Most kanban teams hold daily standup meetings in front of their kanban board, where they can see their work. And they are doing improvement workshops or, as they are often called, “retrospectives” or “kaizen meetings”. Next would be to have some kind of metrics by which to gauge if we are moving in the right direction. If the goal is to improve predictability and deliver quickly and often, it might be a good idea to measure cycle time, meaning the time from starting a task until it is finished. And let’s see what happens if we move one person from development to testing. Or see what happens if we slice our work differently. Or if we agree on a policy that we don’t want to have more than two items in development and three items in testing. There are a couple of other things we might want to try. Now that we have the feedback loops and the metrics, we can measure results and amplify good things while dampening those that are not working correctly. InfoQ: You spoke about the board, which seems to be the central focus. I would like to understand how granular that should be. Do I go from the beginning to the end or do I only include my development steps? Start with this section of the value stream you can control. If your sponsor is the head of development then the starting point should be the development. Our board would start with some kind of analysis task breakdown, then development, testing, and then some interfaces with upstream processes such as product management and downstream processes such as deployment. Of course, in the long run we want to extend the boundaries. We don’t want local optimizations, we want collaboration across department boundaries. But if we cannot control this, it does not make sense to have all of this on your board if your upstream and downstream partners don’t agree to collaborate with you. This is very important. Start with the parts you can control. Don’t try to evangelize; that’s not going to work. If you achieve better results and make them transparent, people will become curious, and curiosity is a very powerful tool. People will come over and ask you questions like “How are you delivering so often?” or “Why do you have fewer bugs?” What we observe very often is that kanban then spreads across all teams.
  19. 19. Contents Page 19 Lean & Kanban / eMag Issue 10 - March 2014 We heard a presentation from Jimdo, a German company that has kanban for their online marketing team, for their press team, for their video team, and for the partners’ teams. Of course, the kanban boards look different for every team, but all are applying the same principals. That means continuous improvement in small steps. InfoQ: How do you scale the board across distributed regions? That’s a tricky question but it’s relevant because a lot of teams today are distributed. There are a lot of good kanban tools in the market, but there are upsides and downsides to electronic tools. I would try to keep it physically present as long as possible. Even two locations can work with physical kanban boards as long as you synchronize the teams, of course. You can use web cams, instant messaging, or a buddy system by which each region’s team has a buddy in the other region. InfoQ: What do you mean by a buddy? In the buddy system, every team has a buddy that permanently resides in the other location. Every time you change the kanban board, say by moving a ticket from development to testing, you would tell the buddy in the other location to update the board there. You can use phone or video conferencing or instant messaging, and it sounds like a lot of overhead and it is. But you need to have this communication. But you will observe that the buddies will start communicating not just about moving tickets but about things like “I am out next week on vacation, so please remind the other team members to do this and that.” Or “I see you are working on this part of the code. I know this and there are tricky parts, so let me give you some hints.” Now, people are communicating across the team boundaries and that is really valuable. InfoQ: What if there are more than two teams, and large time differences like New York and Singapore, which can be 12 hours apart? Two regions can work but not three; I have never seen that work. The other problem is the time difference, which makes it very difficult to do this. I like to point out that kanban can be like a mean mother-in-law: she tells you what you are doing wrong all the time but she does not improve you. In this case, if you apply kanban you will see a lot of pain among your distributed teams; it takes a lot of effort to synchronize those teams. But that’s the reality whether you have kanban or not. Kanban will make these problems transparent. For more than two locations, you will surely need an electronic tool. But what you also need is a lot of bandwidth for your communication. I have seen this over and over again. When people only communicate via the tool, you’re nailed! People need to keep communicating. Face to face is of course better than video conferencing, which is better than telephone, which is better than email. So make sure people communicate as often as possible. That means you have to ship people to the other location from time to time, even if it is Singapore. And you need to have really good equipment for video conferencing, and you need to have a good kanban tool. Building trust is very important for changing the organization (and that is what kanban is designed to do). It is easier to build trust when people know each other. When people see each other, talk to each other face to face, have a beer together, know a little about their private lives like if they have children or the kind of movies they like, that builds trust, and that is really, really important. Standup meetings are one way to create this forum so that people can come together and talk to each other on a regular basis. Of course, if there is a time difference that is a problem, but you have to solve that in any case – it’s nothing to do with kanban. InfoQ: Is there a standard solution for conducting standup meetings cross-region? Even if there is a time difference, you often have one or two hours of overlap. InfoQ: Well, Singapore is 12 hours behind New York, so even if one region works late, it would be hard to do on a daily basis. Yes, even if you could you’re at different points in your days, so the energy level is different. It is a tough question. There needs to be regular communication, even if some people have to work at night. You can have one person talk to the other team using a round-robin mechanism. Also, we have to tear down the boundaries. Very often we see, for example, a team in the US will
  20. 20. Contents Page 20 Lean & Kanban / eMag Issue 10 - March 2014 complain that “These guys from Singapore broke our build,” or vice versa. Often this starts as a joke, but there is a reason behind it. Sending delegates from one to the other location for a few months can be a very effective relationship device. InfoQ: So let’s say we have buy-in from management. Isn’t it better to start small to mitigate the risk? Yes. That is the basic idea about kanban. You start with what you have, then evolve. If you are visualizing your work, visualize what you have now; don’t try to visualize your target state. We had a presentation from Daniel Vacanti who was responsible for implementing kanban at Siemens Health Care. They did it differently; they had a huge kanban rollout throughout the whole enterprise. But usually we start small, and it spreads virally, team after team. There is a principal in kanban that says to respect current roles, processes, and responsibilities. That is very important and it is related to the evolutionary approach I was talking about. So if you have an organization in which the departments are not collaborating, or you have certain management structures or roles, you must retain all of that. Respect the status quo. If you have test managers, architects, and business managers, you need to keep those positions. Experience shows that people do not like it when we change their responsibilities or their titles. They derive a lot of self-esteem from their professional roles. If I worked as a business analyst for the last 20 years, and we start a new process that has no room for a business analyst, I have to print new business cards with a new title on it, and I will be offended. That’s the reason we don’t do this in kanban at the beginning. But as we move on our journey, we develop trust and we can start to introduce those kinds of changes. InfoQ: How granular should the kanban-board columns be? The columns on the board should reflect the way you work at the moment. It’s usually easy to detect this by listening to people talk. They will say, for example, “We are done with development; have you started testing?” That indicates there should be one column for development and one for testing, reflecting the way people are working. We want a realistic picture of our workflow. On the other hand, if we have too much granularity, too many columns, too many swim lanes, the board is not transparent. There is a rule called “three- by-three”: standing three meters from the kanban board for three seconds should tell you what is going on. You can’t read every card but you can see where things are piling up, and where people have nothing to do. But if you have too many columns or too many swim lanes, you start to get lost. (Editor’s note: “columns” refers to the vertical columns on the kanban board. “Swim lanes” refers to the horizontal rows.) InfoQ: In a scrum process, we have a certain number of stories to work on. If we don’t finish, we bring them into the next sprint, but we keep an eye on how much time is left so that we can apply our velocity and determine how many stories to pull in. So in practice, WIP is already a scrum concept! Yes, it is. Scrum limits WIP by the concept of having sprints. It is different from what we are doing in kanban, even though the principle is the same. In kanban, we have WIP limits per column or per swim lane or per person. The trick is to balance demand against capability. We don’t want to accept more work than we are capable of finishing. InfoQ: Let’s say we have 10 developers working on a project and the capacity of each is one. The WIP limit is therefore 10. When someone gets blocked on something, they can’t take on one more. And if there is a production issue, a developer is forced to take on one more. You are asking two different things. A production issue is called an “expedite” in the kanban world. If we don’t handle those immediately, we have a high cost. In such a case, the expedite would need to break the WIP limit, and certain policies would apply. For example, we swarm on the problems and handle them immediately as a team. Afterward, we must reflect as a team on why we have so many expedites. What can we do to reduce those? That would be the kanban approach. The other thing you referred to is an item that is blocked but is not an expedite. I am waiting for another team because I need information or
  21. 21. Contents Page 21 Lean & Kanban / eMag Issue 10 - March 2014 something from them. I can start another item and break the WIP limit, or I can use this “slack capacity” to improve our system. That is the idea behind kanban. The WIP limit is one very powerful way of creating slack. Slack capacity lets you take a deep breath, see what’s going on, evaluate how to remove the slack, and to remove the root cause. For example, if we encounter the same blocker over and over, maybe we should have one person there, or have their person work here for a while so we can transfer knowledge. Kanban doesn’t dictate how to deal with these blockers. It just says, “Use the WIP limits to create slack, and don’t utilize your people to 100%.” That’s what we do in classic project management. We are always trying to fully utilize people and are thereby wasting slack capacity that could be used for process improvement. InfoQ: Say I am a project manager with some minor exposure to kanban and I want to try it, but my organization won’t invest thousands of dollars to train me. What is the minimum I need to get started? I have seen companies that are quite successful with kanban that didn’t use any external coaching or training. They just read a book or a blog post and subscribed to a mailing list. These were small companies, and I would say the chance of success increases if you have at least one really experienced person. It’s best if they are inside the company, but if you don’t have that then that’s the reason you have consultants. Usually we start with a management workshop, and we evaluate questions such as why are we doing kanban at all? Do we agree to pursue incremental change? What are the goals? After that, we train the team so everyone speaks the same language. We figure out the columns and the swim lanes, how to deal with expedite tickets, and so on. After this, I would help the team on a regular basis to reflect on the system and improve it. Now, that’s not a full- time job. It’s more like a package of a couple of full days at the beginning and decreasing hours as we build internal coaching experience. The amount of coaching is not huge but it increases the chance of success. InfoQ: How much time should the coach spend in the organization? That is difficult to answer generally. It depends on how many teams the coach is working with. A coach working with three or four teams at the same time would be a full-time job. But if you have only one team, the best strategy would be to have small amounts of coaching more often. One day per week every week would be better than a five-day stint every six months. InfoQ: Do you have any other final advice? One thing I think is important. What we try to achieve with kanban is to understand the way we are working, and to understand our work. That is one basic value behind kanban. If a consultant comes to my company and says you must do this and this, he is probably wrong. A good change manager facilitates the process of having everyone in the company, and especially the leaders, understand the way they work, because otherwise it is really hard to improve. So don’t just apply kanban by the textbook. Try to understand why you want to have WIP limits, why you want to have transparency, and all this stuff. If you do that, there is a good chance of success. About the Interviewee Dr. Arne Roock works as a trainer and coach for lean and kanban for it-agile in Germany. His focus is on helping companies establishing a kaizen culure using kanban. He wrote several papers on lean/kanban and translated the book Kanban – Successful Evolutionary Change for Your Technology Business into German. Arne is founder of the first Limited WIP Society in Germany and is a board member and organizer of the Lean Kanban Central Europe conference. The Lean Systems Society has rewarded him with the Brickell Key Award 2012. You can contact Dr. Roock via Twitter, his blog or his e-mail address. READ THIS ARTICLE ONLINE ON InfoQ http://www.infoq.com/articles/Implementing_ Kanban
  22. 22. Contents Page 22 Lean & Kanban / eMag Issue 10 - March 2014 Using Kanban to Turn around Distressed Projects by Steve Andrews This case study describes how kanban and lean development techniques rescued a distressed project. Background This particular project was a custom development project for a large client that had been in progress for about a year. The development team fluctuated in size from 10-15 team members. The team started the project using a typical waterfall development model. An analysis phase preceded the development phase. The analysis phase was supposed to take two to three months but ran beyond that time. During the analysis phase, the scope grew beyond the initial understanding of both the client and the development team. Because the client insisted on getting the requirements “nailed down” and “signed off on”, the analysis phase ended up taking about six months to complete. Although the analysis phase ran long, the project end dates were not pushed out to compensate. As a result, the development team was pressured to deliver more-than-anticipated functionality in a shorter-than-anticipated time frame. They missed development deadlines, and since testing was bolted on at the tail end and compressed, the quality of the developed solution was inadequate. The development team operated in an interrupt- driven manner because the project manager did not manage the client well enough to protect the development team from distractions. The typical pattern was that the client would yell at her about quality issues, and she would pass that to the development team. Whatever was the crisis of the moment was what received attention. The development team was never able to focus on a problem and drive it to completion before the next problem interrupted their work. By the time I got involved, the relationship between the client and the development team was damaged and the client was refusing to pay. The solution was unusable by their users from standpoints of functionality, reliability, and performance. The project had run overbudget by hundreds of thousands of dollars. The schedule was blown by months. Neither the client nor the development team could afford the fallout of a failed project, so it had to be turned around. Getting Control The first thing to do when confronted with this type of situation is not to panic. In this particular case, the client was agitated and had zero confidence in the team. The client was blaming the team and the team was blaming the client. Morale was poor, and getting worse because management was demanding that the team work harder to fix the problems. 
  23. 23. Contents Page 23 Lean & Kanban / eMag Issue 10 - March 2014 One of the worst things you can do is to dig in your heels and keep doing what got you in the situation in the first place. Experience has shown me that the best way to start removing the emotion from these types of situations is to work with the data and facts. It is important to understand the root causes responsible for the situation in order to best craft the path forward, but it is not helpful to initially present the team with all the things they should have done differently. That only inflames the situation further. In this particular case, the main fact was that product quality was terrible. The number of reported defects supported this. We had to get the product to a point where the users could actually do their jobs. And the only way we could start to do that was to create an environment in which the development team would be able to focus on one problem at a time. Create a Culture of Quality It seems strange to think that, despite all the advancements in software development, we need to keep re-emphasizing the importance of building software that actually works correctly. Yet this is one of the main areas where software projects continue to be challenged. In the earlier part of the project, the development team spent months trying to document in great detail what they thought the client wanted. This led to a false sense of security, that they (and the client) knew for sure what they were going to deliver in the end. In addition, the only team members that were engaged with the client in the analysis phase were the analysts. The developers were not brought onto the team until the requirements were “done”. This led to the following phenomena: The developers had to digest and interpret the requirements set out in a document running 200-300 pages. The client continued to make changes to the requirements even after both parties signed off on the analysis document, which meant that the developers’ work was continually invalidated. This caused the development to push beyond the originally planned completion dates. Testing happened at the very end, after all development was “done”. Since the original deadlines had passed, testing had to happen in a hurry. Quality was less a measure of whether the developed software worked correctly and more a measure of how frequently testers and developers interpreted the requirements the same way. The ultimate result of all this was that hundreds of defects escaped development and made their way in front of the client. Defects are the worst kind of waste because they are unimplemented requirements for software that has already been developed. This means the client pays for software to be developed and then the client (or the development team) has to eat the cost of making it work correctly. Clearly the way the development team was working did not put quality first. In fact, it put quality dead last. Since analysts, developers, and testers were matrixed onto the project to do their specific tasks, they never really learned how to work as a cohesive unit that felt collective responsibility and ownership of system quality. When problems arose, they pointed fingers at one another. In short, they had failed to develop and embrace a culture of quality. The single most important decision we made to get control over quality was to require the development of acceptance tests for work items before a developer could write code. This is called acceptance-test-driven development (ATDD). With ATDD, we literally put quality first. The way we made ATDD work on this project was to require a set of acceptance tests to be associated with each work item in the backlog. This effectively documented the requirements that were unsatisfied by the developed code. It also forced the tester and developer to get on the same page, before coding started. The developers’ jobs became focused on passing the failing acceptance tests. It is important to clarify that tests were developed for each work item in turn, not for a batch of work items at a time. This approach takes the guesswork out of whether the developed code works properly or not. The test either passes or fails. Yes or no. True or false. Since each developer focused on one work item at a time, they never had to understand as many acceptance tests as they would have when required to digest the entire analysis document up front.
  24. 24. Contents Page 24 Lean & Kanban / eMag Issue 10 - March 2014 The state transitions for an acceptance test were: Failed – The test initially fails because code has not been developed to make the test pass. Developed – The code to make the test pass has been developed. The developer identifies this transition as they implement the code. Passed – The testers have verified that the developed code does pass the test. Using the ATDD approach alone had the most positive transformative effect on product quality. In the first eight weeks of ATDD use, we transformed the project from one that had no documented test coverage to one that had a library of tests and a documented history of passing tests that asserted the overall quality of the developed code. Eliminate Waste and Control the Flow of Work with Constraints As mentioned, the development team started off working in a waterfall approach. However, things broke down into an ad hoc approach once development began and uncontrolled change invalidated the big, up-front requirements document. From there, it didn’t take long for the line from the code back to the requirements to become blurred and eventually erased. The profile of the work assignment was a classic push system with a very large batch size. The analysis team pushed a large requirements artifact on the development team. The development team pushed a large code base plus the requirements artifact from the analysis team on the test team. When testing uncovered defects, a manager pushed them to specific developers. When the fixes were made, a manager pushed them to specific testers for verification. This approach resulted in a lot of waste. In the analysis phase, a vast number of unimplemented requirements accumulated. In the development phase, a vast amount of untested code was developed. In the test phase, a vast amount of unimplemented and improperly implemented requirements were identified. Decrease Batch Size A large number of defects escaped development and made their way in front of the client. The origins of this phenomenon can be traced back largely to the batch size that the team was working with. The team simply did not have the capacity to move forward the entire batch as a unit in a way that maintained the integrity of the unit as a whole. Trying to move such large work products forward resulted in each team becoming a bottleneck for the team that needed to perform the subsequent tasks. In the end, it became a Sisyphean task that sent work products backwards from testing to development to analysis. And the process kept repeating. In other words, all the work done up front to lock down the requirements was complete waste because once defects emerged, the team had to keep asking themselves, “Now, what was this supposed to do?” Even having to ask that question is wasteful. Work as a Team Breaking the destructive cycle and getting the team to a state where they could actually close work items and keep them closed meant changing the team structure and fundamentally altering the way that the team moved work items from pending to done. In fact, it meant changing their definition of work “done”. The fact that the team members did not share a common sense of ownership of the solution was a major impediment. The first thing we did was to dissolve the matrix organization. Analysts, testers, and developers were now just part of the development team. Along with this, we directly set the expectation that it was their collective responsibility to deliver a quality product and that they all owned quality, not just the testers. We also physically co-located all the team members in a large conference room. This further reinforced
  25. 25. Contents Page 25 Lean & Kanban / eMag Issue 10 - March 2014 the fact that they were a single team with shared purpose. It also meant that now they had to actually talk to one another instead of emailing from one cubicle to another. From Push to Pull The next thing we did was to remove tasking authority from the project managers – that is, managers could no longer push work to the team. As mentioned, the team was operating in an interrupt- driven mode, wherein a manager would task team members in an ad hoc manner, which resulted in a low probability that the previous task would be completed.  To put some structure to the development effort and seal the exits through which defects escaped development, we introduced a pull system using kanban. The kanban approach forced the team to work with smaller batch sizes. Initially, this was easy because the all work items that needed to be completed were defects, which are usually pretty small to begin with. It also forced us to define the word “done”. With this approach, work items (depicted as cards) made their way from left to right on a kanban board through a series of states (depicted as columns) starting with “Pending” and ending with “Accepted”. Whenever a card was ready to be worked on, a team member would pull it into the next column, which meant they were working on it. Team members had to apply their particular skill at the right places to keep the cards flowing. A work item was not “done” until it had passed through each of these states and ended up in the Accepted state. “Done” now meant “Accepted”. Each column represents work that needs to be done to move the card forward. In order to decrease coordination costs related to communication of completed tasks, we added ready states to indicate that the previous task was completed and the next task is ready to be performed. For example, when the acceptance tests have been developed, the work item is ready to code. The kanban board provides a simple, visual mechanism that encapsulates the process a work item needs to go through. It also provides a way to see the progress status of work items at a glance. The columns on our kanban board are listed below. Note that the first task for each work item is to define the acceptance tests as described above. Pending Develop Tests Ready to Code Ready to Stage Ready to Accept Accept Accepted In many cases, a kanban board can be drawn on a wall and sticky notes can represent the work items. In our case, the team was geographically spread out, and I wanted to make sure that we were constantly relying on the captured metrics to make more informed decisions about how to keep making the process better. We chose VersionOne as our agile project- management tool.  One of the most valuable tools that we used was the cumulative flow chart. This chart allowed us to look at the composition of work to see how the work items were trending towards accepted status. Since we were promoting builds to the client on a weekly basis, we could track the composition of work on a weekly basis. We could also view the cumulative flow in the aggregate across many weeks to understand broader trends. The above chart shows the cumulative flow of work items over the eight-week period during which we were turning the project around. Each of the stacked bars is an aggregate view of the following weekly charts. These charts are the ones we looked at daily to see if we were on track to close work items for the week. We found that having a visual mechanism like this was much more helpful to the team than simply looking at lists of defects in spreadsheets like they did previously. Eliminate Bottlenecks We also introduced work-in-process (WIP) limits to control the pace at which work items could
  26. 26. Contents Page 26 Lean & Kanban / eMag Issue 10 - March 2014 work their way through the kanban states. We observed that the analysts were not able to produce acceptance tests at a rate that kept pace with the developers. Since the developers could not keep working on new development tasks without violating the downstream WIP limits, the analysts became a bottleneck in the system. This forced the team to work together to figure out how to even out the distribution of work to ensure a consistent flow of work items. Sometimes developers had to write and verify acceptance tests (but not for their own development work). We had to add more analysts and testers to the team. In some cases, we adjusted the WIP limits to work out unnatural wait states. Ultimately, the team had to start working as a real team. They had to learn how to think about flowing the work items through the kanban system. This boosted morale, and the team began to own the quality of the result as a team instead of blaming each other when they were matrixed onto the project to perform some specialized skill and then returned to the resource pool. Decouple Planning and Delivery Cadences Once we solved the problem of how to move work through the kanban system, we had to get work items into the backlog and estimated so that the team could just pull the next work item with minimal interruptions. Previously, the development team was simply told what work items to work on and when they were to be completed. In addition to the problems associated with the aforementioned interrupt-driven tasking model, developers never took the deadlines seriously because they had no ownership of the work- item estimates. The project manager making the commitments to the client had no real understanding of how long it would take to complete the work items so just told the client what they wanted to hear. This resulted in deadlines that were rarely met. Eventually the project manager had lost all credibility with the development team and the client. By declaring everything an emergency, the project manager created an environment in which nothing was treated with any urgency. In agile approaches, it is essential that the team doing the work estimates completion of the work it is asked to do. Therefore, we had to also ensure that the estimation task itself caused minimal interruption of the development tasks. Prioritize If everything is important, nothing is. One of the keys to making a continuous-flow, pull system like kanban work is for everyone on the team to understand and agree on the next most-important work item. If everyone knows what work item to pull onto the board next, the team does not need to continuously absorb the coordination cost of figuring out what to do next. The central mechanism for managing the full list of candidate work items is the backlog, a prioritized list of all the potential work items that have been identified by the product owner and users. User stories and defects are kinds of work items. Users and other stakeholders can request a new work item at any point in time. When they do, those requests go into the backlog. Addition of work items to the backlog will have no impact on the work that is currently being completed on the kanban board. Rather, the backlog is a holding place for requested work items. New work-item requests merely represent the development team’s commitment to have a conversation about the requested change with the requester. All work items in the backlog are prioritized relative to one another. The work item at the top of the backlog is the one that has been deemed the next most-important thing for the team to work on. If the product owner cares about the order in which work items need to be completed, they must play an active role to ensure that the backlog is properly prioritized. By the way, the relative priority of work items is constantly changing in response to changing business needs. Previously, I mentioned that we revoked the development-team manager’s ability to task developers. We repurposed the project manager’s role to one of working closely with the client to force them to prioritize the work in the backlog. And, yes, the client had to be forced to do this because until that point, they were accustomed to controlling what the team worked on by throwing a tantrum, which in turn exacerbated the interrupts on the development side. This ended up being a full-time job for the manager based on the large number of backlog items and the frequency with which the client kept changing their mind about what they wanted next.
  27. 27. KANBAN ROADMAP How to Get Started in 5 Steps LEANKIT.COM/KANBAN-ROADMAP Download the free eBook now Contents Estimate One of the rules we put in place was that a work item could not make its way from the backlog onto the kanban board until it had been estimated. The reason for this was so we would not compromise our ability to report on the velocity of the team, which fed into our ability to make future commitments based on the prior performance of the team. Every Monday morning, we held an hour-long (time- boxed) estimation session for the team to collectively estimate the highest priority backlog items that had not yet been estimated. The team estimated as many items as they could in that time period in units of ideal days. The estimates accounted for all the activities on the kanban board. Previously, what few estimates were done only took the actual coding into account. By having the entire team do the estimates, all members felt more vested in delivery of the items within the estimated time. Since all the development activities were included in estimate, the activity also forced them to better understand their teammates’ roles. It increased their cohesion as a team. By doing the estimation session at the beginning of the workweek, we could get it over with and out of the way so the team could focus on delivery for the rest of the week and not be interrupted to make estimates when they needed to be doing development. We observed that there is a dynamic relationship between prioritization and estimation because the product owner may choose to increase or decrease the prioritization of work items based on how quickly or not they can be completed. For example, a user story that the client thought was a high priority may end up not being as important once the client learns that they can get four or five smaller stories resolved in the same timeframe. Conclusion Projects get off track for a variety of reasons. Projects that start off using traditional, predictive planning are more susceptible to derailment. This article has presented a high-level approach for containing projects that have become distressed. Some of the methods may seem counter-intuitive, such as embracing change instead of trying to control it. The idea of letting the development team pull the Page 27
  28. 28. Contents Page 28 Lean & Kanban / eMag Issue 10 - March 2014 next batch of work instead of pushing it to them may seem strange to some. Using the approaches in this case study, we were able to turn this particular project around from one that was on the brink of failure to one where the client was very happy with the quality of software they were receiving and the predictability with which it was delivered. We started seeing positive results in two or three weeks. After eight weeks, the root causes of all team dysfunction had been completely addressed and the team became largely self- sufficient and self-managing. Equally important, the morale of the development team improved significantly. After years of being beaten down by a barrage of unmanaged interrupts and complaints about the quality of their work, they were finally given the chance to prove to the client and themselves that they, in fact, did know what they were doing and could produce a worthy product. The development team now uses the kanban approach for all its development projects. It allows them to more effectively set client expectations up front and deliver predictably on commitments. Kanban is not merely a project-recovery tool. The best way to keep a project from needing to be bailed out is to employ these methods from the beginning. About the Author Steve Andrews is the founder of Fountainhead Solutions, LLC. His vision was to create a company focused on developing innovative software solutions using agile methods and contemporary engineering techniques. Mr. Andrews has an extensive background as a leader of solution-development initiatives for almost 20 years. He is an expert in finding ways to maximize the effectiveness of teams to develop working solutions for challenging problems as quickly and cost- effectively as possible while also improving the lives of developers and users alike. Mr. Andrews holds BS degrees in computer science and mathematics from Vanderbilt University. READ THIS ARTICLE ONLINE ON InfoQ http://www.infoq.com/articles/kanban-distressed- projects
  29. 29. Contents Page 29 Lean & Kanban / eMag Issue 10 - March 2014 The Evils of Multi-tasking and How Personal Kanban Can Help You by Sandy Mamoli Agile coach Sandy Mamoli spoke at the Agile Australia 2013 conference on the evils of multitasking and how kanban for one (a.k.a. personal kanban) can help overcome them. According to Sandy: We all know that multitasking is really, really bad. There’s lots of research out there and it’s nothing new. For anyone like me, you’d probably think, “Well, yeah, it’s bad.” But it can’t be that bad. And also I’m probably kind of better than other people at it anyway so I’m multitasking a bit. She had the audience do a simple exercise that showed how disruptive attempting to multitask actually is. She then told the story of Snapper, one of her clients in New Zealand: Snapper was one of my clients and at Snapper we found a way to combat multitasking. Before I tell you how we did it and what we came up with, I’ll tell you a bit of the background. Snapper is a New Zealand company and they do contactless payment systems. When you take the bus, you put a card there and it just deducts the money. Snapper hired me as an agile coach in 2011. They asked me if I could help them get their projects done quicker and with higher quality and better and with more fun. Obviously, agile was the solution. When I started at Snapper, I talked to the head of the PMO. What she told me was, “We make sure that nobody ever has nothing to do. All our people are on three to five projects so no one is idle. That way, we want to make sure we have full utilization and we get as much stuff done as possible.” I deeply respect the intentions but this is organizational multitasking. We just saw how bad multitasking really is. So what we did was we started to take one level of the multitasking and just got into teams – cross- functional teams, each person on one team and each team doing one project at the time. That was extremely helpful. One of the things that took off immediately was visual task walls. Those task walls showed what needed to be done on a team level and also showed who was doing what. Very quickly, those visual walls became focal points for people to have discussions, to make work visible and talk about the work, and to coordinate. But this is a picture of me internalizing frustration. You don’t want to see that when I coach. It’s not pretty. The problem was we visualized our work and people really enjoyed working. They also did great work but they achieved nothing. We did all this work and out of six user stories, each of them would have one defect or not be tested. It was simply not done. That happened to us several times. I think we had three sprints; we’re like absolutely zero velocity. We had