From Waterfall to Kanban, the raise of agility.

University College of Dublin - Ireland

February 14, 2014

Abstract

Nowadays, many organizations, are continuously investing looking forthe software development process that can best suit their needs. Existingsoftware 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, scopemanagement related to Waterfall practices was cited to be the largestproblems in 82% of the projects. Only approximately 13% of the projectssurveyed didn't fail [2]; Although many projects, big and small, havebeen 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 waterfallmodel back in the late 1995 [3]. He suggested the use of a risk-reducing,iterative and incremental approach and the use of three milestone anchorpoints 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 de�ciencies, new development processes have beenpresented to the software community trough a series of scienti�c papersat the dawn of the new millennium. These new methodologies have beengiven the name �Agile� and Scrum and Kanban are two of them. One ofthe most important di�erences between Scrum andWaterfall approaches isthat, Waterfall features distinct phases with checkpoints and deliverablesat each phase, while Scrum method have iterations rather than phases.The output of each iteration is working code that can be used to evaluateand respond to changing and evolving user requirements. Scrum is simplebut Kanban is even simpler. The concept of iteration is optional andusually not used. Visualizing your work-�ow and limiting demand tocapacity is enough to call it Kanban.

In this paper, we try to highlight the de�ciencies of the old develop-ment life cycle developed in early 70' and understand if they have beenovercome with the adoption of Agile methodologies. Also, we propose aqualitative and quantitative analysis of the improvements obtained pro-gressing from Scrum to Kanban on a real case basis.

1

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. Itis often considered a subset of systems development life cycle. Several modelsexist 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 fora speci�c project. Sometimes a combination of the models may be even moresuitable.

Every software development methodology approach acts as a basis for ap-plying speci�c frameworks to develop and maintain software. Several softwaredevelopment 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 di�erences between the twomodels:

Figure 1: SDLC vs Agile methodologies

In SDLC the activities involved in the production of software are usuallysequential and well distinct. However there can be some overlap between them.On the other hand, with Agile methodologies, the activities are often performedin the same time span. Analysis, Design, Code and Test can be performed bydi�erent 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

• 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 softwaremethodologies. The goal instead is to provide support and scienti�c evidencesfor helping organizations to choose the development life cycle that best adaptsto the nature of their projects. We will also provide statistic performance dataregarding the adoption of Kanban in an organization that was previously usingScrum.

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 byWinston 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 signi�cant prototyping phasethat was used to �rst better understand the core technologies to be applied aswell 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 acceptablebetween 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 andinformation technology management occurring at the end of most phasesbefore beginning the next phase.

Some of the major failure factors that a�ected this model have been reportedby Andrew Taylor that concludes his study [2] saying:

3

Figure 2: The Waterfall model[6]

The approach of full requirements de�nition, followed by a longgap before those requirements are delivered is no longer appropriate.

The High ranking of changing business requirements suggeststhat any assumption that there will be little signi�cant change to re-quirements once they have been documented is fundamentally �awed,and the spending signi�cant time and e�ort in �ghting to maintainthe maximum level is inappropriate.

Dean Le�ngwell, in his book �Scaling software Agility�[7] highlights four keyassumption of the Waterfall model that turned to be incorrect:

1. There always exists a reasonably well-de�ned set of requirements if weonly take the time to understand them.

2. During the development process, changes to requirements will be smallenough that we can manage them without substantially rethinking or re-vising our plans.

3. System integration is an appropriate and necessary process, and we canreasonably predict how it will go based upon architecture and planning.

4. Software innovation and research and development that is required tocreate a signi�cant new software application can be done on a predictableschedule.

These assumptions can drive to the following failure factors:

• The integration of di�erent components of the software is not completedin time.

• Nothing to delivery to the customer, not even an early version of thesoftware has been initially produced.

4

• Reworking and re-factoring can be extremely complex and heavily involvedocumentation as well.

• Time to market is too long to that the design adopted at planning stagecould now be obsolete because innovative tools and technologies haveemerged.

• Failure in delivery the application as intended to the customer in the timeframe 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 de�nition stage led the way by some distance,with implementation and acceptance testing also scoring highly. The �rst stagedeals with the statement of expectations and the next two cover the delivery ofthose 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 shownin Figure 4.

