Get certified - Transform your world of work today


The Agile Theory of General Relativity

25 July 2013

Steve VanArsdale
VanArsdale & Associates

Agile has a Manifesto. It's about time we had a universal truth. 
"The results of [a] previous investigation lead to a very interesting conclusion, which is here to be deduced" ("Does the Inertia of a Body Depend Upon Its Energy-Content?" by A. Einstein). It's been shown in previous investigations throughout the Web that in Agile projects, story points are obtained over a progression of time with a relatively steady flow of money spent. What is intuitively clear is that there is therefore a predictable relationship.
If we imagine one factor is the cumulative duration of all the project timeboxes, and a second factor is the progressive expenditure that ultimately funds the work, then we can posit a third factor that represents the work being delivered.
TB can be the factor for the timebox for an iteration.
The sum of the time-boxes, or ∑TB, is the total time value for the project as whole.
The agile funding pool, or $AGILE, can represent the total amount of money allocated to pay for the stories (value) to be delivered. 
The value delivered in an Agile project is delivered and accepted at the end of each iteration, and it 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 value of the project effort. This could be represented by ∑v N.
In other words, over time the total duration of timeboxes expressed as ∑TB, plus the funding pool used for development over this duration as $AGILE, ultimately suggests there is a sum of the values in the iterations, ∑v N.
This represents the Agile elements, and it will be shown that these elements form the basis of the relationship of Agile to the fundamental concept of defined-process projects. 

From this equation it directly follows that:

If TB is the timebox for an iteration, then the sum of the timeboxes, or ∑TB, is the timebox for the project as whole. This has been called T and corresponds to time.
The agile funding pool, or $AGILE, is the amount of money allocated to pay for the stories (value) to be delivered. To the client, this is known as cost -- in this context often labeled as C.
The value delivered in an Agile project is delivered and accepted at the end of each iteration. To the stakeholders, each deliverable story includes more than simply effort, and more than simply the value to the product owner. The "value" that is expected and accepted includes the feature or features that meet the client requirement, the specific aspects that make it useful, as well as the general fit of the deliverable in appearance and functionality. In actual fact, it also inherently includes the technical mechanism, the risk of the technical and functional approach used, the effort and/or cost necessary to support the deliverable over its useful life, and even the necessary administrative cost to deploy the deliverable. This is all implicitly included in the value accepted at the end of the iteration. Collectively, over the life of the project, the cumulative "values" delivered and accepted represent the total work or value of the project effort. In the greater context of the stakeholders' project expectations, this is the scope, and is often labeled as S.
Together, these represent a special relationship in all projects. It is often expressed in these terms as "time, cost, and scope," or T+C=S. This relationship is graphically expressed as three intersecting vectors, constrained at their intersections (often called a triangle). There is a well-known rule about triangles. Specifically, with appreciation to Pythagoras, a2 + b2 = c2. Recognizing T+C=S with the rigor of a2 + b2 = c2 while accepting the derivation of the three similar Agile factors ∑TB and $AGILE and ∑v N, and applying the transitive relation "A=B and B=C then A=C," yields a recognition of ∑TB + $AGILE = ∑v N with equal proof.
A small mental experiment illustrates: Time is considered a steady progressive vector. There is little argument on this. Time is a fundamental project dimension in both Agile and defined-process projects. Time can be marked in time periods or in timeboxes but is generally agreed to be linear and is depicted in project graphics and Agile information radiators as a straight line with a steady cadence.
Cost is also typically depicted as a steady line. But as we know from our own personal experience, this is a simplifying assumption. Expenditures are observed to be made in incremental steps.
For planning and progress tracking purposes, however, cost is most often established in budgets and allocated to a project as a single number, whether as a budget or as an Agile iteration funding pool.
Likewise value, or scope, is also most often mapped as a steady progression as indicated on the triangle. However, similar to the cost, it is also readily recognized that progress on the scope is not steady but more often an incremental progression. 
The Agile method can therefore be considered a method of incremental but iterative "progressive elaboration" of scope/value.
In other words, 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 arguably applied to all project efforts for hundreds, if not 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 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 only by the sum of the time-boxes and the size of the funding pool.   
v N  = ∑TB + $AGILE
With appreciation to:
A. Einstein

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 0 (0 ratings)


Bhoodev Singh, CSP,CSM,CSPO, 7/25/2013 3:18:07 AM
I should laugh too :-)To succeed in agile projects every SM should have smile trait. Interesting, thanks for sharing.
Glen Wang, CSM, 7/25/2013 10:18:53 PM
Good to link Agile with Relativity!
Steve VanArsdale, CSM, 8/30/2013 10:23:36 AM
Thanks, Gentlemen. While the article is light-hearted, the proof is important. It says that the myth that project management does not apply to Agile is just that, a myth at best, a self-serving scam in the worst cases. Like all professionals working with OPM (other people's money) we agilists bear a responsibility greater than simply delivering something at the end of a sprint. We embrace the product vision, deliver the product owner's deliverables rather than our own, and commit to the schedule AND the budget. And we self-manage... a huge benefit, but an equally huge responsibility. That's why we don't shun the project manager and project management. A true professional Agilist collaborates. Because the Iron Triangle is still the Triple Constraint.
Be well.
Steve V.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.