Modeling Agile Development: When is it Effective?
Karim Chichakly
isee systems, inc.
31 Old Etna Road, Suite 9N
Lebanon, NH 03766
(603) 448-4990/FAX: (603) 448-4992
kchichakly@ iseesys.com
Abstract
It is very difficult to deliver high-quality software (i.e., with very few bugs) in a reasonable time
period. Indeed, it is not unusual on medium to large projects to spend as much time fixing bugs
as delivering new features. One of the most challenging issues in software development is
keeping pace with changing customer requirements.
Agile development was born from the idea that software development needs to be quick on its
feet, responding to changing customer requirements without compromising delivery schedules or
quality. It was founded on the principle of embracing change rather than fighting it. Some of the
fundamental principles of Agile development include frequent customer interaction, frequent
releases, writing tests before code, nightly builds with automated testing, and not implementing
more than you know the customer needs.
Yet there is a surging debate about whether Agile works and when it works. This paper
investigates when A gile development methods may work and the relative advantages of different
parts of the methodology.
Keywords: Agile, Rework Cycle, Software Development, Project Management
Overview
This paper explores the implications of the following facets of A gile development:
¢ Short development cycles, or more specifically, frequent releases - these cycles are
generated by the model
* Using a schedule/quality tradeoff that leads to both undiscovered and discovered rework
moving from one release to the next (in particular, what are the implications of starting a
project with a large amount of undiscovered and discovered rework?)
¢ Frequent customer interactions
¢ Frequent reviews between developers
¢ “Test first” (rather than code first) - before any code is written
¢ Frequent integrations, nightly builds with automated regression tests
¢ Availability to customers of frequent stable builds (vs. established and defined betas)
¢ Having a less predictable set of releases in the field (does not impact this model)
¢ Being adaptive to regularly changing requirements (hence the name “agile”), including
adapting processes as required
¢ Main metric is working software vs. tasks completed
¢ Close face-to-face cooperation and communication
* Continuous attention to technical excellence and good design
« Always choose simple (spec or design) over complicated - it may change!
Software development is notorious for delivering too little too late, often with many bugs. It is
very difficult to deliver high-quality software (i.e., with very few bugs) in a reasonable time
period. Indeed, it is not unusual on medium to large projects to spend as much time fixing bugs
as delivering new features. The reasons for this are many, but the rework cycle we have been
studying gives a lot of insight into the problem.
One of the most challenging issues in software development has been changing customer
requirements. Since software is fungible, most everyone has some idea of how to change it.
Also, it is a documented phenomenon that people cannot adequately visualize how a piece of
software is going to work by walking through examples. As soon as the real thing is there, they
instantly find several things that need to be changed. Prototyping, RAD, and spiral development
have all been things that have been tried to close this gap. Finally, the 90s saw a lot of
companies shifting to a more customer-centric approach given heightened competition and
greater expectations.
Agile was born from the idea that software development needs to be quick on its feet, while at
the same time delivering quality software (in the land of software, change is usually bad because
it means the introduction of lots of new bugs). Indeed, Agile was founded on the principle of
embracing change (it is a fact of life) rather than fighting it.
Y et there is a surging debate about whether A gile works (and when it does). A lot of people feel
it is just a bunch of hooey that someone made up to make some money. Others think it only
works for specific types of people (and that there aren’t that many of them around). Then there
Modeling Agile Development 2 © 2007 by K. Chichakly
are those who are religious zealots about it. Finally, there are people like me who think there are
some good ideas there, but the entire thing as a package is a bit much for most people to use (and
rather unproven).
This paper investigates when Agile methods may work and the relative advantages of different
parts of the methodology.
The Rework Cycle
The dynamics of a project revolves around the rework cycle. The structure below was given to
the author by Jim Lyneis:
original work
accomplishment
error fraction original work done
Original correcth
Work to Do rework
rework generation fF acconplishment
on original work Gaaaen
error fraction rework done
correctly
Rework to Do Undiscovered
Rework
rework generation
on rework
rework
discovery
time to discov er rework
Each project begins with a stock of original work to do. As the work is completed, a fraction of
the work is done incorrectly (determined by error fraction). This rework remains undiscovered
foratime. As it is discovered, it is fixed, again generating a fraction of errors. Eventually, all of
the work and rework is completed and the project is finished. Note that rework is not just
restricted to specific bugs that have been introduced in the code, but also includes problems in
the customer requirements and the project design.
Both the error fraction and the time to discover rework play critical roles. If the error fraction is
high, much of the work will need to be redone. If the time to discover rework is very long, the
rework may not be discovered until late in the project cycle, or even worse, after the product has
shipped. Even worse, the error fraction necessarily increases when there are errors in the
system, because the code that new code is being tested against is not producing the correct
results. This is called the “errors on errors feedback” and it is a reinforcing loop (shown below).
It is therefore advantageous to decrease the time to discover rework as much as possible.
Modeling Agile Development 3 © 2007 by K. Chichakly
normal eto,
fraction error fraction
+ 4, Undiscovered
Rework
rework
generation
incremental errors from
undiscovered rework
+
(R) work believed
to be done
fraction of undiscovered
errors incorporated fraction work done.
containing errors
a 9
In the waterfall paradigm, the entire project is placed in Original Work to Do and the project
progresses until most of the required work is completed. In Agile, however, the project is broken
down into separate phases (four in these simulations). When each phase is completed, based on
a measure of quality of the completed work, Original Work to Do is injected with the work for
the next phase.
Agile Background
The most fundamental precept of Agile is that the code base never stray very far from a
completely working system.’ This is guaranteed with a number of basic principles.
The first is an automated build and test system that runs every single night. This verifies the
code correctly builds on all supported platforms and also regression tests it to make sure nothing
was broken. Errors in the build or the testing are reported via e-mail or RSS feed so everyone
knows right away that something is amiss. Also, when it is successful, an quasi-official build is
available for manual testing (for this is the same system that builds official releases; this is a
critical point: release builds are just nightly builds that meet a certain criteria, so testing is
always being performed on whatever eventually gets shipped).
The second is the concept of “Test first’. This means programmers are responsible for designing
and writing automated tests before they write the actual code that needs to be tested. This serves
many purposes, the most transparent one being it guarantees a body of regression tests (so-called
“unit tests”). More importantly, it forces the programmer to think about the number of ways his
code might break before he writes the code, thus ensuring he writes more robust code. Finally,
as he writes the code, he now has something to test it against (as he goes) rather than just
assuming the thing works.
1 Ttis possible to have experimental branches of the code that don’t really work, but they should never stray too far
(or too long) from the trunk (main branch).
Modeling Agile Development 4 © 2007 by K. Chichakly
All regression tests must stay current. When a new bug is found that none of the regression tests
uncovered, a new test is added for that specific problem. This ensures the bug will not reappear
in later versions by incorporating what has been leamed into the nightly automated tests.
Lastly, customer releases must be frequent, perhaps as often as once a month, to get quick
feedback and to ensure effort is not being spent in an unproductive direction (e.g., an over
specified feature). These short cycles make it very different from other approaches. A
consequence of never straying far from a working system is also that most people applying these
techniques offer intermediate alpha versions to customers at the end of every single week,
shortening the feedback delay even more. Customers are also usually closely involved in
deciding the features that need to be implemented (they get a vote anyway).
All of this leads to a system that is neither schedule-driven nor feature-driven, though both of
these aspects still play important roles. The decision to release is based more on “Is it working?”
by some standard that will be different for a weekly (intermediate) release than for an “official”
release. “Is there something useful to someone?” is the second most important question. It
doesn’t really matter anymore how much is done or exactly what features are there because
another release isn’t far behind (and a less-stable weekly release is even closer behind if the
customer is willing to take the risk).
To clarify the standards, the weekly releases don’t have a very high threshold. Pretty much if it
built and passed all the automated tests, it can be released. The monthly (or bimonthly) release
needs to pass more stringent tests, but even these can be relaxed in the face of the weekly
releases that can patch a problem (and the confidence one gets from automated regression tests).
This means that both discovered rework and undiscovered rework can move from release to
release. Indeed, the fact of trying to meet a monthly target - and that the fact of a periodic
release is more important than what is in it - means that some of the original work will also
move from one release to another.
The combination of automated builds and tests, writing tests first, and frequent releases all lead
to a reduction in the time to discover rework. This reduces the size of undiscovered rework,
which reduces the gain of the errors-on-errors reinforcing loop, thus allowing an Agile project to
complete in advance of an equivalent waterfall project.
on
Modeling Agile Development © 2007 by K. Chichakly
Base Run
The base run is a consistent schedule, waterfall vs. Agile. The consistent schedule chosen was 5
experienced staff members working on 100 tasks over 29 weeks with an estimated rework
fraction of 0.3. It was expected that Agile would finish close to the waterfall model, perhaps a
little earlier. As can be seen, it finishes a month early while the waterfall model finishes a month
late.
&® cauivatent staff: 1-2 -
1 6.04
ee ee
Fé a
L 3.04
1 0.0: lo2:
0.00 10.00 20.00 30.00 40.00
Page 2 Months 11:00 PM Tue, Nov 28, 2006
Naesé 2? 1: Waterfall, 2: Agile
While the Agile project required less work to be done, it cost exactly the same as the Waterfall
project:
&® cumulative work Done: 1 - 2-
1: 2004
[j-—___
we
1: 1004 4 2
J |
2"
ie
1: 0
0.00 10.00 20.00 30.00 40.00
Page 4 Months 11:00 PM Tue, Nov 28, 2006
NadeF ? 1: Waterfall, 2: Agile
Modeling Agile Development 6 © 2007 by K. Chichakly
® cumulative Person Months: 1-2
a 200%
Le
ee
L 1004 a cf
ao
ye
|
ize
1: 0 T T T 1
0.00 10.00 20.00 30.00 40.00
Page 5 Months 11:00 PM Tue, Nov 28, 2006
N@eF 2? 1: Waterfall, 2: Agile
The error fractions and productivities are shown below (the error fraction spikes are just a DT-
length artifact of switching phases). Note they are both lower in the Agile case (as expected -
they are both lower because of the features built into the process to keep quality high). It is also
interesting to note the total rework done in each case (shown last, and again lower in the Agile
case).
® escor fraction: 1-2
1: 0.455
5s
1 0.204 rrrie et
~ pi-——_—____l }.
2,
4 ae
2: 2:
a: 0.05: 1
0.00 15.00 30.00 45.00 60.00
Months 11:00 PM Tue, Nov 28, 2006
? 1: Waterfall, 2: Agile
Modeling Agile Development 7 © 2007 by K. Chichakly
® productivity: 1-2-
st
1.00% ————— 1
[2 2 2
L 0.604
4 7
ai 0.20 ‘ y T 1
0.00 15.00 30.00 45.00 60.00
Page 8 Months 11:00 PM Tue, Nov 28, 2006
Nea
® cumulative Rework Done: 1-2-
1 404
1; Waterfall, 2: Agile
2:
Sp ee
Lot
1: T
10.00 20.00 30.00 40.00
Page 10 Months 11:00 PM Tue, Nov 28, 2006
Nae ? 1: Waterfall, 2: Agile
Modeling Agile Development 8 © 2007 by K. Chichakly
Analyses
Inconsistent Project
The obvious first question is how much better (if any) is Agile with an inconsistent case? The
inconsistent case chosen is starting with 4 experienced staff members to finish 100 tasks in 25
weeks. In this situation, Agile finishes in month 27 (2 months late) vs. waterfall’s month 31.
Note the more consistent staffing with the shorter cycles. Also note that required staffing grows
quicker in the Agile case. This is due to the pressure of the shorter phases; we know sooner that
we need more staff members. This earlier feedback alone gives A gile an edge over waterfall.
&® couivatent staff: 1-2-
L 15.04
L 159 1
2 2,
2 7-1-
|
a
1
L 0.0 r r — 1
0.00 10.00 20.00 30.00 40.00
Page 2 Months 11:22 AM Wed, Nov 29, 2006
Naef ? 1: Waterfall, 2: Agile
The lower error fractions in Agile lead to less work being done. This combined with the
significantly earlier finish leads to lower costs.
&® cumulative work Done: 1-2 -
L 2004
yl: 1;
2 2
= 1004 a
iv
F a
1
L 0
0.00 15.00 30.00 45.00 60.00
Page 4 Months 11:22 AM Wed, Nov 29, 2006
Naesé 2? 1: Waterfall, 2: Agile
Modeling Agile Development 9 © 2007 by K. Chichakly
® cumulative Person Months: 1-2
L 300%
1 1 1
- 2:
L 1504
2
F7 V
we
1 0 T T T 1
0.00 15.00 30.00 45.00 60.00
Page 5 Months 11:22 AM Wed, Nov 29, 2006
N@eF 2? 1: Waterfall, 2: Agile
Note the fact that we develop the project in phases with minimum quality requirements means
that Undiscovered Rework never grows out of control, so we do not get the large error-on-error
effects we see in the waterfall case.
&® Undiscovered Rework: 1-2-
L 204
1
L 104
Ga i
2. — —
1 0 u 12, =
0.00 15.00 30.00 45.00 60.00
Page 7 Months 11:22 AM Wed, Nov 29, 2006
NaeF ? 1: Waterfall, 2: Agile
Note these benefits are accrued despite having lower productivity due. This is because the focus
on high quality (which causes much of this productivity loss) keeps the error fraction and the
rework generated low.
Modeling Agile Development 10 © 2007 by K. Chichakly
® productivity: 1-2-
L 1.104
XK 1 1
im
KR 2: 2:
2.
L 0.654
4 2
1 0.20: T T 1
0.00 15.00 30.00 45.00 60.00
Page 8 Months 11:22 AM Wed, Nov 29, 2006
N@eeF 1: Waterfall, 2: Agile
s error fraction: 1 - 2
1 0.60%
| ie
L 0.304
; |
—— a ey
2 2:
L 0.00:
0.00 15.00 30.00 45.00 60.00
Page 6 Months 11:22 AM Wed, Nov 29, 2006
NaeFf 2? 1: Waterfall, 2: Agile
s Total Rework Generated: 1 - 2
L 90%
~1: 1
L 459
1
7 2 2
a ie
ian?
1
0.00 15.00 30.00 45.00 60.00
Page 11 Months 11:22 AM Wed, Nov 29, 2006
Nae
Modeling Agile Development
11
1; Waterfall, 2: Agile
© 2007 by K. Chichakly
Inconsistent Project with Uncertain Customer Requirements
In the face of uncertain customer requirements, which Agile was designed to address, Agile
performs even better. Agile still finishes around month 27 (at month 27.8 - 2.8 months late)
while waterfall runs almost out to month 40 (at month 39.8 - 14.8 months late). The cost for
waterfall is almost 50% higher than Agile, while the overall Agile cost has changed very little
from the case without uncertain customer requirements.
® cauivatent staff: 1-2 -
= 20.04
L 10.04 |
1
1!
a 2
ee
ta |
L 0.0 —
0.00 10.00 20.00 30.00 40.00
Page 2 Months 11:39AM Wed, Nov 29, 2006
Naesé 2? 1: Waterfall, 2: Agile
Ss Cumulative Person Months: 1 - 2 -
lL 3004 rt
1
2 2
L 1504
2
1
ZA
ee
L 0
0.00 15.00 30.00 45.00 60.00
Page 5 Months 11:39AM Wed, Nov 29, 2006
Naesé 2? 1: Waterfall, 2: Agile
Modeling Agile Development 12 © 2007 by K. Chichakly
Summary of Inconsistent Missions
The following tables summarize the two inconsistent mission cases, first without and then with
uncertain customer requirements. Note that Agile development provides a definite advantage to
projects that have an inconsistent mission, finishing 14% earlier at about 75% of the cost.
Project Deltafrom | ProjectCost Deltafrom | Work Completed Delta from
Project Type | Length(mo) Base (%) (person-mo) Base (%) (tasks) Base (%)
Waterfall: 31.25 212.84 183.04
Agile: 26.9375 -13.80 163.82 -23.03 118.68 -35.16
With uncertain customer requirements, Agile really shines, cutting 30% off the project length
(only two months late vs. 15 months late) at around 60% of the cost. Clearly, Agile lives up to
its purpose of resiliency in the face of changing customer requirements.
Project Deltafrom | ProjectCost Deltafrom | Work Completed Delta from
Project Type | Length(mo) Base (%) (person-mo) _ Base (%) (tasks) Base (%)
Waterfall: 39.75 290.98 258.11
Agile: 27.875 -29.87 178.58 -38.63 127.93 -50.44
Modeling Agile Development 13 © 2007 by K. Chichakly
Analysis of Benefits of Individual Aspects of Agile
Benefits of Frequent Releases and Customer Interactions
For this test, the base case has all Agile effects tumed off. This will then be compared to the
same case with only the frequent release effect turned on, both with and without uncertain
customer requirements. The inconsistent mission used previously will be retained as a baseline.
Frequent releases serve to reduce customer uncertainty, as do frequent customer interactions.
This cuts the uncertainty in half, as well as changing the shape of the curve to be more
consistent. The traditional shape for waterfall is shown on the left below while the revised shape
for Agile on the right.
1.000 1.000
A Syl elimination
elimination if
: uncertainty
uncertainty Based on
based on
progress std Vea
0.000 : yo : 6.000 : i
| | ] |
B 0.000 7.000 ZB 0.000 7.000
=F —fraction_perceived_to_...omplete {dimensionless} — fraction_perceived_to_...omplete {dimensionless}
As shown in the following graph, there frequent releases and customer interactions have little to
no effect if there are not changing customer requirements (graphs 1 and 2). However, in the case
of uncertain customer requirements (graphs 3 and 4), there is a marked improvement, finishing
after 41.75 months rather than 50) when there are frequent releases and customer interactions.
Not surprisingly, the cost is also much lower.
Modeling Agile Development 14 © 2007 by K. Chichakly
S® equivalent Staff: 1-2-3-4
a 7.0m
4 y1-
mai
1
1: 3.54
‘i 0.0 u u plete I
0.00 15.00 30.00 45.00 60.00
Page 2 Months 11:51 AM Wed, Nov 29, 2006
XN aaF ? 1: Multiphase, 2: w/Releases, 3: Multiphase uncertain, 4: w/Releases
Ss Cumulative Person Months: 1- 2-3-4
1: 300m
L——3
ae 4
#3 1
1
1: 1504
4
Pa
rol
4 i
a
wae
2'
sil
1 0 .
0.00 15.00 30.00 45.00 60.00
Page 5 Months 11:51 AM Wed, Nov 29, 2006
XN aaF ? 1: Multiphase, 2: w/Releases, 3: Multiphase uncertain, 4: w/Releases
Benefits of Nightly Builds and Automated Testing
For this test, the base case has all Agile effects tumed off. This will then be compared to the
same case with only the automated testing effect tumed on, both with and without uncertain
customer requirements. The inconsistent mission used previously will be retained as a baseline.
Nightly build and automated tests lead directly to a shorter rework discovery delay (reduces the
maximum from 12 months to 12/phases months, where phases is the number of phases in the
project). The maximum time to discovery rework will also be varied to see if the model is
sensitive to its value.
Note that automated testing has a significant effect both without (graphs 1 and 2) and with
(graphs 3 and 4) uncertain customer requirements. In the former case, the project finishes 7.5
months earlier (month 28.7 vs. 36.25), while in the latter case the project finishes 17.5 months
Modeling Agile Development 15 © 2007 by K. Chichakly
earlier (month 32.5 vs. 49.8). Once again the respective costs are much lower, although the work
completed in each case is virtually identical (rework generated is almost the same).
S® cauivalent Staff: 1-2-3-4
lL: 8.04
=
1
L 4.04
1 0.0 2. 4 —
0.00 15.00 30.00 45.00 60.00
Page 2 Months 12:01PM Wed, Nov 29, 2006
XN aaF ? 1: Multiphase, 2: w/Autotest, 3: Multiphase uncertain, 4: w/Autotest
&® cumulative Person Months: 1- 2-3-4
Lh 3004
aaa
oe!
1: 1504 = =
oe
LE ;
15.00 30.00 45.00 60.00
Months 12:01PM Wed, Nov 29, 2006
1: Multiphase, 2: w/Autotest, 3: Multiphase uncertain, 4: w/Autotest
To test the sensitivity of the maximum time to discover rework, the base case (curve 1) was
compared against the automated tests case with the original time (curve 3), double the original
time (curve 2) and half the original time (curve 4). It is clear from the progression of the curves
that the model is somewhat sensitive to this value. However, halving it made little difference
(only a one month improvement), while doubling it still provided a significant effect (5 months
better) over the base case. Halving it also led to an excessive ramp-up in the first phase,
suggesting the value might be too small.
Modeling Agile Development 16 © 2007 by K. Chichakly
S® equivalent Staff: 1-2-3-4
at
7.0%
1 3.54
4
L 0.0 r : aS St
0.00 10.00 20.00 30.00 40.00
Page 2 Months 12:11 PM Wed, Nov 29, 2006
NU BEF 2 emuttionase, 2: wautotest double, 3: wAutotest normal, 4: wAutotest halt
These changes had little impact on the project cost.
&® cumulative Person Months: 1- 2-3-4
1:
2004
4 EE
Ly |
1 10044 tea
|
a
-
ea
Ly
z 0 T
0.00 15.00 30.00 45.00 60.00
Page 5 Months 12:11PM Wed, Nov 29, 2006
NU GBF PF _amutticnase, 2: wautotest double, 3: w/Autotest normal, 4: w/Autotest half
Benefits of “Test First”
For this test, the base case has all Agile effects tumed off. This will then be compared to the
same case with only the “test first” effect tumed on, both with and without uncertain customer
requirements. The inconsistent mission used previously will be retained as a baseline.
The “test first” effect lowers productivity (and slows initial progress) by 10% as tests are written
instead of shipping code’. It also decreases the normal error fraction by 5%.
? Note this also could have been implemented by increasing the scope of the project. I felt decreasing the
productivity more accurately represented what actually happens.
Modeling Agile Development 17 © 2007 by K. Chichakly
Note that “test first” gives about a two month improvement in the delivery date in both cases,
though it is slightly less in the face of uncertain customer requirements (curves 3 and 4). The
project cost, however, is higher, especially in the face of uncertain customer requirements -
despite slightly lower total work done due to a lower error fraction. This is because productivity
is lower in “test first” due to the time required to write the tests. The cost is that much higher
when there are changing customer requirements because the project runs longer at the lower
productivity.
S® cauivalent Staff: 1-2-3-4
1: 8.09
1 4.04
F 00 \ i) plc
0.00 15.00 30.00 45.00 60.00
Page 2 Months 12:20 PM Wed, Nov 29, 2006
XN aaF ? 1: Multiphase, 2: w/Test first, 3: Multiphase uncertain, 4: w/Test first
® cumulative Person Months: 1-2-3-4
1 300%
—2
L 1504
J 1
oF |
3
ae
real
L 0 : . . 1
0.00 15.00 30.00 45.00 60.00
Page 5 Months 12:20PM Wed, Nov 29, 2006
XN aaF ? 1: Multiphase, 2: w/Test first, 3: Multiphase uncertain, 4: w/Test first
Modeling Agile Development 18 © 2007 by K. Chichakly
® productivity: 1-2-3-4-
at 1.109
1 3
2 a
1 0.604
1 0.10: T T T 1
0.00 15.00 30.00 45.00 60.00
Page 8 Months 12:20 PM Wed, Nov 29, 2006
XN aaF ? 1: Multiphase, 2: w/Test first, 3: Multiphase uncertain, 4: w/Test first
® cumulative work Done: 1-2-3-4-
1 200%
—3—,-——|
1
- 2
1 1004
jer
xe
v
Lh oF r
0.00 15.00 30.00 45.00 60.00
Page 4 Months 12:20 PM Wed, Nov 29, 2006
XN aaF ? 1: Multiphase, 2: w/Test first, 3: Multiphase uncertain, 4: w/Test first
Benefits of Design and Code Reviews
For this test, the base case has all Agile effects tumed off. This will then be compared to the
same case with only the reviews effect tumed on, both with and without uncertain customer
requirements. The inconsistent mission used previously will be retained as a baseline.
Frequent reviews between developers, including pair programming (which I think most people
can only tolerate in very short doses) and face-to-face communication, leads to both a lower
normal error fraction and a lower productivity (5% reduction on both). Continuous attention to
technical excellence and design may also lower productivity somewhat, but definitely lowers
error fraction. It has been assumed that the 5% reduction already given for reviews sufficiently
covers this effect as well.
Note that having design and code reviews improves the project schedule by about three months
in both cases at about the same cost. There is a modest cost savings (about 4%) without
Modeling Agile Development 19 © 2007 by K. Chichakly
customer changes (curves 1 and 2). These are tied to proportionally lower levels of rework
generation (because of a lower error rate), and hence, total work done.
S® cauivalent Staff: 1-2-3-4
1: 7.04
rr _
ip EH 3 i
——— a!
1
1: 3.54
1 0.0 2 —
0.00 15.00 30.00 45.00 60.00
Page 2 Months 1:09 PM Wed, Nov 29, 2006
XN aaF ? 1: Multiphase, 2: w/Reviews, 3: Multiphase uncertain, 4: w/R eviews
&® cumulative Person Months: 1- 2-3-4
Lh 3004
—
—
1: 1504
1: 0
0.00 15.00 30.00 45.00 60.00
Page 5 Months 1:09 PM Wed, Nov 29, 2006
XN aeaF 7? 1: Multiphase, 2: w/Reviews, 3: Multiphase uncertain, 4: w/R eviews
Modeling Agile Development 20 © 2007 by K. Chichakly
&® otal rework Generated: 1-2-3-4-
at 709
—
£7 —
mm -
ma
‘tL:
af 354 rs 1
Pal a =
oad r a
| oe) =
fe
1!
1. 0 - T T T 1
0.00 15.00 30.00 45.00 60.00
Page 11 Months 1:09 PM Wed, Nov 29, 2006
XN aaF ? 1: Multiphase, 2: wR eviews, 3: Multiphase uncertain, 4: w/R eviews
Benefits of Keeping Things Simple
For this test, the base case has all Agile effects tumed off. This will then be compared to the
same case with only the KISS effect tured on, both with and without uncertain customer
requirements. The inconsistent mission used previously will be retained as a baseline.
Choosing simple over complicated both reduces error fraction and the effect of rework for
uncertain customer requirements (because you haven't yet developed everything that the
customer may be changing). Rather than reducing the error fraction, I decided it made more
sense to reduce the strength of the errors on errors effect because that is where complexity is
likely to cause the worst trouble (reduce by 10%). The uncertain customer requirements effect
was also reduced another 5%.
Note that choosing simpler solutions has a minor impact (1 month - curves 1 and 2) on both the
schedule and the cost when customer requirements are not changing and a dramatic impact (6.5
months - curves 3 and 4) when they are. These changes are directly tied to the amount of rework
generated. The improvements can be clearly seen in the graphs of incremental errors from
undiscovered rework (which includes discovered rework as well) and error fraction.
Modeling Agile Development 21 © 2007 by K. Chichakly
S® equivalent Staff: 1-2-3-4
1 1.09
sone 2
ba 5 A
1
L 3.54 4
2
ii 0.0 u u plete
0.00 15.00 30.00 45.00 60.00
Page 2 Months 1:18 PM Wed, Nov 29, 2006
Nea
&® cumulative Person Months: 1- 2-3-4
1
1: Multiphase, 2: w/KISS, 3: Multiphase uncertain, 4: w/KISS
3004
—
te
ia | “4:
3"
oe =:
1
1: 1504
4
a
3"
ae
4 =r
At
i:
15.00 30.00 45.00 60.00
Page 5 Months 1:18PM Wed, Nov 29, 2006
XN aaF ? 1: Multiphase, 2: KISS, 3: Multiphase uncertain, 4: w/KISS
Ss Total Rework Generated: 1-2-3-4-
a 70m
3:
“|
4 wor 4
LL 1
= |
f°
Jal’
1: 0
0.00 15.00 30.00 45.00 60.00
Page 11 Months 1:18PM Wed, Nov 29, 2006
XN aaF ? 1: Multiphase, 2: KISS, 3: Multiphase uncertain, 4: w/KISS
Modeling Agile Development
© 2007 by K. Chichakly
® incremental errors from undiscovered rework: 1-2-3 -4-
a: 0.50:
30.00 60.00
Months 1:18 PM Wed, Nov 29, 2006
1: Multiphase, 2: w/KISS, 3: Multiphase uncertain, 4: w/KISS
15.00
® escor fraction: 1-2-3-4
L 0.75
3
x
1 0.40 ;
i
4
3
4. Ss
1—2
15.00 30,00 45.00 60.00
Months 1:18 PM Wed, Nov 29, 2006
1: Multiphase, 2: w/KISS, 3: Multiphase uncertain, 4: w/KISS
Summary of Individual Effects
The above results are summarized in the following two tables. The first shows the results
without uncertain customer requirements, while the second shows the results with uncertain
customer requirements. As can be seen from the table below, frequent releases have no impact
when there are not changing customer requirements. On the other hand, nightly builds and
automated tests give a tremendous advantage in terms of both time and cost. “Test first” gives a
modest gain in schedule at a modest cost. The remaining two effects show modest advantages in
both time and cost.
Modeling Agile Development 23 © 2007 by K. Chichakly
Agile feature Project Delta from | Project Cost Delta from Work Completed Delta from
(known regs) Length (mo) _ Base (%) (person-mo) _ Base (%) (tasks) Base (%)
Base (none): 36.375 178.33 135.35
Frequent release: 36.375 0.00 178.33 0.00 135.35 0.00
Nightly builds/test: 28.6875 -21.13 155.13 -13.01 133.64 -1.26
“Test First": 34.125 -6.19 186.42 4.54 128.70 -4.91
Design/Code reviews: 33.4375 -8.08 170.68 -4.29 127.01 -6.16
KISS: 35.1875 -3.26 171.12 -4.04 132.51 -2.10
The story is a little different when there are changing customer requirements. Frequent releases,
nightly builds, and avoiding complexity have strong schedule and cost gains while reviews have
modest schedule gains with no difference in cost. “Test First” has a smaller impact than in the
previous case at a higher cost.
Does this then mean that the doctrine of “test first” should be abandoned? Unfortunately, the
automated tests that run with nightly builds (yielding a very strong benefit in both time and cost)
depend on the automated tests being written. Whether they are written first or last does not
directly affect the productivity, though writing them last tends to increase the error fraction,
worsening the results shown in the table. In other words, to reap the benefits of nightly
automated tests, the tests must be written and it is better to write them first rather than last. This
is not a potential practice to drop.
Agile feature Project Deltafrom | ProjectCost Delta from Work Completed Delta from
(uncertain reqs) Length (mo) Base (%) (person-mo) _ Base (%) (tasks) Base (%)
Base (none): 49.875 263.66 167.57
Frequent release: 41.625 -16.54 210.61 -20.12 148.83 -11.18
Nightly builds/test: 32.5625 “34.71 203.54 -22.80 167.83 0.16
“Test First": 48 -3.76 288.53 9.43 162.74 -2.88
Design/Code reviews: 47.0625 -5.64 263.10 -0.21 160.86 -4.00
KISS: 43.25 -13.28 219.12 -16.89 153.16 -8.60
Agile Without Frequent Releases
One of the burning questions is whether these process improvements still work without frequent
official releases. Since Agile assumes that you are always working in small releasable chunks,
even if you don’t actually release the product, should this aspect be retained in the comparison?
This is hard to answer equivocally because there will be differences between projects in the
amount of customer interaction and releases to the customer. These tests have been run
assuming these remain the same as for the waterfall case.
Without uncertain customer requirements, there is no difference between frequent releases (curve
3) and not having frequent releases (curve 2). [The waterfall case is included for comparison in
curve 1.]
Modeling Agile Development 24 © 2007 by K. Chichakly
SD equivalent Staff: 1-2-3
at 20.0%
1 10.04
1: 0.0
pleat
0.00 15.00 30.00 45.00 60.00
Page 2 Months 1:32 PM Wed, Nov 29, 2006
XN aaF ? 1: Waterfall, 2: Agile no releases, 3: Agile w/releases
However, when there are uncertain customer requirements, there is an improvement in the
schedule (1.5 months) by having frequent releases and customer interaction. In addition, there is
a cost savings. This isn’t a big surprise because frequent releases showed an improvement on
their own.
® couivatent staff: 1-2-3
1 20.0%
L 10.04 K
1
3 Lo
fre ~\
L 0.0 r 2: 1 4
0.00 15.00 30.00 45.00 60.00
Page 2 Months 1:35 PM Wed, Nov 29, 2006
N] aaF ? 1: Waterfall, 2: Agile no releases, 3: Agile w/releases
Modeling Agile Development 25 © 2007 by K. Chichakly
® cumulative Person Months: 1-2-3
1 300% r
1
2 2
3 3
z ss
L 150 ,
Le ;
oO
all
iz
1 0 r . r 1
0.00 15.00 30.00 45.00 60.00
Page 5 Months 1:35 PM Wed, Nov 29, 2006
XN aaF ? 1: Waterfall, 2: Agile no releases, 3: Agile w/releases
These results are summarized in the tables below. The first table shows the results without
changing customer requirements. Not surprisingly (since we already saw frequent releases have
no impact in this case), failing to have frequent releases and customer interactions has no impact.
Project Deltafrom | Project Cost Deltafrom | Work Completed Delta from
Project Type Length(mo) Base (%) (person-mo) Base (%) (tasks) Base (%)
Waterfall: 31.25 212.84 183.04
Agile: 26.9375 -13.80 163.82 -23.03 118.68 -35.16
Agile no rels: 26.9375 -13.80 163.82 -23.03 118.68 -35.16
However, with changing customer requirements, there is a noticeable difference. Failure to have
frequent releases increases the project length 5% (1.5 months) and the cost 12%. Note there is
also more work to accomplish (11%). This is from additional rework that must be done due to
increased Undiscovered Rework from changing customer requirements. This also leads to a
higher error fraction due to the errors-on-errors feedback, causing even more rework.
Project Deltafrom | Project Cost Deltafrom | WorkCompleted Delta from
Project Type Length(mo) Base (%) (person-mo) Base (%) (tasks) Base (%)
Waterfall: 39.75 290.98 258.11
Agile: 27.875 -29.87 178.58 -38.63 127.93 -50.44
Agile no rels: 29.3125 -26.26 199.77 31.35 141.46 -45.19
Cost of no rels: 5.16 11.87 10.58
Modeling Agile Development 26 © 2007 by K. Chichakly
Sensitivity of Assumptions
A number of assumptions have been made about how well Agile performs in terms of error
fraction and productivity. What if the error fraction improvements in Agile aren’t as high as
suggested (or the waterfall error fraction is lower)? What if the price of Agile is even higher in
terms of productivity? This will very likely be true in the early stages of adoption. Additionally,
what if these changes also have a relative impact on new staff members (or maybe we were too
optimistic originally)? Using the inconsistent mission, the following series of tests look at a
progressive worsening of these parameters, as shown in the table below. Note the relative
impact of new staff members in Agile is never worse than the waterfall case, which seems
reasonable.
normal incr.
Case error Normal errors: — productivity:
number fraction _ productivity newstaff _new staff
Waterfall:
1 0.15 1.00 0.50 0.50
Agile:
2 0.05 0.85 0.35 0.65
3 0.08 0.80 0.40 0.60
4 0.11 0.75 0.45 0.55
5 0.15 0.70 0.50 0.50
6 0.18 0.65 0.50 0.50
The following curves show the staffing behavior, cost, and work done for the six cases. Note
that while most of the Agile cases finish before, or close to, the waterfall case, all but two of the
Agile cases are more expensive than the waterfall case. This is despite the fact that all of the
Agile cases accomplish less work (fewer tasks) over the course of the project.
Note also how the first phase of most of the Agile cases over-staffs in an attempt to finish on
time. Some of this staff is subsequently let go in the second phase.
@ Equivalent Staff: 1-2-3-4-5-—
1 20.04
1: 0.0 T
0.00 10.00 20.00 30.00 40.00
Page 2 Months 9:55 PM Sun, Dec 10, 2006
NadeF ? 1: Waterfall, 2-6: Agile
Modeling Agile Development 27 © 2007 by K. Chichakly
@ Cumulative Person Months: 1-2-3-4-5-
1: 4004
L 2004
1 0 7
0.00 15.00 30.00 45.00 60.00
Page 5 Months 9:55 PM Sun, Dec 10, 2006
NdeFf ? 1: Waterfall, 2-6: Agile
@ Cumulative Work Done: 1-2-3-4-5-5
L 2004
z 1004
1: 0
0.00 15.00 30.00 45.00 60.00
Page 4 Months 9:55 PM Sun, Dec 10, 2006
NdeF ? 1: Waterfall, 2-6: Agile
The higher Agile costs are easily explained by the productivity curves. Productivity in Agile is
considerably below the waterfall case across the entire project.
Modeling Agile Development 28 © 2007 by K. Chichakly
@ productivity: 1-2-3-4-5-—
af 1.05
1: 0.554 |
1: 0.05: T T T 1
0.00 15.00 30.00 45.00 60.00
Page 8 Months 9:55 PM Sun, Dec 10, 2006
NadeF ? 1: Waterfall, 2-6: Agile
Finally, the total work accomplished is lower in all Agile cases because the rework generated is
lower than in the waterfall case.
@ Total Rework Generated: 1-2-3-4-5-—
1 904 |
|—
oe
1 454 ra
di 0 r
0.00 15.00 30.00 45.00 60.00
Page 11 Months 9:55 PM Sun, Dec 10, 2006
XQ aaF ? 1: Waterfall, 2-6: Agile
This is, of course, directly tied to lower error fractions in the Agile case across the entire project
(shown below). Lower error fractions also mean a lower errors-on-errors effect. The bump in
the first phase of each A gile case is caused by ramping up the staff at the beginning.
There is something of a paradox here, though. How can the error fraction remain lower than the
waterfall case when the last two cases (five and six) set the Agile error fraction equal to and then
greater than the waterfall case? This is because incremental errors from undiscovered rework
stays smaller due to a slightly smaller effect in the Agile case, a shorter rework discovery delay,
and the clearing out of Undiscovered Rework at the end of each phase.
Modeling Agile Development 29 © 2007 by K. Chichakly
@ errorfraction: 1-2-3-4-5-—
af 0.60%
ee
1 0.30:
1: 0.00: T T T 1
0.00 15.00 30.00 45.00 60.00
Page 6 Months 9:55 PM Sun, Dec 10, 2006
aes
@® incremental errors from undiscovered rework: 1-2-3-4-5-—
1 0.40%
1: Waterfall, 2-6: Agile
1: 0.00: T
0.00 15.00 30.00 45.00 60.00
Page 9 Months 9:55PM Sun, Dec 10, 2006
XN aaF ? 1: Waterfall, 2-6: Agile
@ Undiscovered Rework: 1-2-3-4-5-—
af 209
KL
1 0
0.00 15.00 30.00 45.00 60.00
Page 7 Months 9:55PM Sun, Dec 10, 2006
NadeF ? 1: Waterfall, 2-6: Agile
Modeling Agile Development
30
© 2007 by K. Chichakly
These results are summarized in the table below. Note that all of these tests were done with
uncertain customer requirements tumed off. It is clear from the table that Agile roughly breaks
even with waterfall (4% earlier at 9% higher cost) when Agile has a slightly better error fraction
(and much worse productivity). When the error fraction reaches parity with waterfall, the project
takes longer and costs quite a bit more. Further degradation leads to much higher costs. As
stated earlier, these last two cases are more likely when the methodology is first adopted, giving
the classic worse-before-better behavior.
There is no question that Agile will normally give some improvement in error fraction over
waterfall and it is hard to believe that productivity will be much worse than the 75% given in that
middle case (4). Therefore, conservatively, under normal circumstances with an inconsistent
mission, we expect Agile to be no later than waterfall, with about a 10% increase in cost. If we
are able to improve productivity somewhat while lowering error fraction even more (case 3),
Agile can beat the waterfall schedule with no additional cost. This is, of course, assuming the
maximum rework discovery delay has been reduced. Although changes to this parameter have a
relatively small impact on the Agile case, the small difference is enough to tip the balance back
to waterfall.
Delta Project. Delta Delta
Project from Cost from Work from
Case nomalemor normal __ incr. errors: productivity: || Length Base (person. += Base.~=— Completed Base
number fraction productivity _newstaff __newstaff_| (mo) (%)___mo) (%)___(tasks) (%)
Waterfall:
1 0.15 1.00 0.50 0.50 31.25, 212.84 183.04
Agile:
2 0.05 0.85, 0.35, 0.65 26.9375 -13.80 163.82 -23.03 118.68 = -35.16
3 0.08 0.80 0.40 0.60 28.375 -9.20 193.49 -9.09 127.40 — -30.40
4 0.11 0.75, 0.45 0.55 29.9375 4.20 231.85 8.93 137.10 -25.10
5 0.15 0.70 0.50 0.50 31.8125 1.80 286.12 34.43 149.68 -18.23
6 0.18 0.65 0.50 0.50 32.875 5.20 333.64 56.76 157.95 -13.71
With uncertain customer requirements, Agile wins out in everything except cost in the last two
cases (shown below - graphs follow). This is, of course, the case that Agile was bom to handle.
Note that even in case 5, when the error fraction is the same as in the waterfall case (but the
productivity is much lower), Agile finishes almost 20% ahead of the waterfall case with only a
6% increase in project cost. Also take a moment to compare the project lengths with those
above. Observe that uncertain customer requirements pushed every Agile case back by less than
a month. Compare this to the 8.5 month difference in the waterfall case. Clearly, this is where
Agile shines.
Modeling Agile Development 31 © 2007 by K. Chichakly
Delta Project ~=—‘Delta Delta
incr. Project from Cost. from Work from
Case nommalemor nonmal —errors:_— productivity: || Length © Base —(person-.~=«sBase.~=— Completed Base
number fraction productivity __newstaff__newstaff_| (mo) (%) mo) (%) (tasks) (%)
Waterfall:
¥ 0.15 1.00 0.50 0.50 39.75 290.98 258.11
Agile:
2 0.05 0.85, 0.35 0.65 27.875 -29,87 178.58 -38.63 127.93 -50.44
5 0.08 0.80 0.40 0.60 29.3125 -26.26 210.22 27.75, 136.79 -47.00
4 0.11 0.75 0.45 0.55 30.875 22.33 251.28 -13.64 146.55 -43.22
5 0.15 0.70 0.50 0.50 32.5625 -18.08 308.14 5.90 159.10 -38.36
6 0.18 0.65 0.50 0.50 33.75 15,09 359.85 23.67 167.53 -35.09
&® equivalent staff: 1-2-3-4-5-—
lL 20.04
L 10.04 pea 2
L 0.0
0.00 10.00 20.00 30.00 40.00
Page 2 Months 11:06 PM Sun, Dec 10, 2006
XN aaF ? Uncertain Customer Reqs - 1: Waterfall, 2-6: Agile
&® cumulative Person Months: 1-2-3-4-5-5
1 4004
7
Z
1 2004
1 mW
1 0 ‘
0.00 15.00 30.00 45.00 60.00
Page 5 Months 11:06 PM Sun, Dec 10, 2006
XN aaF ? Uncertain Customer Reqs - 1: Waterfall, 2-6: Agile
Modeling Agile Development 32 © 2007 by K. Chichakly
® cumulative work Done: 1-2-3-4-5- 5
1 300%
1 1504
Lh 0 : . . 1
0.00 15.00 30.00 45.00 60.00
Page 4 Months 11:06 PM Sun, Dec 10, 2006
XN aaF ? Uncertain Customer Reqs - 1: Waterfall, 2-6: Agile
9 esortraction: 1-2-3-4-5-
1 0.75
i
—
=
I
t
0.00 15.00 30.00 45.00 60.00
Page 6 Months 11:06 PM Sun, Dec 10, 2006
XN aaF ? Uncertain Customer Reqs - 1: Waterfall, 2-6: Agile
These results lead to an interesting question when there is an inconsistent schedule, but there are
not uncertain customer requirements: If we can cut the rework discovery delay in half in the
waterfall case, and also double the rework discovery delay in Agile (so they are actually the
same), will the waterfall model give similar results? Doing so, leads to the following behavior:
Modeling Agile Development 33 © 2007 by K. Chichakly
S® cauivalent Staff: 1-2-3-4
a 20.0—
2
1: 10.04
a, zt
3 ee
a 3
[1' \
\ 1
kL 0.0 + r + | 9 1
0.00 10.00 20.00 30.00 40.00
Page 2 Months 9:27AM Mon, Dec 11, 2006
NAG SF Pe watertal, 2: watertalt halt discovery, 3: Agile, 4: Agile double discovery
The original cases are shown in curves 1 and 3, while the curves with the same rework discovery
delays are shown on curves 2 and 4 (red and green). Note there is much less of an advantage to
Agile (about a month) which could be lost to other factors, such as a slightly higher error fraction
or a slightly lower productivity. Agile’s costs, though, remain lower (25% lower) because there
is still less rework due to lower error fractions and removing (almost) all rework before moving
to the next phase.
@ Cumulative Person Months: 1- 2-3-4
1 3005
1 1504
Pa
oP |
3
a
reall
1: 0
0.00 15.00 30.00 45.00 60.00
Page 5 Months 9:27 AM Mon, Dec 11, 2006
XN 3 BaF 2 1: Waterfall, 2: Waterfall half discovery, 3: Agile, 4: Agile double discovery
Finally, under these same circumstances, does Agile still have an advantage if the error fraction
is increased while the waterfall error fraction is decreased, so they are equal (0.1)? The results
clearly show that it still does have this advantage, finishing 2 months earlier with a 10% cost
saving. This advantage is caused by a lower error fraction due to consistently lower levels of
Undiscovered Rework. These consistently lower levels are, as mentioned earlier, due to both a
short rework discovery delay and the fact that the Undiscovered Rework is not allowed to grow
across the length of the project (it is cleared out each phase).
Modeling Agile Development 34 © 2007 by K. Chichakly
S® cauivalent Staff: 1-2-3-4
1 20.0%
1 10.04
- 34
ee 12:
nn
43
k 0.0 : : 1
0.00 10.00 20.00 30.00 40.00
Page 2 Months 10:32 AM Mon, Dec 11, 2006
1: Waterfall, 2: Waterfall lower error, 3: Agile, 4: Agile higher error
Nea
&® cumulative Person Months: 1- 2-3-4
1 300%
1 1
2 2
4: 4
3 3
1 1504
i
0.00 15.00 30.00 45.00 60.00
Page 5 Months 10:32 AM Mon, Dec 11, 2006
XN aaF ? 1: Waterfall, 2: Waterfall lower error, 3: Agile, 4: Agile higher error
® eestor fraction: 1-2-3-4
L 0.60:
Pet_|
a
rr
f——2-
1. 0.30:
‘ |
3, ——— ann
| SR SS ———
OL
4: _ 4
3 3
1: 0.00-F
0.00 15.00 30.00 45.00 60.00
Page 6 Months 10:32 AM Mon, Dec 11, 2006
XN aaF ? 1: Waterfall, 2: Waterfall lower error, 3: Agile, 4: Agile higher error
Modeling Agile Development 35 © 2007 by K. Chichakly
B® Undiscovered Rework: 1-2-3-4
a:
1
Page 7
Naa ?
204
0
1°
2.
104 |
, es
df ZX
y , 123 ——
0.00 15.00 30.00 45.00 60.00
Months 10:32 AM Mon, Dec 11, 2006
1: Waterfall, 2: Waterfall lower error, 3: Agile, 4: Agile higher error
® incremental errors from undiscovered rework: 1-2-3 -4-
1:
1
Page 9
0.40:
2
1
1,
0.20 2
4
Ww
0.004 r eat — = A
0.00 15.00 30.00 45.00 60.00
Months 10:32 AM Mon, Dec 11, 2006
Naat ? 1: Waterfall, 2:
Modeling Agile Development
Waterfall lower error, 3: Agile, 4: Agile higher error
36
© 2007 by K. Chichakly
Additional Performance Issues
There remain two questions regarding the performance of A gile:
¢ Can the performance be improved by prioritizing rework over original work?
¢ Will performance get worse if one phase’s rework isn’t completed before moving onto
the next phase (something that we saw was disastrous for the waterfall model)?
Surprisingly, prioritizing rework over original work makes little difference to the Agile case as
the rework is already being done relatively quickly (very close to as you go). The four cases
{certain customer requirements: base (1) and prioritized (2), uncertain customer requirements:
base (3) and prioritized (3)] are shown below. Note that there is no noticeable difference in the
project length or cost in any of the cases, though the incremental errors from rework are slightly
higher in the non-prioritized cases.
&® cumulative Person Months: 1- 2-3-4
1: 2004
3—4- ca
Le 12 1—2
4 p
a
L 1004
a
i v4
ca
[1
1: T
0.00 15.00 30.00 45.00 60.00
Page 5 Months 5:21PM Mon, Dec 11, 2006
XN aaF ? 1: Agile, 2: w/prior rework, 3: Agile uncertain, 4: w/prior rework
Ss incremental errors from undiscovered rework: 1-2-3-4-
a 0.304 | |
1: 0.154 | | |
my
2
E
a
IS 3m.
i 0.004 a a p12 I's
0.00 15.00 30.00 45.00 60.00
Page 9 Months 5:21PM Mon, Dec 11, 2006
XN aaF ? 1: Agile, 2: w/prior rework, 3: Agile uncertain, 4: w/prior rework
Modeling Agile Development
37 © 2007 by K. Chichakly
Note that there is a slight advantage to doing this in the waterfall case, bringing the project in one
month sooner at a lower cost with uncertain customer requirements.
&® cumulative Person Months: 1-2-3 -4
z 300% 3
4
1: 1504
*
a.
a
lL 0 T T T 1
0.00 15.00 30.00 45.00 60.00
Page 5 Months 5:35 PM Mon, Dec 11, 2006
XN aaF ? 1: Waterfall, 2: w/prior rework, 3: Waterfall uncertain, 4: w/prior rework
In this case, the incremental errors effect is also noticeably lower when fixing rework has top
priority.
® incremental errors from undiscovered rework: 1-2-3- 4
1 0.604
|
ns
2.
3,
L: 0.00 Bias? a plate
0.00 15.00 30.00 45.00 60.00
Page 9 Months 5:35 PM Mon, Dec 11, 2006
XN 3aaF ? 1: Agile, 2: w/prior rework, 3: Agile uncertain, 4: w/prior rework
With regards to the second question, there is no change in performance if the release quality
threshold is lowered because original work is constraining the end of the phase in the base case.
However, if the model is changed to give priority to original work and the quality threshold is
lowered from 0.99 to 0.9 (i.e., the end of phase threshold for Rework To Do is raised from 0.01
of original work to 0.1 of original work), there are some very surprising results. The project
actually finishes almost two months sooner! In the following graphs, the first curve (blue) is the
base case with uncertain customer requirements, the second curve (red) is the same case with
priority given to original work, and the final curve (magenta) lowers the quality threshold.
Modeling Agile Development 38 © 2007 by K. Chichakly
I cauivatent staff: 1-2-3
1: 10.04 |
‘a: 5.04
1: 0.0
0.00 10.00 20.00 30.00 40.00
Page 2 Months 6:15PM Mon, Dec 11, 2006
Naesé 2? 1: Agile uncertain, 2: worig prior, 3: wilower quality
As expected, the error fraction is higher due to a additional backlog of Undiscovered Rework and
Rework to Do (as well as that bump of new hires, which also brings productivity down some).
Ss error fraction: 1-2-3
1
0.554
‘a: 0.3044
1,
i=—3—3} +—a--3
1: 0.05: T T
0.00 15.00 30.00 45.00 60.00
Page 6 Months 6:15PM Mon, Dec 11, 2006
XN aaF ? 1: Agile uncertain, 2: worig prior, 3: wilower quality
Modeling Agile Development
© 2007 by K. Chichakly
® undiscovered Rework: 1-2-3
a 54
1 0 lr}. pit}.
0.00 15.00 30.00 45.00 60.00
Page 7 Months 6:15PM Mon, Dec 11, 2006
XN aaF ? 1: Agile uncertain, 2: wiorig prior, 3: w/lower quality
The explanation for the earlier finish comes from precedence effects on productivity. Because
original work is being given priority and assigned at the highest possible level, there are no
precedence effects on original work. Any precedence effects on rework are caused by idle time
while waiting for more rework to be discovered. As shown in curve 2 below (original work
priority), the initial high quality standard causes productivity delays at the end of each phase.
However, in the third curve, the next phase is started before the rework in the current phase is
completed (or even completely discovered). Therefore, the delays in discovering rework do not
occur (and precedence constraints do not apply) until the end of the project when there is still the
desire to deliver a final quality product. Note in this last case that the precedence effects on
productivity stay at one until the very end of the project. The additional (and consistent)
productivity is what causes the project to finish earlier than the base case.
Note there is considerably more rework generated in this case, but the cost is only marginally
higher (4% - due to the better productivity on average and the early finish).
&® estect on productivity from precedence: 1-2-3-
1 1.054
}1—2—3: 1277-3
}-1—2—3.
1—2—3
a: 0.604
1
0.15:
0.00
Page 12
Naat ?
Modeling Agile Development
15.00
30.00
Months
45.00
60.00
6:33 PM Mon, Dec 11, 2006
1: Agile uncertain, 2: worig prior, 3: w/lower quality
© 2007 by K. Chichakly
&® otal Rework Generated: 1-2-3
at 404 3 3
1: 0
0.00 15.00 30.00 45.00 60.00
Page 11 Months 6:33 PM Mon, Dec 11, 2006
XN aaF ? 1: Agile uncertain, 2: wiorig prior, 3: w/lower quality
® cumulative Person Months: 1-2-3
1 200%
—j—3. =
Ve 1: 1:
2
1
1 1004 ?
| 3
-
Lx
Lh 0
0.00 15.00 30.00 45.00 60.00
Page 5 Months 6:33 PM Mon, Dec 11, 2006
XN aaF ? 1: Agile uncertain, 2: wiorig prior, 3: w/lower quality
This model does not explore the corporate level issues of reducing quality this much. I do not
believe the small time savings to be worth the risk at 90% quality. Sensitivity tests below,
though, show the benefits saturate at the 92% level and a substantial benefit at the 98% level
(about a month) with no change in cost. This small reduction in quality between phases is
probably acceptable for many projects.
Modeling Agile Development 41 © 2007 by K. Chichakly
S® cauivalent Staff: 1-2-3-4
at 8.09
1 0.0 " y Pi
0.00 7.50 15.00 22.50 30.00
Months 8:54PM Mon, Dec 11, 2006
Quality - 1: Base - 99%, 2: 98%, 3: 95%, 4: 92%
@ effect on productivity from precedence: 1-2-3-4
1 1.00-4-1—2— 34 123-4 12 4 1
2
3]
L 0.604
L 0.20 " r 1
0.00 7.50 15.00 22.50 30.00
Page 12 Months 8:54PM Mon, Dec 11, 2006
XN aaF ? Quality - 1: Base - 99%, 2: 98%, 3: 95%, 4: 92%
The graph of rework generated below gives an idea of the overall impact on errors-on-errors of
the various quality levels. The incremental errors from rework are shown after that. Note that
all levels of quality have the same errors-on-errors effect in the first phase. This is a
consequence of the change to giving priority to original work. In subsequent phases, though,
higher quality leads to lower incremental errors.
Modeling Agile Development 42 © 2007 by K. Chichakly
@ Total Rework Generated: 1-2-3-4-
1 304
L
00 30.00 45.00 60.00
Page 11 Months 8:54PM Mon, Dec 11, 2006
XN aaF ? Quality - 1: Base - 99%, 2: 98%, 3: 95%, 4: 92%
® incremental errors from undiscovered rework: 1- 2-3-4
1 0.244
aN
yf 4
+2
L 0.124
1
a
4 2K
2
Nee ele
L 0.00 r r , Sy seme
0.00 7.50 15.00 22.50 30.00
Page 9 Months 8:54PM Mon, Dec 11, 2006
XN aaF ? Quality - 1: Base - 99%, 2: 98%, 3: 95%, 4: 92%
It is interesting to note that giving original work priority in the waterfall case is extremely
deleterious to the project’s completion (shown below - curve one is the waterfall base case with
uncertain requirements, curve two gives priority to original work, and curve three gives priority
to rework). Note also that giving priority to rework does not help as much as might have been
anticipated (the no priority algorithm in place tends to already favor rework a bit).
Modeling Agile Development 43 © 2007 by K. Chichakly
SD equivalent Staff: 1-2-3
L 20.0—
7 1
L 10.04
3 es
ae -
ee 2
Sa
=
L 0.0 ‘ r " SS 1
0.00 12.50 25.00 37.50 50.00
Page 2 Months 9:08 PM Mon, Dec 11, 2006
Nea
® incremental errors from undiscovered
1 0.70%
1 0.354
ie
—
rework: 1-2-3
: Waterfall uncertain, 2: w/orig prior, 3: w/rework prior
A
1.
3
1 0.00: 1
0.00 15.00 30.00 45.00 60.00
Page 9 Months 9:14PM Mon, Dec 11, 2006
Modeling Agile Development
1: Waterfall uncertain, 2: w/orig prior, 3: w/rework prior
44
© 2007 by K. Chichakly
Summary
In summary, Agile methods do not appear to make a difference with a consistent mission. Both
the finish time and the cost are approximately the same despite the lower normal productivity in
Agile. This, of course, means that if there is a danger of not being able to control these
parameters, or if there is reason to believe the Agile parameters are worse than used in this
model, that managers should stick to the waterfall model for consistent missions. Additional
support for this course of action can be found in the cost of switching (there isn’t any benefit to
switch and it will be worse before it is back to the same again, so why do it?).
When there is an inconsistent mission, Agile methods can win out over waterfall methods -
again, assuming you have already adopted the methodology and fought your way through the
worse-before-better startup transition. There are, however, cases where even this may be risky.
As shown in the table in the middle of page 27, if your organization’s error fraction and
productivity under A gile fall just a little short of the values used in this model, Agile will begin
to cost more. It also very quickly begins to cost a lot more.
Finally, when there is both an inconsistent mission and uncertain customer requirements, A gile is
pretty much guaranteed to meet or beat the waterfall method, which was its main goal when it
was developed. As shown in the table at the bottom of page 27, your organization’s parameters
under Agile have to be the same or worse than those for waterfall in order to tum out worse in
either cost or project length. This is not likely except under the initial transition of switching to
Agile.
In conclusion, the ideas behind Agile do indeed help projects come in earlier when there are
changing customer requirements. The combination of frequent releases to, and interactions with,
customers, nightly builds and automated tests, writing tests before code, and avoiding
unnecessary complexity all work together to allow the project to adapt more easily to changing
conditions.
References
Beck, K, et al. 2001. Manifesto for Agile Software Development,
http://www.agilemanifesto.org
Cockbum, A. 2004. Crystal Clear: A Human-Powered Methodology for Small Teams. A ddison-
Wesley: Boston, MA.
Lyneis JM. 2006. Project Dynamics. Lecture notes, Worcester Polytechnic Institute: W orcester,
MA
Modeling Agile Development 45 © 2007 by K. Chichakly
Appendix: Model Structure
FF]
Rework Cycle
project finished
recedence
seen switch
switch
maximum work rte
based on tasks
‘on original work
effect on productivity
from available tasks
7 maximum work i ee
potential work rate
(on original work
productivity before
precedence effects,
Staff on
available effect of overtime
Hise stove Original Work
Productivity on productivity
oribeneuet max work rate based
toibe done average task on original work Siig vote
duration accomplishment
lasks available new work to do [ pital sore th do
towork on this phase enenmatten aiid work dies
Original comects
Work to Do rework
“art new phase “ework generation [accomplishment project Finished
(on original work WaeBens ween
total tasks that could adding work
error fractlon rework done
be worked on rrontac Cealen Previous Work Done
fork to do. Rework to Do Undiscovered
Rework
this phase rework generation
on rework
alle switch
start new phase
rework
fraction of tasks maximum time to_ total work believ ec
iscov
available to work on discover rework ” ta be done
jisnneess NS time to discover rework
minimum time to fraction realy
Phases” automated tests Se rework complete Undtecoverea
effect of work poms Rework
work believed
work to de to be done
a” phase
fraction percelved
to be complete
Modeling Agile Development 46 © 2007 by K. Chichakly
oo
Staff Adjustment
excess experienced Staff
willingness t6
‘ransfer\fire
average time
0 transfer\fire
Vary staff switch
Experienced Staff
©.
‘én stafMleaving
initial new staff
Excess new staff excess stat initial experienced staff
initial scheduled
Tertsiat completion date
willingness to hire
intial scheduled
vary staff switch completion
start new phase
Newptart
staff leaving
time to gain
experience
otal Staff
effect of experience effect of experience
onerrorfraction on productivity
experience dilution
relative productivity
of new staff
New Stat agile Switch
incremental error fraction
of experienced staff incremental error fraction
of new staff
gaining/experience
Ehange schedule
hiring
average time
extra staff needed to hire
Effective Staff
if ha jotal staff needed
phases
scheduled
completion date
aot mime
total staff needée
based on effort and
time remaining
raximum total
one ow
total staff needed
based on max work rate weight on progress
based estimates
project finished
switch
Cumulative
Person Months
estimated
productivity estimated etfor™ ~Tollow budget fraction perceived
f remaining switch to be conplete
effect on productivity
fromavailable tasks | est effort Ti iat effort
based on progress remaining
nM a esa
project finished
productivity ark
switch
weighted work
left to do
estimated
total work believed work todo rework
to be done this phase fraction,
doing work
Modeling Agile Development
47 © 2007 by K. Chichakly
Rework Calculations 8
Total Staff. Stat on
Original Work rework priority
project finished Equivalent Staff 10 priority
switch ma Original work priority
ee
Staff on Rework, potential work
maximum wot te
yate on rework
on origingf work
\ Original
fraction of effort productivity before productivity
to rework precedence effects on rework Workcte Do
rdhstyacciticg productivity before
max Srum:woik: catitaal ao precedence effects ie
rate on rework ccomnlckment — Weiahted work
P left to do
minimum time to relative effort
perform rework required for rework
Rework to Do
Work Metrics 8
yeximumworisrate potential work rate original work
on original work on original work accomplishment
rakinumsiseal potential effect on productivity total work
warersts rk rate from precedence ‘accomplishment
project finished rework
maximum work potential work ‘Switch accomplishment
rate on rework rate on rework
wo 2) Cumulative Metrics 8
original work done FAWSACIARE
correctly correctly Cumulative
Work Done
Cumulative
Rework Done
reworking
rate of doing work
rework generation rework generation
on original work on rework
Total Rework
Generated
generating rework
Modeling Agile Development 48 © 2007 by K. Chichakly
Phase Bookkeeping
Work to De
project finished
‘switch
change latent work
Latent Work in System
Test first Test first switch
- a
agile switch” frequent releasts
frequent release switch
views, reviews switch
Original
start New phas:
Initial
Rework to Do
Undiscovered Rework
Change initial
undiscovered rework
Undiscovere:
Rework Undiscovered Rework
This Phase
issy _kiss switch
jutomated tests
work to di
this ie SS
new work to do
this phase
automated test switch
initial Work to do
_ aa
gile switche
adjusted fraction of
total perceived complete
fraction perceived
to be complete
fraction of total
perceived complete
total work believed
to be done
Uncertain Requirements
jaximum effect of
uncertain customer:
requirements
kiss
uncertainty based
‘on progress freq
fraction perceived
to be conplete
elimination of ———*,
elimination of
uncertainty based
on progress std
frequent releases
‘effect of uncertain
‘customer requirements
uncertain
requirements
switch
Modeling Agile Development
WOE Errors on Errors
maximum error
fraction
effect of uncertain
customer requirements
error fraction pe
errors on
errors switch
normal ertor
fraction effect of schedule
pressure on error fraction
incremental errors from
undiscovered rework
J
fraction of undiscovered
crus nerd
ewotk to 0 }
—
fraction work done
containing errors
Undiscovered
Rework
effect of experience
(on error fraction
effect of overtime
on error fraction
sensitivity of
incremental errors
to past errors
49 © 2007 by K. Chichakly
Schade Pressure 6
of schedule pressure
on error fraction
agile switch
overtime switch
s =<
completion date
_
Initial scheduled
conpletion
indicated completion date
based on progress
estimated effort
remaining Equivalent Staff
antic ua
—_ overrun
completion date
time to perceive
sensitivity for effect
of schedule pressure
on a
project finished As switch
switch agile switch
real schedule
staited new phase
tart new phase
Schedule Sip Fy)
etect of experience productivity before canine
effect of schedule mmypreguctiyin fepcadenee effects: Person Months
pressure on er fraction
schedule pressure” otal prolect
‘switch effect of schedule Gost
-, ‘on productivity. voiel
re ty inpted cost per
ettect of sthedule pressure hontai
‘on error fraction relation Imputed Project Cost
eftectof will ‘pressure i
ere on ra eatin revews
increasing
intial scheduled” imputed cost
completion projct finished
swith
scheduled
completion dal
perceived
completion date
allow schedule sip wilingness
to slip
fraction perceived schedule
to be complete sip switen
es)
Overtime
overtime delay
maximum overtime
om,
indic » overtime
total staff needed
Total Staff
effect of overtime
on error fraction
relation
overtime switch
overtime fractio
7)
effect of overtime
‘on productivity
relation
Effective Staff
maximum effect
of overtime on
error fraction
effect of overtime
on error fraction
effect of overtime
on productivity
maximum effect
effect of fatigue
on productivity
relation
time to develop “fatigue
fatigue
effect of fatigue
‘on error fraction
‘A maximum effect
relation
of fatigue on
maximum effect productiv ity
of fatigue on
effect of fatigue
error fraction
~~ _ on error fraction
effect of fatigue
‘on productivity
of overtime on
productivity
Cumulative Metrics
Cumulative Rework _Done(t) = Cumulative Rework Done(t- dt) + (reworking) * dt
INIT Cumulative_Rework_Done =0 {tasks}
INFLOWS:
reworking = rework_done_correctly + rework_generation_on_rework {tasks/mo}
Modeling Agile Development 50
© 2007 by K. Chichakly
Cumulative _Work_Done(t) = Cumulative Work _Done(t - dt) + (rate_of_doing_work) * dt
INIT Cumulative Work_Done =0 {tasks}
INFLOWS:
rate_of_doing_work = original_work_done_correctly + rework_generation_on_original_work +
rework done_correctly + rework_generation_on_rework {tasks/mo}
Total_Rework_Generated(t) = Total_Rework_Generated(t - dt) + (generating_rework) * dt
INIT Total_Rework_Generated = 0 {tasks}
INFLOWS:
generating_rework = rework _generation_on_original_work + rework_generation_on_rework {tasks/mo}
Errors on Errors
error_fraction = maximum_error fraction - ((maximum_error fraction - normal_error_fraction)*(1 -
incremental_errors_from_undiscovered_rework*errors_on_errors_switch)*(1 -
effect_of_schedule_pressure_on_error_fraction)*(1- effect_of_experience_on_error_fraction)*(1 -
effect_of_uncertain_customer_requirements)*(1 - effect_of_overtime_on_error_fraction)) {dimensionless}
errors_on_errors_switch = 1 {dimensionless}
DOCUMENT: Set to 1 to enable the errors on errors feedback loop. Otherwise, set to zero.
fraction_work_done_containing_errors = IF (total_work_believed_to_be_done =0 OR project_finished_switch)
THEN 0
ELSE (Rework_to_Do + Undiscovered_Rework)/total_work_believed_to_be_done {dimensionless}
incremental_errors_from_undiscovered_rework = (1 -
normal_error_fraction)*fraction_of_undiscovered_errors_incorporated*
sensitivity_of_incremental_errors_to_past_errors {dimensionless}
maximum_error_ fraction = 1 {dimensionless}
normal_error_fraction = IF test_first AND reviews THEN 0.05
ELSE IF test_first OR reviews THEN 0.10
ELSE 0.15 {dimensionless}
sensitivity_of_incremental_errors_to_past_errors = IF kiss THEN 0.8 ELSE 0.9 {dimensionless}
DOCUMENT: Used to scale graphical function "fraction of undiscovered errors incorporated". Normally set
to one for no scaling (range is zero to one).
Decrease sensitivity when including discovered rework in calculation so it is comparable to numbers when
didn't separate discovered rework out.
fraction_of_undiscovered_errors_incorporated = GRAPH(fraction_work_done_containing_errors {dimensionless})
(0.00, 0.00), (0.1, 0.1), (0.2, 0.2), (0.3, 0.3), (0.4, 0.4), (0.5, 0.5), (0.6, 0.6), (0.7, 0.7), (0.8, 0.8),
(0.9, 0.9), (1, 1.00)
Overtime
effect_of_fatigue_on_error fraction =
maximum_effect_of_fatigue_on_error_fraction*effect_of_fatigue_on_error_fraction_relation {dimensionless}
effect_of_fatigue_on_productivity =
maximum_effect_of_fatigue_on_productivity*effect_of_fatigue_on_productivity_relation {dimensionless}
effect_of_overtime_on_error fraction =
maximum_effect_of_overtime_on_error_fraction*effect_of_overtime_on_error fraction_relation +
effect_of_fatigue_on_error_fraction {dimensionless}
DOCUMENT: The fatigue effect from overtime is added in here to create an aggregate effect of overtime.
effect_of_overtime_on_productivity =1 +
maximum_effect__of_overtime_on_productivity*effect_of_overtime_on_productivity_relation +
effect_of_fatigue_on_productivity {dimensionless}
DOCUMENT: The (negative) fatigue effect from overtime is added in here to create an aggregate effect from
overtime. This technically should affect "productivity before effects", but this relies on a subordinate
calculation from this (total staff needed).
Effective_Staff =(1 + overtime_fraction)*Total_Staff {people}
DOCUMENT: Effective number of full-time people working on the project (FTEs).
Modeling Agile Development 51 © 2007 by K. Chichakly
fatigue = SMTH3(overtime_fraction, time_to_develop_fatigue) {dimensionless}
indicated_overtime = IF (Total_Staff <> 0)
THEN MIN(MAX (total_staff_needed - Total_Staff, 0)/Total_Staff, maximum_overtime_allowed)
ELSE 0 {dimensionless}
maximum_effect__of_overtime_on_productivity = 0.5 {dimensionless}
maximum_effect_of_fatigue_on_error_fraction = 0.5 {dimensionless}
maximum_effect_of_fatigue_on_productivity = 0.5 {dimensionless}
maximum_effect_of_overtime_on_error_fraction = 0.3 {dimensionless}
maximum_overtime_allowed = 0.5 {dimensionless}
DOCUMENT: Largest fraction of overtime allowed by management.
overtime_delay = 1 {months}
DOCUMENT: This is short because the reaction to overtime pressure is usually pretty quick.
overtime_fraction = overtime_switch*SMTH3(indicated_overtime, overtime_delay) {dimensionless}
overtime_switch = 0 {dimensionless}
DOCUMENT: Set to one to enable overtime and zero to disable it.
time_to_develop fatigue =6 {months}
effect_of_fatigue_on_error_fraction_relation = GRA PH(fatigue {dimensionless})
(0.00, 0.00), (0.1, 0.02), (0.2, 0.04), (0.3, 0.075), (0.4, 0.12), (0.5, 0.195), (0.6, 0.275), (0.7, 0.365), (0.8, 0.5),
(0.9, 0.72), (1, 1.00)
effect_of_fatigue_on_productivity_relation = GRA PH(fatigue {dimensionless})
(0.00, 0.00), (0.1, -0.01), (0.2, -0.035), (0.3, -0.06), (0.4, -0.105), (0.5, -0.155), (0.6, -0.22),
(0.7, -0.31), (0.8, -0.415), (0.9, -0.61), (1, -1.00)
effect_of_overtime_on_error_fraction_relation = GRA PH(overtime_fraction {dimensionless})
(0.00, 0.00), (0.1, 0.02), (0.2, 0.04), (0.3, 0.075), (0.4, 0.13), (0.5, 0.2), (0.6, 0.295), (0.7, 0.41),
(0.8, 0.56), (0.9, 0.775), (1, 1.00)
effect_of_overtime_on_productivity_relation = GRAPH{(overtime_fraction {dimensionless})
(0.00, 0.00), (0.1, 0.1), (0.2, 0.2), (0.3, 0.3), (0.4, 0.4), (0.5, 0.5), (0.6, 0.6), (0.7, 0.7), (0.8, 0.8),
(0.9, 0.9), (1, 1.00)
DOCUMENT: This is assumed a linear effect. Of course, it won't be, but fatigue will handle this.
Phase Bookkeeping
Initial_Undiscovered_Rework(t) = Initial_Undiscovered_Rework(t - dt) + (change_initial_undiscovered_rework) *
dt
INIT Initial_Undiscovered_Rework = 0 {tasks}
INFLOWS:
change_initial_undiscovered_rework = IF start_new_phase THEN (Undiscovered_Rework -
Initial_Undiscovered_Rework)/DT ELSE 0 {tasks/mo}
Latent_Work_in_System(t) =Latent_Work_in_System(t - dt) + (change_latent_work) * dt
INIT Latent_Work_in_System =0 {tasks}
INFLOWS:
change_latent_work = IF start_new_phase THEN (Original_Work_to_Do + Rework_to_Do +
Undiscovered_Rework - Latent_Work_in_System)/DT ELSE 0 {tasks/mo}
adjusted_fraction_of_total_perceived_complete = IF (agile_switch AND fraction_of_total_perceived_complete +
1/phases < 1)
THEN (1 - fraction_perceived_to_be_ complete) {release excess staff at start of each phase}
ELSE fraction_of_total_perceived_complete
DOCUMENT: Dont let fraction complete exceed 50% until in last phase during agile (otherwise, we let staff
go between phases).
agile_switch = 1 {dimensionless}
DOCUMENT: Set to 1 to enable Agile tests (zero for conventional waterfall).
automated_test_switch = 1 {dimensionless}
DOCUMENT: Set to zero to disabled nightly builds and automated testing (Agile only).
automated_tests = agile_switch AND automated_test_switch {dimensionless}
fraction_of_total_perceived_complete = total_work_helieved_to_be_done/initial_work_to_do {dimensionless}
Modeling Agile Development 52 © 2007 by K. Chichakly
frequent_release_switch = 1 {dimensionless}
DOCUMENT: Set to zero to tum off the effects of frequent releases and customer interactions (Agile and
uncertain customer requirements only).
frequent_releases = agile_switch AND frequent_release_switch {dimensionless}
kiss =agile_switch AND kiss_switch {dimensionless}
kiss_switch = 1 {dimensionless}
DOCUMENT: Set to zero to disable the KISS (Keep It Simple Stupid) effects in agile.
new_work to_do_this phase = initial_work_to_do/phases {tasks}
phases = IF agile_switch THEN 4 ELSE 1 {dimensionless}
reviews =agile_switch AND reviews_switch {dimensionless}
reviews_switch = 1 {dimensionless}
DOCUMENT: Set to zero to disable the effects of design and code reviews, as well as pair programming and
commitment to technical and design excellence (Agile only).
start_new_phase = agile_switch AND (NOT project_finished_switch) AND fraction_of_total_perceived_complete <
0.95 AND Original_Work_to_Do <0.04*work_to_do_this_ phase AND Rework to_Do <
.01*work_to_do_this_phase {dimensionless}
DOCUMENT: We start a new phase if we haven't finished (and aren't close to finishing - within 5%) and we've
finished a significant amount of the original work (at least 96% - numbers down to 90% have little additional
effect) and have met a given standard of quality (less than 1% errors).
test_first = agile_switch AND test_first_switch {dimensionless}
test_first_switch = 1 {dimensionless}
DOCUMENT: Set to zero in Agile to turn off "test first".
Undiscovered_Rework This Phase = MAX (0, Undiscovered_Rework - Initial_Undiscovered_Rework) {tasks}
work _to_do_this phase = new_work_to_do_this phase +Latent_Work_in_System {tasks}
DOCUMENT: All work that must be done this phase (including things we don't know about, such as
undiscovered rework). Note that most of this is known (Undiscovered Rework is marginal), so we use this even
in policy decisions that should only be based on things we know. If we run cases where Undiscovered Rework
becomes larger (unlikely), we will need to separate out another variable for these policies (estimated_work and
start_new_phase).
Rework Calculations
Equivalent_Staff = IF project_finished_switch THEN 0 ELSE Total_Staff {people}
fraction_of_effort_to_rework = MIN(1,
maximum_work_rate_on_rework*relative_effort_required_for_rework/(MAX (0.001,
maximum_work_rate_on_rework*relative_effort_required_for_rework +
maximum_work_rate_on_original_work))) {dimensionless}
maximum_work_rate_on_rework = Rework_to_Do/minimum_time_to_perform_rework {tasks/mo}
minimum_time_to_perform_rework = 0.25 {months}
no_priority = 1 {dimensionless}
DOCUMENT: Set to one to have no priority, i.e., do work as best we can as it comes in (other two priorities
must be zero).
original_work_priority = 0 {dimensionless}
DOCUMENT: Set to one to give original work priority (other two priorities must be zero).
potential_work_rate_on_rework = productivity_on_rework*Staff_on_Rework {tasks/mo}
productivity_on_rework = productivity_before_precedence_effects/relative_effort_required_for rework
{tasks/mo/person}
relative_effort_required_for rework = 1 {dimensionless}
DOCUMENT: This is the effort required to fix problems relative to original work. A value of 1 means the
effort is the same. A value of 0.5 means it takes half the effort while a value of 2 means it takes twice the effort.
rework accomplishment = MIN(potential_work_rate_on_rework, maximum_work_rate_on_rework) {tasks/mo}
rework priority = 0 {dimensionless}
DOCUMENT: Set to one to give rework priority (other two priorities must be zero).
Staff_on_Original_Work = Equivalent_Staff - Staff_on_Rework {people}
Staff_on_Rework =no_priority*fraction_of_effort_to_rework*Equivalent_Staff +
rework _priority*MIN(maximum_work_rate_on_rework/productivity_on_rework, Equivalent_Staff) +
Modeling Agile Development 53 © 2007 by K. Chichakly
original_work_priority*MAX (Equivalent_Staff - maximum_work_rate_on_original_work/
productivity_before_precedence_effects, 0) {people}
weighted_work_left_to_do =Original_Work_to_Do +relative_effort_required_for_rework*Rework_to_Do {tasks}
Rework Cycle
Original_Work_to_Do(t) = Original_Work_to_Do(t- dt) + (adding_work - rework_generation_on_original_work -
original_work_done_correctly) * dt
INIT Original_Work_to_Do =new_work_to_do_this_phase {tasks}
INFLOWS:
adding_work = IF start_new_phase THEN (new_work_to_do_this phase)/DT ELSE 0 {tasks/mo}
OUTFLOWS:
rework _generation_on_original_work = error_fraction* original_work_accomplishment {tasks/mo}
original_work_done_correctly =(1 - error_fraction)*original_work_accomplishment {tasks/mo}
Previous _Work_Done(t) = Previous Work_Done(t - dt) + (shipping_product) * dt
INIT Previous_Work_Done =0 {tasks}
INFLOWS:
shipping_product = IF (start_new_phase OR project_finished_switch) THEN Work_Done/DT ELSE 0 {tasks/mo}
Rework_to_Do(t) = Rework_to_Do(t- dt) +(rework_discovery - rework_generation_on_rework -
rework _done_correctly) * dt
INIT Rework_to_Do =0 {tasks}
INFLOWS:
rework_discovery = Undiscovered_Rework/time_to_discover_rework {tasks/mo}
OUTFLOWS:
rework _generation_on_rework = error_fraction*rework_accomplishment {tasks/mo}
rework done_correctly =(1 - error_fraction)*rework_accomplishment {tasks/mo}
Undiscovered_Rework(t) = Undiscovered_Rework(t - dt) + (rework_generation_on_original_work +
rework _generation_on_rework - rework_discovery) * dt
INIT Undiscovered_Rework = 0 {tasks}
INFLOWS:
rework _generation_on_original_work = error_fraction*original_work_accomplishment {tasks/mo}
rework _generation_on_rework = error_fraction*rework_accomplishment {tasks/mo}
OUTFLOWS:
rework_discovery = Undiscovered_Rework/time_to_discover_rework {tasks/mo}
Work_Done(t) = Work_Done(t - dt) +(original_work_done_correctly + rework_done_correctly - shipping_product)
*dt
INIT Work_Done =0 {tasks}
INFLOWS:
original_work_done_correctly =(1 - error_fraction)*original_work_accomplishment {tasks/mo}
rework done_correctly =(1 - error_fraction)*rework_accomplishment {tasks/mo}
OUTFLOWS:
shipping_product = IF (start_new_phase OR project_finished_switch) THEN Work_Done/DT ELSE 0 {tasks/mo}
average_task_duration = 1 {mo}
effect_on_productivity_from_available_tasks = IF (project_finished_switch OR
potential_work_rate_on_original_work = 0) THEN 1 ELSE MIN(1,
maximum_work_rate_on_original_work/potential_work_rate_on_original_work) {dimensionless}
fraction_perceived_to_be complete = work _believed_to_be done/work_to_do_this_phase {dimensionless}
fraction_really_complete = Work_Done/work_to_do_this_phase {dimensionless}
initial_work_to_do = 100 {tasks}
max_work_rate_based_on_original_work = Original_Work_to_Do/average_task_duration {tasks/mo}
maximum_time_to_discover_rework =IF automated_tests THEN 12/phases ELSE 12 {mo}
Modeling Agile Development 54 © 2007 by K. Chichakly
DOCUMENT: Although it is true there may be rework that shows up later than specified here, if we do not
divide the rework discovery between the phases, we cannot reasonably compare projects completed in one
phase to projects completed in a number of phases. It therefore behooves shorter projects to take steps to ensure
that the rework discovery delay is shortened (which Agile does, so we are safe). Project that don't can be
modeled by removing the division (the result is disaastrous when the rework delay is larger than the scheduled
project).
NOTE: Added automated tests switch to control including division or not.
maximum_work_rate_based_on_tasks_available = tasks_available_to_work_on/average_task_duration {tasks/mo}
maximum_work_rate_on_original_work = IF precedence_switch
THEN maximum_work_rate_based_on_tasks_ available
ELSE max_work_rate_based_on_original_work {tasks/mo}
minimum_time_to_discover_rework = 0.25 {mo}
original_work_accomplishment = productivity*Staff_on_Original_Work {tasks/mo}
potential_work_rate_on_original_work = productivity_before_precedence_effects* Staff_on_Original_Work
{tasks/mo}
precedence_switch = 1 {dimensionless}
productivity = productivity_before_precedence_effects*effect_on_productivity_from_available_tasks*
effect_of_overtime_on_productivity { tasks/mo/person }
project_finished_switch = IF Work Done + Previous_Work_Done >=initial_work_to_do - 0.4 {epsilon} THEN 1
ELSE 0 {dimensionless}
tasks_available_to_work_on = MAX (total_tasks_that_could_be_worked_on - work_believed_to_be_done -
Rework_to_Do, 0) {tasks}
time_to_discover_rework = effect_of_work_progress*maximum_time_to_discover_rework + (1 -
‘effect of work : progress)*minimum_ time_to_discover_rework {mo}
total tasks that could be worked_on = MIN(1, fraction of tasks available to work on_given progress +
agile. switch*0. 12)*work | to do this ; phase {tasks}
DOCUMENT: We have to bump up task fraction by 0.12 in Agile or we would have no tasks to work on. This
may seem arbitrary, but with a smaller scope there are probably fewer interdependencies (meaning it could
probably be bumped up even more). However, care must be taken on an Agile project to reduce the number of
dependencies as too many will severely limit the number of people on the project (relative to a traditional
project).
total_work_hbelieved_to_be_done = Previous Work_Done + Work Done + Undiscovered_Rework {tasks}
work believed to_ be! done = Work Done + Undiscovered Rework {tasks}
effect. of_ work progress = GRAPH(fraction really | complete {dimensionless})
(0.00, 1.00), (0.1, 1.00), (0.2, 0.95), (0.3, 0.85), (0.4, 0.75), (0.5, 0.6), (0.6, 0.4), (0.7, 0.25), (0.8, 0.15), (0.9,
0.05), (1, 0.00)
fraction_of_tasks_available_to_work_on_given_progress = GRAPH(fraction_perceived_to_be_complete
{dimensionless})
(0.00, 0.1), (0.1, 0.2), (0.2, 0.3), (0.3, 0.4), (0.4, 0.5), (0.5, 0.6), (0.6, 0.7), (0.7, 0.8), (0.8, 0.9),
(0.9, 1.00), (1, 1.00)
Schedule Pressure
anticipated_schedule_overrun = IF project_finished_switch THEN 0 ELSE (perceived_completion_date -
scheduled_completion_date)/MAX (17.5, scheduled_completion_date) {dimensionless}
DOCUMENT: We never divide by less than 17.5 because for short projects (e.g., the first phase of a multi-
phase project), schedule pressure is too severe because of the very early due date (differences as a fraction of
the actual due date are very large).
effect_of_schedule_pressure_on_error fraction = IF schedule_pressure_switch
THEN sensitivity_for_effect_of_schedule_pressure_on_error_fraction*
effect_of_schedule_pressure_on_error_fraction_relation + (1 -
sensitivity_for_effect_of_schedule_pressure_on_error_fraction) - 1
ELSE 0 {dimensionless}
effect_of_schedule_pressure_on_productivity = IF schedule_pressure_switch
Modeling Agile Development 55 © 2007 by K. Chichakly
THEN sensitivity_for_effect_of_schedule_pressure_on_productivity*
effect_of_schedule_pressure_on_productivity_relation + (1 -
sensitivity_for_effect_of_schedule_pressure_on_productivity)
ELSE 1 {dimensionless}
indicated_completion_date_based_on_progress = IF Equivalent_Staff <> 0 THEN TIME +
estimated_effort_remaining/Equivalent_Staff ELSE TIME {months}
normal_productivity =IF test_first AND reviews THEN 0.85
ELSE IF test_first THEN 0.9
ELSE IF reviews THEN 0.95
ELSE 1 {tasks/mo/person}
perceived_completion_date = SMTH1(indicated_completion_date_based_on_progress,
time_to_perceive real_schedule, initial_scheduled_completion) {months}
productivity_before_precedence_effects = normal_productivity*effect_of_schedule_pressure_on_productivity*
effect_of_experience_on_productivity {tasks/mo/person}
schedule_pressure_switch = 1 {dimensionless}
DOCUMENT: Switch to enable schedule pressures on productivity to make up for schedule delays (set to one
to enable and zero to disable).
sensitivity_for_effect_of_schedule_pressure_on_error_fraction = IF overtime_switch THEN 0.5 ELSE IF
agile_switch THEN 0.75 ELSE 1 {dimensionless}
DOCUMENT: Reduce schedule pressure effect if implementing overtime or Agile (give overtime precedence).
sensitivity_for_effect_of_schedule_pressure_on_productivity = IF overtime_switch THEN 0.5 ELSE IF
agile_switch THEN 0.75 ELSE 1 {dimensionless}
DOCUMENT: Reduce schedule pressure effect if implementing overtime or Agile (give overtime precedence).
started_new_phase = DELAY (start_new_phase, DT) {dimensionless}
DOCUMENT: Pulses in the first DT of the new phase (vs. start_new_phase which pulses in the last DT of the
previous phase).
time_to_perceive_real_schedule = IF started_new_phase THEN DT ELSE 1 {months}
DOCUMENT: At the start of each phase, the delay is reset to DT to reinitialize the smooth for this phase. Note
that this only works because it isa SMTH1 (a SMTH3 would require 3*DT to reset) and that it introduces an
artifactual 1 DT delay in the response of schedule pressure (in that one DT, pressure will essentially be
removed). DT is small enough that we do not have to worry about this.
effect_of_schedule_pressure_on_error_fraction_relation = GRA PH{(anticipated_schedule_overrun {dimensionless})
(-0.2, 0.85), (-0.1, 0.97), (-2.78e-017, 1.00), (0.1, 1.03), (0.2, 1.08), (0.3, 1.17), (0.4, 1.25), (0.5, 1.34), (0.6,
1.39), (0.7, 1.40)
effect_of_schedule_pressure_on_productivity_relation = GRAPH(anticipated_schedule_overrun {dimensionless})
(-0.2, 0.85), (-0.1, 0.97), (-2.78e-017, 1.00), (0.1, 1.03), (0.2, 1.08), (0.3, 1.17), (0.4, 1.25), (0.5, 1.34), (0.6,
1.39), (0.7, 1.40)
Schedule Slip
Imputed_Project_Cost(t) = Imputed_Project_Cost(t - dt) + (increasing_imputed_cost) * dt
INIT Imputed_Project_Cost = 0 {person-mo}
INFLOWS:
increasing_imputed_cost = IF (TIME <initial_scheduled_completion) OR project_finished_switch
THEN 0
ELSE imputed_cost_per_month_of_overrun {person-months/month}
imputed_cost_per_month_of_overrun = 10 {person-months/month}
schedule_slip_switch = 0 {dimensionless}
DOCUMENT: Set to 1 to enable schedule slipping (zero to disable).
scheduled_completion_date = initial_scheduled_completion + (perceived_completion_date -
initial_scheduled_completion)*willingness_to_slip*allow_schedule_slip*schedule_slip_switch {months}
Total_Project_Cost = Cumulative Person_Months + Imputed_Project_Cost {person-months}
willingness _to_slip = 1 {dimensionless}
DOCUMENT: Ranges from zero to one. One means slip completely, zero means slip not at all.
allow_schedule_slip = GRAPH(fraction_perceived_to_be_complete {dimensionless})
Modeling Agile Development 56 © 2007 by K. Chichakly
(0.00, 1.00), (0.1, 1.00), (0.2, 1.00), (0.3, 1.00), (0.4, 1.00), (0.5, 1.00), (0.6, 1.00), (0.7, 1.00),
(0.8, 1.00), (0.9, 1.00), (1, 1.00)
DOCUMENT: Controls period over which it is okay to slip project (allows there to be schedule pressure in the
beginning of the project).
Staff Adjustment
Cumulative Person_Months(t) = Cumulative Person_Months(t - dt) + (doing_work) * dt
INIT Cumulative_Person_Months = 0 {person-months}
INFLOWS:
doing_work = IF project_finished_switch THEN 0 ELSE Effective_Staff {person-months/month}
Experienced_Staff(t) = Experienced_Staff(t - dt) + (gaining_experience - staff_leaving) * dt
INIT Experienced_Staff = initial_experienced_staff {people}
INFLOWS:
gaining_experience = New_Staff/time_to_gain_experience
OUTFLOWS:
staff_leaving =IF vary_staff_switch THEN
willingness_to_transfer\fire*excess_experienced_staff/average_time_to_transfer\fire ELSE 0 {people/mo}
DOCUMENT: We remove inexperienced staff before experienced staff.
initial_scheduled_completion(t) = initial_scheduled_completion(t - dt) + (change_schedule) * dt
INIT initial_scheduled_completion = initial_scheduled_completion_date/phases {months}
INFLOWS:
change_schedule = IF start_new_phase THEN (TIME + initial_scheduled_completion_date/phases -
initial_scheduled_completion)/DT ELSE 0 {months/mo}
New_Staff(t) =New_Staff(t - dt) + (hiring - gaining_experience - new_staff_leaving) * dt
INIT New_Staff = initial_new_staff {people}
INFLOWS:
hiring = IF vary_staff_switch
THEN willingness _to_hire*extra_staff_needed/average_time_to_hire
ELSE 0 {people}
DOCUMENT: Note we could also add staff by reallocation, but here assume hiring is the worst case.
OUTFLOWS:
gaining_experience = New_Staff/time_to_gain_experience
new_staff_leaving =IF vary_staff_switch THEN
willingness_to_transfer\fire*excess_new_staff/average_time_to_transfer\fire ELSE 0 {people/mo}
average_time_to_hire =4
average_time_to_transfer\fire = 1 {month}
DOCUMENT: Reallocation is usually fairly quick.
budgeted_effort_remaining = (estimated_work/normal_productivity)*(1 - fraction_perceived_to_be_complete)
{person-months}
effect_of_experience_on_error_fraction = IF experience_dilution_switch
THEN (New_Staff*incremental_error_fraction_of_new_staff +
Experienced_Staff*incremental_error_fraction_of_experienced_staff)/(New_Staff + Experienced_Staff)
ELSE 0 {dimensionless}
DOCUMENT: The incremental error fraction based on additional new staff (where fraction is between zero
and one).
Note (New_Staff + Experienced_Staff) is just Total_Staff. This is done to avoid redundancy of data
connections.
effect_of_experience_on_productivity = IF experience_dilution_switch
THEN (New_Staff*relative_productivity_of_new_staff + Experienced_Staff)/(New_Staff + Experienced_Staff)
ELSE 1 {dimensionless}
Modeling Agile Development 57 © 2007 by K. Chichakly
DOCUMENT: The new staff have lower productivity, so are treated as fractional experienced staff. The total
experienced staff equivalents is divided by the total staff to find the fraction of full (experienced) productivity in
effect.
Note (New_Staff + Experienced_Staff) is just Total_Staff. This is done to avoid redundancy of data
connections.
effective_productivity = IF total_work_believed_to_be done =0 OR Cumulative Person_Months =0
THEN normal_productivity
ELSE total_work_believed_to_be_done/Cumulative_Person_Months {tasks/person/month}
DOCUMENT: This is the long-term average productivity.
est_effort_remaining_based_on_progress = IF project_finished_switch THEN 0 ELSE
weighted_work_left_to_do/effective_productivity { person-months }
estimated_effort_remaining = IF follow_budget_switch
THEN budgeted_effort_remaining*(1 - weight_on_progress_based_estimates) +
est_effort_remaining_based_on_progress*weight_on_progress_based_estimates
ELSE est_effort_remaining_based_on_progress {person-months}
estimated_productivity = effective_productivity/effect_on_productivity_from_available_tasks {tasks/mo/person}
DOCUMENT: Divide by effective productivity based on tasks remaining to reduce averse effects at end of
project cycle.
estimated_rework fraction = 0.4
DOCUMENT: The estimated total rework that will be done over the course of the project as a fraction of the
original work.
estimated_work =(1 + estimated_rework_fraction)*work_to_do_this_phase {tasks}
excess_experienced_staff = MAX (0, excess_staff - excess_new_staff) {people}
DOCUMENT: The MAX function isn't strictly necessary here. It is here to guard against errors elsewhere in
the model.
excess_new_staff = MIN(New_Staff, excess_staff) {people}
excess_staff = MAX (0, Total_Staff - total_staff_needed) {people}
experience _dilution_switch = 1 {dimensionless}
DOCUMENT: Set to one to enable experience dilution effects (zero to disable).
extra_staff_needed = MAX (0, MIN(total_staff_needed, maximum_staff_level) - Effective Staff) {people}
follow_budget_switch = 1 {dimensionless}
DOCUMENT: Set to 1 to follow project project with regards to staffing. Set to zero to staff based on progress
and schedule.
incremental_error_fraction_of_experienced_staff = 0 {dimensionless}
DOCUMENT: Fraction of errors generated by the experienced staff above the normal error rate. This will
usually be zero because we would just change the normal error rate otherwise.
incremental_error_fraction_of_new_staff =IF agile switch THEN 0.35 ELSE 0.5 {dimensionless}
DOCUMENT: Fraction more errors generated by new staff than by experienced staff (i.e., new staff error
fraction/experienced staff error fraction - 1).
Improve by 15% for Agile due to short cycles, so easier to jump into a project.
initial_experienced_staff = 4 {people}
initial_new_staff =0 {people}
initial_scheduled_completion_date = 25 {months}
maximum staff_level = 25 {people}
relative_productivity_of_new_staff =IF agile switch THEN 0.65 ELSE 0.5 {dimensionless}
DOCUMENT: New staff productivity as a fraction of experienced staff (i.e., new staff
productivity/experienced staff productivity).
Improve by 15% for Agile due to short cycles, so easier to jump into a project.
time_remaining = MAX(1, scheduled_completion_date - TIME) {months}
DOCUMENT: Automatically extend the schedule one month if we are not yet done. It is fairly typical to
change the date in these cases and we do not want a zero result here. Note this is the time left to when we hope
to finish the project.
time_to_gain_experience = 24 {months}
Modeling Agile Development 58 © 2007 by K. Chichakly
DOCUMENT: Time to gain experience overall (should be shorter for just this project).
Total_Staff = New_Staff + Experienced_Staff {people}
total_staff_needed = MIN(total_staff_needed_based_on_effort_and_time_remaining,
total_staff_needed_based_on_max_work rate) {people}
total_staff_needed_based_on_effort_and_time_remaining = estimated_effort_remaining/time_remaining {people}
total_staff_needed_based_on_max_work_rate = IF project_finished_switch THEN 0 ELSE
maximum_total_work_rate/estimated_productivity {people}
vary_staff_switch =1
DOCUMENT: Switch to enable staff to vary to make up for schedule delays (set to one to enable and zero to
disable).
This also controls the letting go of people at the end of a project.
willingness _to_hire = 1
DOCUMENT: Varied between zero and one. Zero means we are not willing to hire anyone no matter what
happens to the schedule (setting it to zero has the same effect as setting vary_staff_switch to zero). One means
hire as required to meet the schedule. A value in-between allows some hiring to take place. In this case, it is
treated as the fraction of needed hires we are willing to hire at any point.
weight_on_progress_based_estimates = GRAPH(fraction_perceived_to_be complete {dimensionless})
(0.00, 0.00), (0.1, 0.00), (0.2, 0.00), (0.3, 0.1), (0.4, 0.25), (0.5, 0.5), (0.6, 0.75), (0.7, 0.9), (0.8, 1.00), (0.9,
1.00), (1, 1.00)
willingness_to_transfer\fire = GRAPH(adjusted_fraction_of_total_perceived_complete {dimensionless})
(0.00, 0.00), (0.1, 0.00), (0.2, 0.00), (0.3, 0.00), (0.4, 0.00), (0.5, 0.00), (0.6, 0.00), (0.7, 0.1), (0.8, 0.5), (0.9,
0.9), (1, 1.00)
Uncertain Requirements
effect_of_uncertain_customer_requirements = IF frequent_releases
THEN uncertain_requirements_switch*maximum_effect_of_uncertain_customer_requirements*(1 -
elimination_of_uncertainty_based_on_progress_freq)
ELSE uncertain_requirements_switch*maximum_effect_of_uncertain_customer_requirements*(1 -
elimination_of_uncertainty_based_on_progress_std) {dimensionless}
maximum_effect_of_uncertain_customer_requirements = IF kiss THEN 0.15 ELSE 0.2 {dimensionless}
uncertain_requirements_switch = 0 {dimensionless}
DOCUMENT: Set to 1 to enable the effect of uncertain customer requirements on errors (and zero to disable).
elimination_of_uncertainty_based_on_progress_freq = GRAPH(fraction_perceived_to_be_complete
{dimensionless})
(0.00, 0.495), (0.1, 0.5), (0.2, 0.52), (0.3, 0.545), (0.4, 0.58), (0.5, 0.615), (0.6, 0.675), (0.7, 0.775), (0.8, 0.895),
(0.9, 0.96), (1, 0.995)
elimination_of_uncertainty_based_on_progress_std = GRA PH(fraction_perceived_to_be_complete
{dimensionless})
(0.00, 0.00), (0.1, 0.00), (0.2, 0.00), (0.3, 0.00), (0.4, 0.00), (0.5, 0.00), (0.6, 0.1), (0.7, 0.3), (0.8, 0.6), (0.9,
0.85), (1, 1.00)
Work Metrics
effect_on_productivity_from_precedence = IF project_finished_switch THEN 1 ELSE
total_work_accomplishment/potential_work_rate {dimensionless}
maximum_total_work_rate = maximum_work_rate_on_original_work + maximum_work_rate_on_rework
{tasks/mo}
potential_work_rate = potential_work_rate_on_original_work + potential_work_rate_on_rework {tasks/mo}
total_work_accomplishment = original_work_accomplishment + rework_accomplishment {tasks/mo }
Modeling Agile Development 59 © 2007 by K. Chichakly