The general impression given here is that even if the delivery functions ofthe project operated correctly any lack of commitment and support from theclient could potentially cause failure. This indicates that project managersneed to actively manage the client to ensure support and commitment, as wellas ensuring that communication is not only within the project but also out toall potential participants and stakeholders.

The high ranking of changing business requirements suggests that any as-sumption that there will be little signi�cant change to requirements once theyhave been documented is fundamentally �awed, and that spending signi�canttime and e�ort de�ning them to the maximum level is inappropriate.

The evidences and the observation provided demonstrate that the Waterfallmodel has been shown to be an obsolete model when applied to small and evenlarge software project.

5

Figure 4: Causes of failure

3 The raise of agility

Advocates of Agile software development argue the waterfall model is a bad ideain practice�believing it impossible for any non-trivial project to �nish a phaseof a software product's life-cycle perfectly before moving to the next phases andlearning from them.

The picture 5 shows a recent survey regarding the success of software projectadopting 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 singlemethodology, but a philosophy put to paper in 2001 with an initial 17 signato-ries. Agile was a signi�cant departure from the heavyweight document-drivensoftware development methodologies�such as waterfall�in general use at thetime. 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 agilemanifesto:

Agility's been around long enough now that a signi�cant amount of proofis emerging. Craig Larman, in his book Agile and Iterative Development [1]

6

Figure 6: Agile manifesto [8]

summarizes a vast array of writings pertaining to both iterative and incremen-tal (I&I) development, two of agility's most crucial tenets, noting the positiveI&I experiences of software thought leaders. More importantly, he discussesextensive studies that examine the success factors of software development. Forexample, he quotes a 2003 study conducted by Allen MacCormack[9], whichlooked at a collection of project teams of a median size of nine developers and14 months' duration. Seventy-�ve percent of the project teams took an itera-tive and incremental approach, and 25 percent used the waterfall method. Thestudy found that releasing an iteration's result earlier in the life-cycle seems tocontribute to a lower defect rate and higher productivity, and also revealed aweak relationship between the completeness of a detailed design speci�cationand a lower defect rate. Larman also cites a 2003 Australian study of agilemethods, in which 88 percent of organizations found improved productivity, 84percent experienced improved quality, 46 percent had no change to the cost ofdevelopment, and 49 percent lowered costs.

Agile is being successful because it tries to avoid all the wrong assumptionsthat the Waterfall model was making:

• In Agile we don't assume that anybody can fully understand and describeall the requirements in early stage. Requirements can continuously changeand we have to be ready to address these changes.

• One thousand words of documentation can be less descriptive and moretime consuming than a prototype.

• Delivery very small increment very often, instead of big software artifactlate in time, allows the customers and potential users of the system toprovide fast feed-back and eventually change requests.

• System integration is not always easy to perform. Integrate very large

7

system with a big bang approach is not desirable. On the other hand, isbetter 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 theproject.

• One of the key statements of the Agile Manifesto is �Working softwareover Comprehensive documentation.� This statement diminishes the valuegiven to the documentation by the Waterfall model.

• Testing can be performed during the development process. There is noneed to hand-over a piece of software to another team to be tested. Testerscan be part of developer team.

Agile development is not a methodology in itself. It is an umbrella term thatdescribes 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 areincluded 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 singleproject. The 7th annual state of agile development survey [11] shows that therehas been a 15% jump in the number of respondents who work where there areat least 5 agile teams, and a 9% increase in those working with up to 5 agileprojects. In addition, those who plan to implement agile development in futureprojects has increased from 59% last year to 83% this year. Ninety percent

8

of the adopter said that implementing agile improved their ability to managechanging priorities. The number of respondents who have practiced agile for 5or more years grew from 18% in 2011 to 25% in 2012. There was a tremendousgrowth 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 eachorganization surveyed. Nearly half of respondents worked at companies that hadadopted 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 respondentshad up to 5 agile projects (59%), compared to 50% in 2011. About one-thirdsaid their organizations have 10 or more projects. Most of the respondents saidnone of their projects would be considered unsuccessful (18%). Of those withfailed agile projects, most said it was due to either a company philosophy orculture at odds with core agile values (12%), external pressure to follow waterfallprocesses (11%), or a broader organization or communication problem (11%).The top three reason respondent cited for adopting agile were to accelerate timeto market, more easily manage changing priorities, and no better align IT andbusiness objectives. 70% per cent of respondent felt that agile projects havea faster time to completion. Experienced agile users said the top 3 bene�ts ofagile were the ability to manage changing priorities, productivity, and projectvisibility.

