steveVanArsdale

The Reason Clarity Matters in Agile

Discussion created by steveVanArsdale on Jan 18, 2014
The Reason That CLARITY Still Matters in Agile Projects
Published 2013 in the CA Clarity PPM Cookbook on Flipboard (courtesy of John George of CA)
 
Agile has a Manifesto. It’s about time Clarity users had a universal truth.  
 
"The results of [a] previous investigation lead to a very interesting conclusion, which is here to be deduced"(1).  
It has been shown in several ‘previous investigations’ that inherent in Agile projects there are story points delivered over a progression of time with a relatively steady flow of money spent.  What is worth considering is the nature of that relationship, and whether it is a predictable relationship.  
 
If we imagine one factor is the cumulative duration of all the sprint time-boxes, 
and a second factor is the progressive expenditure that funds the work,
then we can suggest a third factor... one that represents the work being delivered. 
 
TB can be the factor for the time-box for a sprint, as shown in figure 1
Figure 1:
 
The sum of the time-boxes, or ∑TB is the total time value for the project as whole.
 
The funding pool, or $AGILE can represent the total amount of money allocated to pay for the story points (value) to be delivered.  
 
The value delivered in an Agile project is delivered and accepted at the end of each sprint, and could be represented by v I for any specific iteration. Collectively, over the life of the project, the cumulative value delivered and accepted represents the total work or story point value of the project effort. This could be represented by ∑vN
 
In other words, with the total duration of time-boxes expressed as    ∑TB
combining with the funding pool for development over this duration expressed as   $AGILE
ultimately suggests that will be a sum of the values in the sprints, or  ∑vN
     
The concept here represents three fundamental elements of any Agile project. It can be shown these elements form the relationship of Agile to fundamental concepts of PMBoK defined-process projects.  And what that implies. (the "So What?" of all this)
 
From this premise, three distinct equalities follow: 
Equality 1) if TB is the time-box for an iteration, then the sum of the time-boxes, or ∑TB is the time box for the project as whole.
This has been called T
and corresponds to PMBoK(2)project "Time". 
 
2) Similarly, the Agile funding pool, or $AGILE is the amount allocated to pay for the stories (value) to be delivered.  To the project Sponsors and Client, this is known as Cost.
In this context this is often labeled as C
and corresponds to waterfall project "Cost". 
 
Now for 3), the Scope.
The principles of the Agile Manifesto dictate that the value delivered in an Agile project is delivered and accepted at the end of each sprint. Yet to the stakeholders, each delivered story includes more than simply the effort, and more than simply the relative value to the Product Owner. The value that is accepted includes:
-the feature or features that meet the Client’s requirements, plus,
-the specific aspects that make it useful, as well as
-the general ‘fit’ of the deliverable in appearance and functionality.  In fact, releaseable value also inherently includes the hidden technical mechanism itself, the risk of the technical and functional approach used, the technical debt incurred, the effort and/or cost necessary to deploy it, and even the necessary costs to support and maintain the deliverable over its useful life.  All this is implicitly included in the "value" accepted at the end of an Agile iteration.  Collectively, over the life of the project these cumulative “values” that are delivered and accepted at the end of a sprint represent the total agile value of the project. In the conventional context of the stakeholders’ "expectations", this conforms exactly to the PMBoK(2) Scope, and is often labeled as S.
 
Together, these represent a very special and widely-recognized relationship in all 'defined-process' or "waterfall" projects.
That relationship is most often expressed “Time plus Cost yields Scope”, or T+C=S.
This fundamental relationship is often graphically expressed, as three intersecting lines, connected in a triangle.  If we establish that one of the angles of the triangle is to be a 90-degree right angle, in other words, that two of the factors Time and Cost are rigorously related, then there is a universal rule about such relationships.
Specifically, that rule is the Pythagoren Theorem, specifically, a2 + b2 = c2.   
It recognizes T "plus" C "yields" S in that "side a2 + side b2 = side c2" or that the sum of the square of the two sides must equal the square of the third side.
So. If we have accepted the equivalency of the three Agile factors ∑TB   and   ∑vN  and   $AGILE for time, cost, and scope, the three sides...
...and we apply the transitive rule that   IF A=B   and   B=C    then A=C
...this implies a recognition of  ∑TB + $AGILE > ∑vN  with equal rigor. 
 
Not convinced? 
In the tradition of Albert Einstein, a mental experiment will illustrate:
 
