Exploring the sources of waste in Kanban software development projects

Abstract

Proceedings 36th EUROMICRO Conference on Software Engineering and Advanced Applications (SEAA 2010). Lille, France, 1-3 Sept. 2010, 376-381 The application of agile software methods and more recently the integration of Lean practices contribute to the trend of continuous improvement in the software industry. One such area warranting proper empirical evidence is a project's operational efficiency when using the Kanban method. This short paper takes a new angle and explores waste in the Kanban-driven software development project context. A preliminary research model is presented for helping the consequent replication of the study. The results from the empirical analysis suggest Kanban can be an effective method in visualizing and organizing the current work, but does not prevent waste from creeping in, although the overall project outcome may be successful. (18 refs.)

Full text

Page 1

To be appeared: Ikonen, M. & Kettunen, P. & Nilay, O. & Abrahamsson, P. in Proc. of SEAA Euromicro 2010 (IEEE).
Exploring the Sources of Waste in Kanban Software Development Projects
Marko Ikonen1
Petri Kettunen1
Nilay Oza2
Pekka Abrahamsson1
1){marko.ikonen|petri.kettunen|pekka.abrahamsson}@cs.helsinki.fi,
Department of Computer Science, University of Helsinki, Finland
2)nilay.oza@vtt.fi, VTT Technical Research Centre of Finland
Abstract
The application of agile software methods and more re-
cently the integration of Lean practices contribute to the
trend of continuous improvement in the software industry.
One such area warranting proper empirical evidence is
a project’s operational efficiency when using the Kanban
method. This short paper takes a new angle and explores
waste in the Kanban-driven software development project
context. Apreliminaryresearchmodelis presentedfor help-
ing the consequentreplication of the study. The results from
the empirical analysis suggest Kanban can be an effective
method in visualizing and organizing the current work, but
does not prevent waste from creeping in, although the over-
all project outcome may be successful.
1 Introduction
The software industry is in constant search of new ways
of solving existing problems [6]. The goals vary in dif-
ferent improvementinitiatives ranging from resolvingtime-
to-market delay to reducing operation costs and increasing
productivity. One of the newest fashions in the software in-
dustry is the attempt to apply lean production principles to
software development. One of the key traits of lean produc-
tion principles is eliminating all kinds of waste from the de-
velopment. Consequently, similar ideas for waste removal
have been proposed to be adopted for software product de-
velopment [12]. One of the lean tools is the Kanban way of
managing production operations [9]. Kanban has been ap-
plied to software production as a project management pro-
cess model[3]. The buzzis alreadyin motiononcombining
Kanban with the well established Scrum method in Agile
softwaredevelopment. E.g.Kniberg[8]introducessimilari-
ties anddifferencesbetweenKanbanandScrum. Yet, to our
knowledgethere are few, if any, empirical studies exploring
the internal dynamics or the process impact of the Kanban
model in software engineering. Therefore, following this
line of lean thinking leads to one of the research problems:
seeing waste in Kanban-drivensoftware projects.
This paper explores different sources of waste in a case
study of such a software development. We employed a con-
trolled case study research approach [14] in a novel exper-
imental software R&D laboratory called Software Factory
[1] wherein the empirical evaluation was performed based
on a 7-week,13-person software development project pro-
ducing a real web service for tens of thousands of users.
The results reveal that while Kanban has been designed to
minimize non-value-addingactivities, there are still several
sources of waste that are likely to appear. In addition, the
preliminaryresearchmodelprovedto be proficientforiden-
tifying potential sources of waste although it requires fur-
ther development. Altogether this research endeavor sug-
gests practical as well as methodological implications.
2 Related Work
In lean thinking, waste is basically everything that does
not add to the customer value of the products. In general,
threebasiccategoriesofwaste-relatedelementscanbeiden-
tified: (1) Muda: non-value-adding activities (NVA), (2)
Mura: variations (in process quality, cost, delivery), and (3)
Muri: unreasonableness (overburden). Consequently, one
of the most important principles of lean software develop-
ment is to learn to recognize waste. In software develop-
ment, such elements can be interpretedas follows [12]: par-
tially done work (inventory); extra processes (NVA); extra
features (overproduction); task switching, waiting, motion
(NVA); and defects. Table 1 illustrates why these issues are
considered waste. Furthermore, some less obvious waste in
certain cases can be wasted development time (e.g. due to
fuzzy front-end activities), wasted progress (requirements
not tied to business priorities), and wasted intelligence (un-
derutilization of personnel competence) [7].
In manufacturingoperations, the differentkinds of waste
are basically straightforward to detect by observing the
physical material flows and machine/worker activities [2,

Page 2

To be appeared: Ikonen, M. & Kettunen, P. & Nilay, O. & Abrahamsson, P. in Proc. of SEAA Euromicro 2010 (IEEE).2
Element
partially
done
work
Rationale for considering as waste
• does it work and really solve the business
problem after integrated into the software en-
vironment?
• ties up resources
• unnecessary paperwork consumes resources
and adds no value for the customer
• consumes resources when an extra feature of
a system is tracked, compiled, integrated, and
tested
• potential failure point
• working in multiple teams causes more in-
terruptions
• re-orientation back to work takes time
• delays in starting a project, staffing, reviews,
approvals, testing, etc. add no value
• prevents realizing value for the customer as
fast as possible
• lack of immediate access to other developers
and appropriate representatives disrupts con-
centration, and reestablish focus takes time
• regarding artifacts (e.g. documents or code),
tacit knowledge does not move with the hand-
offs from the next person in line
• a minor defect discovered after weeks is
more time-consuming than a major defect de-
tected in a minute
extra
processes
extra
features
task
switching
waiting
motion
defects
Table 1. Reasoning for considering the seven
elements as waste [12].
10]. Invisibility of waste in software development, how-
ever, restrains the progress. Partially done work, for exam-
ple, involves such emerging issues like requirement and er-
ror inventories. In order to manage these inventories, extra
processes are typically generated, which creates waste.
The Kanban process model is one of the key operation
management tools in lean manufacturing [9]. It is basically
a flow control mechanism for pull-driven Just-In-Time
production in which the upstream processing activities are
triggered by the downstream process demand signals. In
general, Kanban has three rules: (1) visualize the workflow,
(2) limit work in progress (WIP) at each workflow state,
and (3) measure the lead time (i.e. average time to complete
one item) [8]. Advantages of the Kanban-drivenoperations
are that the inventories (simultaneous WIP) are reduced
and the overall production flow can be balanced easier.
Poppendieck and Poppendieck [12] suggest 22 “think-
ing” tools for practitioners of lean software development
and categorize them into seven principles. Following their
suggestion of seeing waste being the most important tool to
begin with, our research here focuses on revealing waste in
Kanban software development projects. Figure 1 presents
this focus. We applied that tool framework as the research
model (Section 4.1).
3 Study Design
The Software Factory is a new software engineering re-
search and education setting at the University of Helsinki
[1]. It is an advancedR&D laboratoryenvironmentfor con-
ducting software projects. The concept comprises the phys-
ical laboratory environment coupled with a unique opera-
tional model from the empirical research perspective: the
operational setting comprises three different usage perspec-
tives of the laboratory: business (entrepreneurship), educa-
tion, and research.
The case project is a Kanban-based software develop-
ment project. The project size was a thirteen-member soft-
ware team, and an external technical consultant who visited
the Software Factory daily. The participants were Master’s
students with varying amounts of work experience in in-
dustry. The project lasted seven weeks and the participants
worked six hours per working day, which resulted in 23
person months of effort investment during the project. The
members were accepted to the project according to their in-
terests, andthe Bachelordegreewas required. In additionto
technical knowledge (i.e. at least coding and testing skills),
each member in the team had some experience of working
in a team-based environment. Some of the team members
were also experienced in project management.
Besides the use of Kanban, no other particular develop-
ment method was insisted upon. The team had close to full
control within the R&D setting to decide upon the practices
used. As a result, coding and testing were executed mostly
individually after the first two weeks. More experienced
members worked in small groups when they made designs.
They also helped and assisted the others in technical and
practical issues and gave useful advice. In short, the team
was self-organized.
Our research aim was to find out what kind of sources
of waste can be found in Kanban-based software develop-
ment projects. For this aim, we developed a preliminary re-
search model (Section 2) designedto identifythese sources.
We applied the framework illustrated in Figure 1 by gener-
ating questions regarding the waste issues under the seven
element categories (from A to G). The semi-structured in-
terview method [11] was used for collecting data. Five per-
sons from the team of 13 for the interviews were selected
so that they represented the three different roles: less ex-
perienced, more experienced, and the team leader. This is
calleda role-basedsampling. Thefirst authorperformedthe
semi-structured interviews after the project end. We used
open-ended questions and a semi-structured theme inter-

