lean and kanban final

Applying Lean Thinking to Software DevelopmentLeans 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

Contents

Applying Lean Thinking to Software Development Page 4Leans 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. Steven Peeters explains how you can apply Lean principles in an IT environment.

Queues the true enemy of flow Page 9No-one wants IT projects to be late. But when they are, its 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 13Kanban 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 17At the Lean Kanban conference, InfoQ asked Dr. Arne Roock how a team can evaluate whether 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 22This 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 teams progress.

The Evils of Multi-tasking and How Personal Kanban Can Help You Page 29Sandy Mamoli explains how to avoid multi-tasking by using personal Kanban and other Agile practices applied at the individual level.

YOU CANT MANAGE WHAT YOU CANT SEE

Your team has complex processes. Hidden within each process are

subprocesses that are hard to mapand even harder to

visualizewithout 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.

Contents Page 4

Lean & Kanban / eMag Issue 10 - March 2014

Applying Lean Thinking to Software Developmentby Steven Peeters

Lean thinking has been around for a very long time. The basics were laid out at the beginning of the 20thcentury.Takingafewminormodificationsintoaccount, 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 wont, so let me clarify a few things here. Leans major concept is aboutreducing 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 were not living in a perfect world, so thats 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 isnt 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 cant 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 didnt approve it? That, therefore, is considered to be necessary waste.

Use the scrum boardSo how do you apply these lean principles in an IT environment?Well,mostoftheITteams out there are already using lean in their daily routines. The widely accepted scrum board is actually akanban, 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.

Contents Page 5


Set up a pull systemAnother tool from lean that Im quite fond of and which has proven to be very effective in my current project is apull 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 toreduce the amount of work In progress (WIP). Littles law, which Ill 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 doesnt 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(Illcomebacktothislater, too). And, of course, your team doesnt stress out at the beginning, seeing the huge amount of work that needs to be done. Theres a psychological factor in here as well, which should not be underestimated.

Reduce the setup timeIn 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 its 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.Itslow-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, youve 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.Thatmeansthattheso-called process lead time (PLT) will shrink. PLT is the time a task takes to get through the entire process, from request to production.

Littles 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. Thats exactly where the pull system comes to life.

The seven wastes of ITMany circumstances can increase setup time. Constantly switching tasks is not something youd do naturally, so some other forms of waste are often responsible.

In a manufacturing environment,these are considered to be the seven wastes:

1. Transport2. Inventory3. Motion4. Waiting5. Overproduction6. Overprocessing7. 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: TransportTransport is probably the hardest waste to detect in a software-development environment. The end

Contents Page 6


