Practical intro to kanban- Joakim Sunden

A Practical Introduction
To Kanban
Joakim Sundén
1

BODEN

2

I am born and raised in Boden in the very North of Sweden, far away from this hot and exotic
place.

3

But now I live in Stockholm.

Kul
bild
här
4

Where I work at Avega Group.

• Principles behind Kanban

• When Should I Use
Kanban?

• Kanban in practice

6

7

Kanban is based on a very simple principle - agree on a limit to work-in-process...

8

...and pull new work from the queue only when something is ﬁnished.

9

Kanban is actually Japanese for visual card or sign.

10

Toyota Production System, TPS. What we in the West call lean. Simply put.

The two pillars of the
Toyota production system
are just-in-time and
automation with a human
touch, or autonomation.
The tool used to operate
the system is kanban.

Taichi Ohno

11

Taichi Ohno, the father of TPS, said that:

“The two pillars of the Toyota production system are just-in-time and automation with a
human touch, or autonomation. The tool used to operate the system is kanban.”

Just-in-Time means that you do things when there is an actual need for them instead of
keeping inventories Just-in-Case.

Autonomation means that if an abnormal situation arises in production, the machine stops,
the worker is signaled and will stop the production line. This prevents defects from being
reproduced and focuses attention on understanding and removing the problem when it
occurs, ensuring that it never recurs.

Just like Continuous Integration can be used in software development.

The idea with JIT is to achieve a ﬂow...

So that we...

• Don’t build features that nobody needs right now

• Don’t write more specs than we can code

• Don’t write more code than we can test

• Don’t test more code than we can deploy
12

...where value is added in a continuous flow from idea or concept to value in the hands of the
customers.

Instead of moving big batches of work between different phases in a workflow through hand-
offs, we focus on moving small units of work through the entire workflow quickly and without
interruptions.

We do this so that we...

We simply try to decrease the risk of wasteful over-production. But, equally important, this
makes it easier to discover problems and waste that is always present in a process, such as

unnecessary hand-offs
defects and rework
bad specifications
unavailable resources and so on

Because when there is no inventory of other work to use or to be working on when something
happens, every problem will result in a slowdown of the flow. Or make the flow uneven or
even...

13

...stop it entirely.

And this is a Good Thing because it gives us a chance to understand how our work works, to
remove impediments and to eliminate waste.

In summary you can say that lean is all about engaging all the workers in a never-ending
quest to identify and eliminate problems and waste. And using tools, like flow and Kanban,
that help them do that.

A one piece continuous flow where software basically materializes when a customer needs it
is of course an unachievable ideal state, but it gives us a target condition to continuously
improve towards.

In practice you will have inventory or work in process, but you constantly ask yourself “how
can we achieve more flow, how can we get the value to flow faster”. Flow where you can, pull
where you must.

14

To get faster ﬂow, we focus on cycle time and try to drive it down.

Cycle time.

Lead time.

15

Time is money. The faster we can get value delivered, the earlier our customer can buy and/
or beneﬁt from the value and the more money we will make.

16

How do we get shorter lead times? What can we do? We can try to increase the rate by which
we complete stuffs, to go faster.

Difficult, expensive - otherwise we would have done it already.

Fortunately there is an easier way.

Little’s Law
(Cycle Time)
=
(Work-in-Process) / (Average Completion Rate)

ABC ABC ABC
AAA BBB CCC

17

Queueing theory.

Little’s Law states that the more things in process, the longer the cycle time.

If we have an average completion rate of 1 feature a week and we have 3 features in process
we get a cycle time of 3 weeks per feature. If we instead are working on 1 feature at a time,
we get a cycle time of 1 week per feature.

Source: Quality Software Management:
Systems Thinking, Gerald Weinberg

18

In knowledge work it’s even worse because of context switching. 20% time is lost to context
switching per task, so fewer tasks means less time lost.

One study on context switching showed that context switching also represented a 10-point
fall in IQ - more than twice that found in studies of the impact of smoking marijuana. So if
you have to choose...

In Software Development
19

Work In Progress/Process - WIP.