Page 3

To be appeared: Ikonen, M. & Kettunen, P. & Nilay, O. & Abrahamsson, P. in Proc. of SEAA Euromicro 2010 (IEEE).3
SEEING
WASTE
Eliminating
waste
Amplify
learning
Decide as late
as possible
Deliver as fast
as possible
Empower
the team
Build
integrity in
See the
whole
E. waiting
G. defects
F. motion
D. task
switching
C. extra
features
B. extra
processes
A. partially
done work
Principles of
Lean Software
Development
The element of the
interest in our
study.
Figure 1. Our preliminary research model based on [12].
view technique. Each interview lasted approximately one
hour. The interviews were recorded in audio and the an-
swers were categorized into the seven kinds of waste based
on the research model presented in Section 2. In addition
to this evaluation, we measured the overall project success
based on Shenhar’s [15, 16] first (i.e. project efficiency),
second (impact on the customer), third (i.e. business suc-
cess) and fourth (preparing for the future) dimension.
4 Empirical Analysis
The interviewsrevealedwaste andincreasedunderstand-
ing of the functioning of the Kanban process model. We
organized our interview results according to the research
model into seven categories of waste (from A to G), based
on Figure 1. Section 4.1 assembles the interviews by these
categories with sample questions and responses, and ex-
plores waste found (see Table 2) in the project while Sec-
tion 4.2 determines the overall success of the project.
4.1 Waste Found in the Project
4.1.1 Waste A: Partially done work
• Did anyone have unfinished tasks before a new task
assignment?
• What were the reasons for this simultaneous task as-
signments?
A team member answered: “Actually, there was no ma-
jor partially done work because the Kanban board allowed
onlytwo tasks in eachcolumnper developer. Mostly, people
did a single task from the beginning to the end before they
were assigned to a new task.”
Partially done work was mostly present in an individual
sense, when members started tasks but then they had to re-
assign the tasks to more skillful persons who finished the
tasks. Another member commented: “We had to reassign
some tasks to more skillful persons because of inexperience
and lack of routines in some junior members.”
However, only one major problem in this waste category
was found when another member stated: “One task was
estimated to be ready within half an hour. However, it took
over two days, which blocked a couple of other tasks until
the delayed task was accomplished.”
Sometimes, members had to implement two tasks at the
sametime. Amemberexplainedthereasonforthis: “Some-
times, when a person was assigned to a task, it turned out
that it cannot be done because it needs some other task that
has not been done yet.”
Partially done work showed several indicators of waste
withintheprojectoperation. Itemergedfromdifferenttypes
of inadequacies at different levels in the system. This form
of waste also generated redundant task switching efforts.
4.1.2 Waste B: Extra processes
• What unnecessary processes were there in the project
in your opinion?
• What kinds of processes were eliminated during the
project?
One member described some unnecessary processes:
“We discussed inour retrospectives thatallcodereview and
quality assurance actions would not have been needed for
small tasks [these two actions were accepted as columns in
theKanbanboardsothese actionshadtobedone]. Another
inefficient process we agreed was retrospectives at the be-
ginningoftheproject: theytookalmostalldayforthewhole
team to process and analyze what was bad, what was good,
what had been done and what will be done.”
By asking about extra processes, the questions revealed
such processes but also the team’s capability to adapt to
changes by optimizing their processes.

