Another challenge to a premise of agile comes in a well assembled argument from Tony at Seilevel, in his article, Agile…again.
Perspective
At Tyner Blain, we believe in the power of requirements. We sell services in product management, business analysis, and other elements of the software process. Everything we do strives for Software Product Success. Tony has a similar disclosure:
Some people have pointed out that the reason I don’t like agile methods is because I am trying to sell services which depend on “traditional” requirements. The reason I like “traditional” requirements is because I don’t like screwed up projects.
We firmly believe that there is benefit to defining the goals of a project (requirements) before beginning the project. While we are occasionally guilty of using hyperbole when contrasting different software approaches, we stand behind the spirit of those arguments.
Processes that trivialize requirements definition activities are flawed processes. Processes that over-emphasize requirements gathering (e.g. “Big Up Front Requirements”) are also flawed. An underemphasis introduces the risk of missing critical requirements. It also increases the likelihood that the team will sub-optimize by focusing their initial efforts on the wrong requirements. An overemphasis on “defining everything” before we begin to deliver valuable solutions can cause problems too. By delaying delivery, we magnify the impact of requirements gathering errors.
The question, ultimately, is a matter of degree.
Opposing Perspectives
People who push for minimizing pre-development requirements efforts often justify that approach as a response to projects that wasted a lot of time on the wrong requirements. As Tony points out, the fundamental requirements or goals (market requirements) do not change frequently. Imagine a product manager identifies requirement “A” as the most important one. After delivering the software, the customer is dissatisfied with “A” and the product manager is faced with a decision. Should he accept blame for doing a bad job at gathering requirements, or should he claim that the requirements changed after he specified “A”? I think too many people fail to accept responsibility, and blame it on “change”.
How many times have people tried to create a mass-market pen-based portable pc? Did the requirements change, or did the teams just pursue the wrong objectives? What about Microsoft’s Bob operating system?
For people that push for heavy up-front requirements work, it is a command and control issue. Personally, I’ve seen a lot of high-caliber implementation teams thrash around “searching” for great products, and delivering (well-implemented) junk. Maybe that’s why I believe in the value of having a vision and a set of goals.
Feedback
Feedback loops are great. In the engineering world, a process without feedback is considered to be out of control. Incremental delivery is the mechanism by which we put feedback into the software development process. There are small feedback loops throughout the process, but the big one is customer feedback. These feedback loops make incremental delivery a good idea.
Feedback is a key component of agile software development. Feedback only works when you respond to it – hence the adaptation to changes in requirements. If the initial requirements are bad, the project can only succeed if the feedback requirements are good enough to replace the initial bad requirements. If the initial requirements are good, then the feedback requirements are requirements of refinement not replacement.
I, and I suspect Tony, believe that the best way to run a project is with good initial requirements and with feedback requirements that help us refine our vision or approach or design and implementation. This dependence on feedback does not preclude the need for good initial requirements. And that availability of feedback requirements does not obviate the need for good initial requirements.
Conclusion
Tony is right, and the passage he quotes from Agile modeling is unfortunately misguided. Good initial requirements are not impossible to gather. Failing to do so is expensive and dangerous. Incremental approaches that allow for customer feedback throughout the development process are outstanding. The ideal way to apply the feedback is in the refinement of initial requirements, not the replacement thereof.
With respect, I must disagree with Tony’s comments and with your assessment of his argument as “well assembled.” Instead, I think Tony has missed the mark entirely. He has misunderstood the original authors comments about requirements. It’s a question of going beyond the point of diminishing returns. On the one hand, one can try to elaborate requirements in great detail in advance. A good deal of that effort will be wasted, since the details are subject to change as a project goes forward. On the other hand, one can go too far in trying to avoid that very problem, and end up with an inadequate definition of the goals of a project. The solution is to avoid the extremes, not merely to debate one extreme against the other.
The problem with gathering software requirements is that they are easy to formulate and understand only for (experienced) IT specialists. Thus the advantage of using prototyping for requirement validation and refinement.
However, prototyping is often be most efficient by simply issuing a new release of the product.
Dave,
Thanks for reading and commenting!
You make a great point about finding balance. Sufficient initial requirements are required. Changes to requirements should be embraced during a project.
I believe the right answer is to do both, and as you say, avoiding planning and avoiding change the extreme are both bad.
I would also like to point out to anyone who’s reading these comments that Dave has posted an OUTSTANDING response to Tony’s post on the Seilevel blog.
This discussion goes hand-in-hand with an article in the latest issue of productmarketing.com about “Extreme Product Management”. My comments on the article are in today’s blog entry.