Another challenge to a premise of agile comes in a well assembled argument from Tony at Seilevel, in his article, Agile…again.
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.
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 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.
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.