It's like a light bulb turning on. That's how Bob Schatz, agile trainer and consultant, describes the realization that the traditional thinking around requirements needs to change in an agile environment. "The fact is, in these iterative environments, things are being produced quicker; it almost forces people. You have to start thinking what you really want, and do the most valuable things first."
In addition to prioritization, organizations need to think of requirements as more organic and negotiable versus something that gets captured, specified and locked in with reams of documentation before a line of code is ever developed, explained Schatz, who formerly led the successful agile transition at Primavera Systems Inc., where he was vice president of development.
"Traditionally there's a big effort up front to collect all the requirements, and describe in text what you conceptualize visually, so a 'contract' can almost come to life," Schatz said. "There is never an effort to think about prioritization. No one is thinking things will change, and that there will be constant negotiation."
Schatz advises companies to focus on what the goals they trying to achieve with the project are and how the goals are prioritized. Once that lesson is learned, the next task is determining what features and functions are needed to achieve those goals? "Then, you prioritize, and in an iterative way start focusing on the highest value first," he said.
Forrester Research analyst Dave West sees three major differences in the requirements process for agile versus traditional development projects. First, he said, the relationship between development and business is "more collaborative and less confrontational." Second, both the size and complexity of requirements documents are reduced, and other mediums are employed to express requirements.
"A lot of agile organizations use the user story—it's an invitation for a conversation rather than detailed specification," said West. "It's a placeholder for collaborations and discussions vs. [a specification that says] 'the system shall do this.' Does that always work? No, sometimes you need more specification, but traditional requirements take this to the extreme."
Agilists use the right medium for their needs, West said. For some teams this may be a whiteboard, a video recording or a PowerPoint, or a simulation tool like iRise, West said.
The third major difference, West said, is around scope. "One of the biggest challenges in a traditional project is you go through requirements capturing by going to the business and asking them for everything they could ever want around a system, and you get a complicated, long list of things." But the business only interfaces with that system once, he said, and only when the system is delivered do they see that some of those requirements really aren't right, or even necessary.
"With agile projects, [requirements] can incrementally develop, and scope changes as all parties get more of an understanding," West said. "It reduces feature bloat."
In addition to process changes, agile projects get more roles involved with requirements. "Probably the biggest change is getting the end user involved," Schatz said. "It's something people are struggling with, especially with getting feedback on what we've done." The fear of feedback, he said, is that the users will request a change, and they typically will as the system evolves. "The dynamic there changes quite a bit. It gets away from 'give us the requirements and we'll go away and deliver something.'"
But it's not just user involvement, West said. "Everyone is a lot more involved in requirements," he said, from the customer to the business analyst to developers and testers.
That's true at Vertafore Inc., a Bothell, Wash.-based provider of software and services to the insurance industry, said Chris Kinsman, vice president of development. "More of the development team is involved and interacts directly with customers instead of just the business analysts," he said.
An agile development practitioner, Vertafore, is also changing the way it gathers requirements. "We have been trying to move away from large functional requirements and more to a user story approach. We are still working on this," Kinsman said.
Changing the approach to requirements with agile projects, however, doesn't mean abandoning everything traditional. Agile projects still have some documentation, Schatz said, but "the documentation becomes more of an artifact of what happened."
And some projects, and industries, require traceability and must prove compliance, such as software for medical devices, said David Locke, Rational Director, Offerings Marketing, IBM Software Group. "It's an age-old problem," he said. "In communicating and capturing requirements, you have to find the right weight." For a medical device that needs FDA approval, he said, the process is rigorous. "It's heavyweight stuff, but you still need to be agile enough to be competitive."
Mary Gerush, an analyst at Forrester, said agilists need to be realistic. "There are pure agilists that may shirk from using a requirements management tool, but others recognize there are times you have to have rigor, so if there are compliance issues you have to have traceability of requirements. Agilists in the real world understand that."
Gerush's colleague West said even traditional projects can benefit from some of the requirements techniques agile organizations use, such a closer relationship with business and delivering more appropriate requirements artifacts vs. huge documents. However, he said, the frequent delivery of working code and constant reevaluation of requirements would be difficult to apply to a traditional project.
That said, the question remains, does an agile approach help organizations produce better requirements? "We haven't gotten better at producing requirements, but I would argue we have gotten better at delivering what the customer truly wants," Kinsman said. "This can in many cases be very different from what the former requirement documents set out."