PROJECT MANAGEMENT
USING KANBAN
Jérôme Wagener, Sam Schmit,
Avikarsha Mandal and
Vaishnavi Rajendran
Kanban (Japanese for signboard) refers to a project management method which quite
recently gained a lot of attention in the field of IT project management. To increase
awareness, we collected in this document some of the current knowledge about IT based
Kanban. It was created as part of the Advanced Project Management course at the
University of Luxembourg.
University of Luxembourg
Master in Computer Science
Advanced Project Management
2011-2012
CONTENT
WHAT IS KANBAN? ............................................................................................................................ 5
1
2
THE ORIGINS OF KANBAN..........................................................................................................................6
THE OBJECTIVES AND CONCEPTS BEHIND KANBAN........................................................................................6
2.1
Lean and Just-in-time Production ................................................................................................... 6
2.2
Limiting the Work In Progress ......................................................................................................... 7
2.3
From Push to Pull ........................................................................................................................... 7
2.4
Visualization of the Work ............................................................................................................... 7
2.5
Process Improvements ................................................................................................................... 8
3
KANBAN IN IT PROJECT MANAGEMENT ........................................................................................................ 8
3.1
The Properties ............................................................................................................................... 8
3.2
Integrating Kanban ........................................................................................................................ 9
3.3
The Board .................................................................................................................................... 10
3.4
Kanban by Example ..................................................................................................................... 11
4 COMPARING KANBAN TO OTHER AGILE METHODS ...................................................................................... 14
4.1
Kanban vs. OpenAgile .................................................................................................................. 14
4.2
Kanban vs. Scrum and XP ............................................................................................................ 15
4.3
Kanban vs. the Rest ..................................................................................................................... 16
5
THE ADVANTAGES AND DISADVANTAGES OF KANBAN ................................................................................. 16
5.1
Advantages ................................................................................................................................. 16
5.2
Disadvantages ............................................................................................................................. 16
LITERATURE AND CASE STUDIES ..................................................................................................... 17
6
THE KANBAN BOOKS.............................................................................................................................. 18
6.1
Kanban - Successful Evolutionary Change for Your Technology Business ........................................ 18
6.2
Kanban and Scrum - making the most of both ............................................................................... 19
6.3
Kanban: Just-In-Time At Toyota ................................................................................................... 19
7
INDUSTRY SUCCESS STORIES ................................................................................................................... 19
7.1
Case Studies ................................................................................................................................ 19
7.2
Scientific Case studies .................................................................................................................. 20
TOOLS AND APPLICATIONS ............................................................................................................. 23
8
APPLICATIONS....................................................................................................................................... 24
8.1
Flow.io ........................................................................................................................................ 24
8.2
Swift Kanban ............................................................................................................................... 24
8.3
Kanban Tool ................................................................................................................................ 26
8.4
LeanKit Kanban ........................................................................................................................... 26
8.5
KanbanSim .................................................................................................................................. 27
i
SMALL SCALE LEGO CASE STUDY .................................................................................................... 29
9
10
OBJECTIVES .......................................................................................................................................... 30
PREPARATION ................................................................................................................................... 30
10.1 Lego Schematics .......................................................................................................................... 30
10.2 Kanban board .............................................................................................................................. 30
10.3 Kanban Cards .............................................................................................................................. 31
10.4 Questionnaire .............................................................................................................................. 31
11 EXECUTION ........................................................................................................................................... 32
11.1 Instructions ................................................................................................................................. 32
11.2 Experiment .................................................................................................................................. 32
12
OBSERVATIONS ................................................................................................................................. 33
13
RESULTS........................................................................................................................................... 34
SUMMARY ........................................................................................................................................ 35
14
SUMMARY ........................................................................................................................................ 36
APPENDIX ........................................................................................................................................ 37
APPENDIX A EXPERIMENT FORM ...................................................................................................................... 38
APPENDIX B QUESTIONNAIRE.......................................................................................................................... 39
ii
FIGURES
Figure 1: Exemplary Kanban-Board ................................................................................................................ 10
Figure 2: Exemplary colour coded features ..................................................................................................... 10
Figure 3: Exemplary Kanban-Board with Swim Lanes ..................................................................................... 11
Figure 4: Card priority .................................................................................................................................... 11
Figure 5: Kanban Board in the beginning ........................................................................................................ 11
Figure 6: Manager puts two cards on the board .............................................................................................. 12
Figure 7: Cards pulled by development team .................................................................................................. 12
Figure 8: Progress on the board ..................................................................................................................... 12
Figure 9: Development Team stalled .............................................................................................................. 13
Figure 10: After fixing problems with card F ................................................................................................... 13
Figure 11: The board after a while .................................................................................................................. 13
Figure 12: Service Level Agreement board example ....................................................................................... 14
Figure 13: The three Kanban books ................................................................................................................ 18
Figure 14: Flow.io Board Example .................................................................................................................. 24
Figure 15: Flow.io metrics .............................................................................................................................. 24
Figure 16: Swift Kanban Card Example ........................................................................................................... 25
Figure 17: Swift Kanban Board Example ......................................................................................................... 25
Figure 18: Swift Kanban swim lanes configuration ......................................................................................... 25
Figure 19: Kanban Tool stylish board example................................................................................................ 26
Figure 20: LeanKit Kanban statistics example ................................................................................................ 26
Figure 21: KanbanSim Screenshot .................................................................................................................. 27
Figure 22: Example Lego House Schematic .................................................................................................... 30
Figure 23: The experiment's Kanban board .................................................................................................... 31
Figure 24: Experiment execution, phase 1 ...................................................................................................... 32
Figure 25: Experiment execution, phase 2 ...................................................................................................... 33
Figure 26: The created Lego city .................................................................................................................... 33
Figure 27: Lego Pieces form used during the experiment ............................................................................... 38
Figure 28: Picture card used during the experiment ....................................................................................... 38
iii
WHAT IS KANBAN?
In this section we will define what Kanban is in the context of IT based
project management. To better understand its nature, we start by
exploring its origins in the automotive industry. We move on to defining
and explaining the main concepts behind Kanban and we will show how
they apply to IT projects. We also compare Kanban to other agile
development methods and give a brief overview over some of its
advantages and disadvantages. Lastly we will outline how to apply
Kanban and how it can be integrated into an existing business.
What is Kanban?
1 THE ORIGINS OF KANBAN
1
To explore the origins , we have to go back into the late 1940s. At that time, Toyota tried to improve their
production system to be competitive with the American automobile market. Then in 1956, Taiichi Ohno, a
leader of a machining shop within the Toyota production system, travelled to the United States where he
intended to visit automobile plants in order to determine how to improve the production system back home
in Japan.
However, not the automobile plants but the American self-service supermarkets inspired him. He was
fascinated by the possibility to choose exactly what and how much you want, as well as the simple, efficient
and timely replenishment of the supermarkets. These practices should later become the fundamentals for
Kanban.
During the following years, Ohno developed different tools to operate the production in a systematic
framework. The best known method is the Kanban system, based on the idea of lean and just-in-time
production (c.f. The Objectives and Concepts behind Kanban below).
2
Originally, Toyota defined six elementary rules to be used, which consisted of:
•
•
•
•
•
•
Never send defective products downstream to the next process
Each process only orders what it currently needs from the upstream process
Each process only produces the quantity ordered by the downstream process
Maintain a level rate of production
Use Kanban to fine-tune the rate of production
Work to reach a stable rate of production
Although these rules originally refer to the production of automobiles or automobile parts, most are generic
and can easily be adapted to the IT domain. An example is avoiding the forwarding of a “defective” or
incorrect specification to the programmers.
2 THE OBJECTIVES AND CONCEPTS BEHIND KANBAN
So as not to cause confusion, we want to make clear that Kanban is not an “off-the-shelf”, or ready to apply
3
project management methodology. As David Anderson (one of leading experts in IT based Kanban) puts it :
“Kanban is not a software development methodology or an approach to project management. It
requires that some process is already in place so that Kanban can be applied to incrementally
change the underlying process.”
What it means is Kanban does not provide a complete structure or plan on how to manage a given project. It is
a set of guidelines on how to adapt existing processes, such that one may for example implement change
management more easily and find bottlenecks more accurately. The desired effect is achieved by adhering to
the following concepts.
2.1 LEAN AND JUST-IN-TIME PRODUCTION
Lean manufacturing or production is a practice which focusses on eliminating any waste of resources,
including physical resources or man-hours. To that extent, it is essential to only create goods that have an
additional value for a customer, i.e. that he is willing to pay for. Waste may occur in different forms, for
example: useless inventory, defects or waiting times.
1
Background from Toyota History (http://www.toyotageorgetown.com/history.asp)
Rules taken from WCM: Kanban System (http://www.world-class-manufacturing.com/Kanban/kanban.html)
3
Kanban - Successful Evolutionary change for Your Technology Business, David J. Anderson, ISBN: 978-0-9845214-0-1
2
6
The Objectives and Concepts behind Kanban
However, in software development, waste has different manifestations which need to be addressed
appropriately. Mary and Tom Poppendieck summarized the lean principles for software development in their
4
book as follows: 1) eliminate waste 2) amplify learning, 3) decide as late as possible, 4) deliver as fast as
possible, 5) empower the team, 6) build integrity in & 7) see the whole. These principles become important
when using Kanban in a software development context.
Just-in-time Production is a strategy used to keep the in-process inventory to a minimum, in order to
reducing carrying costs. In fact, goods are only produced based on the current demand.
With respect to the automobile domain, this means that a manufacturer should receive raw materials or parts
from his supplier(s) only shortly before they will be used in production. The output should be shipped to its
5
customers as soon as possible.
Mapping this to the IT domain means that only essential components are produced and immediately
forwarded to the next stage, e.g. a piece of code is written and then forwarded to the testing department. The
goal is to avoid producing non-required components.
2.2 LIMITING THE WORK IN PROGRESS
So as not to overwhelm any given department, Kanban enforces work in progress limits (WIP). The general
idea is to reduce the current workload of a department by letting its people concentrate on a few tasks and
have them finish them before taking on something new. The goal is to reduce stress and to raise productivity
as well as product quality.
Limiting the WIP for a given department allows it to finish the work at hand and helps avoiding the creation of
more and more new tasks. Studies have shown that this also increases the worker satisfaction due to a more
constant rate of work.
On the other hand, a team is not allowed to switch their currently assigned tasks before these have been
accomplished. Consequently, if for example they are faced with some problems, these need to be addressed
immediately.
2.3 FROM PUSH TO PULL
Existing and more traditional approaches to product development are usually based on a push-system. A
finished product, or part of it, is pushed down the line to the next station for them to handle. As a
consequence of introducing Lean and Just-in-Time Production and especially of work in progress limitations,
Kanban introduces the pull-system. Instead of overloading a team’s backlog with finished work-items from
previous teams, the idea is for them to get new ones as soon as they have capacities available, i.e. when the
number of work items is lower than the WIP limit.
The effects of combining the pull principle with the previous three are that a given team as well as the project
managers are able to detect and to solve bottlenecks more easily. For example, teams may merge for the
purpose of solving a difficult problem or the managers may see fit to reassign resources such that the
workflow remains constant.
2.4 VISUALIZATION OF THE WORK
Kanban is a system relying on visual means with which to present the work that needs to be accomplished. It
uses the so called Kanban-boards and cards to visualise a project’s current state. As a matter of fact, the word
Kanban is of Japanese origin and translates to signboard. Other common translations include visual card,
billboard or signboard.
4
Lean Software Development: An Agile Toolkit, Mary Poppendieck & Tom Poppendieck (2003), ISBN-10 0321150783
5
eNotes: Encyclopedia of Management (http://www.enotes.com/management-encyclopedia/lean-manufacturing-just-time-production)
7
What is Kanban?
Moreover, principles such as Lean and Just-in-Time production as well as limiting the workflow become easier
to implement with the exhibition of all on-going tasks. A Kanban card, describing for example the building of
a new car-part, moves through the Kanban board depending on the current stage. Hereby stages represent
for example the Specification, Construction and Testing of car-parts.
2.5 PROCESS IMPROVEMENTS
One of the key ideas behind Kanban as applied in IT is to constantly and iteratively improve the process. First
of all, a means for measuring and managing the work flow is needed, which in Kanban is achieved by the
principle of visualising the work in combination with statistical measures on the work flow, e.g. lead time.
Improvement is also achieved by making the process policies explicit, which not only allows the employees to
apply them properly, but also to actively collaborate in revising the used methodologies (c.f. next chapter).
3 KANBAN IN IT PROJECT MANAGEMENT
Although Kanban originated in the automotive industry, it was soon adapted and extended to other fields and
quite recently to IT project management in particular. In the last few years, as its reputation is spreading,
Kanban has seen much adoption in the area of software development (c.f. chapter 7 on page 19).
3.1 THE PROPERTIES
As a lean and agile approach to software development projects, no single Kanban model exists that can be
applied to any project. Every project, and possibly every team working on that project, needs to define their
own set of guidelines to follow.
Then again, by careful analysis of successful Kanban implementations, David Anderson was the first to
determine the following basic set of properties common to all of them:
1.
2.
3.
4.
5.
Visualize Workflow
Limit Work-in-Progress
Measure and Manage Flow
Make Process Policies Explicit
Use Models to Recognize Improvement Opportunities
Properties 1 and 2 follow directly from the previous chapters 2.5 and 2.3.The third property is a key concept in
Kanban, as we have seen in chapter 2.4. In combination with work visualisation (chapter 2.5) Kanban allows
you to easily measure the flow of work items and react to or manage any arising problems. The measurement
used in Kanban is called lead time, which is equal to the time needed by a team to accomplish a work item.
As for the fourth property, it would seem to be common sense to make process policies explicit. Especially for
Kanban, for which the applied rule set may change even from project to project. Openly stating and
explaining the applied rules and methodologies can help the staff members to properly apply them.
The last property comes from the “Agile nature” of Kanban. Kanban facilitates change management and as
such, constant adaptation to ever changing requirements is welcome. Indeed, “The Kanban Method suggests
6
that a scientific approach is used to implement continuous, incremental and evolutionary changes” in order to
decrease the lead times.
6
Taken from: Wikipedia - Kanban (Development) (http:/en.wikipedia.org/wiki/Kanban_%28development%29)
8
Kanban in IT project management
3.2 INTEGRATING KANBAN
Kanban is a tool or technique based on the principles of just-in-time and lean production. However, people
rightfully argue that Kanban cannot be seen as a silver-bullet approach towards project management. In fact,
as mentioned earlier, some underlying process should already exist before Kanban can be deployed.
This requirement is necessary because Kanban does not enforce any particular method on how to get work
done, as long as their combination is logically feasible and people are willing to use it. Building software using
a model driven approach is equally valid as doing for example XP in which models are avoided. The idea is that
the teams should use whatever works best for them.
Software development companies all over the world have been using agile methods such as Scrum for some
time now. Only recently, a new hybrid solution called Scrumban was introduced, which combines aspects of
both Scrum and Kanban. It tries to replace the normally time-boxed Scrum sprints by Kanban’s pull
mechanism, thus ensuring a more constant rate of work and simplifying bottleneck detection. Although
7
Scrumban is relatively new and only a few books exist , it should be noted that by simply merging the two
methods, one might still adhere to the Kanban principles but not necessarily to those of Scrum.
A similar scheme is followed by XKanban which describes an approach where eXtreme programming is
combined with Kanban. The goals, activities, values, rules and principles defined by XP are implemented
whereas the scheduling mechanisms of Kanban are used to eliminate workflow problems.
Anderson explains in his book, that in order to integrate Kanban you should implement a plan and follow the
following steps:
1. Agree on a set of goals for introducing Kanban
Agree on why you want to introduce Kanban.
2. Map the value stream
Define the development actions i.e. the Kanban board columns - e.g. design, coding, testing…
3. Define a point where you want to control the input
E.g. a requirement control point might be placed before the design phase.
4. Define an exit point
Define where and when a work item is completely finished.
5. Define a set of work item types
Define different card types as for example bugs, maintenance, requirements…
6. Analyse the demand for each work item type
Analyse the arrival rate and the according variation of for example bug reports, and decide how to deal
with peaks and fluctuations.
7. Meet with upstream and downstream stakeholders to distribute global knowledge amongst
all parties
Discuss WIP limits, prioritization as well as release and delivery coordination...
8. Create the board and cards with respect to step 2 & 5.
The board and card creation might be done using electronic systems as presented in chapter 8 (page 24).
9. Agree on daily stand-up meetings in front of the board
10. Agree on regular review meetings to analyse the current process
7
E.g.: Scrumban - Essays on Kanban Systems for Lean Software Development
9
What is Kanban?
11. Educate the team on the new board.
Explain WIP limits and the pull system and most importantly explain that the people’s activities remain
the same. No new job titles, descriptions or responsibilities are introduced.
As the books, papers and case studies from section “Literature and Case Studies” indicate, the difficulty of
integrating Kanban seems to be fairly manageable. Usually employees recognize at very early stages of the
integration process that the approach is aimed towards improving the working atmosphere and people seem
generally open to adapt and integrate the system.
3.3 THE BOARD
Since workflow visualisation is such an important part of using Kanban, we will give a short introduction to
Kanban-boards with respect to IT project management. The next chapter contains more details on how these
boards may be designed.
The Kanban board consists of different columns which represent specific steps in the development process.
Since a team needs to know which item they can pull from the board, these column require a means to
differentiate between on-going and finished work items. For the purpose of this example, this
differentiation is shown only for the analysis and development phases.
7
4
6
3
5
Pending
Analysis
Development
Test
Deploy
Doing
Done
Doing
Done
Figure 1: Exemplary Kanban-Board
The Kanbans, i.e. the cards, are shown in Figure 1 as orange rectangles. Each one represents a feature of the
target product. To show the nature of the work that is to be done, differently coloured Kanban cards may be
used:
maintenance
new feature
bug fix
Figure 2: Exemplary colour coded features
You can use the same approach for differentiating between different products and attach the nature of the
Kanban using other means, e.g. different symbols. Another way of visually handling multiple projects on a
single board is to introduce so-called swim lanes. The columns on these boards represent the different stages
a product has to go through. In IT projects this simply means the different teams that are involved in its
development. Furthermore, the numbers on top of the columns indicate the work-in-progress limitations. At
no point in time may more than the indicated number of work items be in any given column.
10
Kanban in IT project management
7
4
6
3
5
Pending
Analysis
Development
Test
Deploy
Doing
Done
Doing
Done
P1
P2
Figure 3: Exemplary Kanban-Board with Swim Lanes
3.4 KANBAN BY EXAMPLE
8
In this part of the document, we use a small example , to illustrate how the principles of Kanban are applied
and how the Kanban board is used. For the purpose of this example, we suppose that an integration plan has
been created. In that plan three types of Kanban cards have been defined, as in Figure 2 on page 10. In
addition the cards have an implicit priority ordering attached to them, as in:
bug fix
>
maintenance
Figure 4: Card priority
>
new feature
In combination with a backlog, this sets up a flexible priority system. The manager can define priorities
dynamically, by putting the wanted cards on the board in the helper column named Ready. The development
and the deployment teems have to adhere to the defined ordering.
Now suppose during planning, the following board was designed. The backlog contains the work-breakdown
structure of the project. The manager will put the highest priority cards on the ready stack, which then in turn
will get pulled through by the developers, from left to right.
Backlog
2
2
1
Ready
Development
Deploy
In progress
Live
Done
E
Figure 5: Kanban Board in the beginning
The manager decides that the bugs and maintenance work described on the cards F and H are currently the
highest priority and puts them on the Ready stack. Due to the WIP limit of 2 in the Ready column, he cannot
put more cards on the board afterwards and has to wait for the developers to start working on those cards.
8
Based on One day in Kanban-land, p.44-46, from Kanban and Scrum - making the most of both
11
What is Kanban?
Backlog
2
2
1
Ready
Development
Deploy
In progress
Live
Done
E
Figure 6: Manager puts two cards on the board
Since the development team has the capacities available, they pull those cards into the In progress column
and start working on the tasks defined on them. This allows the manager to put two new cards on the board:
Backlog
2
2
1
Ready
Development
Deploy
In progress
Live
Done
E
Figure 7: Cards pulled by development team
After some time, the developers finish card F, allowing the deployment team to start working on it. Only then
can the programmers pull a new card. In the following example, that new card has to be D, due to the card
priorities defined during the planning phase. The project manager in turn puts card B on the board.
Backlog
2
2
1
Ready
Development
Deploy
In progress
Live
Done
E
Figure 8: Progress on the board
In the following situation the development team is stalled and cannot take on new work items. The problem is
that the deployment team is blocked due to a problem with card F, which they are not able to solve by
themselves. In such a situation, both teams may merge for the purpose of solving the issue faced.
12
Kanban in IT project management
Backlog
2
2
1
Ready
Development
Deploy
In progress
Live
Done
E
Figure 9: Development Team stalled
As soon as the issues have been resolved, the respective teams may return to the normal work-item schedule,
pulling in cards as capacities become available.
Backlog
2
2
1
Ready
Development
Deploy
In progress
Live
Done
E
Figure 10: After fixing problems with card F
Backlog
2
2
1
Ready
Development
Deploy
In progress
Live
Done
E
Figure 11: The board after a while
Please note that this is only an example to show the basic principles of Kanban and the Kanban board. Those
will hold however complicated the card and board designs are. The defined “work-rules” should extend
Kanban such that it fits the particular project’s needs.
Lastly we want to show a more complicated example based on a board with two swim lanes. Here the second
lane represents cards associated with a high priority Service Level Agreement (SLA). Usually,
developers, testers, etc. should not stop working on current WIPs, before moving on to the next one, even if
the next one has higher priority than the current one. As such you may add an additional rule, which states
that cards in the SLA lane have a higher priority than the other lane.
13
What is Kanban?
7
4
6
3
5
Pending
Analysis
Development
Test
Deploy
Doing
Done
Doing
Done
Std
SLA
Figure 12: Service Level Agreement board example
However Kanban can also be adapted such that project team members immediately have to work on items in
the SLA lane, suspending any current WIPs. At first glance this may seem counter-productive, but it may
make sense depending on how the SLA is phrased, i.e. how much the customer is willing to pay for the
expedited service.
4 COMPARING KANBAN TO OTHER AGILE METHODS
What makes Kanban different from other software development methodologies such as Scrum, eXtreme
Programming (XP) or OpenAgile?
First of all, where Scrum and XP are designed to specifically target IT project management, OpenAgile and
Kanban can be applied in virtually any project with teams doing operational work. Additionally, Kanban is a
lot less structured, or in other words prescriptive, than most other agile methods. It is so close to not having
any rules or structure at all, that it cannot be considered to be an entire process framework.
Hence, it would not make sense to compare the models directly. On the one hand, they target different parts
of project management and as such contain incomparable rules or guidelines. Secondly, throughout literature
we have found many different rule-sets for some of the methodologies. Scrum for example ranges from nine
9
10
rules up to twenty-three, with an additional optional twelve .
Nevertheless, we will give a short overview over the main differences between Kanban and the other three
methods. Any rules, means and methods implemented by Scrum or XP that are not mentioned by Kanban,
can be applied as needed.
4.1 KANBAN VS. OPENAGILE
Compared to Kanban, OpenAgile takes a more philosophical approach to project management as can be seen
11
from the three rules it is built on :
1.
2.
3.
Truthfulness
Consultive Decision-Making
The Learning Circle
Hence, OpenAgile compliments the more process oriented Kanban with respect to employee morale.
Additionally, as a model of learning circles and just like Kanban, OpenAgile emphasises continuous
improvement of the currently implemented processes. But unlike Kanban, it relies on circular time iterations
9
Kanban and Scrum - making the most of both, Henrik Kniberg & Mattias Skarin (2010)
Agile Advice: Scrum Rules, Mishkin Berteig (2007), URL: http://www.agileadvice.com/archives/2007/05/scrum_rules.html
11
The OpenAgile Primer, version 1.0.5 (2009), URL: http://www.openagile.com/TheOpenAgilePrimer
10
14
Comparing Kanban to other Agile Methods
of equal length for time management. Kanban makes no such assumptions on how you should limit the time a
work-item takes from start to completion. In fact it allows long running tasks.
On the other hand, Kanban does not forbid the use such an approach. Additionally, even though it says to
constantly improve processes and even gives some measurement techniques, it does not define how to do it.
One is free to combine Kanban with OpenAgile for a more complete improvement model.
4.2 KANBAN VS. SCRUM AND XP
Due to the different natures of Kanban, Scrum and XP, we will focus their comparison to the few properties as
defined in chapter 3.1 The Properties:
V ISUALISE THE W ORKFLOW
In Scrum, the use of a Scrum-Board is prescribed, whereas Kanban enforces Kanban-Boards. Both are
basically card walls, either physical or virtual. In comparison, Kanban adds WIP limits which we will discuss in
the next rule.
XP does not make any prescriptions on using visualisation techniques or even attributes any big importance to
workflow visualisation as it would take too much time from programming tasks.
L IMIT W ORK I N P ROGRESS
Kanban enforces to set limitations on the WIP, by setting upper bounds on the number of possible WIP at any
given stage. These limits should be indicated on the Kanban-board for everybody to see.
Kanban does not limit the time needed to complete a task in any way. In contrast Scrum and XP share the
technique of time boxing (called sprint in Scrum terminology), which means that the teams need to commit
to a defined set of work items for a defined period of time. Since an active time box may not be changed in
either methodology, that commitment indirectly limits the WIP.
Another difference between Kanban and the other two is that Kanban uses these work in progress limits to
change the basic project management paradigm from pushing work downstream, i.e. from development to
testing, to pulling it from upstream.
M EASURE AND M ANAGE F LOW
Although not part of Kanban itself, software development projects in general and Kanban infused projects in
particular require some form of management and measurement. David Anderson identified both to be of such
importance, that he included them in the Kanban rule set.
With Scrum and Kanban, project management is simplified or helped by their respective boards. An empty
column, or row depending on the design of your specific boards, will hint at a problem, either beforehand or
afterwards, that needs to be addressed. Their measurement methods are different though.
Scrum and XP define and use Velocity, which is the number of story points a given team can accomplish
during a sprint. Or in other words: it is a calculated measure for the efficiency of a team. Kanban on the hand
uses Lead Time as its main measuring instrument. That is the time needed to accomplish a task from start to
finish, which could be seen as more natural and easy to understand by the stakeholders.
To gain a more complete and concise insight into the current state of your project, similar to Scrum, regular
Kanban-meetings should be held. These are short gatherings to get input from the developers, testers, etc…
Only then can the project managers learn whether any problems are of temporary nature due to unusual
complexity or if a team- or resource-restructuring is in order.
15
What is Kanban?
M AKE P ROCESS P OLICIES E XPLICIT
As we already mentioned, the rules and management methodologies should be defined, explained and
communicated to the people working with them. Otherwise it would be very difficult to do the What if you do
not know the How. Being an elementary property of effective project management, this holds true for any
methodology.
U SE M ODELS TO R ECOGNIZE I MPROVEMENT O PPORTUNITIES
All three methodologies, being agile in nature, suggest some form of continues process improvement.
Kanban encourages collaborative improvement of existing processes using a scientific approach. What this
means is that everybody should be part of the improvement process itself. Furthermore, a mere trial and error
should be avoided and more structured and organised methods should be used. One such example is the
Theory of Constraints, which defines a process to determine and eliminate restricting constraints.
4.3 KANBAN VS. THE REST
We could go on comparing Kanban to many other agile development methods, as for example Dynamic
Systems Development Method (DSDM) or Feature-Driven Development (FDM). In any case, Kanban makes
no restrictions or assumptions other than to apply the principles mentioned in this document. By using
Kanban some, if not all, of a project team’s current issues may become apparent and solvable. On the other
hand, Kanban is not an off the shelf methodology and needs to be completed using any or more of the other
methodologies, e.g. use FDM to create work-items based on requested features.
5 THE ADVANTAGES AND DISADVANTAGES OF KANBAN
5.1 ADVANTAGES
The main Advantage of Kanban over other agile methods (e.g. Scrum) is its flexibility which is the result of a
smaller set of predefined rules (as described in chapter 3).
As a concrete example, Kanban allows the addition and removal of tasks (e.g. a high priority database
component), while teams are still working on something else. Compared to Scrum, where it is not allowed to
add extra work to an on-going sprint, Kanban handles such issues more flexibly since it is tailored to changing
12
dynamics and requirements.
Studies have shown that another advantage is the visualization aspect of Kanban. Project members can easily
determine the state of the project by looking at a simple Kanban board. Thereby showstoppers can be
detected more easily than with other non-visual approaches.
Moreover, the pull approach together with the work in progress limits beware workers from unnecessary
stress, while at the same time enforcing a better prioritization of the tasks that need to be done.
5.2 DISADVANTAGES
Although an increased flexibility may be attractive, it also requires people who are committed to the
approach. In fact, Kanban cannot be seen as a standard solution to successful project management. Rather it
is a tool which builds upon existing approaches and helps solving certain kinds of problems, as for example
the detection of bottlenecks and the meeting of deadlines. Other approaches such as Scrum or eXtreme
Programming give more guidelines on how to conduct the development process and might be better suited
depending on the project teams.
12
This is often solved by adding priorities to Kanban cards. Single teams can then process higher priority tasks as soon as
they have the resources for it.
16
LITERATURE AND CASE STUDIES
In this part, we will introduce some of the existing literature about
Kanban. We will cover three of the more popular books and present
some exemplary case studies.
Literature and Case Studies
6 THE KANBAN BOOKS
During our research we found that throughout literature, the following three books are the most referred to.
We will therefore give a brief introduction to all three, while trying to capture to most essential content. For
more details please have a look at the books themselves.
Kanban - Successful
Evolutionary Change for
Your Technology Business
Kanban and Scrum - making
the most of both
Kanban: Just-In-Time At
Toyota
by David J. Anderson
by Henrik Kniberg & Mattias
Skarin
by David John Lu and Nihon
Nōritsu Kyōkai
Blue Hole Press (2010)
C4Media Inc. (2010)
Japan Management Association
(1985)
Figure 13: The three Kanban books
6.1 KANBAN SUCCESSFUL EVOLUTIONARY CHANGE FOR YOUR TECHNOLOGY BUSINESS
This particular book, written by David Anderson who is credited with the first implementation of Kanban in
software development, has to be the reference guide on how to use and set-up Kanban in an IT business.
Anderson starts off in the first two parts by giving an introduction to Kanban, defining the basic principles and
emergent behaviour. He then writes about Kanban’s benefits by sketching a recipe for its implementation and
explaining the Kaizen culture that is Kanban’s constant stride for improvement. He also includes a case study
on how a team from Microsoft managed to improve their process by using Kanban (c.f. chapter 7.1.2).
In the third part of his book, Anderson gives detailed information on how to implement Kanban. He stresses
the importance of mapping existing value streams and how to set-up work-in-progress limits. He also touches
the field of Service Level Agreements, and how Kanban can help to expedite or even to introduce them. Since
Kanban affects not only development, he then writes about how the adapted processes can be measured and
managed.
In the fourth and last part of his book, Anderson talks about how to make improvements to the “kanbanised”
work flow. He introduces three types of improvement opportunities and details their respective natures and
effects.
18
Industry Success stories
6.2 KANBAN AND SCRUM - MAKING THE MOST OF BOTH
This book focuses on the question: “What is Kanban and how does it compare to Scrum?” It compares both
approaches in a software development scenario and is starting at the very basics. In fact, no major knowledge
about Scrum or Kanban is required to understand the presented concepts.
The book gives a good overview on Kanban and highlights the advantages and potential risks. It also includes
a case study about a Swedish game development company. It shows how they transitioned from Scrum to
Kanban and hence were able to meet deadlines while reducing lead time and the backlog (c.f. chapter 7.1.3).
It is noteworthy that the authors also distribute the book also as a free-of-charge PDF!
13
6.3 KANBAN: JUST-IN-TIME AT TOYOTA
This book is one of the earlier publications with respect to Kanban. It describes the Kanban method as it was
initially used at Toyota for improving their production of automobiles. It explains the just-in-time basics as
well as the Toyota production system.
Despite the fact that this book focuses on the industrial aspects, the spirit of lean manufacturing is
transferable to the IT domain. Essentially, it shows how Kanban can be used in any production context.
7 INDUSTRY SUCCESS STORIES
7.1 CASE STUDIES
7.1.1
MONEYSUPERMARKET.COM
Moneysupermarket.com is one of the United Kingdom’s leading comparison websites. This case study shows
how they were able to improve their delivery process through the introduction of Kanban. Like many other
software development companies they were faced with too many simultaneous tasks, while the single tasks
often had various priorities.
Through adopting Kanban, they were able to spot the bottlenecks and blockers within their system and to
address the issues. The visualization using the Kanban board gave an end-to-end flow and allowed the
resolution of bottlenecks as soon as they occurred.
The IanCarroll consulting company, which published the case study, summarized the results as follows:
•
•
•
•
Throughput was measurably increased
The backlog (469 jobs) was completely cleared within 5 months
The collaboration was improved
The clarity on the current situations was improved due to the visualization
7.1.2
FROM WORST TO BEST IN F IVE QUARTERS
In his book (c.f. chapter 6.1) David Anderson presents a case study from 2004 on how Dragos Dumitriu
managed to improve the processes of a Microsoft development team based in India. This team had the
reputation of having the worst customer service within Microsoft and Dumitriu was determined to change
that.
By applying the Kanban method, i.e. workflow visualization and limitation as well as mapping the value
stream and implementing the pull-system, Dumitriu was able to spot and solve most of the problems faced by
the Indian team. They were able to detect and solve bottlenecks as for example wrong resource attribution
between developers and testers. They furthermore abolished time estimation as it was in itself a time-waste
13
After a quick registration, the book can be downloaded at http://www.infoq.com/minibooks/kanban-scrum-minibook
19
Literature and Case Studies
and they removed the necessity for ROI (Return On Investment) calculations by relying solely on work-item
priorities.
In the end, even though they did not implement all the possibilities of Kanban, the results of these few small
changes were impressive:
•
•
•
•
7.1.3
They managed to eliminate an originally overflowing backlog entirely in just over a year.
They reduced the lead time from an original 155 days to 14 days.
The due-date performance on the 25-day delivery time target was 98 %.
The throughput of requests had risen more than 300% and lead times dropped by more than 90%.
KANBAN AND SCRUM - MAKING THE MOST OF BOTH (BOOK PART II CASE STUDY)
The second part of the previously introduced book “Kanban and Scrum – making the most of both” provides
an exhaustive case study about a Swedish game development company’s transition from Scrum to Kanban.
The case study introduces how they set up teams, addressed stakeholder needs and how they established the
Kanban boards and WIP rules. The results presented were that they managed to resolve bottlenecks, achieve
a constant work flow and most importantly that by adopting Kanban they were better able to meet deadlines.
7.1.4
CONVERTING A SCRUM TEAM TO KANBAN (CRISP CASE STUDY)
This industrial success story is about a Swedish consulting company named Crisp and a French software
14
company named Nuxeo . One of the major alterations introduced by this consulting company was the
conversion of a Scrum team into a Kanban team.
Before this conversion, Nuexo’s Scrum team had major problems in meeting deadlines. As a result, the main
client was not satisfied and a project failure was certain. As the development team was using Scrum, their
burn-down-chart confirmed the issues and provided evidence that Scrum was not the way to go in this case.
After transitioning to Kanban, improvement results were visible after only two weeks. Progress occurred also
in another form, meaning that a previously unknown bottleneck was detected. For the first time, employees
were able to see that the testing department couldn’t handle the work load. As a countermeasure, Test
Driven Development was introduced which then helped resolving these issues, such that at the end, the
project succeeded after all.
In retrospect, statistics showed that the velocity of all involved teams was almost doubled.
7.2 SCIENTIFIC CASE STUDIES
7.2.1
DEVELOPER-DRIVEN BIG-BANG PROCESS TRANSITION FROM SCRUM TO KANBAN
This scientific case study describes the transition of a Swedish content management system development
company from Scrum to Kanban.
Although the company’s initial experiences with Scrum were positive, it showed that over time, problems “of
the disciplinary manner started to emerge”. The paper gives the example of Scrum demos which were more
and more rarely conducted over the time. Also, the company experienced that for example the job
satisfaction decreased and that process related problems occurred more and more often. The paper gives a
list of 11 problems the company had including
1.
2.
3.
4.
14
15
Confusion upon the definition of “done”
15
Low prioritization of the technical backlog items
Lack of production vision
...
Converting a Scrum team to Kanban by Mattias Skarin, Crisp
The backlog in its most simplistic form is an exhaustive TODO list with respect to a project.
20
Industry Success stories
9. Low developers’ motivation
10. Insufficient Development Process Flow
11. Increase of the technical depth
As a possible solution to address problems 9, 10 & 11, Kanban was implemented. Interesting in this particular
case study is that the transition was performed almost overnight, meaning that all changes were applied as
soon as possible.
As part of the conclusion, the authors state that: “As a result, the company has solved various process related
problems, improved developers’ motivation, and therefore, successfully implemented software process
improvements.”
7.2.2 ON THE IMPACT OF KANBAN ON SOFTWARE PROJECT WORK
Another case study investigates the impact of Kanban with respect to software project work in general.
The paper therefore introduces a research framework which is empirically investigated in an experimental
software Research & Development setting.
It shows that using Kanban, seven of the nine pre-defined team-related aspects (e.g. problem solving,
visualization, feedback, ...) were supported. The authors give as possible explanations:
•
•
•
the autonomy that the single teams have in Kanban
the simplicity of Kanban and the resulting quick reaction ability
the fact that Kanban takes into account the dynamic nature of software development including
unrealistic schedules and continuous requirement changes
The paper comes to the conclusion that Kanban bears considerable benefits including motivation and control
over a project’s activities. The paper also claims that Kanban is a relatively basic control tool. It needs to be
supported with additional practices and connections.
21
TOOLS AND APPLICATIONS
In this part of the document, we present a few Kanban based project management
applications. These tools vary in the included feature-set as well as the underlying
technology.
Tools and Applications
8 APPLICATIONS
As Kanban is getting more and more popular, many Kanban related applications arise. The functionalities
offered by these applications vary greatly and include everything from basic board features up to complex
management tools.
In this chapter we will introduce four exemplary Kanban applications, namely Flow.io, Swift Kanban, Kanban
Tool and LeanKit Kanban. We researched available software and sampled these four from those that are
publicly available. They show what can be expected of Kanban oriented project management software.
Additionally, we present a program that in the future may be used for simulating the Kanban process.
8.1 FLOW.IO
Flow.io is a web-based centralized solution accessible via www.flow.io. The feature set of this application is
fairly limited - e.g. no support for special board types - but nevertheless, it provides all essential elements to
get started with Kanban.
Figure 14: Flow.io Board Example
Figure 15: Flow.io metrics
The main focus of the application is to:
1.
2.
3.
visualize the workflow
support just-in-time production
give accurate estimates.
Besides basic features such as adding custom board columns and Kanban cards, the application also provides
additional features such as assigning Kanban cards to people or commenting on Kanban cards. Moreover,
automatically generated metrics on task completion, cycle breakdown and flow can be consulted.
A personal version of flow.io is available free of charge. However, using this version, it is not possible to create
and assign teams to Kanban cards or boards. Therefore, a team variant ($5/user monthly – 30 days free trial) is
advertised.
In conclusion, flow.io provides many interesting features and might be interesting to get started with Kanban.
However, a physical board might be more appealing to many people while at the same time, no information
about the own development is sourced to third-party servers.
8.2 SWIFT KANBAN
Swift Kanban is another, more sophisticated or feature rich example of a cloud based project management
solution based on Kanban. It supports the same basic board-management features as Flow.io. This includes
amongst others, the creation, modification and movement of Kanban cards, the handling WIP limits as well
the assignment of cards to people and the calculation of statistics.
24
Applications
Swift Kanban handles its backlog of cards separately from the different
boards. This gives the managers the ability to prioritise the work globally,
instead of only on a by card basis. The cards themselves already give a
great deal of information about any specific WIP. Figure 16 shows an
example of a card that has been blocked. Moreover, a card can be
archived, (un)blocked and have comments attached to it. Swift Kanban Figure 16: Swift Kanban Card Example
also provides a feature which we have not found with many other Kanban applications, namely adding
multiple tasks to a card. Using this ability, items from the work breakdown structure can be grouped into
logical units or components.
A
B
Figure 17: Swift Kanban Board Example
One feature worth mentioning is that Swift Kanban is able to handle multiple projects, even when using the
limited free version. Every project has its own assigned team members, card backlog, releases and much
more. Furthermore, you can personalise your Swift Kanban start page with widgets. These are small snippets
which give you for example an overview over the current states of the projects you are working on.
As you can see under A in Figure 17, Swift
Kanban allows you to heavily modify your
board to fit the needs of your project and
developers (unlike Flow.io). B is an example
of Swift Kanban’s ability to handle swim
lanes, called Smart Lanes in this webapplication, which you can configure based
on a multitude of Kanban card attributes
(see figure 18).
Although it has a lot more features than
Flow.io, Swift Kanban is nearly as easy to
use. It has a clear, somewhat self-explaining
web-interface with an easy to navigate menu-system.
Figure 18: Swift Kanban swim lanes configuration
25
Tools and Applications
8.3 KANBAN TOOL
16
Kanban Tool is a Software as a Service (SaaS) based Kanban-board solution. At first glance, the difference
between this service and for example Swift Kanban seems minimal. However, Kanban Tool may be better
suited in situations in which the card design of Swift Kanban is overloaded and a sleeker version is needed.
Additionally, since Kanban Tool is a SaaS, their system can be integrated into existing software environments
using a REST base API.
Figure 19: Kanban Tool stylish board example
8.4 LEANKIT KANBAN
17
Next, we want to introduce LeanKit Kanban . On the one hand, it is yet another web-based Kanban system,
with a similar feature set than Swift Kanban. It provides all the necessary functionalities to create, manage
and customise a board, including for example service level agreements.
On the other hand, LeanKit Kanban has a very advanced metric system. Aside from the standard cumulative
flow diagram and cycle time charts, it allows you to show and precisely configure process efficiency, process
control and work distribution charts, to name just a few examples.
Figure 20: LeanKit Kanban statistics example
16
17
Kanban Tool: http://kanbantool.com/
LeanKit Kanban: http://www.leankitkanban.com/Home/
26
Applications
Figure 20 is an example of an efficiency diagram. It shows on how many of the active tasks work is actually
being done. It also provides precise control over the time period to use for the calculations as well as which
board-category to use the cards from and whether the size of a card (i.e. the work-load associated with) is to
be considered.
8.5 KANBANSIM
Although not publically available at the time of writing this document, KanbanSim is an application which
offers a “Simulation Engine For Kanban Systems” developed by FocusedObjective.com.
18
The reason behind developing such a simulator is that we often have to deal with questions such as : When
will my project be finished? Which factors most influence that date? And how many people do I need?
Answering these questions is often a very challenging and complex process which involves a lot of
uncertainty.
Figure 21: KanbanSim Screenshot
The presented KanbanSim application focuses on the complex modelling of software development teams and
projects delivering visualizations and statistics as a result. These statistics can then be used to help improve
decision making processes.
Some of the most interesting features planned for the release include:
•
•
•
•
•
Forecast completion dates and budgets using statistical data and charts
Manage WIP limits and staffing levels by analysing column usage
Model Kanban board definitions, including columns, WIP limits, and cycle-times
Visually display a modelled Kanban board card positions and status
Create videos of a simulated Kanban board to share with others
A demo video showing the simulation process and a brochure describing the application are available at
www.focusedobjective.com/simulators/kanbansim
18
Questions copied from KanbanSimulator brochure
27
SMALL SCALE LEGO CASE STUDY
In this part of the document, we present a small scale case study on the usage of
Kanban. The intention behind this case study was to investigate how Kanban works in
an active setting, and to better illustrate Kanban to people that are new to the
approach.
Small Scale Lego Case Study
9 OBJECTIVES
The objective of this small scale case study was to get a first-hand impression on how Kanban works in an
active scenario. As often with agile methods, it is best to show people how a method works as opposed to just
giving them instructions. One of the major goals was to find a suitable way of illustrating the method to
people and to motivate them, such that they might consider using this approach in real life.
The final experiment was conducted in the form of a “serious game”. We decided to challenge the participants
with building a city out of Lego based on predefined schematics. This idea arose out of an initial experiment
conducted by Prof. Dr. S. Coronado which often challenges students of his project management class with
building two dimensional paper houses using scissors, duct tape and pens. However, compared to the
professor’s experiment in which most students normally do not follow a specific method, this experiment was
intended to investigate and demonstrate Kanban.
To further illustrate the link between the study and software development, each phase was loosely based on
real life software development stages such as design, preparation, development and testing respectively
integration.
10 PREPARATION
One of the major problems in designing such an experiment is to let participants focus on the essential parts.
Hence, we tried to minimize distractions as far as possible and provided schematics and forms to the
participants to use. As an additional constraint, we defined a time limit of one hour for the execution of the
experiment. Furthermore, the participants should be able to enjoy the experience. Finally, the opinions of the
participants were to be collected using a questionnaire.
10.1 LEGO SCHEMATICS
As stated above, predefined schematics were handed to the participants.
However, they were required to introduce small modifications, as detailed
in the chapters 10.2 and 11.1.
10.2 KANBAN BOARD
To ensure a non-problematic execution of the experiment, as well as
defining a relationship to software development projects, a Kanban board
with predefined phases and WIP limits was provided to the participants.
Although the WIP limits were predefined, these were not fixed such that
participants had the possibility to adapt. In addition to the “project
backlog” and a “Finished” category, the following sections were used:
Figure 22: Example Lego House
Schematic
Design:
The team of participants responsible for the design phase was in charge of choosing a specific Kanban card
and thus Lego house. They then had to make changes to the chosen house and specify the types and number
of different Lego pieces needed by the “developers” to create that house.
Preparation:
The preparation team then needed to collect the Lego pieces from a big collection as per the specifications
from the design team. They were allowed to organize themselves as they saw fit, but they had to keep to the
lean principle of not producing waste. In this scenario this meant they had to provide exactly the specified
pieces and nothing else. If they were to detect any anomalies, they should defer to the design team.
30
Preparation
Figure 23: The experiment's Kanban board
Development:
The development team, or more accurately the building team, had the task of actually building the Lego
houses, according to the specifications and using the pieces provided. For missing Lego pieces they should
refer to the preparation team and for any design issues to the design team.
Integration/Testing:
The last team was in charge of testing the different house for stability and of verifying them against the
specifications. As a last step, they needed to place and fixate the houses on a predefined Lego City floor plan.
10.3 KANBAN CARDS
Each Kanban Card (Kanban Bag) within the backlog contained three items.
1.
2.
3.
A high quality picture of the object that needed to be built along with some minor modifications.
Participants were allowed to draw the modifications directly onto this image.
19
A form to fill out the number and type of the required Lego pieces
A bigger low quality picture of the object which was put onto the Kanban board. This picture was
moved along the board by us. At a later stage, participants did this by themselves.
10.4 QUESTIONNAIRE
The previously mentioned questionnaire consisted of 10 questions related to the described experiment. In
fact, a list of statements on which the participants were required to agree or disagree on by crossing a square
20
on a scale from -3 to 3 was provided . The participants were asked to fill the questionnaire out right at the
end of the experiment.
19
20
For an example of a used form, see appendix A
For the full questionnaire see appendix B
31
Small Scale Lego Case Study
11 EXECUTION
11.1 INSTRUCTIONS
At the beginning of the experiment, a small presentation was given to the participants in order to introduce
the most important concepts behind Kanban as well as the rules and constraints of the game. Additionally,
the team roles were explained as defined previously.
The rules of the game included that
•
•
•
•
the design team must do some small modifications to the provided schematics
the preparation team is only allowed to collect pieces as listed by the design team
the development/building team must built the objects as specified
the testing and integration team must ensure a more or less equal distance between all objects on
the floor plan
Finally, three additional constraints stated that
1.
2.
3.
each wall must be of a single colour (unless explicitly stated otherwise)
each roof must be of a single colour
each object must be different
Last but not least, the participants were reminded that they should try to build as many houses as possible.
11.2 EXPERIMENT
After the introduction, the participants divided themselves into teams and started building objects. A long
classroom table functioned as a product line in which the design team was the first, followed by the
preparation team with the Lego box, the development team building the objects and the testing and
integration team standing next to the floor plan.
Figure 24: Experiment execution, phase 1
32
Observations
After 30 minutes, a short brake allowed the participants to reflect on what they had done so far. This also
allowed them to investigate some of the problems. For one, they detected a bottleneck in the preparation
phase, while the development team was often waiting idly. As a result, the WIP limits were adapted and the
teams were reorganized.
Figure 25: Experiment execution, phase 2
At the end of the experiment the participants were able to build almost all of the predefined objects resulting
in a small Lego city. All participants were then kindly asked to fill out the short questionnaire.
Figure 26: The created Lego city
12 OBSERVATIONS
During the case study, we observed that after an initial coordination phase, people started working in a very
structured and effective way. The communication between the participants was very high which was most
probably due to the predefined work-in-progress limits. These WIP limits helped detecting some bottlenecks
very early during the experiment which then lead to discussions on how to improve the process.
33
Small Scale Lego Case Study
After a 5 minute break, the participants rearrangement themselves according to their particular skills and
decided to adjust the work-in-progress limits to avoid future bottlenecks. The participants continued working
in an even more coordinated fashion.
13 RESULTS
The analysis of the questionnaire outcome showed us that due to the experiment most participants became
more interested with Kanban. The 10 statements of the questionnaire were:
1.
I enjoyed the experiment
2.
The experiment helped me to understand Kanban
3.
I believe that Kanban, by using the “pull” principle could help to identify bottlenecks in a real-life project
4.
I believe that the work in progress (WIP) limits could improve worker satisfaction by reducing stress
5.
I believe that the work in progress (WIP) limits could improve productivity
6.
I believe that the lean and just-in-time principles are valid for software development
7.
I believe that the visualization of work via Kanban boards provides a better project overview
8.
The key principles of Kanban were illustrated during the experiment (Lean, JIT, Pull, WIP Limits &
Visualization)
9.
I would consider using Kanban in a real-life software development context
10. Due to the experiment, I'm more interested in Kanban than before, and would like to get additional
information
S1
P1
3
P2
3
P3
2
P4
3
P5
3
P6
3
P7
3
P8
3
P9
2
Avg.
2,8
StdDev
0,4
S2
3
1
1
1
1
3
2
2
2
1,8
0,8
S3
2
1
1
1
2
2
1
1
0
1,2
0,7
S4
2
2
1
3
2
1
0
0
1
1,3
1,0
S5
1
1
1
1
0
2
0
0
0
0,7
0,7
S6
0
0
0
0
2
2
1
1
0
0,7
0,9
S7
2
2
0
2
2
3
1
1
3
1,8
1,0
S8
2
1
1
2
1
2
2
3
-1
1,4
1,1
S9
1
2
1
1
2
2
1
0
1
1,2
0,7
S10
2
2
0
3
3
3
0
-1
2
1,6
1,5
Most notable is the average answer to statement 1. Almost all the participants completely agreed, which is a
good indicator that the experiment worked in a sense that it was educational without being boring. High
agreement was also identified with respect to statement 2 and 7. This lets us conclude that the game really
helped the participants identify the mechanisms and the usefulness. Because no real disagreement on any of
the statements is identifiable, it is possible that the participants (university students and classmates) might
have been too friendly to disagree. Nevertheless, the stronger agreement on the mentioned statements as
well as the weaker agreement on the other statements indicates that some of the principles, e.g. lean
production, were not well demonstrated by the experiment. To get more conclusive results, a broader study
or experiment needs to be done in the future. This is supported by the relatively high standard deviation
values.
34
SUMMARY
In this last part of the document we will briefly summarize the content
of the document as well as the conducted case study.
Summary
14 SUMMARY
As mentioned throughout the document, Kanban is a well-known management method in engineering, which
quite recently gained popularity in the context of software development. As one of the latest agile software
development approaches, Kanban promotes flexibility and communication over rules and protocols. Although
originally developed in the context of the Toyota Production System, Kanban is nowadays used in many other
domains.
The just-in-time and lean aspects of Kanban stem from a car manufacturing process. However, both aspects
proved to be also valuable in software engineering as well as other engineering domains. Moreover, Kanban’s
transition from pushing work to employees towards pulling it depending on free resources (WIP slots) seems
to support the detection of bottlenecks. Finally, the combination of pulling work together with predefined
work-in-progress limits and a graphical representation leads to a very effective project management tool.
In order to further investigate these principles, and to witness Kanban in action, we conducted a small scale
experiment. We asked participants to build a Lego city while using Kanban. Our observations indicate that
indeed Kanban helped people to increase productivity in a structured fashion and to detect bottlenecks more
easily. Finally, the questionnaire analysis showed that due to the experiment an impressive six out the nine
participants became a lot more interested in Kanban.
While our results essentially resemble those of many Kanban success stories and papers of which some are
mentioned within this document, we also discovered that there is at least one major issue as well as one major
opportunity.
The most noticeable issue with Kanban is its need for commitment since people need to pull work and to
finish this work as quickly as possible while respecting certain quality levels. However, real life shows that
often people need a certain level of work related pressure in order to deliver.
On the other side, the most imminent opportunity of Kanban is employee empowerment. Since people can
pull work at their personal pace, employees feel more responsible for the particular tasks, possibly leading to
an increased level of engagement.
In conclusion, we would like to add that Kanban is a very interesting approach which, if applied correctly,
seems to be very useful for project managers. Nevertheless, it is not a silver bullet solution to all problems
related to scheduling and work in progress management.
36
APPENDIX
Appendix
Appendix A EXPERIMENT FORM
Figure 27: Lego Pieces form used during the experiment
Figure 28: Picture card used during the experiment
38
Questionnaire
Appendix B QUESTIONNAIRE
39
Appendix
40