Speciﬁcations Waiting To Be
Implemented

20

Non-Integrated Code

21

Code Not Yet In Production

23

Sitting on the shelf

24

But how do we do it? Besides from the obvious: reducing the number of things.

Smaller Units Of Work

25

Instead of working on big use cases that takes weeks or months to ﬁnish, maybe
business value can be sliced into smaller parts and delivered incrementally. As people
often do with user stories in Scrum and XP.

User story slicing / Sashimi
Tracing bullet / Walking skeleton

Limit Work To Capacity

26

Have you ever experienced that? Not the donkey, but having someone pushing work onto you
or your team and setting a deadline? This builds queues and increases the amount of WIP.
You should instead limit the work to the capacity and let the team pull work when they’ve
ﬁnished the work in process.

Less Rework

27

Build Quality In from the start.

Less Waiting

28

Hand-offs, gold-plating, bad speciﬁcations etc.

Because what do you typically do if you have to wait?

You pull new work and thereby increase the WIP and the lead time of all other work in
process.

Remove Impediments

29

Same thing with impediments.

Exploit and Elevate
Bottlenecks

30

And bottlenecks. I don’t know if you’re familiar with this terminology from Theory of
Constraints? More on that later.

Cross-Functional Teams

31

Help each other ﬁnish stuff instead of working on one thing each. Staff teams with all
the necessary skills needed to take a request from need to production. Then you reduce
the risk of waiting and other wastes.

32

Mr. Hitoshi Yamada, 61 years old. He is a successor of Taiichi Ohno,

He is called "The Factory Reconstructor".
He receives requests and goes into the factory to undertake reformation
of production lines and education of managers.

He comes to the production line.
As soon as he approaches the line, he shouts.

“Those are all work in process.”

He points out all work in process everywhere. one place after another.

"These are all waste, mountains of waste!"

“These are all work in process, and you know that it is a bad thing!”

“It is after a long time I saw this much waste.”

What would happen if Yamada-san came to your workplace in order to help you reduce work
in process? Would he ﬁnd any?

33

In order to easier discover work in process, queues and impediments, we need to visualise
our work. In order to visualise the work, we must understand how the work works.

34

For a small development team, maybe it’s as easy as this: analyze, develop, test/verify, and then you’re
done!

Source: Jeff Anderson
35

Or maybe it’s as complex as this? Many organisations don’t even know what their process looks like,
let alone the value stream.

Kanban

Source: http://www.kanban101.com/
36

So, in summary - and this particular summary is from Janice Linden Reed’s excellent
Kanban101 site - you can say that Kanban is all about making the work visible, limit work in
progress and help the work to ﬂow and to ﬂow fast, i.e., focus on reducing lead times.

The Kanban principles can actually be applied to whatever method you’re working with.
Chances are you’re already applying them to a certain degree.

37

Do you know Scrum?
Scrum can in a way be seen as an implementation of the principles I’ve talked about.

Do you see it?

Sprints = limit WIP.
Definition of done, potentially shippable.

Breakdown of work in small, vertical slices of shippable value.

Cross-functional teams to minimise waiting and help flow.

PO present. Less hand-offs and waiting, specify requirements Just-in-time etc.

Sprint planning = sort of limiting work to capacity

Visualisation = Scrum board, burndown

To take something from requirement to potentially shippable inside of a timebox can be seen
as a way of focusing on flow to bring problems and waste to the surface. That’s a not
uncommon way of describing Scrum.

TDD = limit the amount of unverified code through short test-and-implement-cycles.

Why Should I Use Kanban?

38

If many agile methods already incorporates Kanban principles, why should I use Kanban?

39

Where other agile methods, e.g. Scrum, isn’t a natural ﬁt, e.g., operations and maintenance.
These teams often have to be very responsive and it’s difficult for them to plan work for a 4
week timebox and then shut the door so to speak. They don’t have one clear product owner
and there is no point in batching the work for a review or demo with stakeholders - it has to
be reviewed and deployed immediately.

Some more normal development teams don’t see a need to use time intervals as a WIP limit.
How often does a customer order “4 weeks of software please”.