Overall, the �project visibility� category saw the great increase in bene�t,from 77% in 2011 to 84% in 2012.

4 Scrum

Most of the agile practitioners are using Scrum or Scrum variants (72%). Figure8 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

an enhancement of the iterative and incremental approach to delivering object-oriented software; SCRUM approach assumes that the analysis, design, anddevelopment 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 re�ne is de�nition 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 highestpossible value. Scrum is:

• Lightweight

• Simple to understand

• Di�cult to master

Scrum employs an iterative, incremental approach to optimize predictabilityand 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, anda Scrum Master. Scrum team are self-organizing and cross-functional. Theychoose how best to accomplish their work and they have all competencies neededto accomplish the work without depending on others not part of the team.Teams deliver products iteratively and incrementally, maximizing opportunitiesfor feedback. Incremental deliveries of �Done� product ensure a potentiallyuseful version of working product is always available.

The heart of Scrum is a Sprint, a time-box of one month or less during whicha �Done�, useable, and potentially releasable product increment is created. Anew 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. Inthe Sprint planning the team will plan what will be delivered in the comingSprint and how the work needed to deliver the increment be achieved.

2. The daily Scrum is a 15-minute time boxed event for the DevelopmentTeam to synchronize activities and create a plan for the next 24 hours.During the meeting the Development Team members explain:

10

• What did I do yesterday that helped the Development Team meet theSprint 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 frommeeting the Spring Goal ?

• The daily Scrum usually takes place at the Scrum board. You can see anexample board in the �gure: 9

Figure 9: Scrum Board

3. The Sprint review is held at the end of the Sprint to inspect the incrementand adapt the Product Backlog if needed. During the Sprint Review, theScrum Team and stockholders collaborate about what was done in theSprint. Based on that and any changes to the product backlog, duringthe Sprint, attendees collaborate on the next things that could be done tooptimize value.

4. The sprint retrospective is an opportunity for the Scrum Team to inspectitself and create a plan for improvements to be enacted during the nextSprint. 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 Teamdoes its work.

We have been using Scrum for almost two years before the adoption of Kanban.

11

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 �cardsignal�. Kanban is a lean approach to agile software development. It underpinsToyota's �just-in_time� (JIT) production system. Although producing softwareis a creative activity and therefore di�erent 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 providesgreater visibility into the status of the work and how is proceeding. This meansthat potentially you can combine Kanban with your current development pro-cess, in order to see where the bottlenecks are.

Anderson identi�ed �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 thewall represent steps in your work-�ow. An electronic board can be usedin 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. Newwork is pulled into the next step when there is available capacity withinthe local WIP. This constraints will quickly illuminate problem areas inyour �ow so you can identify and resolve them.

3. Manage �ow: The �ow of work items through each state in the work-�owshould be monitored and reported. A fast smooth �ow means our systemis both creating value quickly, which is minimizing risk and avoid cost ofdelay, and is also doing so in a predictable fashion.

4. Make process policies explicit: The process needs to be de�ned, publishedand socialized explicitly. Without an explicit understanding of how thingswork and how work is actually done, any discussion of problems tends tobe emotional and subjective.

5. Use models to evaluate improvement opportunities: Gathering data onsystem performance like �ow time, WIP, delivery throughput, will providescienti�c 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) methodthat has stalled and bring it back to life, creating a custom solution based onthe unique needs of the organization. It is designed to reveal issues and createthe opportunity to address problems so that we can achieve smooth, predictabledelivery of �nished work.

David Anderson synthesize some of the bene�ts that can be deliver by theKanban method [16]:

12

Figure 10: Kanban Board [15]

1. Optimize existing processes : Introducing of visualization and the WIPlimit will catalyze change with minimal disruption;

2. Deliver with higher quality : Limiting work in progress and de�ning poli-cies for work prioritization will bring greater focus on quality.

3. Improve Lead Time Predictability : There is a correlation between theamount of work-in-progress, lead time and defect rates. Limiting WIPmakes lead times dependable and keeps defect rates low.

4. Improve Employee Satisfaction : Kanban reduces context switching andpulls work at the rate the team can complete it.

5. Provide slack to Enable Improvement : Create slack in the value chainimproves 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 : Improvedvisibility builds trust with customers and managers.

