Faster, Cheaper, Better

As I work on Implementing Agile Values and Principles, the follow-up book to Understanding Agile Values and Principles (UAVP) (https://www.infoq.com/minibooks/agile-values-principles/), I have been editing out material that, while of some interest, does not really advance the point of this new book. I’ve decided to post this material, bit by bit, here on Medium. This is the first of these.

— — — — — — — — — — — — — — — — — — — — — —

Something I did not talk about in UAVP is whether an Agile approach should be expected to be “faster, cheaper, better” which is what new development approaches have claimed over the years and what many people have wanted and expected when they pursued those new ways of working. My belief is that Agile is not necessarily “faster,” but should be “sooner,” perhaps cheaper, but always better.

“Sooner,” Not Necessarily “Faster”

If you have a full year’s work to do, adopting an Agile approach will not suddenly get that done in 10 months. Look at the situation in terms of when you get something of value that, at least, could be shown to stakeholders even if not put into production. In a traditional phased-sequential approach, you would likely have to wait until the end of the project before you even saw, let alone could use, anything of value. In an Agile approach, you should get some amount of observable value at the end of every iteration, so “sooner” than traditional delivery would occur.

It is left up to stakeholders to decide how many such incremental deliveries of value are enough to put the accumulated results into production. Though they have value sooner, everything they want is not there, but, potentially, enough high value might exist to make it worth putting into production. The goal would be that, when possible, each iteration would offer something of value could be put into production.

All of this, of course, is a business decision which is not controlled by waiting for everything before anything could be used. Value is achieved “sooner” and delivered in highest-priority order. This is a significant change in how a business might currently view planning and structuring new work in releases many months in the future. The Agile way challenges them to think of shorter releases in high-priority order.

Perhaps “Cheaper”

An Agile approach could be, perhaps even should be, “cheaper” because it would save on rework typically encountered in traditional development approaches. That rework is caused by defects, misunderstood requirements, scope creep, and other related requests or needs for change. The Agile approach should, at least, significantly help reduce rework costs due to defects.

While it does not eliminate the desire for changes, the frequent, iterative opportunities for feedback should surface such requests sooner than a traditional development approach since stakeholders see working results early in the release cycle as opposed to waiting until near the end. Change should cost less and be less risky given frequent opportunities to surface such needs.

But Always “Better”

Related to the cases for increased costs in a traditional development approach, an Agile approach should produce better, more satisfactory results because:

a) defects will be discovered earlier, delivering a system more fit for use;

b) the delivered functionality will more clearly meet stakeholder needs at the time of that delivery as well as being more satisfying as a user experience; and,

c) future desires for enhancements should be able to be delivered sooner, less expensively, and with high quality because the existing work has greater intrinsic design integrity making change easier and more reliable.

An Agile approach focuses attention on achieving these aspects of quality.