Maybe you don’t see a reason to use the same intervals, the same cadence, for planning work
as you do for reviewing or releasing it or reﬂecting how to improve, i.e., retrospectives. But if
you’re doing Scrum and start using different cadences, you can’t call it Scrum anymore
because it will upset a bunch of guys with beards.

That’s probably one of the reasons why Kanban is becoming so popular these days. The
minute you start planning the work just-in-time, you have to stop calling it Scrum.

40

Reached plateau with improvement with your current method. Need inspiration. New tools/
techniques. Metrics. Focus on reducing WIP and shortening lead times.

An understanding of the effects of WIP and ﬂow have helped many Scrum teams to work more
as a team, see bottlenecks, and so on.

41

Evolutionary introduction of agile and lean ideas in hostile or conservative environments. Or
in any environment for that matter.

Kanban can be seen as an agile approach to introducing agile ideas. You simply start where
you are and take it from there. Introducing Scrum or XP is often more of a big design up front
approach, where people are expected to take a leap of faith and hope for the best.

In many cases not only people working with software development are expected to change
but also the business, just because someone in IT wants to try out a new method.

Kanban in practice

42

So, let’s look at how we do this in practice. Because there is actually more to Kanban than these basics.

43

One of the good things of Kanban is that it’s a evolution, not a revolution. You can adapt Kanban step
by step.

Start from your current Scrum board and enhance it to reﬂect your process.

Agree on a policy to prefer completing to starting new work. Try to work on only one item at a time.

44

So a good starting point could be to visualize your workflow. If you are working with Scrum you are
doing that already.

But maybe your workflow could be a little more defined than Todo, Doing and Done. What steps are
you actually doing?

<<Talk about more complex orgs where visualisation is the main benefit.>>

45

Make room for some more columns

47

and move the “Done” items to that column

48

Maybe you start by analyzing a story, so lets a put a column to represent that work.

- what’s included
- how should it be solved
- break down into task
- etc.

49

And then we’ll add a column for the development of the story

50

And ﬁnally we need to verify and test the feature so that we are sure that the quality is good enough
for our team to release.

51

One way of handling handoffs between specialists is to introduce queues so that work is buffered. In
this way the next step can see when things are ready to be pulled from the Done-queue of the previous
step.

It doesn’t have to be hard specialization - even if it’s roughly the same people doing the work this can
be useful to visualize the ﬂow. So that we can see where impediments, unevenness and other problems
occur.

52

Let’s add a done-queue for development, to give a signal to Test when new work is ready to pull.

In this case we added the Done-queue in the Development-step. You could also argue that it should be
in the Test-step and be called “Ready for test” or something.

53

We now have our (simpliﬁed) work ﬂow setup. Now it’s time to decided how to limit how much work we
will allow to be in progress at one time - to Limit our WIP.

There are some different approaches to come up with the total number for that:
- 2 per person, so that you don’t get blocked. A bit less maybe. We don’t want everyone to be blocked
- Equal to the number of persons in the team
- The number of persons divided by 2 for experienced agile teams
- Start from the bottleneck, the number of tester for example

- Any number! We will change it as we see problems and opportunities.

54

Limit Work in progress for all columns or some, at least “Doing”

We have limit Work in progress for Analyze to 2, Development to 3 and Test to 2 features at the same
time.

We have no limit for our backlog, Todo - but you very well could, to limit the ﬂow into the system.

Kanban-board
A normal ﬂow

55

We will now quickly demonstrate a normal ﬂow on a Kanban board.

56

Here’s the initial stage...

57

Work is pulled from the backlog into the Analyze column as the WIP-limit allow.

58

You could wonder what Dev and Test is doing in these early stages of the ﬂow... They should of course
be helping out, but in practice this does not always work.

Well, the start will get a bit bumpy since no work is ready to be pulled. But this is for the very ﬁrst time
only, since a Kanban board never will be reset. In Scrum, for example, this situation is likely to occur in
each sprint.

59

As work progress you monitor the ﬂow of items.

60

Follow the WIP limits and only pull new work to your capacity

64

