Measuring Agile Performance with the Agile Triangle

Posted by Vikas Hazrati on Aug 25, 2009

Sections

Process & Practices

Topics

Agile in the Enterprise ,

Best Practices ,

Agile Techniques ,

Programming ,

Agile ,

Measurement

Share |

RELATED Research

Traditional software development teams are supposed to work within the confines of the software 'Iron triangle'. The three sides of the triangle are Scope, Schedule and Cost. Since Agile places a lot of emphasis on quality, it is often considered a dimension which sits at the middle of the triangle. For any project to succeed there is a need to manoeuvre one of the dimensions keeping the others relatively constant. Most Agile teams vary the scope and keep a tab on Cost, Schedule and Quality.

Jim Highsmith suggested that the Iron triangle, imposes a lot of constraints on the flexibility of the Agile teams and suggested an alternate Agile Triangle.

According to Jim,

Many agile teams are now caught in a dilemma. On one hand they are told to be agile, flexible, and adaptable, but on the other they are told to conform to pre-planned traditional Iron Triangle framework of scope, schedule, and cost. In essence they are being told “be flexible in a very small box.” Agile teams are striving to meet one set of goals and managers and executives are measuring against another set.

Jim suggested that the Agile triangle consists of the following vertices

1. Value – to the customer in terms of current releasable product.
2. Quality – continuous delivery of value to the customer in terms of reliable, adaptable product.
3. Constraints - the traditional scope, schedule, and cost.

He suggested that though the constraints are important project parameters but they are not the goal of the project. He added that,

Value and Quality are the goals and constraints may need to be adjusted as the project moves forward to increase customer value. Schedule might still be a fixed constraint, but then scope could be adjusted to deliver the highest value within the schedule constraint.

Jim also suggested that the focus of development should be on the releasable product rather than the implemented scope. Agile teams should ask the question “Does the product have enough capability to release today?” This would help maintain a strategic focus for the product rather than keeping a focus on the detailed requirements.

He admitted that though Value and Quality are difficult to measure as compared to Cost and Schedule, however, focus should be more on measuring value delivered via a releasable product rather than trying to precisely calculate less important things like the constraints of the Agile triangle.

It’s much better to have fuzzy measures of really important things that precise measures of less important things.

Thus, according to Jim, Agile teams should focus on the releasable product rather than getting constrained by the iron triangle. The three vertices of the iron triangle collapse into one vertex of the Agile triangle called constraints. The other vertices i.e. value and quality define the goals, they are of utmost importance to the stakeholders and need more attention.

RelatedVendorContent

Five Key Practices to Agile ALM

Agile Practices to Improve Project Management Organization (PMO) Effectiveness

Agile Maturity Model Applied to Building and Releasing Software

Agile assessments for your team

Agile workshops and training

Related Sponsor

Maximize your business-responsiveness with Mingle. Provide your global development team a shared space that adapts to the way they work.

1. Back to top

   4 Dimensions to rethink

   by Udayan Banerjee

   A rethink is required in 4 dimensions:
   - Project Funding
   - Method of Interaction
   - Definition of Defect
   - Measure of Success
   setandbma.wordpress.com/2008/06/14/agile-adoption/

   Reply

2. Back to top

   Real world

   by Anand H

   Now welcome to the real world. I love Agile and it works but as a consulting company how do I write up a contract for this?

   Reply

3. Back to top

   Re: Real world

   by Michel Löhr

   Well agile contracts do exists. There is even a workshop for this:
   
   www.poppendieck.com/agilecontracts.htm

   Reply