The document discusses the evolution and comparison between waterfall and agile software development methodologies, noting the challenges organizations face in adopting agile despite its increasing popularity due to higher success rates. It highlights barriers to agile adoption, particularly organizational culture and resistance to change, while emphasizing the need for holistic planning and leadership support for successful implementation. The author proposes a multi-pronged strategy for agile adoption, focusing on leadership engagement, organizational culture alignment, adequate training, and utilization of appropriate tools.

1. Understanding Alternative Approaches for Systems Building in the Digital Era
Tameez Ansari
Florida Institute of Technology
ABSTRACT
Software development methodologies have been in existence for a long time and as
the business and technology landscape changes, it’s not surprising to see something new
comes around to makes waves. Waterfall software development methodology was first
adopted in the 1980s and it became a standard at the US DoD. While it provided for a
structured approach to software development and delivering the product, it also was faulted
for high project failure rates.
Other methodologies have come along since the waterfall and Agile process has
gained much attention due to how this framework can be used to speed up the development
and delivery cycles. In this process the customer is also directly involved in the making of the
product, unlike in waterfall. Surveys upon surveys indicate how agile is responsible for
increase in project success rate, particularly in small scale projects.
Organizations, however, are still finding it tough implementing agile and this is due to
internal culture and how they are organized. Sometimes, these organizations do not approach
agile adoption in a serious manner and leave it to developers to figure out. Other times, they
do not provide enough resources and support to ensure success. With holistic approach and
proper planning, success adoption of agile can be achieved.

2. Understanding Alternative Approaches for Systems Building in the Digital Era 1
Table of Figures
Figure 1. Implementation steps to develop a large computer program......................................4
Figure 2. Example of Agile/Scrum Methodology......................................................................5
Figure 3. Agile Adoption Strategy by me as CIO....................................................................10
Table of Tables
Table 1. Waterfall and Agile: Similarities and Differences.......................................................6
Table 2. Pros and Cons of Waterfall and Agile Methodologies (adapted) ................................7
Table 3. Success Rates of Projects: Agile vs Waterfall .............................................................8

3. Understanding Alternative Approaches for Systems Building in the Digital Era 2
TABLE OF CONTENTS
INTRODUCTION 3
DAWN OF WATERFALL 3
HIGH RATE OF FAILURE 4
ITERATIVE METHODOLOGY AND AGILE 5
AGILE ATTRACTION 6
AGILE SUCCESSES 7
MY PLAN FOR AGILE ADOPTION 10

4. Understanding Alternative Approaches for Systems Building in the Digital Era 3
Introduction
There have been several software development methodologies over the past decades,
each one designed to produce the desired results. One of the first such methodology was
called waterfall and it is still being used in modified form. As the business landscape has
changed in the immediate last few years and in response to increased competition,
organizations have turned to other forms of methodologies to satisfy their requirements.
Agile processes have gained much attention and methodologies based on this
framework are making inroads. While agile is gaining momentum, waterfall is by no means
dead. Agile is facing its own adoption pains and organizations do not fully understand how
approach adoption. This paper takes a look at the history and development of waterfall and
agile methodologies. It also points out the barriers to agile adoption and suggest how
adoption could be accomplished holistically.
Dawn of Waterfall
The “Waterfall” software development methodology was first described by a director
at the Lockheed Software Technology Center Dr. Winston W. Royce in 1970. In a paper
published by Dr. Royce, entitled “Managing the Development of Large Software Systems:
Concepts and Techniques,” he described his personal views on managing large software
development. He described computer development functions as: “There are two essential
steps common to all computer program developments, regardless of size or complexity.
There is first an analysis step, followed second by a coding step.” He goes on to say that
many additional steps are required, otherwise an implementation plan to develop larger
software system with only these two steps is doomed to failure. In the paper he further
describes the steps and processes for software development.1
The steps are depicted in Figure 1.

5. Understanding Alternative Approaches for Systems Building in the Digital Era 4
Figure 1. Implementation steps to develop a large computer program
Dr. Royce believed in this concept but he believed the implementation described
above was “risky and invites failure.”2 As can be seen in the figure above, progress “rolls
down” from one step to another. The basic idea is that work is done in sequential manner.
This is why the model has come to be known as waterfall, even though Dr. Royce never
named it as such.
The United States Department of Defense (DoD) adopted the waterfall software
development methodology as its standard in 1985 and named it DOD-STD-2167. The North
Atlantic Treaty Organization (NATO) later followed and adopted it as well.3
High Rate of Failure
While the waterfall methodology was an improvement over the code and fix method
being practiced before it, change was needed because the projects had a high rate of failure.
In one key study of 1,027 IT projects in the United Kingdom in 2001, it was reported
that “scope management related to attempting waterfall practices was the single largest
contributing factor for failure.”4 The study suggested that the approach followed by the
waterfall methodology as regards requirements definition, followed by gap until the
requirements were delivered were no longer appropriate.
Other evidence of failure in applying the waterfall came from the DoD. In the 1980s
and 1990s, most DoD projects followed the waterfall methodology.
A 1999 review of failure rates in a sample of earlier DoD projects drew grave
conclusions:5
System
Requirements
Software
Requirements
Analysis
Program
Design
Coding
Testing
Operations

