1. From Waterfall to Kanban, the raise of agility.
University College of Dublin - Ireland
February 14, 2014
Abstract
Nowadays, many organizations, are continuously investing looking for
the software development process that can best suit their needs. Existing
software models like Waterfall, have been shown to be obsolete and non-
optimal in most cases[1].
In one key study of failure factors in 1027 IT projects in the UK, scope
management related to Waterfall practices was cited to be the largest
problems in 82% of the projects. Only approximately 13% of the projects
surveyed didn't fail [2]; Although many projects, big and small, have
been developed using this methodology, late delivery, customer and re-
quirements dissatisfaction, have been experienced too often.
Barry Boehm summarized the limits and the failure of the waterfall
model back in the late 1995 [3]. He suggested the use of a risk-reducing,
iterative and incremental approach and the use of three milestone anchor
points around which to plan and control project. In his opinion Plan-
driven methods work best when developers can determine the require-
ments in advance and when the requirements remain relatively stable,
with change rates on the order of one percent per month[4].
To mitigate these deciencies, new development processes have been
presented to the software community trough a series of scientic papers
at the dawn of the new millennium. These new methodologies have been
given the name Agile and Scrum and Kanban are two of them. One of
the most important dierences between Scrum and Waterfall approaches is
that, Waterfall features distinct phases with checkpoints and deliverables
at each phase, while Scrum method have iterations rather than phases.
The output of each iteration is working code that can be used to evaluate
and respond to changing and evolving user requirements. Scrum is simple
but Kanban is even simpler. The concept of iteration is optional and
usually not used. Visualizing your work-ow and limiting demand to
capacity is enough to call it Kanban.
In this paper, we try to highlight the deciencies of the old develop-
ment life cycle developed in early 70' and understand if they have been
overcome with the adoption of Agile methodologies. Also, we propose a
qualitative and quantitative analysis of the improvements obtained pro-
gressing from Scrum to Kanban on a real case basis.
1

2. 1 Introduction
A software development process, also known as a software development life-cycle
(SDLC), is a structure imposed on the development of a software product. It
is often considered a subset of systems development life cycle. Several models
exist to streamline the development process. Each one has its pros and cons,
and it is up to the development team to adopt the most appropriate one for
a specic project. Sometimes a combination of the models may be even more
suitable.
Every software development methodology approach acts as a basis for ap-
plying specic frameworks to develop and maintain software. Several software
development approaches have been used since the origin of information technol-
ogy and we can classify them in two big macro-categories:
1. Software development life cycle methodology
2. Agile methodology
The picture 1 shows a very high overview of the dierences between the two
models:
Figure 1: SDLC vs Agile methodologies
In SDLC the activities involved in the production of software are usually
sequential and well distinct. However there can be some overlap between them.
On the other hand, with Agile methodologies, the activities are often performed
in the same time span. Analysis, Design, Code and Test can be performed by
dierent people but at same time.
There are many models under these two macro-categories:
1. Software development life cycle:
• Waterfall: a linear framework
• Spiral: a combined linear-iterative framework
• Incremental: a combined linear-iterative framework or V Model
2

3. • Prototyping: an iterative framework
• Rapid application development (RAD): an iterative framework
2. Agile methodology:
• Scrum
• Extreme programming
• Adaptive software development (ASD)
• Dynamic system development method (DSDM)
• Kanban
The goal of this paper is not to provide an historical description of all software
methodologies. The goal instead is to provide support and scientic evidences
for helping organizations to choose the development life cycle that best adapts
to the nature of their projects. We will also provide statistic performance data
regarding the adoption of Kanban in an organization that was previously using
Scrum.
2 The fall of the Waterfall model
The Waterfall model is a sequential development approach, in which develop-
ment is seen as owing steadily (like a waterfall) though the phases of require-
ments analysis, implementation, testing (validation), integration and mainte-
nance. The rst formal description of the method is often cited as an article by
Winston W. Royce [5] in 1970. However Royce did not use the term Waterfall
in his article. His view of this model has been widely misinterpreted: he recom-
mended that the model should be applied after a signicant prototyping phase
that was used to rst better understand the core technologies to be applied as
well as the actual requirements that customer needed!
The picture 2 gives an high level view of the phases involved in this model.
The basic principle are:
• Project is divided into sequential phases, with some overlap acceptable
between phases as we've shown in the previous section.
• Emphasis is on planning, time schedules, target dates, budgets and imple-
mentation of an entire system at one time.
• Thigh control is maintained over the life of the project via extensive writ-
ten documentation, formal reviews, and approval/sign-o by the uses and
information technology management occurring at the end of most phases
before beginning the next phase.
Some of the major failure factors that aected this model have been reported
by Andrew Taylor that concludes his study [2] saying:
3

