Are You Still Using the Wrong Control Levers in your Agile projects? Part 3: The Iron Triangle vs. The Gang of Four

 

Welcome back! Or, if this is the first time you visit, welcome!

It’s been awhile since I wrote the first two parts in this series about high level project control levers, their use, and abuse. This is the third and final part. In it, we will have a look at two control lever systems, the classic Iron Triangle, and the somewhat less well known Four Lever system from the first edition of Extreme Programming.

First, a brief recapitulation of the first two parts of this series:

In the first part I wrote about how using Cost and Capacity to control an agile software project can trap an organization in a hire and fire cycle that increases project duration and cost.

In the second part, I wrote about how to optimize a project for delivering maximum business value. I also wrote about a common mistake companies do, which will disable the Business Value lever, so it no longer works as intended.

You can read each part, including this one, as a standalone article. To get as complete an understanding as possible, I do recommend you endure the pain of reading all three. I’ve done my best to reduce the pain as much as possible.

The Iron Triangle

The Iron Triangle is the classic set of project constraints: Scope, Duration, Cost. The idea is that if you change any one of these, the other two will also change. The trick is to maintain an optimal balance. If you do that, you will have a successful project.

Quality is considered the result of managing Scope, duration, and Cost. Thus, in this model, Quality is not itself a control lever. It is worth noting that Quality is used more in the meaning fit for purpose, rather than free from defects.

Problem One: The Variable Lockdown Fallacy

A still fairly popular way of screwing both Project Managers and development teams over, is to lock all three variables before the project even begins. That way, it becomes impossible, or at least very difficult, to compensate for even fairly small deviations from the original plan.

Of course, if management locks the steering variables from the start, you can be pretty sure that the original plan is…not very realistic. It will serve as an excellent basis for playing blame games and punishing the innocent though.

Fortunately, this form of abuse seems to be less common than it used to be. I still see it in project descriptions now and then.

Problem Two: Decoupling from Business Value

When used as intended, that is, a set of controls for managing the project, the Iron Triangle works a bit better. There is one rather glaring flaw though:

The Cost, Duration, and Scope controls are decoupled from delivered Business Value!

Wait! What?!

The Iron Triangle model assumes that if the project delivers the agreed Scope, at optimal Cost, and Duration, the project is a success. That is not quite true. I’ll illustrate with two stories:

Story One: Perfect Product, but Not Viable

I worked in my first real development project as a programmer. It was around 1980, and I was sixteen or seventeen years old. It was a combined software/hardware project. There were a couple of hardware people in the project, and I was the one and only programmer. The project was lead by the manager of the marketing department of the company we worked for. He was one of the best project managers I have ever worked for. On top of that, he was a very nice and supportive person. I learned a lot from him.

We did have a time constraint: six months! After that, I would do my military service, and would of course not be available to work on the project.

Judged by Iron Triangle criteria, the project was a resounding success! We finished about a week before my time at the company was up. The software and hardware worked flawlessly together, and the data presentation model I had created exceeded all expectations. Scope - Check! Duration - Check! Cost - Check! Perfect!

Not quite! The day before I left, the manager told me the equipment we had built would be mothballed, and never used. He was very careful to explain why: We had developed a product for internal use at the company. The same week we finished the project, another company released a commercial product that did the same thing. The company decided to use the commercial product instead, because the maintenance costs would be much lower. It was the correct decision to make. I am still, more than forty years later, very grateful that my manager took the time to explain the basis for the decision.

Story Two: Feature Fatigue

Several years ago I got commissioned by a large company to figure out why one of their flagship products didn’t sell nearly as well as expected. It was a big job, and I spent six months traversing the entire production chain end to end, finding out what problems people had, and what solutions they proposed. I also talked to customers who had bought the product, and prospective customers that did not buy the product. The latter group provided vital insights.

I organized the data I collected using The Logical Thinking Process, a set of problem solving tools from the Theory of Constraints (TOC) management paradigm. One afternoon, I sat staring at a Current Reality Tree, a model I had built to give me an overview of the current situation. I was trying to find root causes of known problems, but the pieces didn’t quite fit. Something was missing.

