Wednesday, May 18, 2011

The iron triangle

This is an updated repost of a blog entry I wrote in June 2010 on our internal blog, combined with some material I wrote earlier this week as a result of a good discussion with @duarte_vasco. Enjoy!

An interesting thought occurred to me last Thursday. You all know about the "iron triangle": out of scope, time and quality, you can pick any two. The reason why you can't nail down all three is the unpredictability inherent to software development.

If you have read your Fred Brooks, you know that software is invisible. Walk into a factory and you perceive noise, activity, movement. But walk into a software development office and you perceive silence, inactivity, stillness. A lot of things are happening, a lot of work is being done, but it is invisible to the naked eye. Fred Brooks says in his infamous essay "No Silver Bullet" that software is an abstract construct of interlocking data sets, data item relationships, algorithms and functions. It is "pure thought-stuff, infinitely malleable", complex, changeable, and invisible. These essential and inherent attributes makes software virtually impossible to visualize, model and understand.

Orthodox plan-driven methods attempt to nail down all three parameters. Since quality is the least visible of the parameters, it will be the one that fluctuates. Therefore in a plan-driven project, you set a Quality Manager to "manage" the problem of quality. Unfortunately quality management is a post-facto task; there's nothing much relevant a Quality Manager can do himself to improve the quality of the product. It's not like he's going to go and fix the bugs himself, right? He can try to prioritize change requests and bugs and increase visibility into where the product is. Another problem is that depending on how long your development cycle is i.e. how often you integrate your product and how long the system testing takes, the picture that emerges doesn't show where the product is, but where it was.

In Scrum and other Agile methods, we do it the other way around. We require high quality in a short time and let the scope float. The quality is defined and controlled using automated tests, and the timebox is defined as the maximum time we can keep change out of the project (or even better, as the minimum time needed to make something we can demonstrate and invoice the customer for). But we don't send out the scope to sea to float freely around, oh no! The key is that instead of letting the scope fluctuate randomly, we set a scope manager (actually, let's call him e.g. the Product Owner) to actively manage it. And this must be done ahead of implementation.

You see where this is going? Paradoxically enough, the Product Owner also prioritizes change requests and bugs (read: backlog items) and increases visibility into where the product is going.

So what's the difference between the PO and the QM? The difference is that the QM works in a system based on predictability, while the PO works in a system based on unpredictability. Since software development is fundamentally unpredictable, the QM tries to salvage the product afterwards, while the PO is effectively managing the product one step ahead.

And that, my friends, is it.

1 comment:

  1. GREAT to see you blogging!

    I'd extend your argument to point out that this is just an example of how,in some cases we have to manage something oblique to our goal in order to actually achieve it! The classic example is that by focusing on faster development (shorter iterations) we get better quality. This is the side effect of focusing on less things at a time and getting them to 'done' instead of starting too many things.