Martin Fowler May Have Slept Here
Andrew - a little lesson in Physics for you today. Trust me that this will eventually lead to another favorite subject of mine and the theme of our blog - Agile Software Delivery.
Let's say you have an environment that is really cold, potentially at Absolute Zero. You decide that you want to measure the temperature of the environment to see if it really is at Absolute Zero. But you quickly realize that if you introduce a measuring device into the environment, the warmth of the measuring device actually affects the temperature of the environment because it will transfer some of its heat into the environment. Your conclusion - you cannot accruately measure something that is really cold without affecting its temperature by trying measuring it.
This same problem occurs in other areas of Physics, most noteably in the area of quantum Physics. The Heisenberg Uncertainty Principle states that there is an observer effect on the measurement of the position or the measurement of the momentum of a sub-atomic particle. Stated differently, you can know either the position of a particle or its momentum but you can't know both. Measuring one affects the other. (The Heisenberg Uncertainty Principle has led to the most famous of all Physics bumper stickers - "Heisenberg May Have Slept Here".)
This Observer Effect also has a place in software development. The following is a quote from Scaling Software Agility by Dean Leffingwell:
"We also discovered an even more pernicious aspect of providing software solutions: delivery of a new system changes the basic requirements of the business and the behavior of the system, so the actual act of deliverying a system causes the requirements of the system to change." (The Italics are the author's.)
Agile's preference for early and frequent delivery of working software allows for the requirements of a system to emerge and the business process to evolve as the system is being coded and delivered incrementally. In Agile Software Development we are constantly asking the question "What can we code next that adds the most business value?". In contrast, complete up front gathering of requirements for a new software solution is more an exercise of the memory, not the imagination. "Let's make sure we don't forget anything" is the mantra of Functional Spec contributors.
So let's complete our analogy: in Agile Software Development the Observer is our Agile enabled development team (aptly portrayed by Martin Fowler here); the thing that is measured is business value at the end of each sprint/iteration; the thing that is affected by our measurement is the backlog of story cards as we re-prioritize and add or remove (yes remove!) story cards based on feedback from our users. Also affected by our measure of business value is the user's business process - it will become better optimized as the software is continually optimized for greater business value.
In contrast, in the Waterfall approach the Observer is the keeper of the project plan (or occasionally a requirements traceability matrix); what is measured is progress to the plan; what is affected is...hmmm...this is interesting...what is effected is quality. A poor quality software solution will have an effect on the business process but negatively as the business process must adapt to deal with the shortcomings of a badly designed and buggy software solution rather than adapting to provide greater business value.
Let's say you have an environment that is really cold, potentially at Absolute Zero. You decide that you want to measure the temperature of the environment to see if it really is at Absolute Zero. But you quickly realize that if you introduce a measuring device into the environment, the warmth of the measuring device actually affects the temperature of the environment because it will transfer some of its heat into the environment. Your conclusion - you cannot accruately measure something that is really cold without affecting its temperature by trying measuring it.
This same problem occurs in other areas of Physics, most noteably in the area of quantum Physics. The Heisenberg Uncertainty Principle states that there is an observer effect on the measurement of the position or the measurement of the momentum of a sub-atomic particle. Stated differently, you can know either the position of a particle or its momentum but you can't know both. Measuring one affects the other. (The Heisenberg Uncertainty Principle has led to the most famous of all Physics bumper stickers - "Heisenberg May Have Slept Here".)
This Observer Effect also has a place in software development. The following is a quote from Scaling Software Agility by Dean Leffingwell:
"We also discovered an even more pernicious aspect of providing software solutions: delivery of a new system changes the basic requirements of the business and the behavior of the system, so the actual act of deliverying a system causes the requirements of the system to change." (The Italics are the author's.)
Agile's preference for early and frequent delivery of working software allows for the requirements of a system to emerge and the business process to evolve as the system is being coded and delivered incrementally. In Agile Software Development we are constantly asking the question "What can we code next that adds the most business value?". In contrast, complete up front gathering of requirements for a new software solution is more an exercise of the memory, not the imagination. "Let's make sure we don't forget anything" is the mantra of Functional Spec contributors.
So let's complete our analogy: in Agile Software Development the Observer is our Agile enabled development team (aptly portrayed by Martin Fowler here); the thing that is measured is business value at the end of each sprint/iteration; the thing that is affected by our measurement is the backlog of story cards as we re-prioritize and add or remove (yes remove!) story cards based on feedback from our users. Also affected by our measure of business value is the user's business process - it will become better optimized as the software is continually optimized for greater business value.
In contrast, in the Waterfall approach the Observer is the keeper of the project plan (or occasionally a requirements traceability matrix); what is measured is progress to the plan; what is affected is...hmmm...this is interesting...what is effected is quality. A poor quality software solution will have an effect on the business process but negatively as the business process must adapt to deal with the shortcomings of a badly designed and buggy software solution rather than adapting to provide greater business value.
posted by Tom Looy, Tacit Knowledge PM at 4:46 PM
8 comments