product of an IT department is a virtual thing. Its 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. Lets 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. Im sure you can imagine that it takes some time to get to that point (and Im 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 Ill discuss in detail later.

Waste #2: InventoryInventory is another form of software waste that might not seem obvious at first. Its software! You dont 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 youre building.

Now, backlog isnt 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 customers 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: MotionMotion 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 thats just a wrong point of view.

Motion is all about physical motion: people or objects that are moving.Andwhentheyaremoving,theyare 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.Theymayhavetoperformnumerouskeystrokesormousemovementstofulfillatask.Forexample, think of what you need to do in Word to copy and paste between two documents when you only use the menus. Dont you love those little icons and, even better, the shortcut keys?

Also, people dont sit at their desks all day long(someofyoumightthinkthey 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, butputting 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

Contents Page 7


naturally, more directly, and more instantaneously which brings us automatically to our next waste: waiting

Waste #4: WaitingIf 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 isnt 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: OverproductionOverproduction is a typical waste within a software-development environment. In my opinion, it exists on two levels.The first is scope creep.Scopecreephappenswhenyousetoffwithadefinedsetoffeatures,butin 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.Doesthatmeanyoushouldnotdevelopthematall?Definitelynot!Thesebellsandwhistlesareoftendelighters, things that make clients happy. They may result in an advantage over the competition, attracting more clients. And since youre in business to earn money, attracting more clients is always a good thing.

Waste #6: OverprocessingEvery 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 governments 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.Sometimestwo people will undertake the same action in different steps of the process. Is that really necessary? Cant you simply eliminate one of those tasks? Sometimes you cant, because they are an additional quality-control step, but Im 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 individuals 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: DefectsDefects 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

Contents Page 8


the customer. If the customer isnt happy with the solution youre offering, you have a defect.

As you can deduce from the previous sentence, a defect isnt necessarily a bug.If the client orders or buys a product and it doesnt fully meet his expectations, you have a defect.Ifyouretalkingaboutanactualcriticalbug,thenitshoulddefinitelybefixed.Butnotalldefectscanbefixed.Sometimesyourunintolimitationsthatdontallowyou to completely satisfy the customer.In other cases, its just not economical or even financially feasible to satisfy all the customers needs, and you have to make some tough choices about what to implement and what to scrap.Thecostofsatisfyinga specific need may be higher than the return on investment. And if you have multiple clients (which I hope you have), you cant 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).

COPQCOPQ 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.Itisusuallycomparedto 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 youre 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,thedefectsareobviousbynow,aswevediscussedthemabove.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.

ConclusionMario Andretti, a former F1 world champion, once said, If you feel like you have things under control, youre 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 youre doing. After all, its called continuous for a reason!

About the AuthorSteven Peetersisafreelanceconsultantwithanextensivebackgroundinbothapplicationandwebdevelopment.AsanAdobeCertifiedInstructorhehasalsogiventrainingstovariouspeopleand

institutionsintheBeLux region. In 2012 he started his own company, Silver Lining,withtheintentiontocombinethetrainingaspectwithconsultancyinproject,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 InfoQhttp://www.infoq.com/articles/applying-lean-

thinking-to-software-development

Take the GUESSWORKout of TEAMWORK

Try it FREE FOR 30 DAYS at

LEANKIT.COM/TEAMWORK

Contents Page 9


Queues: the True Enemy of Flowby Paul Dolman-Darrall

When a project is late, its rarely because of how long the actual work has taken us. Its 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 flowA watched kettle never boils.

If were 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. Its only your desperation for tea symbolised by your anxious attention on the kettle that makes it seem slow.

Lets imagine you thought about having a cup of tea half an hour ago. If you dont yet have one, the issue is unlikely to be the kettle malfunctioning. Its 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.

Its a proverb, and a situation, that ought to ring bells for most software development teams yet worryingly, it doesnt. Thats because were so blind to these queues that we dont 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 everywhereAll of our working life is filled with queues. Because we are so busy, we find it odd to realise that of a projects 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 colleagues inbox).

Why dont we see them?We tend to respond very well to visible queues. We can avoid them (big queue at the bank, Ill 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).

Contents Page 10


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 timeIn 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 wouldnt take the week marked out for them in the project plan, or even a day, theyd take the two hours actually spent in discussion. Researching an idea for development (maybe a daring new user interface) wouldnt 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 moreFaced 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. Its known as the diffusion principle and theres 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

Contents Page 11


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 visibleA 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 queuesWe can estimate queues using Littles 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. Its a piece of information that can really help product owners decide whether they need to reprioritise.

4. Sequence our queuesOnce 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 weve 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 queuesIf 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 its 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.

Contents Page 12


Where should we hunt for queues in IT?

The fuzzy front endReinertsen 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.

SpecialistsWe 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 specialists 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.

EnvironmentsBig 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.

ConclusionQueues 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 dont 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 authorPaul Dolman-Darrallis 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 InfoQhttp://www.infoq.com/articles/queues-enemy-of-

flow

Contents Page 13


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: Theres 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 isnt about the pursuit of perfection. So thats 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 peoples 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. Im 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 theres 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. Its okay if their passions lie outside work. I believe a lot of agile people think everyone on a team should be deeply passionate

Contents Page 14


about their profession. I dont think thats 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? Doesnt it go against this idea?

David: Empowerment isnt about letting people do whatever they want, or assuming theyll 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 theyre allowed to play, whether theyre allowed to go outside the yard of the house, theyre allowed to swim at the shallow end of the pool, they arent 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 didnt really add the practice, Ive 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 didnt 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 its not new, Ive 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 its 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. Whats 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 theres 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, its 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 wasnt novel; it didnt

