Including two-week sprints to Minimum Viable Products, there are plenty of elements involved in building innovative projects using agile development, but requirements aren't among them, said Greg Godbout, chief technology officer of the Environmental Protection Agency, during an event Tuesday.
In fact, the very mechanics of setting requirements for a particular project conflicts with the whole idea behind agile, he explained during the Association for Federal Information Resources Management’s event in Washington, D.C., called “Navigating Agile Development: Catching the Prevailing Winds.”
“There is nothing required in agile,” Godbout said during the event. His explanation came in response to a statement by the event moderator, Federal News Radio host Tom Temin: “You can't get good software by any methodology if the requirements aren't right.”
Godbout referenced a particular project he had helped with. Its members said they were going to do agile, and yet had prepared for this by spending years building requirements.
“Agile is not something you do in the future,” Godbout said during the event. “You live it everyday, and it's not just for building; it's how you work together.”
This common misunderstanding likely comes from the fact that the waterfall approach, which the government has been using long before agile and contributed to such infamous failures as HealthCare.gov in 2013, does involve requirements. But it is also likely because many tend to confuse "requirements" with "user stories," a tool used in agile software development, he explained.
The General Services Administration’s Chief Information Officer, David A. Shive, appears to agree.
“In successful delivery of agile, you actually want less requirements, not more, in the traditional sense of the word,” he said during the event.