... work is ﬂowing along nicely since...

65

... each step is only pulling work when it’s done ...

66

... and not over their capacity.

68

Tam-tam-tam - working with Kanban is a breeze!

73

We’ve started work on the last feature in our backlog.

74

About the same time as the ﬁrst feature is ready to be launched!

Yeah! Champagne to all!

79

And we’ve pulled the last feature into development.

83

Now the development of the last feature is done and we’re ready to do the last bit of testing

84

The testers are working along to bring our goodness to the customers.

85

Closing in on the last feature.

Kanban-board
Queue as a leading
indicator

87

That wasn’t to educating since everything went well. It was good - but not educating...

How do we handle problems? Let’s reset the board to a problem situation and ﬁnd out.

88

Here all columns are fully loaded. Test is up to their limit and Development is ﬁnishing off the last
story.

89

Actually, the Development team want to pull some new work. They are sitting idle...

90

But we cannot allow that - that would break their Work in progress limit off 3, now wouldn’t it?

So here we have a bottleneck in the Test-step. We want to move things along, but since Test are up to
their WIP-limit we cannot.

What’s good is that queues like this doesn’t happen instantly. You can see it build up and you can react
to prevent it. The queue is a “leading indicator”. Compare that with burndown in Scrum which is an
example of an trailing indicator that gives you the ﬁgures on how things went.

What to do? Theory of Constraints gives some options:
- Exploit the bottleneck so that it’s used to the maximum, for example remove other work from the
testers so that they are only doing the bottleneck activity
- Elevate the bottleneck by increasing the capacity, for example employ more testers or automate tests

91

We can see the bottleneck building up earlier. This is the state of the board right before the bottleneck
just discussed.

Kanban-board
Starvation

92

Another thing to look out for is starvation.

93

This situation gives us empty columns or starvation.

94

The analyze don’t have anything done and Development is idle with no more work to pull.

95

This of course not good either but is another leading indicator. You can see when it’s about to happen
and maybe react early, rather than face the ﬁgures afterwards.

Kanban-board
What should I work on
next?

96

That was one example of the flow of work on a Kanban board.

But what should I be working on next, when I’ve finished something? It’s always easier to start new
work than it is to finish something. What are the strategies and guidance in Kanban?

97

Here is Joakim - the tester - ready to complete the feature he is testing right now.

100

Since there is work in process in his column - the testing Marcus is doing - he should first and
foremost see if he can help finish the work in process.

That’s our main goal - to finish work in process.

101

So Joakim and Marcus will test that feature together

104

... that feature is also Done!

105

What now? Both Joakim and Marcus is ready for some more work. Nothing to ﬁnish in their column.

106

But there is new work to be pulled from the Done-queue of the Development step.

107

Great! They pull new work...

108

Each starting a feature - to get work to done as quickly as possible.

109

Another way to handling the situation...

110

would be to work together...

111

... on the highest prioritized item...

112

... to quickly get that item done.

113

Look - they are on their way to being done

114

Well - that was quick! Great work guys!

115

Here is a case where Marcus, the tester is left with no work in his column AND no new work to draw.

What should he do now?

116

Mikaela apparently wants some help, to get the item she’s working on ready for test...

117

But that is sadly not possible since Marcus has no programming skills.

118

But... we have a bottleneck in Analyze. They are fully loaded and no new work is ﬂowing from them.

Both Joakim and Black-And-White-Marcus is working. Could Full-Color-Marcus possibly help over
there?

119

Yes, he can help Joakim to ﬁnish his work.

120

In this way they can resolve the bottleneck and move it to ready for development.

121

Great - another bottleneck resolved!

But, if he couldn’t have done that either? What should Marcus do then?
Well - ﬁnd other interesting work maybe. Prepare that automation of tests or get that pesky build
server to run faster. Something to help the team.

Strive to not pull new work. You could, and break your WIP limits - but remember that then all work to
come will suffer and take longer time to complete.

What to work on next?
1. Can you help ﬁnish an existing item? Do that.

2. Don’t have the right skills? Find a bottleneck and
work to release it.

