Agile Software Development
The Motivation for Agile Development
Christopher Jones Fall, 2020-2021
School of Computing, DePaul University
Motivation
Software development is risky and many things can go wrong:
• Time or budget overruns.
• Defective or inflexible to change.
• Key requirements are not addressed.
• New requirements cannot be addressed.
1/44
Dr. Barry Boehm
Software Engineering Economics [1]
“The further a project progressed, the more accurate the estimates for the remaining effort and time became.”
2/44
Risk stems from one root cause: uncertainty. How can we narrow the cone of uncertainty?
3/44
The waterfall model is a time-honored way of trying to understand and mitigate risk.
4/44
The classic Waterfall Model was proposed by Winston Royce. [2]
He knew it wasn’t perfect even then, which lead to the additional feedback loops between phases.
5/44
6/44
7/44
The spiral model was proposed by Barry Boehm in 1988. [3]
It is a form of development called “incremental and iterative.”
8/44
Iteration
Repeated cycles during which a system is changed incrementally.
Increment
Small additions or changes to a system’s capabilities.
We don’t always deploy on each iteration. We must deliver sufficient business value for a deployment to be worthwhile. This is one aspect of continuous delivery, which we discuss in detail in SE441.
9/44
Software Economics
Different methodologies are attuned to different models of software development economics. The goal is to make software development more valuable based on these factors:
• Cash flows
• Interest rates
• Project mortality
Using these factors we can devise a strategy for maximizing the economic value of a project.
10/44
Project value can be increased by:
• Spending less
• Earning more
• Spending later
• Earning sooner
• Increasing project life expectancy
Maximize the net present value (NPV) of each project.
11/44
Money today is worth more than money tomorrow. The present value is the value of future money in terms of today’s money.
Present Value
The value of an investment’s future earnings in today’s money. [4]
12/44
Inputs
Ct Net cash inflow during t. r Discount rate.
T Number of time periods.
Calculation
PV =
∑T Ct
t=1
(1 + r)t
13/44
Suppose a new software feature is expected to drive an additional $10,000 of revenue each year for the next three years. How much should we be prepared to invest in the development of that feature assuming a 5% annual rate of return and that we can complete the feature this year?
Calculation
Inputs
Ct $10,000 r 5% T3
∑3 $10, 000 PV= (1+0.05)t
t=1
= $9,524 + $9,070 + $8,638
= $27, 232
14/44
The present value tells us how much our future expenditures will cost in today’s dollars. It doesn’t tell us how much those expenditures are actually worth. The net present value (NPV) does.
Inputs
C0 Initial investment.
Ct Net cash inflow during t. r Discount rate.
T Number of time periods.
Net Present Value
Calculation
∑T Ct
NPV = (1+r)t −C0
t=1
= PV−C0
The present value of an investment’s earnings less the investment itself. Positive NPV is good, negative is bad.
15/44
Suppose we invest $25,000 in developing the feature from the prior example. What is our NPV?
Calculation
NPV =
Inputs
C0 $25,000 Ct $10,000 r 5% T3
∑3 t=1
$10, 000
(1 + 0.05)t − $25, 000
= $27, 232 − $25, 000
= $2, 232
16/44
Suppose we have $10,000 to invest in the development of one of two proposed features with the following income schedules:
Feature 1 – Cash Inflows
C1 $5,000
C2 $5,000
C3 $5,000
Feature 2 – Cash Inflows
C1 $8,000 C2 $5,000 C3 $2,000
If we assume an annual discount rate of 5%, which feature should we invest in and why? What is it about that feature that makes it a better investment?
17/44
Year
Income
Option 1
Option 2
Year 1
$4,800
$7,600
Year 2
$4,600
$4,600
Year 3
$4,400
$1,700
PV
$13,800
$13,900
The difference comes down to the front-loading the of higher development cost.
18/44
Suppose we wish to develop a feature that will return $15,000 per year for the next 4 years. Suppose that there are two ways to implement this feature:
Option 1 – Custom Development
Option 2 – 3rd-Party License
C0 $20,000 C0 $10,000 C1..4 $2,500 C1..4 $5,000
This example is more complicated because the expenditures must be converted to today’s dollars and summed to derive the total cost of investment.
If we assume discount rate of 5%, which approach should we take to implement the feature and why? Suppose we extend the analysis to 5 years?
19/44
Option 1 – Custom Development
NPV =
= = =
∑4 t=1
$15, 000 (∑4 $2, 500 ) (1+0.05)t − (1+0.05)t +$20,000
Option 2 – 3rd-Party License
NPV =
$5, 000 ) (1+0.05)t +$10,000
t=1
$53, 200 − ($8, 900 + $20, 000)
$53, 200 − $28, 900 $24, 300
∑4 t=1
$15, 000 (∑4
(1+0.05)t −
= $53, 200 − ($17, 700 + $10, 000)
= $53, 200 − $27, 700
= $25, 500
t=1
20/44
Income
Costs
Option 1
Option 2
Year 0
—
$20,000
$10,000
Year 1
$14,300
$2,400
$4,800
Year 2
$13,600
$2,300
$4,600
Year 3
$13,000
$2,200
$4,400
Year 4
$12,300
$2,100
$4,200
PV
$53,200
$9,000
$18,000
Cost
—
$29,000
$28,000
NPV
—
$24,200
$25,200
The difference is the front-loading of the higher development cost. Suppose we extend the horizon out to 5 years.
21/44
Income
Costs
Option 1
Option 2
Year 0
—
$20,000
$10,000
Year 1
$14,300
$2,400
$4,800
Year 2
$13,600
$2,300
$4,600
Year 3
$13,000
$2,200
$4,400
Year 4
$12,300
$2,100
$4,200
Year 5
$11,600
$2,000
$4,000
PV
$64,800
$11,000
$22,000
Cost
—
$31,000
$32,000
NPV
—
$33,800
$32,800
Now the difference comes down to the ongoing maintenance costs.
Why does this matter? Because agile encourages making the best decision at the time it’s needed given the information that’s known – not information that is assumed or guessed at.
22/44
There are several alternatives to maximizing value:
Abandon: Refocus:
Defer: Grow:
Value can still be derived from a canceled project.
Allow new requirements to be introduced, even late in the project.
Wait until the cone of uncertainty has narrowed. Scale up to take advantage of a growing market.
All of these approaches require a certain management maturity.
23/44
Traditionally the “iron triangle” was based on cost, time, and quality and scope was held immutable.
More money or time isn’t always better (e.g. too many contractors too soon) but too little is fatal. The trick is to throw enough resources at a problem at the right time.
24/44
Traditional software development has been characterized by an exponential cost curve, called “Boehm’s Curve”, where the cost of a change rises exponentially the later in the development lifecycle that the change is implemented.
25/44
Agile development attempts to change the curve so that it is no longer exponential.
26/44
Principles
Manifesto for Agile Software Development [5]
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
• Individuals and interactions over processes and tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation
• Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
27/44
Our highest priority is to sat- isfy the customer through early and continuous delivery of valuable software.
28/44
Welcome changing require- ments, even late in develop- ment. Agile processes har- ness change for the cus- tomer’s competitive advan- tage.
29/44
Deliver working software fre- quently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
30/44
Business people and devel- opers must work together daily throughout the project.
31/44
Build projects around moti- vated individuals. Give them the environment and support they need, and trust them to get the job done.
32/44
The most efficient and effec- tive method of conveying in- formation to and within a de- velopment team is face-to- face conversation.
33/44
Working software is the pri- mary measure of progress.
34/44
Agile processes promote sus- tainable development. The sponsors, developers, and users should be able to main- tain a constant pace indefi- nitely.
35/44
Continuous attention to tech- nical excellence and good design enhances agility.
36/44
Simplicity–the art of maxi- mizing the amount of work not done–is essential.
37/44
The best architectures, re- quirements, and designs emerge from self-organizing teams.
38/44
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior ac- cordingly.
39/44
40/44
“Early delivery of business value.”
Dr. Alistair Cockburn [6]
41/44
Scott Ambler [7]
“Agile is an iterative and incremental (evolutionary) approach to software development which is performed in a highly collaborative manner with ‘just enough’ ceremony that produces high quality software which meets the changing needs of its stakeholders.”
42/44
Agile approaches are best treated as frameworks rather than methodologies. They allow teams to modify their activities to best serve their needs.
43/44
References i
[1] [2]
[3] [4]
[5]
[6] [7]
Barry Boehm.
Software Engineering Economics. Prentice Hall, 1st edition, November 1981.
Walker W. Royce.
Managing the development of large software systems: concepts and techniques.
Proc. IEEE WESTCON, Los Angeles, pages 1–9, August 1970.
Reprinted in Proceedings of the Ninth International Conference on Software Engineering, March 1987, pp. 328–338.
Barry W. Boehm.
A spiral model of software development and enhancement.
Computer, 21(5):61–72, 1988. Net present value – npv.
http://www.investopedia.com/terms/n/npv.asp.
Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, and Others.
Manifesto for agile software development.
http://agilemanifesto.org/.
Alistair Cockburn.
Agile Software Development. Addison-Wesley Professional, 2001.
Scott Ambler.
http://www.agilemodeling.com/essays/agileSoftwareDevelopment.htm, 2005.
44/44