A (slightly) cleaner version of the hitherto-uploaded powerpoint presentation (with notes)

1. This talk is designed to communicate the basic spirit (or underlying principles) of the
Kanban approach to managing workflow within an organization…
…so why is there a picture of Nelson Mandela (or is it William Shatner, or <your name
here>)? Bear with me….
DISCLAIMER: I have freely pillaged the internet in search of appropriate artwork and in
my research about Kanban – this material is presented with thanks and apologies for
those with true creativity. Please don’t sue me – contact me directly and I will be glad
to acknowledge or pull down your content as necessary.
1

2. Some of you are here today with no idea what Kanban means – this talk is perfect for
you (and not so much for aficionados or anyone already familiar with Kanban or Lean,
or Project Management for that matter).
2

3. No-one will actually read this, so…let me try this a different way…
3

4. Kanban kinda falls under the heading of PROJECT MANAGEMENT, but not in any traditional
sense…
4

5. Kanban really addresses the broader subject of understanding and improving the way
we work together – the systems, processes, people and tools that make things happen
– the way that work items flow through those systems - and dealing with the
complexity inherent in doing so
5

6. In many ways, Kanban takes traditional thinking about time management and project
management and turns it on its head…
6

7. So get ready!
7

8. So Kanban is a shiny new paradigm – a new way of thinking about how we work….but
on the other hand, it might seem familiar….
8

9. Does anyone remember seeing these? The Voxeo Leadership Team has been pounding
on these as priorities for 2011 – and as we’ll see, they tie in quite nicely with the
Kanban approach…
9

10. But let’s start by thinking about the evolution of project management – Kanban did not
emerge from a vacuum, but can be understood as a progression in our thinking about
how to work together in the age of information…
10

11. NOT that each new approach is necessarily better than the last – each has their place
and should not be thought of as a panacea or silver bullet
11

12. In the beginning, the project was a shapeless void – people pretty much did what
seemed like it most needed attention, for whatever reason…
12

13. …but this quickly gets hectic and unmanageable; more than a few tasks, or more than
a handful of people and chaos inevitably ensues.
13

14. So naturally, we decide that it is time to get organized…
14

15. And this often takes the form of a punch-list
15

16. A punch list is a simple way of ordering and sharing the list of stuff that needs to get
done; but still, it quickly becomes apparent that we need to assign tasks to people,
understand the timeline and establish dependencies between tasks…
16

17. This brings us to the more traditional planned project that we are used to in the world
of software development…
17

18. Look – a checklist with a timeline, resources, dependencies and constraints! It’s called
a Gantt chart.
18

19. Pretty soon we notice a pattern in our project plans, and define standards for the
phases that projects should go through – these are established as our project
management process…
19

20. This is all great, but as we do this more and more, we realize something important: the
earlier we plan, the less accurate our plan is (even when sophisticated estimation
models and historical data are used, which often they are not) – so when we define a
nice project plan up front, we get the least accurate plans. This is called the Cone of
Uncertainty (and it is actually worse, more random than depicted here). This is
particularly acute in knowledge-based projects such as software development, and is
the fundamental challenge that gives rise to the ubiquitous death march projects so
familiar in the world of IT. When things don’t work out as planned – and they never do
– what happens?
20

21. The other thing that was realized a long time ago, is that projects do not follow a nice
linear one-pass path from inception to production – in reality, we iterate through a
series of activities and releases to get to the desired end-point (this diagram is from a
paper by Barry Boehm in 1981)
21

22. For this reason, all the standard Project Management standards embrace this concept
of iteration: PMI, RUP, MSF, Prince2, etc…
22

23. But there is a another problem: projects do not exist in a vacuum. Organizations must
juggle a large number of projects, decide on their relative priority, how to allocate
resources to them, track how much they cost and keep them aligned with business
strategy. This can quickly get complicated…
23

24. And we end up with increasingly complicated projects and processes that attempt to
take all this into account. The trouble is, almost no-one can keep all this in their head -
projects and organizations become bloated – people follow rules and stop using their
brains – and it is just no fun.
24

25. Dilbert captures the consequences nicely…
25

26. And how about this - have you ever felt like Zombie PMs and their endless meetings
are robbing you of your Joie de Vivre?
26

27. This was the context for the emergence of the AGILE APPROACH to software or product
development
27

28. In 2006, some well-known figures in the word of software outlined a new way of
thinking about projects…
Ref: http://http://agilemanifesto.org/
28