3. Don’t have the right skills for that? Pull work from
the queue.

4. Can’t do that either? Find other interesting work.

Source: David Joyce, “Pulling Value Lean and Kanban”
122

So in summary, what should you work on next?
1. Can you help ﬁnish an existing item? Do that.
2. Don’t have the right skills? Find a bottleneck and work to release it.
3. Don’t have the right skills for that?
Pull work from the queue.
4. Can’t do that either? Find other interesting work.

Kanban-board
Inspect and adapt

123

We will now take a look on how your Kanban board can and should evolve over time.

It’s not done - strive to ﬁnd way to improve your process.

124

Say for example that you want your product owner to accept all items before shipping them.

We add a new column for that - Accept.

125

And since the product owner is what is called a Non instant availability constraint we add a queue for
things that is ready to accept.

126

And a column for accepted items.

127

The product owner cannot be with us all the time, but when she’s here she can accept many items at
once. It doesn’t take too long.

We allow up to 4 items in the Ready for Accept queue.

128

and as you see all items are quickly accepted when she had the time to sit down with and do it.

Kanban-board
New member in the team

129

Here is another situation when we need to change our board.

130

Here is a situation where it’s not possible to share work and all Developers are busy on one feature
each.

131

And suddenly a new Developer is added to the team. Mikaela is newly employed.

What should she do?

132

This could be a time to increase the Work In Process limit.

133

And then she can pull new work.

Of course the WIP limit could also be increased or decreased simply because you ﬁnd that it was too
low/high to start with.

Kanban-board
Work Item Types

134

With different work item types you can visualize how different kind of work should be treated in
different ways. To enable the team to easier be self managed.

135

Up to now all the items on our board looks and are treated the same.

136

But they are not, e.g., this is a bug.

137

And here is a maintenance issue that we are testing.

138

Over here is a change request that is waiting to be pulled.

139

And these normal yellow ones are ordinary features

140

Now it’s more visual to us what we are working on. If the board goes all red with bugs we know that
we’re having a quality issue for example.

To remind us and others what the color mean we could add a legend or key for the different items.

Avoid “the yellow sea”.

Kanban-board
What is on a card?

141

The cards we’re moving around could also communicate a lot of information.

142

First and foremost it should describe the feature. In this case in the form of a user story.

143

The use of an avatar is an easy way to show who is working on what.

It could also be used to limit work in process since you only can put your avatar on one card.

144

Here is a hard deadline added to the card - so everyone knows how we are doing against it.

145

If an electronic system exists with more information you could add the id of the item.

146

“Stamp” the date of each stage to get data for lead and cycle times that can be used to create
cumulative ﬂow diagrams, for metrics to improve or make predictions etc.

This card entered the Analyze step 2010-01-19

147

and did not reach Development until 2010-02-01...

What was going on there?

148

Use other items to signal deviations, such as delays or prioritization.

As you can see we have plenty of room on our card ...

149

... which makes room for another avatar, for when you pair program for example.

It also forces us use ladders to move the items around on the whiteboard that holds these big cards :)

Kanban-board
Classes of Service

150

If we want our team to be self organized, we need to help them to know which feature to
work on next.

With classes of service we get a prioritization and policy approach that can help team
members to chose their next work item.

It will also help you increase customer satisfaction by using different service levels for
different types of work. David Anderson will talk more about this in the end of the day on this
track.

151

A common situation is to introduce an expedite/urgent/silver bullet for things that is need to
be prioritized over other work.

152

Those items are often given their own “swim lane”

153

Everyone is happily working on their items...

154

... when suddenly an urgent feature is introduced.

155

A common policy for urgent features is that it should be prioritized over all other work. Just
let go and start to work on the urgent feature to move it quickly through the whole process.

156

Phew - the developers were quick. The item is pulled by the tester and get going on it immediately.

157

And in no time the item is handled.

158

Another kind of policy is a minimum number or percentage of items of a certain kind.

159

So here we should strive to have 50% features, 12,5 % (1) technical stories, 25% maintenance and the
rest bugs.

160

