Hard value versus System value of Agile Methods

First a clarification. I’ve used “hard” value as opposed to “system” value in this article, and my definitions are:
“Hard value”: any value that can be or is systematically quantified in terms of money or time and normally focus on details (e.g. the value of TDD, the value of incremental development).
“System value”: any value that can be quantified after the fact but is mostly subjective and understood when the whole picture is taken into consideration (e.g. the value of Agile in a software development project/organization).
“System value” is characterized by the fact that it cannot be quantified by looking at any of items in a system without understanding how that item interacts with all other items in the same system, i.e. the “system value” approach assumes that you cannot understand the “system value” of TDD without considering how it interacts with other practices, principles and values in the Agile system (e.g. how TDD interacts with Unit Testing and Continuous Integration).

Now for the real post:
In a recent series of posts (1,2,3) Dave Nicolette argued for a roadmap to assess the hard value of Agile, even more recently he described some studies that try to measure TDD/Pair Programming in “money terms” like productivity.

I think that his effort is commendable and I’ve also been devoting a lot of time to the question “why does Agile work?” and scientific evidence regarding that question.

However, I’d like to caution ourselves. Agile represents a new way of developing software that builds on a lot of shared experiences (failed and successful) in our community. Trying to pin down “every cent” of productivity for each of the different practices in Agile should not be the main goal for us as a community, even for those that want to “cross the chasm“.

Agile Methods inherit an ecosystem (I like that word!) of values, principles and practices. Values and principles should always be present and guide the adoption of practices.

The practices per se do not yield any more value than any other point-improvement in a waterfall project. Indeed some of the practices advocated by the Agile community are being used in waterfall projects, with TDD and pair-programming being some of the most used, but certainly not the only ones.

The “system” value of Agile comes from much more than just practices, and we should not get blinded by the focus on justifying every “cent” of productivity and forget that without living the values and implementing the principles of Agile we are missing the big picture.

As a systems thinking apprentice I must also emphasize that the search for the answer to the question “why does Agile work?” in the details will only yield crumbles and small anecdotal evidence (albeit scientifically anecdotal) of something that is much bigger, the System of Agile values, principles and practices.

More anecdotal evidence

In my company we’ve had a few pilot projects to introduce Agile software development, some more successful than others. One of the learnings we took from one of the projects was that introducing the Agile practices without providing the full understanding of the values to the people working with the practices led to big people problems, even though the project was successful in monetary terms (on time, very few quality problems, with less resources than a third party estimated, etc.) it left behind a trail of problems that later on had to be tackled by the organization and eventually led to some of the developers getting back to the old habits of software development waterfall-style.

In another project the approach was totally different. No practices were forced on the team, the team was constantly challenged to follow the Agile values and principles but given the freedom to find their own solutions (which the Agile practices being presented to them as possible solutions, but not forced).
After that project the people were motivated to learn more about Agile and Agile practices and the project itself was a success in terms of schedule and controlled costs – but there was no third party estimate to compare it with.

When comparing these two projects in my mind I would say that the first was focused on the “hard” value of Agile software development, and delivered a successful outcome if you follow “hard” value only.
The second project was focused on “system” value, which at first did not necessarily include “hard” (money) value as a goal, but eventually also delivered “hard” value.

The point I’m trying to make is this: Agile is a system of Values (with principles and practices) not a collection of practices that you can apply separately in search of some “hard” value here and there. You can of course apply those practices separately but you will not be able to rip the larger benefit of applying the Agile system of values, principles and practices.