8. Enables emergence of �high maturity� organization : As improvements areimplemented, organizational maturity improves leading to better decisionmaking 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 magnifyingglass that will reveal the kinks in the current process. People who turn to Kan-ban are usually people who are less than satis�ed with their current process. In

13

this section I want to provide real data regarding the adoption of Kanban in myorganization.

We found that Scrum alone was non-optimal for us; It was too rigid andcreated too much useless overhead. Some of the limits we experienced withScrum are:

• Sprint planning: estimation is a process too rigid and nobody can esti-mate with absolute precision. Even the best estimation can reveal totallywrong. Sprint planning forced engineers focused on one component tosit through a discussion of unrelated components - for half day. Time isspent debating about the exact size of a feature. Once sprint planning isdone, making changes to the sprint triggers more planning meetings. If abug is discovered and it takes the highest priority, engineers have to workvery long hours to add the bug �x in the Sprint release. If a feature isDE-prioritized, more meetings will have to take place to try to redesignthe 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 theSprint planning. Sometimes, code review is skipped and code coveragefalls down when the only goal is to avoid business anger. Following isa productivity crash an increasing number of bugs that will break thecon�dence with the business anyway; This situation is better representedin the �gure 11.

Figure 11: Scrum Sprint hours worked [17]

• Static prioritization: Change the priority of the items during the Spring isextremely di�cult. Once the items to be delivered have been agreed at thestart of the Sprint, everybody is pushing for delivery them even if higherpriority items require to be worked especially if we are going toward theend of the sprint.

• There is no WIP : So the work in progress is virtually unlimited, creatingthe need of continuous and expensive context switch.

14

Thus we decided to adopt Kanban in early 2013. For analyzing the e�ective-ness of this choice I extrapolated some meaningful metrics from our informaticssystem.

Take in consideration that metrics are expensive and time-consuming if youdon't have automatic tool that can gather data. Also in order for a metric tobe e�ective, it has to be comparable;

Scrum �Story points� for example, is a completely not comparable metricacross di�erent team. So we tried to report only those metric that are actuallyre�ecting the in�uence of the adoption of Kanban in our organization.

• Lead Time is de�ned as a period of time, measured from the momentwhen the request is made until the tasks are completed. This is one of themost important metric in Kanban. Our Lead time progression is shownin �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 maturitystate. The average time to Acceptance went to 29 days to 4 days, showing areduction 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 inour process, and correct them. Improving the time to acceptance of 625% meanscreating the opportunity for a continuous feedback from the business about thesoftware that is going in production

• The quality of the software you are building is usually given by the measureof the number of UAT defects. This is shown in �gure 13

15

Figure 13: Development e�ciency

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 UATwas 28. In 2013, when we applied Kanban to our process, the collective numberof defect in UAT was 4.

This graph alone shows how Kanban gave us the opportunity to switch ourfocus toward quality. 4 UAT defect in a whole year represent almost perfectionon 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 towardthe �nal user. A low number of releases means that the customers will notreceive a new and update version of the software for long time. An highnumber of releases means that the organisation is able to continuouslyintegrate and delivery software. The number of releases is shown in �gure14

Again, this graph shows a dramatic improvement. The number of releaseswent from 3 in 2011 to 17 possible releases in 2013, which means a release everythree weeks.

16

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 de�ne and less dynamic and it didn't adapt well tothe software world has we have shown in this paper.

Agile methodologies changed the way to think about software. They didnot only a�ect the software development itself. They totally revolutionized theidea of producing software starting from the deep involvement of the customer,a�ecting individuals and interaction and arriving to de�ne a lean process forshipping 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 Sprintplanning and the �xed iterations are the most criticized principles that Scrumadopts. They were limiting our dynamism. So we decide to adopt Kanban, arelative new scheduling system for lean and just-in-time production. Kanbanhelped us to highlight all the bottlenecks in our process, visualizing the work �owand limiting the work in progress. Several metrics data have been shown thatKanban deeply improved our process. Our average day to acceptance reduceof 625% and out time to done reduce of 173%. The number of defect in UATreduced to 4 in 2013 from 28 in 2012. The number of release went up to 17in 2013 from 3 in 2011 showing the ability of our department to continuouslydelivery software to the customer.

17

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 Le�ngwell. 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