Professional Documents
Culture Documents
Lean &
Kanban
eMag Issue 10 - March 2014
Contents
Page 4
Leans major concept is about reducing waste, meaning anything in your production cycle that
is not adding value to the customer is considered waste and should therefore be removed from
the process. Steven Peeters explains how you can apply Lean principles in an IT environment.
Page 9
No-one wants IT projects to be late. But when they are, its rarely because of how long the
actual work takes. Tasks and projects spend more time inactive, sitting in a queue, than being
worked on. Despite this, most project management offices measure activity, not queues.
This article examines why we should track queues and quantify their cost in order to make
meaningful gains in speed of delivery.
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.
Page 17
At the Lean Kanban conference, InfoQ asked Dr. Arne Roock how a team can evaluate whether
Kanban is the right tool, and how to kick it off. Dr. Roock offers some prescriptive advice.
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 teams progress.
Page 29
Sandy Mamoli explains how to avoid multi-tasking by using personal Kanban and other Agile
practices applied at the individual level.
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.
Contents
Page 4
Contents
Transport
Inventory
Motion
Waiting
Overproduction
Overprocessing
Defects
Contents
Page 6
Page 7
Conclusion
Mario Andretti, a former F1 world champion, once
said, If you feel like you have things under control,
youre just not going fast enough! This is a motto by
which I try to live by and which also applies to lean
thinking in my opinion. Because I believe that if you
feel comfortable in your situation, it means you have
room for improvement.
When it comes to continuous improvement, you
should always step outside your comfort zone and
find new or better ways to improve what it is youre
doing. After all, its called continuous for a reason!
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 youre making 100 items on which you
make no money whatsoever. The cost of making
those 100 extra items is your COPQ. The origin of
these defects can lie in a lot of places: defective base
components; bad machinery; etc.
Page 8
Take the
GUESSWORK
out of
TEAMWORK
Try it FREE FOR 30 DAYS at
LEANKIT.COM/TEAMWORK
one. All that time, the boil water for tea task is
essentially sitting in a queue behind other tasks.
Page 9
Page 10
Contents
Page 11
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 specialists
time to train others.
What can we do?
Having generalised specialists such as developers
who can test or statistical modellers who are happy
to pair can be a fantastic way to add temporary
spare capacity when required. The team can also
provide support to help work flow as smoothly as
possible through the bottleneck. This can range from
offering secretarial support (you want specialists
working, not booking train tickets) to doing as much
advance preparation as possible.
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.
Contents
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 dont wait.
A blindness to queues means you are unable to make
such decisions. It means that your business could
be suffering huge bottlenecks and incurring a heavy
cost of delay in complete ignorance. A company that
is worried about delivery times but looks only at
activity and not queues is watching a kettle when the
fire has gone out.
Page 12
Kanban Pioneer:
Interview with David J. Anderson
Page 13
Page 14
Page 15
Page 16
Take the
GUESSWORK
out of
TEAMWORK
Try it FREE FOR 30 DAYS at
LEANKIT.COM/TEAMWORK
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?
Contents
Page 17
Contents
Page 18
this case, if you apply kanban you will see a lot of pain
among your distributed teams; it takes a lot of effort
to synchronize those teams. But thats the reality
whether you have kanban or not. Kanban will make
these problems transparent.
For more than two locations, you will surely need
an electronic tool. But what you also need is a lot of
bandwidth for your communication. I have seen this
over and over again. When people only communicate
via the tool, youre nailed! People need to keep
communicating. Face to face is of course better than
video conferencing, which is better than telephone,
which is better than email. So make sure people
communicate as often as possible. That means you
have to ship people to the other location from time
to time, even if it is Singapore. And you need to have
really good equipment for video conferencing, and
you need to have a good kanban tool. Building trust
is very important for changing the organization (and
that is what kanban is designed to do). It is easier
to build trust when people know each other. When
people see each other, talk to each other face to face,
have a beer together, know a little about their private
lives like if they have children or the kind of movies
they like, that builds trust, and that is really, really
important.
Standup meetings are one way to create this forum
so that people can come together and talk to each
other on a regular basis. Of course, if there is a time
difference that is a problem, but you have to solve
that in any case its nothing to do with kanban.
InfoQ: Is there a standard solution for conducting
standup meetings cross-region?
Even if there is a time difference, you often have one
or two hours of overlap.
InfoQ: Well, Singapore is 12 hours behind New
York, so even if one region works late, it would be
hard to do on a daily basis.
Yes, even if you could youre at different points in
your days, so the energy level is different. It is a tough
question. There needs to be regular communication,
even if some people have to work at night. You
can have one person talk to the other team using a
round-robin mechanism.
Also, we have to tear down the boundaries. Very
often we see, for example, a team in the US will
Page 19
Page 20
Contents
Page 21
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 interruptdriven manner because the project manager did
not manage the client well enough to protect the
Contents
Getting Control
The first thing to do when confronted with this type
of situation isnot to panic.In this particular case, the
client was agitated and had zero confidence in the
team. The client was blaming the team and the team
was blaming the client. Morale was poor, and getting
worse because management was demanding that the
team work harder to fix the problems.
Page 22
Contents
Page 23
Work as a Team
Page 24
Pending
Develop
Tests
Ready
to Code
Ready to
Stage
Ready to
Accept
Accept
Accepted
Eliminate Bottlenecks
We also introduced work-in-process (WIP) limits
to control the pace at which work items could
Page 25
Contents
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-importantwork 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 thebacklog, 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 teams 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 managers ability to task
developers. We repurposed the project managers
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.
Page 26
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 (timeboxed) 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
ofideal days. The estimates accounted forallthe
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.
KANBAN
ROADMAP
How to Get
Started in 5 Steps
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
Contents
Page 27
LEANKIT.COM/KANBAN-ROADMAP
Contents
Page 28
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.
Theres lots of research out there and its nothing
new. For anyone like me, youd probably think, Well,
yeah, its bad. But it cant be that bad. And also
Im probably kind of better than other people at it
anyway so Im 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, Ill 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
Contents
Page 29
Things to do
Next
Doing
Done
She said:
We split up the things to do and next mainly
because its really overwhelming or can be really
overwhelming if you look at all the tasks that
you want or need to achieve. If we split that into
something that is in your focus and everything
else thats later, its really, really helpful, a bit like
a backlog, a product backlog, and a sprint backlog.
We had a doing area which was quite small. What
happened there was we didnt explicitly introduce
any work in progress limits; we just limited space.
Theres no way you can get more than two sticky
notes into the doing column. It really effectively
stopped people from multitasking. I still dont know
why, but you could easily just stack them but people
dont.
Contents
Page 30
Page 31
Contents
Page 32