Page 4

To be appeared: Ikonen, M. & Kettunen, P. & Nilay, O. & Abrahamsson, P. in Proc. of SEAA Euromicro 2010 (IEEE).4
4.1.3Waste C: Extra features
• Did you design or implement any extra features that
the customer did not ask for?
• If any, what were the reasons for that? How relevant
were they in the customer’s opinion?
A member stated: “Some extra features were produced
without consulting the customer. This was a result from the
customer representatives’ unawareness of what they really
needed. So we thought these extra features are important.
There were a few big extra elements and some smaller ones.
When we then demonstrated these features, the customer
praisedourinsight.” andthenspecified these extrafeatures:
“They were not ‘extra hyping’ but intuitive increments for
usability of the interface, for example.”
Another member commented: “Without comments from
the customer, we usually implemented only such extra fea-
tures we were quite sure that the customer wants. These
implementations related mostly to certain basic features.”
Someextrafeatureswereimplementedintheprojectpar-
ticularly to increase usability. While extra features increase
the possibility of defects and malfunctioning and take time,
they actually benefitted the customer of this project.
4.1.4Waste D: Task switching
• If there were any overlappingtask assignments for one
person, how difficult was it to reorient different tasks
simultaneously?
• How much did people have to suspend their own tasks
in order to help others? How badly did this disturb
their own work? E.g. did the quality decrease?
A memberanswered: “Primarily, peoplecarriedoutone
task at a time. If two tasks needed each other in order to be
completed,then a person might carry out two tasks simulta-
neously. Another exception was the code review [a column
in the Kanban board, which required someone else to re-
view this code]: if no one was currently available to make
the code review, then the person might be assigned to a new
task... If a task required contribution from more than one
person, we attempted to break it into smaller parts.”
Another viewpoint regarding the task switching was re-
vealed in a member’s answer: “When I help someone, it
usually takes time to orientate to the task already started.
When I do tasks assigned to me and then someone asks for
help, it does not take so long to re-orientate to my tasks
again, except when I have just started a new task.”
As the project demonstrated, task switching can be used
as an option for waiting. On the other hand, task switching
was time-consuming and created some waste.
4.1.5 Waste E: Waiting
• What things or people did you have to wait for
(e.g. customer-related or technical support)?
• What were the issues you had to wait for most of all
and how long did it take?
One memberhad noted the followingon waiting: “Some
tasks ended up in the code review column [of the Kanban
board] for waiting for a free reviewer for a long time. The
implementers, however, spentthis waitingtime efficientlyby
carrying out other tasks or by helping other people... When
we needed IT support for temporal hardware or software
problems, the waiting time was no more than one day.”
Another member stated: “Sometimes I needed more in-
formation from that senior member who had designed task
tickets. If he was occupied, I had to wait since I didn’t
want to put effort into implementingsomethingin the wrong
way... Another thing we had to wait for was delayed cus-
tomer demos. Fortunately, these delays happened seldom
and were about 15 minutes only. The only big deal was the
headsets which were ordered at the beginning but they ar-
rived at the end of the project. For this reason, we could not
watch important screen casts because the audio would have
disturbed other people’s work.”
Another member commented that: “Because the tasks
were partitioned into small pieces, excluding a couple of
exceptions, people mainly did not have to wait for the ac-
complishment of other tasks.”
Waiting is an inseparable part of projects. While some
waiting can be tolerated, damages for a project caused by
waiting must be eliminated to have more efficient progress.
4.1.6 Waste F: Motion
• How much did people have to move around physically
inside or outside the workspace and how much did it
disturb your progress or concentration?
• What problems occurred with sharing information?
Because of the ideal work space for the project, we did
not find any relevant motion waste in physical terms. A
membercommented: “My only visit was the IT supportunit
[located on the same floor]. Some members moved around
much more than at lunch breaks but these related to getting
some extra snacks, for example, not to the process. This
moving around didn’t disturb me.”
An environment with well-designed hardware, appro-
priate software tools, and services makes motion greatly
unnecessary since there is no need to visit outside the
workspace in order to get things done. Problems with shar-
ing information,however,caused duplicate work as another
member admitted: “It happened (once) that two members
were carrying out the same task by accident.”