29. A number of different approaches emerged from this thinking – perhaps the most
famous is Scrum
29

30. Scrum provides a simple system for iteratively delivering software in the context of
fluid requirements through a series of sprints…
30

31. And can be integrated into a broader, iterative agile planning framework
31

32. The trouble is – well, read this slide :-) So this brings us to…
32

33. Ta-da!
33

34. Enter the Kanban Ninja! Kanban presents a (ninja-like) shift in the way we think about
managing workflow...
34

35. Kanban asks us to think differently about organizing our work – and (typically)
eliminates the (first order) concept of a timeline or timebox, Huh?
35

36. But what does it all mean? Let’s start with the basics…
36

37. These are the core principles of Kanban – now we’ll see what they look like in practice
using a very simple example
37

38. Here is a typical Kanban visualization of the work going in a particular system (an
individual, team or project); tasks are represented by cards in columns that indicate
the basic sequence of activities that must take place for a task to be considered
complete. In this case, you have a list of items that are waiting to happen, some stuff
that is actively in progress, then a stack of items that are done.
The idea is that work visibly flows from left to right, representing the flow of value that
is being delivered. For this reason, this visualization of the work flow is sometimes
given a more fancy name – the value stream.
38

39. These task lists are typically prioritized – and the workflow is usually a little more
involved. However the idea is to start simple and then adapt and extend based on
experience using the simple system – as we’ll see in the following slides.
39

40. Once the workflow is made evident in this way, it usually becomes apparent that only a
certain number of tasks can be accommodated (in each category, for each individual,
and within the whole system). For this reason, and to encourage focus and dynamic
flow (therefore productivity), limits are defined for the number of work items in the
system (as represented here in red). These are referred to as WIP Limits (WIP: Work In
Progress).
40

41. This affects the flow of work since you are not allowed to start new work that exceeds
the WIP limits.
41

42. The whole (somewhat counter-intuitive) idea of limiting WIP is to INCREASE
productivity and focus – if it does not, then consider adjusting WIP limits or refining the
value stream (but then again, perhaps you are already perfect?)
42

43. So now our system is nicely balanced – there are one or two items waiting for attention
and we are productively working on a full complement of in-progress tasks.
Let’s talk about how we might optimize this flow using the second principle…
43

44. …measure and manage flow
44

45. We complete an item that we were working on and it moves to the DONE column –
leaving an open slot in the IN-PROGRESS column within our defined WIP limit
45

46. So we start working on the highest priority item that was in the BACKLOG
46

47. Of course, there is still room to add items to the backlog
47

48. So, let’s do that….
48

49. Until we have a full complement of items ready to go.
Note: In this case, an item’s presence in the backlog indicates that it is defined to the
point of being actionable – the WIP limit reflects the fact that definition work might be
required, but also that it is not useful (confusing, distracting) to have too many items
queued up. A longer list of lower priority and not as well defined items might exist
elsewhere. There are different ways to model this, but let’s go with that for now…
49

50. So what happens when we complete an item and move it to the DONE column?
50

51. Now we can move an item from the BACKLOG to IN-PROGRESS
51

52. …and repopulate the BACKLOG column
52

53. That gives you a sense of what it looks like to model the full flow, from the point at
which an item is added to the backlog until it is done.
This is referred to as the CYCLE TIME – and this the fundamental metric used to
understand the performance of a system (and predict work completion). In addition to
measuring and limiting WIP, the other metric you may hear mentioned is LEAD TIME.
For now, we’ll keep it simple and go with CYCLE TIME as the metric that it makes sense
to optimize…
53

54. Which brings us to our fourth and final core principle: OPTIMIZE CYCLE TIME.
54

55. Imagine this:
We realize that tasks that are IN PROGRESS fall into two basic categories – stuff that is
being coded and stuff that is being tested. Our sense is also that there are folks on the
team who could be productively testing even though our complement of coding tasks is
full.
We adjust the board to reflect this explicitly and increase the overall number of items
based on this new division of labor. Now, in addition to three tasks that are being
coded, we have room for a couple of tasks that are being tested.
This legitimately increases the amount of work that can be active within the system,
hopefully without affecting focus. This already holds the promise of improving cycle
time, since it may allow more work to flow through the system. We won’t know until
we try it and measure the results – but let’s see what often happens next…
55

