Mishkin Berteig suggests that the differences between agile and waterfall are similar to the differences between a bank loan and a Visa cash advance. The trouble with this analogy is one loan is secured and one loan is unsecured. The cash advance from Visa is an unsecured debt, where the bank loan requires some sort of collateral for security - ranging from your house for a mortgage, to the car in an auto loan.
But that is not really the point. The continued comparison between agile and "waterfall" fails to make clear the differences between agile and other approaches to development.
The granularity of the deliverables have varying sizes. Small granularity in the deliverables needs to have a matching small granularity buckets in the receiver of the deliverables. If not there is a mismatch - an impedence mismatch between production and use.
If I can't use the rapidly produced results then they have less value than the advocates would suggest.
Agile software development process produce outcomes on fine-grained boundaries - weeks. Development processes that produce outcomes on larger grained boundaries are less agile for one simple reason - the feedback sample time is larger and therefore the interval in which the system can respond to change is large.
If the development of software is seen as a "system" in the systems engineering or systematics sense, then the role of feedback becomes clear. There are several important points though.
- Just calling it feedback doesn't mean it is feedback - it's not feedback until the system changes its direction.
- Feedback intervals need to be tuned to the needs of the system - the rate at which feedback is made must match the response characteristics of the system.
With this background the comparison between agile and something else MUST address the needs of the system. One topic currently making the rounds in the aerospace business is the use of weekly earned value. One might assume that have earned value numbers on a weekly basis is better than on a monthly basis. This may or may not be true and depends on the underlying development processes.
A similar example is the delivery of working software on a bi-weekly basis versus longer intervals. The value of this software to the end-user depends on whether the "system" can make use of the this software. What is needed in any discussion of agile software development is to first identify who is receiving this software on each boundary.
- Fine grained - build working code, check it into the repository and 100% complete. Fine grained receivers are most often QA and CM.
- Moderate grained - assemble the working components for integration testing. Moderate grained receivers are often test, tech pubs, intermediate V&V.
- Large(r) grained - deliver the "system" to the user on some boundary that matches the needs of the business. Large(r) grained receivers are often Beta, small user communities, limited production.
These distinctions never seem to enter the conversation. The problem with the simple examples of Visa versus Banks is they never really address the problem of software (or for that matter any engineered product) delivery - what is the appropriate interval for sampling the performance of the project to gain corrective feedback for its course of progress? Over sampling a digital (in this case the finite interval deliverables) system creates noise. Noise drives the system into oscillation in undesirable ways. "Chasing ones tail" is a good analogy. The feedback gain in an analog system has simialar outcomes.
One way to view the problem (and this is a systematics approach) is to invert the problem. "Who is the receiver of the resulting outputs?" Once this is determined, then the appropriate receipt interval can be determined. Questions like:
- How fast can the receiver receive partially working product?
- When received, how fast can the receiver provide feedback for corrective changes in the plan?
- At what rate can changes be tolerated in the production system to avoid oscillations in the underlying processes?
Continuing to compare agile with waterfall provides no value, since it hides the need to determine the appropriateness of the sampling interval and the ability of the "customer" to receive value from the output of the agile process.
As Kent Beck suggests - in software development optimism is the disease, feedback is the cure. Well maybe not the cure, but feedback can be the diagnosis. The cure comes from making changes as a result of the feedback. Changes that actually change the outcome of the project.
