voke, inc.’s recent survey of Agile use, discussed in two reports: “Market Snapshot Report: Agile Realities” and “Strategic Brief on the Cost of Rework for Agile and Non-Agile Projects,” caused a bit of controversy in the Agile world.
Ellen Gottesdiener, a seasoned Agilist and consultant at EBG Consulting, took issue with some of voke’s conclusions, though she affirmed that she did not have access to the specific survey questions or answers. She shared her thoughts in a recent interview.
One of the survey’s findings, referenced in TechTarget’s Executive Editor Jan Stafford’s first article in a two-part series, Software defects increase cost of Agile projects, is that “In effect, Agile embraces the fundamental realignment of business ownership of requirements to developer ownership of requirements through frequent changes in source code,” according to voke co-founder Lisa Dronzek.
Gottesdiener disagrees. “That is not what Agile is about. It’s in fact the opposite. It’s not true that you’re realigning business ownership of requirements. There’s a huge burden and responsibility of ownership of the requirements on the business.” She emphasized that the business responsibility when it comes to requirements is actually extremely valuable.
“I’ve found that there’s a tremendous amount of discipline in Agile and responsibility that the business has about what needs to be built and when it needs to be built.”
Another assertion, cited in Stafford’s article about documentation, is a misconception according to Gottesdiener: “Agile values documentation less while advocating self-organizing teams and a constant pace of development,” said Dronzek. “This creates a huge problem for ongoing maintenance when individuals or teams move on to a new project and are unavailable to help support a prior project that has little or no documentation.”
Gottesdiener explained that while there is a myth that Agilists don’t care about documentation, the truth is “just like all other practices, documentation has to be calibrated for the situation at hand.”
“If the team is going to develop and not maintain their own product—which, right there is a questionable practice because you learn a lot by maintaining your own product—then, there needs to be an understanding by the business that it is likely to be more costly in the long run to maintain a product without useful and usable documentation. Therefore, part of each delivery of the product should include maintenance-related documentation.”
In regards to evaluating QA practices, the article mentions: “Another key factor in cost of quality is how early QA is started in a development project. In the voke survey, most enterprises (71%) reported not starting QA testing at a project’s beginning, during requirements definition.”
“Then they’re not implementing Agile appropriately,” Gottesdiener responded. Thinking about how to validate that the team is building the right product and verifying that it is built correctly is everyone’s responsibility, she explained.
One point that Gottesdiener does agree with is “The importance of laser focus on requirements is what comes out of this survey,” said co-founder Theresa Lanowitz. “Requirements are at the center of every successful or unsuccessful software project, regardless of the style of development.”
The focus on requirements is essential, though challenging, explained Gottesdiener. “I think that Agile practices, when you apply them correctly, help you do a much better job with requirements and business analysis.”
In the second article of the series, The Agile method remains confusing for software professionals, Lanowitz and Dronzek call into question the standards of Agile as described in the Agile Manifesto.
“Building software is complex. The best organizations will have some standard practices that they know are good practices,” said Gottesdiener. She explained that the assumption that there can be a standard set of practices which apply across all organizations implementing Agile is mistaken. The practices must be adapted to suit the specific needs within the context of what each organization is creating. “There is no such thing as best practices. There are good practices in context.”