Then it struck me: Feature Fatigue! We had a giant organization set up to crank out new features at maximum velocity, but many features were of interest to only a single customer. This was due to the organization using sales people to collect and prioritize requirements. The sales people often used promises of new features to make a sale: “If you buy now, I’ll make sure your feature request gets top priority.”

The inevitable result was that the application was flooded with junk features. These features may have been of interest to one customer, but to everyone else, they were useless and just made the software clunky and difficult to use.

Thus, delivering the agreed scope actually reduced the value of the product!

Don’t Use Scope as a Proxy for Business Value!

In both stories above, success as measured by the Iron Triangle, did not translate into delivered business value. Why the discrepancy? Because while scope is a perfectly valid thing to measure and control, it is not usable as a proxy for Business Value.

The iron triangle is useful for keeping projects on track, but it is not enough! By itself, it will tell you nothing about whether a project is going in the right direction. It will only tell you whether it is going somewhere, or if it is just burning money while standing still.

Of course, the argument about using vertically sliced requirements in Part 2 holds when using the Iron Triangle too. Your requirements must be vertically sliced, otherwise you can’t measure how much of the Scope that has actually been implemented. If you can’t do that, you won’t know whether you are burning through money too fast, or not. Nor will you have any basis for estimating the duration of the project. Thus, the entire Iron Triangle model collapses.

On the other hand, if you have vertically sliced requirements, and if you keep track of delivered business value, and the revenue you get from it, then the Iron Triangle is useful.

The Gang of Four - The Extreme Programming Way (sort of)

In the First edition of Extreme Programming Explained, Kent Beck described four high level project controls, and how to use them. The controls were Scope, Duration, Cost, and Quality.

An interesting difference from the Iron Triangle, is that while the triangle regards quality as the result of managing Scope, Duration, and Cost correctly, Beck regarded Quality as a very powerful control lever in its own right.

According to Beck, the Quality lever should almost always be pushed up! Higher quality, from a software developer’s perspective, means fewer defects, and code that is decoupled, well written, and easy to work with. The higher the code quality, the faster you can deliver features, and the more fun it is to work with the code. Of course, delivering features faster does bring Cost and Duration down.

It is worth noting that while none of the control levers ensure that delivered features have Business Value, this is handled by the User Story prioritization system that is also part of Extreme Programming. Thus, unlike the Iron Triangle, the XP four lever system is explicitly designed to support a system for maximizing Business Value.

An important idea was that the customer could pick three of the control levers, while the XP team would control the fourth. Since duration and cost were usually more or less fixed, and giving the team control over quality meant they would have the right to deliver hopelessly buggy software, customers usually took control of Duration, Cost, and Quality, and left Scope for the team.

In the second edition of Extreme Programming Explained, Kent Beck and his co-writer Cynthia Andres, did away with the entire system, declared explicitly that Quality is not a control variable, and gave the XP team control of the Scope, as the one and only control variable. Features are still prioritized according to value, so there is a method for delivering Business Value in the second edition too.

Unfortunately, while the first edition of Extreme Programming Explained was very well structured, and provided clear, easy to use advice, the much expanded second edition looks like it was written by a raccoon on speed. The descriptions are fuzzy, it’s incoherent, there is no longer a sense that the pieces fit together in a well designed system for producing software.

Summing up, the Four Lever system has two advantages over the Iron Triangle system:

• It explicitly supports, and is subordinate to, a prioritization system designed to maximize Business Value per time unit.
• It makes explicit that Quality does not just happen. It is a control lever that can be moved by practices such as Pair-Programming, Test-Driven Design, and Continuous Integration. It is also made very clear that Quality should be pushed up, in order to reduce Duration and Cost.

The main disadvantages are:

• There is some risk of abuse. For example, a customer can grab the Scope lever, and use it to overload the project team.
• The original description of the model is in the 1st edition of Extreme Programming Explained, which is out of print. If you want to use the model, you will have to rely on secondary sources, like the Extreme Programming Pocket Guide, by Chromatic, which describe the original version of Extreme Programming.

Coming up: Levers that Work!

If you have followed this article series from the start, you may have noticed that none of the different sets of levers I have described is really good. They are not necessarily incredibly bad, but none of them is what I would pick if I had to run a large, multi-team project or program.

Which levers would I choose, and why? That will be revealed in Part Four: Levers that Work!