Page 5

To be appeared: Ikonen, M. & Kettunen, P. & Nilay, O. & Abrahamsson, P. in Proc. of SEAA Euromicro 2010 (IEEE).5
4.1.7 Waste G: Defects
• How fast did you detect bugs or malfunctioning?
• How fast did you react to these detections?
The attempt was made to optimize detection time in or-
der to minimize the causes of the defects: “Bugs were fixed
immediately after noticing them... We used much TDD and
BDD in order to find malfunctioning. Despite this, testing
during the last week revealed some serious issues.” In other
words, defects noticed at last-minute encumbered the team.
Waste element
A. partially
done work
Sources discovered in the case project
• delays in the critical path
• to implement a task required another,
yet unimplemented task
• someKanban-basedroutinesunneces-
sary for tiny tasks
• inefficient retrospective meetings
• unawareness of the key requirements
• two tasks need each other in the im-
plementation phase
• disruptions: helping other people or
contributing other tasks
• avoidance of waiting: utilizing the
waiting time by doing other tasks
• for customer representatives
• for IT support
• for hardwareshipments for the project
• a person occupied when someone
needs assistance
• lack of communication
• defects found at last-minute
B.
cesses
extrapro-
C. extra features
D. task switch-
ing
E. waiting
F. motion
G. defects
Table 2. Waste and its sources found.
4.2Degree of Project Success
RegardingShenhar’s first dimension(project efficiency),
the project was a success: the limits were not exceeded.
The delivery date was fixed and the required functionality
changedsomewhat duringthe project. Likewise, the project
completed each of the six goals of the second dimension
(impact on the customer). In contrast with the customers’
expectation,the project exceeded them. Regardingthe third
dimension (business success), the project met its set tar-
get which was to generate interest in the corporate funding
schemes. In the terms of the fourth dimension (preparing
for the future), the project documented its work and find-
ings for the futureSoftware Factory teams’ use. The project
outcome is successfully continuing to be developed beyond
the alpha-release phase.
5 Discussion
5.1 Findings
Two principal findings can be presented. First, all poten-
tial sources of waste proposed in the research model were
found in practice at varying levels as summarized in Ta-
ble 2. Second, finding waste, however, did not significantly
contribute to explaining the success of the project.
Thelevelofsuccess wasevaluatedsystematicallysinceit
is necessary to relate this to the sources of waste. Hypothet-
ically, it can be arguedthat the more waste a team produces,
the less chances for success it has. The good success of the
project is a probable reason explaining why only a small
amount of waste was found. Whether this was the direct
result of the application of Kanban, experience of the team
leader and developers or customer pressure remains harder
to pinpoint. Yet, it is argued that waste represents elements
that restrain the progress of projects, which endangers their
chances for success [5].
The study demonstrates that zero waste is not a require-
ment for a successful project. When observing the waste
and its sources in Table 2, it can be concluded that they are
quite minimal. As an example, a team member expressed
his distress with having to wait for a customer demonstra-
tion. Yet, the extra waiting time was only 15 minutes in
this particular case or cases. However, on another occasion,
the team had to wait for the headsets for the whole project,
which prevented them from using web casts for learning or
otherpurposes. This is a significantlymoreseriousissue. In
a large organization, the waiting time may amount to days
or even, in some cases, weeks.
Thus, when using the seven possible elements of waste
as thelenses foran analysis,it is likelythatmostofthemare
apparent in any software developmentproject. What makes
a difference is the attempt to minimize their impact or exis-
tence. This is where Kanban is likely to be useful. Even if
Kanban strives for minimizing the non-value-adding work,
waste may very well still creep in as the case study shows.
Thereby, by applying Kanban as a means to organize the
development, attention must particularly be paid to the fol-
lowing sources of waste: delays in the critical path (waste
element A in Table 2), optimizing Kanban board function-
ing for both tiny and large tasks (B), elimination of ineffi-
cient methods (B), more informativecustomer co-operation
in order to diminish unawareness of the customer’s needs
(C), and clarification of sharing information (F). The team
can affectthese fivesources of waste easier than e.g.limited
project resources, such as one person cannot assist many
people simultaneously.
Moreover, the results show a dependency between task
switching (D) and waiting (E): Members had to wait when
they were unable to proceed with their tasks. In order to