6. Understanding Alternative Approaches for Systems Building in the Digital Era 5
“Of a total $37 billion for the sample set, 75% of the projects failed or were
never used, and only 2% were used without extensive modification.”
Something had to be done and a task force at DoD was convened. The report by the
task force recommended replacing the waterfall methodology with iterative and incremental
development:
DOD STD 2167 likewise needs a radical overhaul to reflect modern best
practice. Evolutionary development is best technically, it saves time and
money.6
Waterfall was not doing what it was supposed to do and even the DoD realized
something had to be done and recommended adopting evolutionary development and in 1994
replaced the earlier standard with the MIL-STD-498 which supports iterative development.7
Types of Development Methodologies
The iterative development is a type of development methodology based on a cyclical
process of prototyping, testing, analyzing and refining a product, whereas Waterfall is an
example of an incremental approach to software development. In this method product is
designed, implemented and tested incrementally. The delivered product is considered
complete only when all the requirements in the steps are satisfied. There are several other
methodologies, such as Rapid Application Development (RAD), evolutionary and spiral.
Each one has some advantage over the other.
Iterative Methodology and Agile
An example of an iterative development is agile and it is gaining tremendous attention
over the past few years. More and more organizations are adopting it and even the US
Federal Bureau of Investigations (FBI) has gone agile. The FBI CIO turned the agency's case
Figure 2. Example of Agile/Scrum Methodology

7. Understanding Alternative Approaches for Systems Building in the Digital Era 6
management implementation into an agile project.8 In a report entitled: “Effective Practices
and Federal Challenges in Applying Agile Methods” and published in July 2012, the US
General Accountability Office (GOA) in a report identified 32 practices and approaches as
effective at applying agile methods to IT projects.9
Why has agile gained such attention? Let’s review what agile is and how it compares
to waterfall. Agile itself is not a methodology; it’s a process and a common methodology is
called scrum and there are several others within the agile framework. In this development
framework, instead of extensive planning and design up front, one can change requirements
over time using cross-functional teams which work on successive iterations of the product.
The work is organized into a backlog and is prioritized based on business value. The
emphasis is on face-to-face (or conference call) and short feedback loops. Each iteration
produces a working product that can be demonstrated to the stakeholders. Feedback is
incorporated into the next iteration and it goes on and on.
Agile Attraction
The attractive feature of agile is that it allows the customers to be part of the
development process. Waterfall does not have this capability. In waterfall, the initial input
from the customer in terms of the requirements is pretty much all that is provided. Once the
requirements are completed, the development team goes off and starts coding and developing
the deliverables.
In agile there is constant interaction between the various parties and there are quick
deliverables. In this regard, it is thought that the product matches the requirements and
adjustments are quick to make, unlike in waterfall where there is much gap and time between
the original requirements and the final product.
Much has been written about the software development methodologies, their features
and pros and cons of each over the other. It is the same in the case of agile and waterfall. It is
easy to find supporters and detractors since developers become used to routines and
organization have heavily invested in a particular development process. Overtime, however,
advantages of adopting efficient techniques and processes get attention from the practitioners
and industry. That is exactly what has happened as regards agile and developers have
seemingly found agile to solve their problems.
Waterfall and agile both share many similarities and there are differences as well and
the following table illustrates these at the highest level.10
Table 1. Waterfall and Agile: Similarities and Differences
Similarities Differences
Traditional (waterfall) and agile
share the same goal
Waterfall is backward-looking while
agile is forward-looking
The old and the new worlds share
many of the same principals
There are terminology differences
between the waterfall world and the agile
world
The traditional and agile worlds use
the same building blocks

