Lean and-kanban-final

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

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.

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.

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.

Contents Page 5
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

Contents Page 6
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

Contents Page 7
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

Contents Page 8
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

Contents Page 9
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).

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

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

Contents Page 12
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.
http://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: 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

Contents Page 14
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

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

Contents Page 16
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.
http://www.infoq.com/articles/David-Anderson-
Kanban
Take the
GUESSWORK
out 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 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

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

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?
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

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

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 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.
http://www.infoq.com/articles/Implementing_
Kanban

Contents Page 22
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.

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

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

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

Contents Page 26
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.

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

Contents Page 28
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.
http://www.infoq.com/articles/kanban-distressed-
projects

Contents Page 29
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

Lean and-kanban-final

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (19)

Ähnlich wie Lean and-kanban-final

Ähnlich wie Lean and-kanban-final (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Lean and-kanban-final