And with that policy in place Marcus, the tester, can easily see what kind of work item should be the
next to prioritize for the todo queue - since a maintenance issue was ﬁnished, we put a new
maintenance issue in the todo queue.

161

Here’s another situation.

Test-Marcus is ready to pull new work from the dev done queue. There are two items ready to be
pulled.

Which one should he choose?

162

The maintenance features (light green) has certainly been in the queue long, but we have a policy in
place that tells us to always prioritize features (yellow) above maintenance, so First-In-First-Out does
not apply in this case.

163

Test-Marcus can then easily know what to pick.

More powerful when there is more work than in this simple sample.

Also: use to guarantee a minimum of a certain type of stories, such as retrospective actions, dealing
with technical debt, low prioritised maintenance or customers.

Kanban-board
Daily Stand-up

164

We all know the ceremony during a Scrum Daily Stand up. But is there a difference now that we’re doing
Kanban?

Notice that we’re still within the limits of Scrum - everything we have done so far can still be referred
to as “doing Scrum”. It doesn’t look like your regular Scrum board but still...

We will let you know when we’re out of Scrum-country.

165

The major difference in Kanban standup is that the meeting facilitator enumerates work, not people.
Traverse the board from right to left (downstream to upstream) in order to emphasize pull.

The board shows the status, instead we focus on the exceptions.

Any bottlenecks?
Impediments not handled?
Are we keeping our WIP limits?
Is the prioritization clear?

Kanban-board
Managing defects

166

How are defects handled on a Kanban board? Can items travel backwards?

This is one of the most common questions we get when doing this presentation. Here are some
different strategies for handling defects.

167

When Test-Marcus ﬁnds a defect he could...

168

1. Mark the feature as blocked

169

2. Create a new defect work item

170

3. And place it in ready for development. Or maybe in Todo if it needs to be analyzed before
development.

171

4. Work on something else in the meantime. Given that Test-Marcus cannot resolve the issue himself.

172

Another approach is that Test-Marcus
1. Mark his feature as blocked and
2. Creates a new defect work item

173

3. and place it in the Urgent swim lane for quick processing

174

Test-Marcus could also.
1. Mark his feature as blocked

175

2. “stop the line” and call for help. The whole team is “swarming” on the issue and work together to
resolve it.

What policy you use, and wether blocked features and new defect items count against the WIP limit,
depends on how much tension you want to create for your team and your organization. If you are a
kick-ass-die-hard-zero-defects-team you probably want to stop the line or at least make work
blocked by defects to count against the WIP limit and thus trigger a discussion and perhaps some
improvement suggestions.

If not, well start with what you can do and work towards a target.

Kanban-board
Exit criterias

176

You could further help the team handle specialization with exit criteria for each column.

177

By deﬁning exit criteria for what is needed to move items into the Done column, we make it explicit
what has to be done before handing work off to the next step. This can be used as “standardized
work” in the lean sense of using as a baseline for improvement and better communication and
collaboration between different steps in the workﬂow.

Kanban-board
Feeding the queue

178

We have now reached the point where you cannot call it Scrum anymore. We will stop doing sprint
planning and start doing our planning just-in-time, or at least not coupled to the same cadence as
review/demo, retrospective etc.

179

How is the Todo-column ﬁlled with new items?

Start by ﬁlling the Todo-column or “backlog” with as many as the team usually commits to for a sprint,
maybe with a small buffer.

Agree on a cadence based on coordination costs and reprioritisation needs.

180

If coordination costs are low: event-driven planning.

Decouple the planning from the release and retrospective cycle and start planning just in time.

181

Maybe once every week or when event driven with an order point when new items should be added.

182

We are closing in on the order point

183

When all the items above the order point is moved the rest is moved up.

Note the instruction card that tells you to call to a meeting to get new items in the backlog from the
product owner. That is referred to in the industry as a Kanban card

184

Three new items are prioritized by the product owner (or who ever is doing the prioritization in your
organization)...

186

A WIP-limit on the backlog indicates how much that should be planned in advance.

Kanban-board
Disneyland wait times

187

After a while you can use your data and the different work item types to predict how long before an
item is released

