Many teams are good at delivering working software throughout the Agile process, but not so good at building software that meets business needs. Often, tight deadlines spur teams to start coding before fully identifying business and user requirements, according to application requirements experts Ellen Gottesdiener and Mary Gorman. They laid out the value of techniques and tools for discovering those needs in the Agile process.
Gottesdiener and Gorman are principals of EBG Consulting, based in Sudbury, Mass., and authors of the how-to book,
"In the attempt to go lightweight, many Agile teams end up going no-weight, skipping analysis," Gottesdiener said. "They pay a big price for that. Once they get into the work, into delivery -- whether it's an iteration or release -- they realize how many business needs and questions they can't answer."
Traveling app stories that lead nowhere
The lightweight requirements analysis approach usually leads to "traveling stories," in which developers discover new user needs during development. Because they can't get those requirements done in an iteration or release, they have to extend the Agile process.
Traveling stories can also happen and weigh down development if teams spend an inordinate amount of time planning and still not understanding the product needs they have to deliver. "They end up often having huge backlogs or bulging backlogs instead of lean backlogs," Gottesdiener said.
How development estimates go bad
In the attempt to go lightweight, many Agile teams end up going no-weight, skipping analysis.
Ellen Gottesdiener, EBG Consulting
Insufficient analysis also leads to poor estimates. Estimating doesn't go away in the Agile development process, but it's common for Agile teams' estimates to be way off, Gottesdiener said. They get into an iteration, into the building, and they find that they forgot an interface, or they come across detailed business rules they haven't explored, Gottesdiener said. The team hasn't collaborated enough on refining the backlog to figure out how wide and deep they need to build individual stories. "So, they can't get any traction and understanding of how much work they can get done or meet service-level agreements (SLA)," she said.
Not anticipating dependencies is another project problem, Gorman said. Within the requirements themselves, the project team has to build certain aspects of the product to enable other aspects to work. That's particularly so around the data; developers must create data and make it available before they can update it or perform some other action on it.
"Without having a shared understanding of the actual business needs, of the product needs, they really can't come up with reasonable estimates," Gorman said.
Agile process: More efficient communication
A process the authors call structured conversations can bring efficiency to the discovery, shared understanding, estimating and building of applications that meet business and user needs.
In the "structured conversation," the development team explores, evaluates, and confirms business and technical needs.
"The structured conversation is a meta-framework that you would use at any planning horizon," Gorman said. It's an ongoing and iterative process of exploring, evaluating and confirming product needs. It includes scheduled and spontaneous, just-in-time conversations among all team members, including business, user and technology partners.
In the exploration phase, the team considers options for product dimensions, including user needs, interface, data, control, environment, quality and more. In exploration, the team researches and evaluates such criteria as competitors' markets and products, existing and potential markets, and technology trends. That information is the foundation of assessing the organization's expectations for the product and the technical teams' ability to meet those expectations.
The level of granularity in the exploratory process will vary as the process goes on. At first, features will be "big chunky stories," Gottesdiener said. In previews, Gorman said, "you're starting to connect the dots and draw clear boundaries." Eventually, they said, those stories will be become thinly sliced iterations that can be delivered in a couple of days.
In evaluation, the second part of structured conversations, the Agile project team weighs the solution options, dependency risks and feature delivery order, Gorman said. Estimation is a key part of evaluation. This is when solution options get measured for size, complexity and other attributes that determine how long it will take to build the product. Considerations here include product lifecycle, user acceptance and, of course, business needs. Note that evaluation of the value of product options is critical to establishing feature delivery order.
Checking the software in each phase of delivery is the third step in the structured conversation process. The team must continually evaluate and verify that business needs are being met by the application. The structured conversation ends only when all team members agree that chosen solutions are working well and meeting business needs.
"In planning, the team has to define its 'doneness' and 'goodness' criteria," Gottesdiener said. She worked on a project in which the lead developer was the only person who really knew the code base. A key part of the project's acceptance criteria -- doneness and goodness -- for each iteration and release was doing code walk-throughs with junior developers. "They realized they were not done unless they had paid the learning price, so to speak," she said. Without that, the future of the feature or product was compromised.
Structured conversation leadership skills
One or more skilled facilitators are needed to lead and educate cross-functional development teams doing Agile collaboration in the structured conversation style, Gottesdiener and Gorman said. Leaders need product, technology and business knowledge, of course, but Agile methodology, business analysis and facilitation skills are must-haves, too. Leaders should help people set up a framework for collaborating and using analysis tools quickly, so requirements can be explored, planned and delivered in a lightweight but rich manner. Facilitators should "lead conversations in a facilitative way without driving to the answer [and slice] the options for product needs based on values that have been articulated by the whole community," Gottesdiener said.
The concept of value is the guiding star of requirements discovery and delivery, Gorman said. From exploration to evaluation to confirmation, always ask, "What is the value to those being served?"
What communication problems hinder your team's ability to gather and deliver on business requirements? How has your team addressed these challenges, if it has? Let us know and follow us on Twitter @SoftwareTestTT.
This was first published in April 2013