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.
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.
at
11:07
"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.
RSS link
1 Comments:
Vasco,
I think your observations are exactly right. Agile is definitely more about the values and principles than it is about any specific practices. I think I mention something similar to this a couple of times in the series of posts you cited, although the focus of those posts is on the hard value of specific practices, and that focus is purposeful.
Our ability to explain value in hard terms will be important to our customers because they can relate to that sort of explanation, but I don't mean to understate the holistic benefit of agile as an ecosystem of values, and I agree with you that we should never lose sight of that as we explore the question of hard value. The agile ecosystem is the larger context in which we assess value in different ways - hard or soft, cultural or procedural, single practices or cohesive methodologies, etc.
As a practical matter, very few IT organizations are able to make a cultural transition directly from a traditional environment to an agile environment. Another challenge is that we usually introduce agile methods in just one part of an organization, and that part must not clash with the rest of the organization, or the agile initiative will fail. That particular aspect has been a critical success factor for us at my present company, which has a much larger traditional IT organization than the agile group - about 1300 people vs 70. We must introduce principles and practices piecemeal, depending on an organization's particular circumstances and its readiness to embrace change. The agile ecosystem is the ideal toward which we aim, but in a traditional organization we must introduce change gradually and systematically, and we must be able to demonstrate the value at each stage.
To be successful in that, we must understand the operation of each practice in isolation as well as how various practices reinforce each other when applied together. We also need to know how to make our case convincingly to various audiences, many of whom will initially be hostile to the idea. It's a complex problem. But I think we must face this problem in 2006-2008 in order to take agile to the next level of industry adoption.
By
Anonymous, at July 14, 2006 3:53 PM
Post a Comment
<< Home