8. Understanding Alternative Approaches for Systems Building in the Digital Era 7
Since the goals, principals and building blocks are similar between waterfall and
agile, what sets them apart and what makes one preferred over the other? There are pros and
cons of each and let us dig a little deeper to highlight these.11
Table 2. Pros and Cons of Waterfall and Agile Methodologies (adapted)
Pros Cons
Waterfall Opportunity to find and address
potential issues before any code is
written.
The customer does not often know
what he needs up front and is not
involved along the way.
There is usually better
documentation (upfront) since
requirements and other design
documents are very much
required.
Designers are not often able to
forecast the problems arising out
of implementation.
The linear nature of waterfall is
easier to understand by many
more people and teams feel more
comfortable.
Change management is difficult
and changes to requirements
cannot easily be incorporated into
the design along the way.
The linearity of the method does
not lend itself to building
momentums.
Agile Developed software is developed
iteratively and delivered quickly
and there is consistent pace.
Agile methodologies are often
more difficult to understand than
linear, sequential ones and require
coaching.
There is closer collaboration
between developers and the
business.
Some key artifacts, such as
documentation, can be neglected
because of the nature of delivery
and iterations.
Changes to requirements can be
incorporated at any point of the
process – even late in
development.
In large organizations, a poorly
implemented agile can introduce
extra inefficiencies that can work
against existing processes.
There is opportunity for
continuous improvement for live
system.
It is highly transparent
We can see there are reasons for using either waterfall or agile, or both.
Agile Successes
The adoption of agile over waterfall is increasing all the time and it is gaining
popularity. A CHAOS report release in 2015 by Standish Group revealed interesting findings
regarding waterfall and agile. These CHAOS reports have been published each year since
1994 and they provide a look into the software development industry. The 2015 report
studied 50,000 projects around the world, ranging from tiny enhancements to massive
systems re-engineering implementations. The report showed that success rate for projects was
higher when agile was used as compared with waterfall. See Table 3 below.12

9. Understanding Alternative Approaches for Systems Building in the Digital Era 8
Table 3. Success Rates of Projects: Agile vs Waterfall
Method Successful Challenged Failed
Agile 39% 52% 9%
Waterfall 11% 60% 29%
In the 10th Annual State of Agile Report by VersionOne.com, the top reason given by
enterprises for adopting agile for the past three year is that it accelerates product delivery
(62%) and it enhances their ability to manage changing priorities (56%). For the past five
years, the top three benefits of agile include: manage changing priorities (87%), team
productivity (85%), and project visibility (84%).13
Impediments to Agile
The same VersionOne.com report also highlights the barriers facing agile in the
workplace. The barriers are the typical cultural, organizational issues that we all face all the
time. Namely the key barriers identified revolve around culture, including the ability to
change, general resistance to change, and management support.14
When Craig Larman and Bas Vodde were writing the "Organization" chapter in
Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-scale
Scrum, they asked a group of agile development experts working in and with large companies
about the most challenging impediments their organizations faced. They aggregated their
responses into a list of what they called the top ten organizational impediments.15
10. Failure to Remove Organizational Impediments
Common reasons for not removing impediments are "That's the way we've always
done business" and "We won't change because we invested so much in this."
9. Misguided Cost Savings and Synergy Efforts
Centralized departments can make decisions that adversely affect the groups working
on solutions.
8. Lack of Training
This is self-explanatory. A number of organizations do not spend enough on training
and consider learning a waste of time.
7. Single-Function Groups
Functional organizations are one of the largest impediments to becoming agile.
6. Local vs Global Optimization
Systems that foster local optimization over global is a major barrier to success.
5. Assumption that Book Learning is Enough

10. Understanding Alternative Approaches for Systems Building in the Digital Era 9
Related to training, many organizations think that you can learn from reading books
alone and they do not bring outside expertise to help them see beyond their own horizon.
4. Individual Performance Evaluation and Reward
The archaic practices of rewarding individuals hinder team performance.
3. Unrealistic Promises
Agile is not a cure-all and unrealistic promises to organizations can be an obstacle.
2. Assuming Agile Is All About Developers
Organizations do not understand that successful move to agile requires a shift in
thinking at multiple levels of an organization.
1. Silver bullet thinking and superficial adoption
Organizations think that agile will provide productivity and with lack of educated
executives, it leads to some sort of silver bullet, meaning that agile can solve all the
problems. In fact, this thinking does not solve any problems and does not lead to change.
Large organizations are difficult to change and find more challenges adopting
technologies due to inertia and the direction they have taken. Smaller organizations are more
easily maneuvered. It is similar to the difference between an oil tanker and a cruiser boat. The
oil tanker takes a mile to dock while the cruiser is much quicker and maneuver much more
quickly. Just because agile may be perceived as providing many benefits, it does not mean
that it will work without making the hard choices in the organization.
All is not Lost on Agile
Evidence is mounting that agile has delivered the goods. Its adoption has resulted in
benefits to the organizations and teams. The changing landscape in terms of mobility and
time-to-market pressures means agile will continue to find takers. There is also evidence that
agile does better for smaller projects as compared to larger projects. The success rate for
small size projects is much higher (58%) than for large size projects (18%).16
This highlights an interesting fact that large size projects do not necessarily benefit
from agile processes. It could be because all the team members do not have the same
understanding and appreciation for how a project in agile should be run. It is always difficult
to manage a large project, whether agile is used or not. Other reasons could be related to
people and organizational culture instead of agile.
There are steps that an organization’s management can take to ensure that agile and
its benefits are realized. As a CIO I would tackle the agile adoption in a multi-pronged
strategy.