56. A coding task is completed and ready for test. In our previous simpler model, IN
PROGRESS items flowed directly to the DONE state, which has no WIP limit.
In our refined model, we want to move the item from the CODE to TEST sub-category.
56

57. But wait! That would exceed the WIP limit for the TEST category – those folks are all
busy testing previously coded items...
Unfortunately, that in turn means that a new item cannot be pulled in from the backlog,
since that would exceed the WIP limit for the CODE subcategory – and that seems
wrong, since a coder is really available. The lingering complete item in the CODE
column is artificially (and incorrectly) blocking the flow.
Kanban is particularly good at identifying bottleneck by visualizing them on the board.
Sometimes the bottlenecks reflect a problem with representation of the workflow;
sometimes they reflect real problems with the actual workflow.
57

58. How do we resolve this?
We could just increase the WIP limit in the CODE column (and the IN PROGRESS
category) – but that doesn’t seem quite right, because there is a task that affecting the
WIP limit that is not actually being worked on.
So let’s try something different – we’ll need to create a little space….
58

59. … to make room for a test queue!
59

60. So this allows us to unblock the flow by moving an item to the test queue…
60

61. …and pull an item from the backlog to be coded. Yay!
61

62. This in turn frees up a spot on the backlog, so that another item can be prepared for
action.
A few notes on this simple example:
- the real idea is to accurately reflect (and resolve bottlenecks affecting) the real
workflow (not just have fun with visualizations) ;-)
- resist the temptation to over-engineer the workflow – but most will evolve as
bottlenecks and optimizations emerge
- turns out (not really by accident) that the concept of QUEUE-ing and the resultant
PULL dynamic are key drivers of optimization (which is related to something called the
Theory Of Constraints or TOC) – follow the references to learn more about this if you
are curious about the theoretical underpinnings
- another closely related Kanban (or Lean) priority is to ELIMINATE WASTE – where
WASTE is understood as a mismatch between available resources and available work;
bottlenecks and queues are a key indicators of waste in the value stream
Finally, a more complete Kanban board also includes explicit work rules (for instance,
around when tasks are complete and ready for the next stage in the workflow), and
provisions for dealing with interrupts (by allowing for differentiated Class Of Service, or
tagging/arranging cards into horizontal swim-lanes - and – CRUCIALLY - visualizing
the impact).
62

63. So much for the theoretical example – how might you use Kanban in your daily work?
63

64. A great place to start is a simple Kanban reflecting your personal work items – this can
be created in a few minutes using a whiteboard and post-it notes.
64

65. A whiteboard approach can also be extended to the work of your team or project – this
is a nice, annotated real-world example.
65

66. A number of popular tools provide direct support for Kanban-style visualization –
Atlassian JIRA with GreenHopper is probably the dominant example of a general
purpose tool of this kind.
66

67. Okay Mister Kanban – if Kanban is so great - show me how we are or could be using
Kanban here at Voxeo!
67

68. As we mentioned at the outset – and I hope is obvious by now - Kanban aligns very
well with our stated priorities for execution:
FOCUS:
Limit WIP
EXECUTE:
Visualize Work Flow (and get work moving from BACKLOG to DONE)
MEASURE:
Measure and Manage Flow
ITERATE:
Optimize Cycle Time
68

69. Here are three quick examples…
69

70. Individuals can and do use Kanban to optimize their personal workflow – start out with
simple paper/whiteboard approach or use a free online tool like: http://
www.personalkanban.com
70

71. The Voxeo Engineering team has defined its Software Development Life Cycle (SDLC)
with Kanban (and Scrum) in mind – check it out on the Wiki at http://
evolution.voxeo.com/wiki/corp:engsdlc
71

72. Product Delivery is using a tool called LeanKit Kanban to model the delivery team goals
– feel free to request access (read-access is free).
72

73. That seems like enough for a first dose: Any questions?
73

74. Remember: Kanban is about enhancing the flow of work through a system…
74

75. …and improving focus and execution – so STOP STARTING and START FINISHING – and
enjoy using Kanban!
75

76. • http://www.personalkanban.com
Applying Kanban to your personal task list
• http://www.agilemanagement.net/
David Anderson website addressing Kanban and
Agile Management
• http://www.limitedwipsociety.org/
Kanban Community Website
• http://refcardz.dzone.com/refcardz/getting-started-kanban
Handy-dandy detailed summary of
Kanban for Software Development
76