4. Figure 2: The Waterfall model[6]
The approach of full requirements denition, followed by a long
gap before those requirements are delivered is no longer appropriate.
The High ranking of changing business requirements suggests
that any assumption that there will be little signicant change to re-
quirements once they have been documented is fundamentally awed,
and the spending signicant time and eort in ghting to maintain
the maximum level is inappropriate.
Dean Lengwell, in his book Scaling software Agility[7] highlights four key
assumption of the Waterfall model that turned to be incorrect:
1. There always exists a reasonably well-dened set of requirements if we
only take the time to understand them.
2. During the development process, changes to requirements will be small
enough that we can manage them without substantially rethinking or re-
vising our plans.
3. System integration is an appropriate and necessary process, and we can
reasonably predict how it will go based upon architecture and planning.
4. Software innovation and research and development that is required to
create a signicant new software application can be done on a predictable
schedule.
These assumptions can drive to the following failure factors:
• The integration of dierent components of the software is not completed
in time.
• Nothing to delivery to the customer, not even an early version of the
software has been initially produced.
4

5. • Reworking and re-factoring can be extremely complex and heavily involve
documentation as well.
• Time to market is too long to that the design adopted at planning stage
could now be obsolete because innovative tools and technologies have
emerged.
• Failure in delivery the application as intended to the customer in the time
frame predicted.
In Taylor survey [2] managers were also asked at which stage failure could occur.
Figure 3 shows the results:
Figure 3: Failure stages
Failure at the requirements denition stage led the way by some distance,
with implementation and acceptance testing also scoring highly. The rst stage
deals with the statement of expectations and the next two cover the delivery of
those expectations: often the rst time the clients see the results.
Causes of failure once a project started were highlighted in a separate ques-
tion, which again had requirements at the top. The top seven issues are shown
in Figure 4.
The general impression given here is that even if the delivery functions of
the project operated correctly any lack of commitment and support from the
client could potentially cause failure. This indicates that project managers
need to actively manage the client to ensure support and commitment, as well
as ensuring that communication is not only within the project but also out to
all potential participants and stakeholders.
The high ranking of changing business requirements suggests that any as-
sumption that there will be little signicant change to requirements once they
have been documented is fundamentally awed, and that spending signicant
time and eort dening them to the maximum level is inappropriate.
The evidences and the observation provided demonstrate that the Waterfall
model has been shown to be an obsolete model when applied to small and even
large software project.
5