11. Understanding Alternative Approaches for Systems Building in the Digital Era 10
Figure 3. Agile Adoption Strategy by me as CIO
My Plan for Agile Adoption
My plan would include the following:
Top Leadership and Expectation
At the leader of the corporate IT business unit, it is my responsibility to ensure the
strategy the IT unit adopts is part of the overall corporate strategy and this includes ensuring
the leadership sees benefits of technologies and the directions IT takes. I would want to get
the maximum support from the leadership to ensure there is success at all levels.
Organizational Culture
I would take the necessary steps to ensure the direct reports are onboard 100 percent
and support me and people in their own organizations to ensure we realize the maximum
benefits of agile where it was possible. We also need to identify where agile is not going to
work and continue working in that fashion. Furthermore, I will go on a tour and engage the
business leadership to seek support from them for agile and changes. I would also initiate an
incentive program to institutionalize the forthcoming changes.
I also need to review the governance, specifically IT governance, to ensure we are
going to have proper project governance as regards projects in agile.
Business Benefits
I would need to show the agile adoption in terms of business benefits. I need to be
fully prepared with statistics and rely on outside experts, whom I will bring in, to further
make the case more solid.
Agile
Adoption
Top
Leadership
Organizational
Culture
Training
Business
Benefits
Toolsand
Technology

12. Understanding Alternative Approaches for Systems Building in the Digital Era 11
Tools and Technologies
While it is possible to run agile process in Microsoft Excel, it is not the best option.
There are a number of tools specifically well-suited for agile and bringing teams together,
whether they are in IT, business or offshore somewhere.
Training
One of the areas where management does not focus as much is providing training to
people who go through change. I would create a training program that is suited to our people.
I would also bring in outside experts so that our developers and other can benefit from their
expertise. I would also find support groups and other resources to tap into should they be
needed, either on an ongoing basis or as-needed basis.
I think it is clear you cannot achieve the goals without proper thought, planning and
without taking others onboard. If you are going to change, you want to know why you want
to change and the next questions is: how?
It is clear that agile is more than just development and it changes very many
processes. It also brings in a new culture of doing the development work. There is a new
perspective and there is no reason to believe that waterfall will just disappear.
I believe that with the holistic approach I have described above, I stand a better
chance at agile adoption than without it.
1. Managing the Development of Large Software Systems. (n.d.). Retrieved from
http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf
2. Managing the Development of Large Software Systems.

13. Understanding Alternative Approaches for Systems Building in the Digital Era 12
3. Applitude. (n.d.). Retrieved from http://www.applitude.se/tag/the-waterfall/
4. Leffingwell, D. (2007). Scaling software agility: Best practices for large enterprises. Upper
Saddle River, NJ: Addison-Wesley.
5. Agile Changer. Retrieved from http://www.agilechanger.com/2013/08/history-of-waterfall-
model/
6. (Leffingwell, 2007)
7. (Agile Changer)
8. How the FBI Proves Agile Works for Government Agencies. (2012). Retrieved from
http://www.cio.com/article/2392970/agile-development/how-the-fbi-proves-agile-works-for-
government-agencies.html
9. Rep. No. Gao-12-681 (2012).
10. Palmquist, Steven., Lapham, Mary Ann., Garcia-Miller, Suzanne., Chick, Timothy., &
Ozkaya, Ipek. (2013).Parallel Worlds: Agile and Waterfall Differences and
Similarities (CMU/SEI-2013-TN-021). Retrieved October 09, 2016, from the Software
Engineering Institute, Carnegie Mellon University website:
http://resources.sei.cmu.edu/library/asset-view.cfm?AssetID=62901
11. @. (2015). Agile vs Waterfall - Comparing project management methods. Retrieved from
https://manifesto.co.uk/agile-vs-waterfall-comparing-project-management-methodologies/
12. Standish Group 2015 Chaos Report - Q&A with Jennifer Lynch. (n.d.). Retrieved
October 09, 2016, from https://www.infoq.com/articles/standish-chaos-2015
13. The 10th Annual State of Agile Report. N.p.: VersionOne.com, 2016. Pdf.
14. (The 10th Annual State of Agile Report.)
15. Top Ten Organizational Impediments. (n.d.). Retrieved October 09, 2016, from
https://www.scrumalliance.org/community/articles/2009/april/top-ten-organizational-
impediments
16. (Standish Group 2015 Chaos Report)