Contents Page 15


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 shouldnt use it on big projects. Thats clearly just disinformation. In 2007, for instance, we did an $11-million project with more than 50 people using kanban.

So weve 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 shouldnt 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 dont 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. Its natural that, if that was the case, all the early examples are non-agile examples. However, nowadays its 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 didnt 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 theyre operating, the design of that system, all the policies, and the decisions that get made to change a policy or override it. So thats all very well, but truly we want anyone whos 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 whatevers happening now is not good enough and suggest or show that we can do better. If you dont have that, then you dont have the catalyst for continuous improvement. Everyone could shrug their shoulders and say, Oh, well, thats the way it is. Back to work! Nothing would ever get any better. So leadership is the magic ingredient. Its the catalyst.

Recently theres another similar example: Hkan Forss, whos a kanban consultant from Sweden, has been reading Mike Rothers 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

Contents Page 16


think about improvements. In order to do that, they dont 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 thats correct. Theres 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 thats completely wrong. Scrum is difficult to adopt for a lot of organizations. Its culturally the wrong fit for many companies and people resist adoption of it.

Kanban, on the other hand, is designed for easy adoption. Its designed as a way to start with what you do now. Its 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 Appelos 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. Whats your take on this?

David: Im 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 its 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. Thats 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 lets be generous and say all 15% are working wonderfully. That leaves the other 85% of the market. I think thats the problem I want to solve. Whats 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 wouldnt 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 Im more interested in the rest of the space. Im sure there are plenty of people in the scrum community that are interested in improving scrum.

About the IntervieweeDavid 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 InfoQhttp://www.infoq.com/articles/David-Anderson-

Kanban

Take the GUESSWORKout of TEAMWORK

Try it FREE FOR 30 DAYS at

LEANKIT.COM/TEAMWORK

Contents Page 17


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 dont 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 its not; its 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: Lets 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. Its important to talk to the management and understand what they

Implementing Kanban in Practice

Contents Page 18


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 thats 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 lets say we see things are piling up in the testing column. We are faster in developing things than in testing and deploying them. So lets 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 lets 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 dont 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 dont 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 dont agree to collaborate with you. This is very important.

Start with the parts you can control. Dont try to evangelize; thats 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.

Contents Page 19


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?

Thats a tricky question but its 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 regions 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 thats 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, youre 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 its 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 youre 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

Contents Page 20


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 lets say we have buy-in from management. Isnt 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; dont 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. Thats the reason we dont 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. Its 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 cant 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. (Editors 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 dont 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 dont want to accept more work than we are capable of finishing.

InfoQ: Lets 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 cant take on one more. And if there is a production issue, a developer is forcedto take on one more.

You are asking two different things. A production issue is called an expedite in the kanban world. If we dont 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

Contents Page 21


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 whats 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 doesnt dictate how to deal with these blockers. It just says, Use the WIP limits to create slack, and dont utilize your people to 100%. Thats 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 wont 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 didnt 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. Its best if they are inside the company, but if you dont have that then thats 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, thats not a full-time job. Its 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 dont 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 IntervieweeDr. Arne Roockworks 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 viaTwitter, hisblogor hise-mail address.

READ THIS ARTICLE ONLINE ON InfoQhttp://www.infoq.com/articles/Implementing_

Kanban

Contents Page 22


Using Kanban to Turn around Distressed Projectsby Steve Andrews

This case study describes how kanban and lean development techniques rescued a distressed project.

BackgroundThis 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 ControlThe first thing to do when confronted with this type of situation isnot 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.

Contents Page 23


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 QualityIt 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,beforecoding 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.

Contents Page 24


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 ConstraintsAs 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 didnt 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 SizeA 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 TeamBreaking 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 thedevelopment 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

Contents Page 25


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 PullThe next thing we did was to remove tasking authority from the project managers that is, managers could no longerpushwork 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 wouldpullit 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 addedready statesto 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.

PendingDevelop

TestsReady

to CodeReady to

StageReady to

AcceptAccept 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

lean and kanban final

Documents