Time is always considered a steady progressive vector. There is little argument on this.  It can be marked in time periods or in time-boxes, but Time can be seen to be a fundamental project dimension in both 'defined-process' and Agile projects. It is generally agreed to be linear, and time is depicted in project graphics and Agile information radiators as a straight line with a steady cadence, as shown here in figure 2.
Figure 2: 
 
Cost is also typically depicted as a straight line. But we know from our own personal experience this is a simplifying assumption.  Expenditures are observed to be made in incremental steps, as shown in figure 3. 
Figure 3: 
 
For project planning and progress tracking purposes, however, cost is most often established in budgets and allocated to a project as a single number, Cost, whether as a defined-process budget, or as an Agile iteration funding pool, is recognized at one time and therefore it is depicted as a straight line.  This is appropriate for our purpose, and our proof.
 
 
Likewise, value, or Scope is also most often mapped as a steady progression as indicated on the triangle. Similar to the Cost, however, it is readily recognized that in waterfall defined-process projects, progress on the scope of work is not typically steady, but more often observed and measured in an incremental “progressive elaboration” (PMBoK(2)) as shown in figure 4.  
 
Figure 4:  
 
However, the whole purpose of the Agile scope or ∑vN  is to be a method of incremental, iterative  “progressive elaboration” of value (PMBoK Scope). Agile projects more rigorously reflect PMBoK progressive elaboration, as shown here in figure 5,
Figure 5  
 
In summary:  Agile projects can be shown to exhibit the same fundamental factors of defined process projects. These fundamental factors are bound by a predictable rule. The rule of T+C=S, often called the “Iron Triangle” or “Triple Constraint”, has applied to all project efforts for dozens and arguably thousands of years.
 
Therefore, because we have shown this special relationship can be applied to Agile projects with the same rigor as applied in all defined-process projects, this can be called the general relativity of Agile to legacy PMBoK “defined-process” project principles. 
 
Specifically: 
”In every project Cost and Time are immutably linked by Scope” or T+C=S
becomes 
“In every Agile project the sum of values in the iterations are constrained by the sum of the time-boxes and the size of the funding pool.    ∑vN  = ∑TB + $AGILE
 
Afterword:    So What?
Well, this deduction simply says that it has been established that there is a relationship between a project’s time, cost, and scope.  If this relationship is expressed as a triangle, then the relationship can be expressed in mathematical terms. We often hear this expressed as T+C=S.  
       While it's presumptious to make a comparison, in at least one way this T+C=S approximation can be compared to the famous Theory of General Relativity when it is expressed as E=mc2.  Although this relationship is most often verbalized as “E equals ‘em’ ‘see’ squared”, instead of being a rigorous mathematical equation, the expression is taken to mean simply that there is a predictable mathematical relationship through which a quantity of energy "E" is related to the multiplication product of some specific amount of mass and the square of the speed of light… or a similarly extraordinarily BIG number.  
      Likewise, the shorthand for the famous PMBoK Triple Constraint is verbalized as “T plus C equals S”. But it actually means “T plus C yields S”  …because we know that although the Triple Constraint is being expressed mathematically, one cannot necessarily calculate time or cost or scope from the other two factors. Indeed, the three factors are typically expressed in different units of measure, and the whole equation would have go through a variety of transformations just to get all three factors into like quantities that could be equated. And even then, as a mathematically-inclined friend politely pointed out, there could be lots of T’s and C’s that yield a specific S.  So the really useful aspect of the Iron Triangle principle of T+C> (“yields”) S is that there is a relationship. Which (thanks to a legendary gentlemen named Pythagoreus who proved that there is a known relationship of T2 + C2 = S2)  is an immutable, inescapable relationship.  Or, in other words, a predictable relationship. The “So What” is simply the fact that there is such a relationship is used somewhere every minute of every day, when one of us explains that when one factor changes, such as time or scope, you can confidently predict that there will absolutely be a corresponding change to one or both the other factors.  This article simply makes the argument that the same thing applies to Agile projects. 
With all that that implies.  
         Because what it implies is that when one uses Clarity or similiar project-measurement tools, one can measure Agile projects like defined-project projects. And one can predict that, just like waterfall projects or nuclear fission, changing one factor or another could result in a uncomfortably large explosion with a Sponsor.   And by monitoring any two of the factors, we can reliably predict when that is going to happen.   And maybe the size of the explosion. 
 
With humble appreciation to:
  Figure 6  
         the legendary good humor of A.Einstein
---------
“Article previously published 2013 in the Berlin Agile Record magazine (August 2013, Issue No. 15, www.agilerecord.com)”
Title: The Agile Theory of General Relativity
Author: Steve VanArsdale, CSM, PMI-ACP
 
 

Outcomes