188

This is referred to as Disneyland wait times, from the queues at Disneyland that tells you that you only
have to wait 30 more minutes before 1,5 minutes of roller coaster joy is yours.

189

Here we can see that the item on top only have 14 days to go before it’s in production.

Many managers and clients actually value predictability more than speed (to a certain amount of
course), but when there are no policies for how work ﬂows through the system and no predictable
delivery times lots of requests have to be expedited and the development team confuses need for
predictability with need for speed and thus get disturbed by “changed prioritization” all the time.

Disneyland wait times, or actually SLA:s and due date performance, can sometimes help solve this
problem.

Kanban-board
Other visualizations

190

The board can be used to communicate other important information.

191

Here is a team member on vacation...

192

... and here is the same team member down with the swine ﬂu.

Some teams really like the visualization in Kanban - embrace it!

193

Ok, so now you have visualised your work, limited your WIP, and monitor the ﬂow. So now
what? Now the next level begins. Relentless continuous improvement.

“I thought of kanban entirely in terms of
reducing work-in-process, raising
productivity, and illuminating problems.
Of course, it is good for all those things. But your
basic aim is something else, isn't it? You use the
kanban to create a positive tension in the
workplace by reducing work-in-process, and that
motivates people to do better than
they ever thought they could do.”
Michikazu Tanaka

194

Michikazu Tanaka, disciple of Taichi Ohno.

Target conditions. See book Toyota Kata

Kanban

195

Before we wrap this up we have to mention something about the problems with Kanban. Of
course Kanban has it’s critics as well. So what are the pitfalls to watch out for?

Here’s
Kanban!

196

All work and no play makes Jack a dull boy...

No cadence, no celebration - just work, work, work...
- Have cadence for these things if you want to, but it doesn’t have to be the same for all.

197

Timeboxing is good!
- Use timeboxing for each work item against its SLA or average completion time.

198

Sometimes you need a revolution...

199

Don’t let Kanban become an excuse for not doing any planning at all, not working agile, not
focus on good teamwork etc. Of particular importance when introducing Kanban in a non-
agile, non-mature environment.

Does It Work?

200

Why take my word for it?

BBC Worldwide Case Study

David Joyce’s blog: http://leanandkanban.wordpress.com/
201

Lean Software Management: BBC Worldwide Case Study
http://leanandkanban.wordpress.com/2010/02/11/bbc-worldwide-kanban-case-study/

Abstract: This case study examines how the lean ideas behind the Toyota Production System
can be applied to software project management. It is a detailed investigation of the
performance of a 9 person software development team employed by BBC Worldwide based in
London over a 12 month period.
The data was collected by one researcher in 2009. It involved direct observation of the
development team, the kanban boards, the daily stand up meetings, semi structured
interviews with a wide variety of staff, and statistical analysis.
The evidence shows that over the 12 month period, lead time to deliver software improved
by 37%, and consistency of delivery rose by 47%. Output increased, while defects
reported by customers fell 24%. The significance of this work is that it shows how to
considerably improve the performance and consistency of Agile software development
techniques.

The conclusion is that the adoption of lean and kanban ideas have enabled the maturity of
an Agile software process to move rapidly towards CMMI Level 4. The faster, more
responsive delivery has reduced both technical and market risks. The drawbacks are that
it may not fit well with existing corporate standards and managers may find their new
role challenging.

Start tomorrow!
• Stop starting, start finishing
• Visualise and study the workflow
• Limit WIP and improve lead times
• Monitor flow and use leading indicators
such as queue utilisation and bottlenecks
• Use metrics to improve
• Learn more on
http://www.limitedwipsociety.org/
202

Joakim Sundén
Twitter: @joakimsunden
Blog: http://www.joakimsunden.com/

Thanks to Marcus Hammarberg and Christophe
Achouiantz, co-developers of this presentation.

203

Practical intro to kanban- Joakim Sunden

More Related Content

What's hot (12)

Similar to Practical intro to kanban- Joakim Sunden (20)

More from AGILEMinds (20)

Practical intro to kanban- Joakim Sunden