This presentation stipulates that there is a defined ratio of Scope Creep above which Agile approaches lose their edge and become less efficient than methodologies that favor significant Upfront planning and freezing of total work to do.
Raspberry Pi 5: Challenges and Solutions in Bringing up an OpenGL/Vulkan Driv...
Agile scope creep and the Golden Ratio – Balancing Project Flexibility and Controllability
1. Agile Scope Creep and the Golden Ratio –
Balancing Project Flexibility and Controllability
Copyrights (c) 2011-2013 Pragmatic
Cohesion Consulting
1
2. Responsiveness (Flexibility) Vs
Robustness (Controllability)
• In the history of software development, a struggle has
existed between building a Responsive Software
product and building a Robust Software product
[Rosenberg, Stephens, Collins-Cope].
• A Responsive software product is capable of quickly
reacting to changes in software requirements while
being developed; it is often the prime attribute of
adopting agile methodologies.
• The potential drawback of high responsiveness is the
loss of robustness when reacting quickly also
introduces undetected defects in the software.
Copyrights (c) 2011-2013 Pragmatic
Cohesion Consulting
2
3. Responsiveness (Flexibility) Vs
Robustness (Controllability)
• A Robust software is designed with a lot of care and
upfront considerations so that the software overall
architecture remains resilient to changing or new
requirements.
• The potential drawback of high robustness is the loss of
agility due to a slower pace of development as more
time is usually spent up front putting in place risk
mitigating measures such as: requirements gathering
and analysis tasks, Requirements traceability matrices,
design documents, unit tests, customer acceptance
tests, defect tracking software, etc…
Copyrights (c) 2011-2013 Pragmatic
Cohesion Consulting
3
4. Scope Creep
• Scope creep is a deviation from an initially agreed-
upon set of requirements that the software
development team must implement.
• This presentation does not consider scope creep a “bad
thing” by default unless it goes above a given threshold
that we are going to determine later on.
• Responsive software development or Agile
development responds better to moderate scope creep
since one of Agile’s main attributes is its ability to
quickly adapt to new or changing requirements.
Copyrights (c) 2011-2013 Pragmatic
Cohesion Consulting
4
5. The Limits of Agility (Flexibility)
• Agile software development is now most favored within the
industry. It is considered much more effective than
methodologies that promote Robustness via significant
upfront planning and freezing of requirements with more
analysis and perhaps more design activities upfront.
• This presentation stipulates that there is a defined ratio of
Scope Creep above which Agile approaches (Flexibility) lose
their edge and become less efficient than methodologies
that favor significant Upfront planning and freezing of total
work to do (Controllability).
• This threshold ratio is the famous Golden Ratio!
Copyrights (c) 2011-2013 Pragmatic
Cohesion Consulting
5
6. The Limits of Agility (Flexibility)
• The presentation demonstrates that:
– if Tagile is the time required to complete a sprint/iteration
initial amount of work with an ongoing addition of work
throughout the entire sprint/iteration on top of the
starting amount of work
– And if Tupfront is the time required to complete an “initially
planned and frozen” amount of work plus a portion of
work added to the planned one without adding any more
work during the effort
Tagile < Tupfront if AdditionalWork <
𝑰𝒏𝒊𝒕𝒊𝒂𝒍 𝑾𝒐𝒓𝒌
𝑮𝒐𝒍𝒅𝒆𝒏 𝑹𝒂𝒕𝒊𝒐
Copyrights (c) 2011-2013 Pragmatic
Cohesion Consulting
6
7. The Limits of Agility (Flexibility)
• The Scope Creep Rule can be stated as:
– For each unit of work that you complete as part of
an ongoing Agile sprint/iteration effort that starts
with an initially planned amount of work, do not
add more than 62% ( close to 1/GoldenRatio) new
work to your current work, otherwise you would
be done faster if you had first added that
percentage of the initially planned work to the
initial amount of work and then if you had frozen
the total work until all work was fully completed.
Copyrights (c) 2011-2013 Pragmatic
Cohesion Consulting
7
8. What the Scope Creep Rule does not specify
• The Scope Creep Rule:
– Does not specify how you come up with a
measurement of the size of the initial amount of
work.
– Does not specify how you determine the nominal rate
at which your development team completes a unit of
work.
• The following papers are a great references on
ways of sizing software work :
– ”A Complexity Measure based on Requirement
Engineering Document”
– “Agile in an Imperfect World”
Copyrights (c) 2011-2013 Pragmatic
Cohesion Consulting
8
9. Scope Creep in Agile Methodologies
• In Agile methodologies, a partially complete
and manageable enough set of Requirements
is selected for implementation during a Sprint
or Iteration to quickly produce a set of
software functionality that can be presented
to the project sponsor to demonstrate
progress and elicit feedback.
Copyrights (c) 2011-2013 Pragmatic
Cohesion Consulting
9
10. Scope Creep in Agile Methodologies
• Scope Creep in Agile Sprints/Iterations usually
happens because of:
– The identification of additional Requirements very
relevant to the initial set being implemented
– Additional implementation work needed because
the development team better understands the
existing requirements as it works trough them.
Copyrights (c) 2011-2013 Pragmatic
Cohesion Consulting
10
11. Quantifying Scope Creep in Agile
Methodologies (Flexibility)
• Let’s call W the amount of work that was selected
at the beginning of an agile sprint or iteration.
• Let’s call dw the additional amount of work
discovered during the sprint or iteration that
results from:
– The identification of additional Requirements very
relevant to the initial set being implemented.
– And additional implementation work needed because
the development team better understands the
existing requirements as it works trough them.
Copyrights (c) 2011-2013 Pragmatic
Cohesion Consulting
11
12. Quantifying Scope Creep in Agile
Methodologies (Flexibility)
• The ratio dw/W is the relative amount of new
work added per completed unit of existing
work.
• If dw=0 then dw/W=0 so there is 0% new
work
• If dw=W then dw/W= W/W=1 so there is
100% new work
Copyrights (c) 2011-2013 Pragmatic
Cohesion Consulting
12
13. Quantifying Scope Creep in Agile
Methodologies (Flexibility)
• Let P be the overall completion rate if no additional
work is created during the sprint/iteration
• Let Pa = P.(1-dw/W) be the adjusted completion rate
when you have dw additional work.
• If dw=0 then Pa =P.(1-0/W) = P, as expected.
• If dw=1 then Pa =P.(1-W/W) = 0
• Pa = 0 means that if you always end up having the
same amount of remaining work to complete as the
amount you started with, you are constantly working
with no end in sight; it is as though your overall
completion rate is 0.
Copyrights (c) 2011-2013 Pragmatic
Cohesion Consulting
13
14. Quantifying Scope Creep in Agile
Methodologies (Flexibility)
• Another way of understanding why Pa=0 when dw=W:
– Imagine that you are running on a treadmill, if the
treadmill was not moving then after a step or two you
reach the end of the belt and there is nowhere to go past
it. When the treadmill is moving at the same pace as you,
when you complete a step or two, you can still run the
exact same length of belt as the length you just ran.
– From your reference point, your are running and covering
some distance, but from the reference point of someone
standing next to your treadmill you are not moving.
– Pa=0 is how your progress appears to an outside observer
waiting for you to complete the work ahead of you during
a sprint/iteration.
Copyrights (c) 2011-2013 Pragmatic
Cohesion Consulting
14
15. Agile Completion Time with Scope
Creep
• So if you start with W amount of work and
your Scope Creep ratio is dw/W then the time
Tagile it takes you to finish the sprint/iteration
total work is:
Tagile =
𝑊
𝑃𝑎
=
𝑊
𝑃(1−
𝑑𝑤
𝑊
)
=
𝑊2
𝑃(𝑊−𝑑𝑤)
Copyrights (c) 2011-2013 Pragmatic
Cohesion Consulting
15
16. Upfront planning and freezing of total
work
• With Upfront planning and freezing, the
development team spends a lot of efforts
identifying, quantifying and planning the amount
of work needed to complete the implementation
of a set of Requirements.
• It is important to note that if an Agile project
strictly enforces Freezing the Requirements
selected for each sprint/iteration prior to
beginning work, it behaves like the “Upfront
planning and freezing” approach over the scope
of the Sprint/Iteration development work.
Copyrights (c) 2011-2013 Pragmatic
Cohesion Consulting
16
17. Scope Creep in Upfront planning and
freezing of total work
• Scope Creep can also happen in Upfront planning
and freezing of total work.
• In this case, Scope Creep takes the shape of
additional work that will come from new
requirements that the development team is
considering adding to the initially planned set of
Requirements prior to beginning any work.
• In this case no new requirements are added once
planned work begins and until all work is
completed.
Copyrights (c) 2011-2013 Pragmatic
Cohesion Consulting
17
18. Scope Creep in Upfront planning and
freezing of total work
• The important distinction between Agile scope
creep and ‘Upfront planning and freezing” scope
creep is that the former happens during the
iteration/sprint work while the latter happens
before starting the development work.
• Because of this distinction, both approaches
tackle the complexity and risk added by scope
creep differently. The following slides will clarify
this point.
Copyrights (c) 2011-2013 Pragmatic
Cohesion Consulting
18
19. Quantifying Scope Creep in Upfront planning
and freezing of total work (Controllability)
• Let W be an initially planned amount of work
• Let dw be the additional amount of work added to W by
additional requirements
• (W+dw)/W is the ratio of additional work to initial work
• Let P be the overall completion rate of work in Upfront
planning when there are no new additional work.
• Let Pu be the adjusted completion rate in Upfront planning
when dw work is added to W.
• Pu = P.W/(W+dw), Pu decreases as more work is added
upfront because of the added complexity of the total work.
• If dw=0 then Pu = P.W/(W+0) = P.W/W = P
Copyrights (c) 2011-2013 Pragmatic
Cohesion Consulting
19
20. • So if you start with W+dw planned amount of
work, the time Tupfront it takes to complete the
total work is:
Tupfront =
𝑊+𝑑𝑤
𝑃𝑢
=
𝑊+𝑑𝑤
𝑃.𝑊
𝑊+𝑑𝑤
=
𝑊+𝑑𝑤 2
𝑃.𝑊
Copyrights (c) 2011-2013 Pragmatic
Cohesion Consulting
20
Quantifying Scope Creep in Upfront planning
and freezing of total work (Controllability)
21. Comparing Agile Completion Time (Flexibility) to Upfront
planning and freezing Completion Time (Controllability)
• The question is: for a given Scope Creep ratio dw/W, which
approach completes the total amount of work W first?
• We are comparing:
Tagile =
𝑾 𝟐
𝑷(𝑾−𝒅𝒘)
to Tupfront =
𝑾+𝒅𝒘 𝟐
𝑷.𝑾
Copyrights (c) 2011-2013 Pragmatic
Cohesion Consulting
21
22. • Plotting Tagile and Tupfront as functions of dw for W=100 units of work and
P=50 units of work/week gives:
dw=62
Copyrights (c) 2011-2013 Pragmatic
Cohesion Consulting
22
Comparing Agile Completion Time (Flexibility) to Upfront
planning and freezing Completion Time (Controllability)
Flexibility Wins Controllability Wins
23. • The positive analytical solution to:
Tagile =
𝑾 𝟐
𝑷(𝑾−𝒅𝒘)
= Tupfront =
𝑾+𝒅𝒘 𝟐
𝑷.𝑾
Is: dw = 0
and dw =
1
1+ 5
2
W The Golden Ratio =
𝟏+ 𝟓
𝟐
= W/dw
Tagile < Tupfront if AdditionalWork <
𝑰𝒏𝒊𝒕𝒊𝒂𝒍 𝑾𝒐𝒓𝒌
𝑮𝒐𝒍𝒅𝒆𝒏 𝑹𝒂𝒕𝒊𝒐
Copyrights (c) 2011-2013 Pragmatic
Cohesion Consulting
23
Comparing Agile Completion Time (Flexibility) to Upfront
planning and freezing Completion Time (Controllability)
24. Check the Online Illustration
Copyrights (c) 2011-2013 Pragmatic
Cohesion Consulting
24
Illustration is explained in further details at the above link!
25. Copyrights (c) 2011-2013 Pragmatic
Cohesion Consulting
25
Contact didier@pragmaticohesion.com to learn more about
Controlling your Software Delivery Schedule and Cost.
http://pragmaticohesion.com/
Check the Online Illustration