Scott Ning
Professor Jones
SE 459
19 March 2013
Change Requests in Software Engineering
The possibility of making changes during the project development lifecycle is very likely.
Clients may change their minds and request modifications to the originally-agreed-upon project
requirements, technologies can change, the importance of the project’s features may alter, or
even external factors may influence change requests. While these are among the many reasons
for changing the original list of requirements, there will most definitely also be a continual cycle
of change requests even after the deployment of a project, during its maintenance phase. Whether
using engineering practices such as Agile, Waterfall, or Spiral, the notion of change is almost
unavoidable in any project and being prepared to handle changes is a very important aspect of a
project’s lifecycle. Therefore, knowing the way these practices handle such changes is extremely
useful, and even more useful when understanding Agile’s approach compared to its counterparts.
Recognizing the similarities and differences between other engineering practices’ and Agile’s
change principles, benefits, more-welcoming change processes, change management, fluidity
and locking of changes, values and beliefs, and influences on business and cost, is essential.
Agile embraces change and accepts the idea that requirements will evolve throughout a
project. Due to this acceptance, Agilists are not limited and locked out of changes, but rather,
they are able to “strive to truly manage change, not to prevent it” (Agile Requirements Change
Management 2). In contrast, the Waterfall approach does not allow room for changes;
requirements are locked and, thus, this brings forth a “painful change management process”
(Waterfall - The Monkey's Paw of Software Development 2). Agile believes in flexibility while
Waterfall believes in structure; Agile expects requirements to change versus Waterfall requires
that requirements are clearly defined initially. Therefore, the values regarding change between
Ning 2
these two practices differ through the fact that “[i]n Agile, you get the product you need and in
Waterfall, you get the product that you initially asked for” (2).
Many Agile values assist its fluidity of changes. One value that Agile practices is the
concept of simplicity and one way that simplicity can be achieved is through the delivery of only
necessary functionality and delivering them in increments, thus keeping complications to a
minimum and keeping models simpler. As conveyed in Bhakti Satalkar’s article, Agile Model,
“[i]f the system is complex, then it will take a lot of time to incorporate these changes” (14). In
an Agile world, because the delivery of a project’s functionality is done at consistently shorter
intervals and developed in smaller batches, as opposed to Waterfall’s longer and bigger delivery
periods, changes can easily be introduced into each set of deliveries. Therefore, this allows more
room for adapting to the changing circumstances.
Another Agile value that assists its fluidity of changes is the belief of always delivering
the highest business value first. According to Jeff Sutherland’s online article, Agile Principles
and Values, customer satisfaction is vital and in order to succeed, change must be planned for.
To accomplish this and “[f]or teams to create products that will please customers and provide
business value, teams must respond to change.” As opposed to the opposite, even “when
traditional projects finish on time, on budget, with all features in the plan, customers are often
unhappy because what they find is not exactly what they wanted.” As a result of following this
value, Sutherland claims, customers are much happier (22-23).
But in order to know the highest business value, teams must communicate efficiently and
seek it out. Sutherland references Humphrew’s law, saying that “customers never know what
they want until they see working software. If customers do not see working software until the
end of a project, it is too late to incorporate their feedback.” This is where another Agile value
Ning 3
supports a more fluid change management; communication, feedback, reviews are imperative for
determining a customer’s satisfaction and the steps that lead to such satisfaction. Sutherland
explains that this “is why they have established processes, such as reviews and retrospectives
that are specifically designed to shift priorities regularly based on customer feedback and
business value.” Because Agile values communication and feedback during a project lifecycle,
Agile will have teams seek customer feedback so that the new information can be incorporated
into the project during development (22-23).
These Agile values enable many benefits for many parties, and more importantly, to the
business stakeholders. Business stakeholders, specifically, are allowed more fluidity to “add new
requirements, change priorities, or rework existing requirements whenever they want” (Agile
Requirements Change Management 13). Because newer and more appropriate requirements or
functionality can be accomplished much easier, and without disagreement, the many business
stakeholders’ requests are much more often fulfilled. Therefore, this extraordinary flexibility, inturn, can also strengthen relationships. Building relationships is important and therefore, Agile’s
approach to change positively influences much business stakeholders and their values (The
Process of Change - The Agile Change Agent 6).
Another benefit to Agile’s more-welcoming change process is that it strives to keep costs
minimal and the cost of change is generally lesser than other alternative engineering practices.
Their strategy for keeping costs at a minimal is due to their strict minimalistic-doing behavior;
Agilists do not waste time, effort, and costs on implementing any unnecessary functionality.
Agilists understand that “requirements evolve over time” and “any early investment in detailed
documentation will only be wasted” (Agile Requirements Change Management 1). Because of
this, Agilists simply do just enough initial requirements and stay within project scope; they
Ning 4
follow the idea of focusing only on necessities and since those are “all you really need early in a
project, so that’s all you should do” (1). Therefore, extra wasteful costs can generally be better
avoided.
In relation to change management, because of their belief of only doing what needs to be
done and not solidly locking requirements, change requests are deemed as a need and can be
more welcomingly adapted into their project and project’s costs. Unlike Agile, Waterfall freezes
requirements, making change requests more costly, difficult, and overall, really unwelcomed.
According to James Christie’s article, Usability and Traditional Development Lifecycles, Christie
explains that many factors within the Waterfall principles discourage change; whether it is soft
costs such as an already-determined state-of-mind or hard costs such as the tedious and time and
effort consuming process of modifying contracts and project plans, changes are difficult to make
during the Waterfall development lifecycle. Christie states that “I don't say it's impossible, but
that it would be difficult to do because of the mind-set that the Waterfall encourages. The way
that contracts are written, and project plans defined, for such projects is a powerful
discouragement to early usability testing and iteration” (5). All these overhead processes that
need to be modified, simply for granting a change, can drastically lower overall productivity.
While an Agilist’s approach to alterations evidently brings forth benefits for managing
costs, it also brings forth uncertainty. One of which is that the cost and time for the project would
be less clear. “It isn’t clear how much the system will cost up front. As the requirements change,
the cost must also change” (Agile Requirements Change Management 15). Business stakeholders
would not be able to present an upfront and solid estimate of the costs for a project. While this
may seem unusual compared to Waterfall’s concrete estimate for costs, it may actually present
many benefits. In an Agile situation, “stakeholders don't need an estimate up front because of the
Ning 5
increased level of control which they have. Would you rather have a detailed, and very likely
wrong, estimate up front or would you rather be in control and spend your money wisely?” (15)
Being able to dynamically determine the amount to spend and the needs or changes that should
be addressed, stakeholders can have projects accomplished in ways that would satisfactory in a
cost-efficient perspective.
The Waterfall approach, on the other hand, invests a good amount of time analyzing and
determining the precise requirements and scope of a project. Waterfall binds a project to a fixed
price, a fixed contract, and approval-based decisions. As noted in an online article, Waterfall
Development, Development cannot be started “until all of the designs have been approved,
because it is very costly to change design after we are in development” (2). This proves to be a
very big disadvantage because, as stated in the article, “[b]y the time we actually got to coding,
the requirements were often already obsolete. But, we had to keep moving forward because of
contract requirements. By the time we actually delivered the system, if it actually got delivered,
it was millions of dollars over budget, years past due, and was no longer what the customer
needed” (8). This suggests that Waterfall strongly disallows change due to the time, effort, and
costs initially invested on the project. In fact, in this scenario, the project not only suffered from
a hard cost of wasting millions of dollars, but the final delivery wasn’t even needed by the
customer any longer. Therefore, very dissimilar to Agile, Waterfall may not always fulfill the
needs, or at least, the eventual needs and satisfaction of business stakeholders.
Of course, making modifications while practicing the Waterfall principle is not
impossible, but it is definitely considered as extremely challenging and inefficient. This is
because “the only way to amend something which has been already developed is to go back and
start again” (The Advantages and Disadvantages of Waterfall Software Development 6). Within
Ning 6
the Waterfall approach, since parts of the project is hard to change and once a stage is completed,
there is no turning back. If a problem exists or a different functionality must be implemented, it
can only be fixed or added by completely backtracking and designing and developing an entirely
new system, which can introduce much overhead, be very costly, and be very time inefficient.
Because of this, Business stakeholders would, of course, dislike the idea of starting a project
from the beginning again, especially when much time, money, and effort was already invested
previously. This is the reason for Waterfall’s strong discouragement of change and its extreme
challenge and expense.
However, the Waterfall approach can sometimes be a better choice than Agile under
certain situations where the environment is stable and there is definitely no room for changes.
This can even, in fact, be beneficial to developers in the sense that the developers would have a
clearer understanding of the goals that need to be accomplished. Since the goals are already set
in stone, they can have a clear focus on what to strive for. And due to the locking of the inability
to make changes, projects may be easier to manage and, unlike Agile, a project will not “easily
lose its way” (Agile vs. Waterfall Methods: Which Should You Choose 9). Therefore, due to the
possible heavy amounts of changes that need to be adapted for, if Agile is not executed properly
and successfully, confusion can increase and productivity will decrease, generating a
disadvantage for Agile.
Another engineering practice that closely follows Agile’s idea of handling changes is the
Spiral methodology. Similar to Agile, the Spiral methodology is more flexible to and can
accommodate change. And dissimilar to Waterfall, Spiral does not have problems handling new
requirements during the development phase; the fluidity of changes is possible and there is no
locking of the ability for requesting and making changes. Due to Spiral’s better acceptance of the
Ning 7
welcoming of changes, a Spiral environment is also able to enjoy the similar benefits that the
stakeholders enjoy within an Agile environment.
According to John Sullivan’s book, Definitive Guide To Enterprise Change Management,
due to this methodology’s nature of having multiple phases and phases that are “short and
eventually followed by additional requirements analysis and design stages, the newly discovered
requirements are readily accommodated” (66). Sullivan explains that these short incremental
stages allow for more flexibility since they are short. And the immediate analysis, design, and
review of when each stage is complete, can provide the team with valuable knowledge and
feedback. Sullivan also states that “[t]his information is especially useful when business
processes change in response to the new system. Business users do not need to anticipate all
possible changes in their work patterns early in the development effort” (66). Therefore, both
Agile and Spiral do not have heavily invested initial requirements, but rather, they both do what
they can in the early development phase and adapt for anything new through the project
lifecycle.
The Spiral methodology also presents a similar slight disadvantage that Agile has,
compared to Waterfall. Similar to Agile being able to “easily lose its way,” Spiral can also easily
have the same side effects if it is not executed properly. As conveyed by Sullivan, the “drawback
of the Spiral methodology is that it does not define a fixed number of cycles, which can lead to
undisciplined requirements gathering.” Such undisciplined actions include “determining that they
can address it in a later cycle. In addition, unnecessary features might be added and eventually
discarded.” Therefore, this causes an unstructured approach to tackling the project. And
“[w]ithout a fixed design… frequent changes to applications cause ripple effects” (66). These
“ripple” effects, as how Sullivan describes, is the same effects that Agilists may experience when
Ning 8
confusion is high and structure is lacking, which, would also eventually lead to a decrease in
productivity. Therefore, in a Spiral environment, if the amount of change requests that happen
increases, then the risk for side effects happening heightens, thus causing less-than optimal
performances from team members.
Understanding the differences between how the Waterfall, Spiral, and Agile engineering
practices view, approach, and handle change will evidently present more of the benefits and
drawbacks of each of these approaches. Both Agile and Spiral practices are more lenient towards
changes, as opposed to how Waterfall strongly discourages them. Whether hard costs such as
wasting time, effort, and money, or soft costs such as the decrease of overall productivity, are
involved, all three of these practices have obvious reasons for being or not being incorporated
into a project. Situations where a team envisions that a project would necessitate for many
changes may lead the team into deciding against using the Waterfall method and possibly lean
them more towards an Agile approach; because the request for even a simple change can bring
about more hard and soft costs under Waterfall, Waterfall may not be the best decision when
changes are expected within a project development lifecycle.
However, if the changes are less evident, the advantages are more prominent, and certain
values can be justified, Waterfall can be a possible approach as well. As long as the team is
aware of the similarities and differences, benefits and drawbacks, and values and influences of
how each of these practices manages changes, they would have a solid foundation of deciding
which engineering approach to choose. Therefore, each of these engineering practices are valid
and depending on the circumstances, having a balanced perspective, and recognizing that change
requests may or may not occur during the project development lifecycle, teams can make better
decisions on which practice to follow.
Ning 9
Works Cited
Satalkar, Bhakti. "Agile Model." Buzzle. Buzzle, 20 Feb. 2013. Web. 17 Mar. 2013.
<http://www.buzzle.com/articles/agile-model.html>.
Sutherland, Jeff. "Agile Principles and Values." Agile Principles and Values, by Jeff Sutherland.
Microsoft, n.d. Web. 17 Mar. 2013. <http://msdn.microsoft.com/en-us/library/dd997578.aspx>.
"Agile Requirements Change Management." Agile Requirements Change Management. N.p.,
n.d. Web. 16 Mar. 2013. <http://www.agilemodeling.com/essays/changeManagement.htm>.
Nayab, N. "Agile vs. Waterfall Methods: Which Should You Choose?" Brighthub Project
Management. Bright Hub PM, 12 July 2012. Web. 17 Mar. 2013.
<http://www.brighthubpm.com/agile/50473-agile-vs-waterfall-is-there-a-real-winner/>.
"The Advantages and Disadvantages of Waterfall Software Development." , Waterfall
Development, Waterfall Methodology from Www.My-Project-Management-Expert.com. N.p.,
n.d. Web. 16 Mar. 2013. <http://www.my-project-management-expert.com/the-advantages-anddisadvantages-of-waterfall-software-development.html>.
Sullivan, John. The Definitive Guide To Enterprise Change Management. N.p.:
Realtimepublishers, 2004. Print.
Peter. "The Process of Change - The Agile Change Agent." The Process of Change. N.p., 19
Dec. 2011. Web. 16 Mar. 2013. <http://agilescout.com/the-process-of-change-the-agile-changeagent-part-14/>.
Christie, James. "Usability and Traditional Development Lifecycles (Waterfall & V Model) Software Testing Club - An Online Software Testing Community." Usability and Traditional
Development Lifecycles (Waterfall & V Model) - Software Testing Club - An Online Software
Testing Community. N.p., 12 Nov. 2008. Web. 16 Mar. 2013.
<http://www.softwaretestingclub.com/forum/topics/usability-and-traditional>.
Toddcharron. "Waterfall - The Monkey's Paw of Software Development." Web log post.
Planning for Failure. N.p., n.d. Web. 16 Mar. 2013.
<http://www.planningforfailure.com/post/259532859/waterfall-the-monkeys-paw-of-softwaredevelopment>.
Blake. "Waterfall Development." InQbation. N.p., n.d. Web. 16 Mar. 2013.
<http://www.inqbation.com/washington-dc-website-design-development/agilemethodology/waterfall-development/>.