6. Figure 4: Causes of failure
3 The raise of agility
Advocates of Agile software development argue the waterfall model is a bad idea
in practicebelieving it impossible for any non-trivial project to nish a phase
of a software product's life-cycle perfectly before moving to the next phases and
learning from them.
The picture 5 shows a recent survey regarding the success of software project
adopting Waterfall vs Agile methodologies.
Figure 5: Waterfall vs Agile rate of success
Agile software development (also called agile) isn`t a set of tools or a single
methodology, but a philosophy put to paper in 2001 with an initial 17 signato-
ries. Agile was a signicant departure from the heavyweight document-driven
software development methodologiessuch as waterfallin general use at the
time. While the publication of the Manifesto for Agile Software Development
didn't start the move to agile methods, which had been going on for some time,
it did signal industry acceptance of agile philosophy. Figure 6 presents the agile
manifesto:
Agility's been around long enough now that a signicant amount of proof
is emerging. Craig Larman, in his book Agile and Iterative Development [1]
6

7. Figure 6: Agile manifesto [8]
summarizes a vast array of writings pertaining to both iterative and incremen-
tal (II) development, two of agility's most crucial tenets, noting the positive
II experiences of software thought leaders. More importantly, he discusses
extensive studies that examine the success factors of software development. For
example, he quotes a 2003 study conducted by Allen MacCormack[9], which
looked at a collection of project teams of a median size of nine developers and
14 months' duration. Seventy-ve percent of the project teams took an itera-
tive and incremental approach, and 25 percent used the waterfall method. The
study found that releasing an iteration's result earlier in the life-cycle seems to
contribute to a lower defect rate and higher productivity, and also revealed a
weak relationship between the completeness of a detailed design specication
and a lower defect rate. Larman also cites a 2003 Australian study of agile
methods, in which 88 percent of organizations found improved productivity, 84
percent experienced improved quality, 46 percent had no change to the cost of
development, and 49 percent lowered costs.
Agile is being successful because it tries to avoid all the wrong assumptions
that the Waterfall model was making:
• In Agile we don't assume that anybody can fully understand and describe
all the requirements in early stage. Requirements can continuously change
and we have to be ready to address these changes.
• One thousand words of documentation can be less descriptive and more
time consuming than a prototype.
• Delivery very small increment very often, instead of big software artifact
late in time, allows the customers and potential users of the system to
provide fast feed-back and eventually change requests.
• System integration is not always easy to perform. Integrate very large
7

8. system with a big bang approach is not desirable. On the other hand, is
better to integrate from the beginning and continuously.
• We assume that we can deliver the most important features to our cus-
tomer earlier, using feature prioritization, rather than later than the cus-
tomer might have expected.
• Business people and developers must work together daily throughout the
project.
• One of the key statements of the Agile Manifesto is Working software
over Comprehensive documentation. This statement diminishes the value
given to the documentation by the Waterfall model.
• Testing can be performed during the development process. There is no
need to hand-over a piece of software to another team to be tested. Testers
can be part of developer team.
Agile development is not a methodology in itself. It is an umbrella term that
describes several agile methodologies. At the signing of Agile Manifesto in 2001,
these methodologies included Scrum, XP, Crystal, FDD, and DSDM. Since then,
lean practices have also emerged as a valuable agile methodology and so are
included under the agile development umbrella in the illustration 7:
Figure 7: The agile umbrella [10]
Organizations are continuing to scale agile beyond single teams and single
project. The 7th annual state of agile development survey [11] shows that there
has been a 15% jump in the number of respondents who work where there are
at least 5 agile teams, and a 9% increase in those working with up to 5 agile
projects. In addition, those who plan to implement agile development in future
projects has increased from 59% last year to 83% this year. Ninety percent
8

9. of the adopter said that implementing agile improved their ability to manage
changing priorities. The number of respondents who have practiced agile for 5
or more years grew from 18% in 2011 to 25% in 2012. There was a tremendous
growth in the 2-5 years of experienced group, which increased from 37% to 64%.
In 2012 there has been a growth in the number of teams practicing agile at each
organization surveyed. Nearly half of respondents worked at companies that had
adopted agile practices across 5 or more teams (48%), up from 33%. in 2011,
and 30% said they had 10 or more agile teams. The majority of respondents
had up to 5 agile projects (59%), compared to 50% in 2011. About one-third
said their organizations have 10 or more projects. Most of the respondents said
none of their projects would be considered unsuccessful (18%). Of those with
failed agile projects, most said it was due to either a company philosophy or
culture at odds with core agile values (12%), external pressure to follow waterfall
processes (11%), or a broader organization or communication problem (11%).
The top three reason respondent cited for adopting agile were to accelerate time
to market, more easily manage changing priorities, and no better align IT and
business objectives. 70% per cent of respondent felt that agile projects have
a faster time to completion. Experienced agile users said the top 3 benets of
agile were the ability to manage changing priorities, productivity, and project
visibility.
Overall, the project visibility category saw the great increase in benet,
from 77% in 2011 to 84% in 2012.
4 Scrum
Most of the agile practitioners are using Scrum or Scrum variants (72%). Figure
8 shows the state of Agile.
Figure 8: Agile methodology usage [11]
The rst paper describing SCRUM was released in 1995 on OOPSLA con-
ference in 1995 by Ken Schwaber [12]. In this article SCRUM is described as
9

10. an enhancement of the iterative and incremental approach to delivering object-
oriented software; SCRUM approach assumes that the analysis, design, and
development processes in the Sprint phase are unpredictable. A control mech-
anism is used to manage the unpredictability and control the risk. Flexibility,
responsiveness, and reliability are the results.
Ken will rene is denition of SCRUM in the scrum guide [13]:
Scrum is a framework for developing and sustaining complex prod-
ucts and in which people can address complex adaptive problems,
while productively and creatively delivering products of the highest
possible value. Scrum is:
• Lightweight
• Simple to understand
• Dicult to master
Scrum employs an iterative, incremental approach to optimize predictability
and control risk and prescribes four formal events for inspection and adaption:
• Sprint planning
• Daily Scrum
• Sprint review
• Sprint retrospective
The Scrum team consists of a Product Owner, the Development Team, and
a Scrum Master. Scrum team are self-organizing and cross-functional. They
choose how best to accomplish their work and they have all competencies needed
to accomplish the work without depending on others not part of the team.
Teams deliver products iteratively and incrementally, maximizing opportunities
for feedback. Incremental deliveries of Done product ensure a potentially
useful version of working product is always available.
The heart of Scrum is a Sprint, a time-box of one month or less during which
a Done, useable, and potentially releasable product increment is created. A
new Sprint starts immediately after the conclusion of the previous Sprint.
Sprints contain and consist of the sprint planning, daily Scrums, the devel-
opment work, the Sprint Review, and the Sprint retrospective:
1. The work to be performed in the Sprint is planned at Sprint Planning.
This plan is created by the collaborative work of the entire Scrum Team. In
the Sprint planning the team will plan what will be delivered in the coming
Sprint and how the work needed to deliver the increment be achieved.
2. The daily Scrum is a 15-minute time boxed event for the Development
Team to synchronize activities and create a plan for the next 24 hours.
During the meeting the Development Team members explain:
10

11. • What did I do yesterday that helped the Development Team meet the
Sprint Goal?
• What will I do today to help the development Team meet the Sprint Goal?
• Do I see any impediment that prevents me or the Development Team from
meeting the Spring Goal ?
• The daily Scrum usually takes place at the Scrum board. You can see an
example board in the gure: 9
Figure 9: Scrum Board
3. The Sprint review is held at the end of the Sprint to inspect the increment
and adapt the Product Backlog if needed. During the Sprint Review, the
Scrum Team and stockholders collaborate about what was done in the
Sprint. Based on that and any changes to the product backlog, during
the Sprint, attendees collaborate on the next things that could be done to
optimize value.
4. The sprint retrospective is an opportunity for the Scrum Team to inspect
itself and create a plan for improvements to be enacted during the next
Sprint. The purpose of the Sprint retrospective is to:
• Inspect how the last Sprint went with regards to people, relationships,
process and tools;
• Identify and order the major item that went well and potential improve-
ments;
• Create a plan for implementing improvements to the way the Scrum Team
does its work.
We have been using Scrum for almost two years before the adoption of Kanban.
11

12. 5 Kanban
Kanban and Kanban variants methodologies usage nearly double last year,
mostly due to an up-stick in Scrum-ban use [11].
The name Kanban originates from Japaneses, and translates roughly as card
signal. Kanban is a lean approach to agile software development. It underpins
Toyota's just-in_time (JIT) production system. Although producing software
is a creative activity and therefore dierent to mass-producing cars, the under-
lying mechanism for managing the production line can still be applied.
Kanban takes an organization's current development process and provides
greater visibility into the status of the work and how is proceeding. This means
that potentially you can combine Kanban with your current development pro-
cess, in order to see where the bottlenecks are.
Anderson identied ve core properties that had been observed in each suc-
cessful implementation of the Kanban method [14]:
1. Visualize the work-ow: The most common way to visualize the work-
ow is to use card walls with cards and columns. Each column on the
wall represent steps in your work-ow. An electronic board can be used
in place of the wall, especially if the teams are distributed.
2. Limit WIP: work-in-progress at each state in the work-ow is limited. New
work is pulled into the next step when there is available capacity within
the local WIP. This constraints will quickly illuminate problem areas in
your ow so you can identify and resolve them.
3. Manage ow: The ow of work items through each state in the work-ow
should be monitored and reported. A fast smooth ow means our system
is both creating value quickly, which is minimizing risk and avoid cost of
delay, and is also doing so in a predictable fashion.
4. Make process policies explicit: The process needs to be dened, published
and socialized explicitly. Without an explicit understanding of how things
work and how work is actually done, any discussion of problems tends to
be emotional and subjective.
5. Use models to evaluate improvement opportunities: Gathering data on
system performance like ow time, WIP, delivery throughput, will provide
scientic insight into opportunities for improvements.
These properties are visualized in the Kanban board shown in gure 10.
The principles of the Kanban method are designed to help organizations
improve with minimal resistance. It can take an agile (or Waterfall) method
that has stalled and bring it back to life, creating a custom solution based on
the unique needs of the organization. It is designed to reveal issues and create
the opportunity to address problems so that we can achieve smooth, predictable
delivery of nished work.
David Anderson synthesize some of the benets that can be deliver by the
Kanban method [16]:
12

13. Figure 10: Kanban Board [15]
1. Optimize existing processes : Introducing of visualization and the WIP
limit will catalyze change with minimal disruption;
2. Deliver with higher quality : Limiting work in progress and dening poli-
cies for work prioritization will bring greater focus on quality.
3. Improve Lead Time Predictability : There is a correlation between the
amount of work-in-progress, lead time and defect rates. Limiting WIP
makes lead times dependable and keeps defect rates low.
4. Improve Employee Satisfaction : Kanban reduces context switching and
pulls work at the rate the team can complete it.
5. Provide slack to Enable Improvement : Create slack in the value chain
improves responsiveness to urgent request.
6. Simplify prioritization : Kanban enables fast re-prioritization to accom-
modate changes in the market.
7. Provide a transparency on the system design and operation : Improved
visibility builds trust with customers and managers.
8. Enables emergence of high maturity organization : As improvements are
implemented, organizational maturity improves leading to better decision
making and improved risk management. Risk, managed appropriately,
bring predictable results.
6 An agile case comparison
As we said many times, Kanban does not replace the current development pro-
cess; It is overlaid on top of it. We can think of Kanban as a big magnifying
glass that will reveal the kinks in the current process. People who turn to Kan-
ban are usually people who are less than satised with their current process. In
13

14. this section I want to provide real data regarding the adoption of Kanban in my
organization.
We found that Scrum alone was non-optimal for us; It was too rigid and
created too much useless overhead. Some of the limits we experienced with
Scrum are:
• Sprint planning: estimation is a process too rigid and nobody can esti-
mate with absolute precision. Even the best estimation can reveal totally
wrong. Sprint planning forced engineers focused on one component to
sit through a discussion of unrelated components - for half day. Time is
spent debating about the exact size of a feature. Once sprint planning is
done, making changes to the sprint triggers more planning meetings. If a
bug is discovered and it takes the highest priority, engineers have to work
very long hours to add the bug x in the Sprint release. If a feature is
DE-prioritized, more meetings will have to take place to try to redesign
the sprint structure.
• Iterations: At the end of the Sprint, when the iteration is about to nish,
engineers try to commit all the jobs that were agreed to be nished in the
Sprint planning. Sometimes, code review is skipped and code coverage
falls down when the only goal is to avoid business anger. Following is
a productivity crash an increasing number of bugs that will break the
condence with the business anyway; This situation is better represented
in the gure 11.
Figure 11: Scrum Sprint hours worked [17]
• Static prioritization: Change the priority of the items during the Spring is
extremely dicult. Once the items to be delivered have been agreed at the
start of the Sprint, everybody is pushing for delivery them even if higher
priority items require to be worked especially if we are going toward the
end of the sprint.
• There is no WIP : So the work in progress is virtually unlimited, creating
the need of continuous and expensive context switch.
14

15. Thus we decided to adopt Kanban in early 2013. For analyzing the eective-
ness of this choice I extrapolated some meaningful metrics from our informatics
system.
Take in consideration that metrics are expensive and time-consuming if you
don't have automatic tool that can gather data. Also in order for a metric to
be eective, it has to be comparable;
Scrum Story points for example, is a completely not comparable metric
across dierent team. So we tried to report only those metric that are actually
reecting the inuence of the adoption of Kanban in our organization.
• Lead Time is dened as a period of time, measured from the moment
when the request is made until the tasks are completed. This is one of the
most important metric in Kanban. Our Lead time progression is shown
in gure 12
Figure 12: Lead time
The graph shows a dramatic lead time reduction from February, when Kan-
ban was fully applied, to September when the process reached a good maturity
state. The average time to Acceptance went to 29 days to 4 days, showing a
reduction of of 625 %.
The time to done went down from 52 to 19 which implies a reduction of 173
%.
This graph shows how Kanban helped us to understand the bottlenecks in
our process, and correct them. Improving the time to acceptance of 625% means
creating the opportunity for a continuous feedback from the business about the
software that is going in production
• The quality of the software you are building is usually given by the measure
of the number of UAT defects. This is shown in gure 13
15

16. Figure 13: Development eciency
In this case the the improvements are extremely clear. In September 2012,
when Kanban was still 3 months away from us, the number of defect in UAT
was 28. In 2013, when we applied Kanban to our process, the collective number
of defect in UAT was 4.
This graph alone shows how Kanban gave us the opportunity to switch our
focus toward quality. 4 UAT defect in a whole year represent almost perfection
on a quality point of view.
• Another metric extremely meaningful, is the number of release per year.
This metric shows the ability of an organization to push software toward
the nal user. A low number of releases means that the customers will not
receive a new and update version of the software for long time. An high
number of releases means that the organisation is able to continuously
integrate and delivery software. The number of releases is shown in gure
14
Again, this graph shows a dramatic improvement. The number of releases
went from 3 in 2011 to 17 possible releases in 2013, which means a release every
three weeks.
16

17. Figure 14: Number of releases
7 Conclusion
The Waterfall model have been shown to have several bottlenecks; It was cre-
ated to be applied in the manufacturing and construction industries were re-
quirements were easier to dene and less dynamic and it didn't adapt well to
the software world has we have shown in this paper.
Agile methodologies changed the way to think about software. They did
not only aect the software development itself. They totally revolutionized the
idea of producing software starting from the deep involvement of the customer,
aecting individuals and interaction and arriving to dene a lean process for
shipping software in small and incremental piece and receiving fast feedback.
Post-adoptive agile usage studies show the dramatic improvements obtained.
Scrum is the most agile methodologies nowadays. It prescribe four formal events
: Sprint planning, daily Scrum, retrospective and Sprint Review. The Sprint
planning and the xed iterations are the most criticized principles that Scrum
adopts. They were limiting our dynamism. So we decide to adopt Kanban, a
relative new scheduling system for lean and just-in-time production. Kanban
helped us to highlight all the bottlenecks in our process, visualizing the work ow
and limiting the work in progress. Several metrics data have been shown that
Kanban deeply improved our process. Our average day to acceptance reduce
of 625% and out time to done reduce of 173%. The number of defect in UAT
reduced to 4 in 2013 from 28 in 2012. The number of release went up to 17
in 2013 from 3 in 2011 showing the ability of our department to continuously
delivery software to the customer.
17

18. References
[1] Larman. Agile and iterative development: A manager's guide. 2004.
[2] Andrew Taylor. It projects sink or swim. 2001.
[3] Barry Boehm. Anchoring the software process. 1995.
[4] Barry Boehm. Get ready for agile methods, with care. 2002.
[5] Royce. Managing the development of large software system. 1970.
[6] Peter Kemp. The waterfall model. 2010.
[7] Dean Lengwell. Scaling Software Agility: Best Practices for Large Enter-
prises. 2007.
[8] Agile Manifesto. Agile manifesto principles. 2001.
[9] Cusumano Crandall MacCormack, Kemerer. Trade-o between productiv-
ity and quality in selecting software development practices. 2003.
[10] Leadinagile. The agile umbrella. 2007.
[11] VersionOne. 7th-annual-state-of-agile-development-survey. 2012.
[12] Ken Schwaber. Scrum development process. 1994.
[13] Ken Schwaber. The scrum guide. 2013.
[14] Anderson David. Kanban, successful evolutionary change for your technol-
ogy business. 2010.
[15] Henrik Kniberg. Kanban kick-start example. 2009.
[16] David Anderson. Getting started with kanban for software development.
2006.
[17] Alex Salazar. So long so scrum. 2014.
18