How Agile is being adopted by our customers, why requirements management has remained a challenge, and where prototype-driven requirements fits in.
At iRise, we pitch ourselves as a solution that improves the software development process for any customer: large or small; waterfall, Agile or hybrid. We improve the product definition phase so that a better vision—clearer and more digestible—is presented to developers, and that’s going to mean a better final product, with fewer costly missteps to get there.
But having made it our mission to improve requirements-gathering and the full product definition process, we’re often surprised at the challenges we see with Agile teams. This is especially so for larger enterprises, and some teams are further along than others.
“We’ve seen cases where a team appears to be working with the Agile methodology,” says our director of product management, Bryan Lipson, “but when you dig into their user stories, you find the same old specs buried underneath.”
We think it’s time for a real evolution in the way teams approach requirements, and we’re starting to see a hunger for it. Maybe it’s because the Agile and DevOps movements have done so much to streamline the process from code to customer, that it’s finally time to look at the start of the process—identifying the idea or business problem that a software application can address. We think that’s the next frontier of modern application development, which is why we created our partnership with Tasktop, bringing iRise into Sync with leading ALM tools like Jira, Microsoft TFS, Rally, HP Quality Center, IBM Rational, and many others.
Prototype-driven requirements and product definition
For many some IT teams, wireframe tools and prototypes come late in the game, too far into the definition phase to make a real impact. We, instead, see prototyping as a tool to help both IT teams and stakeholders collaborate on that definition up front.
“Prototyping shouldn’t just be the final step before you go into development,” Lipson says. “Using collaborative prototyping to identify, validate and capture requirements from the beginning is far more effective and efficient.”
Long gone are the days when design was an afterthought. Today, doesn’t nearly every requirement involve some level of interaction and design?Let alone the necessity of considering the “experience” of the application. Written requirements alone won’t convey any of that – prototyping + written requirements will.
Is our goal to replace 500-page binders full of unread requirements with a single, simple, interactive prototype? Well, if you can pull it off, sure—but in most cases, no. There will be, and should be, requirements. Yet they don’t have to be painful to create. They don’t have to be confusing, unclear, and a seemingly impossible burden for your business stakeholders. They don’t have to make your Agile developers lunge for their torches and pitchforks.
In an ideal situation, you could replace a lot of that text with something visual and interactive, and the requirements are effectively the prototype itself.
Democratizing the prototype
Prototyping is becoming more widely adopted, Lipson says, because it doesn’t just reside in the hands of designers. iRise pioneered the idea of Business Analysts using rapid collaborative prototyping as a tool to drive the requirements gathering process. To allow teams to quickly iterate as they interact with prototype – a very “agile” concept.
“What we’ve been advocating for 15 years, even before the Agile movement,” Lipson says, “is this idea that not only designers, but the people who are responsible for defining the solution—the business analysts, product owners, and product managers—should be leveraging prototyping, too. It’s transformed the way teams collaborate. ”
The role of the quick, functional prototype, then, is to let stakeholders interact with a realistic representation of the solution, rather than hundreds of pages of text asking them to imagine what it’ll look like. You still gather text requirements and user stories, but they’re captured in-context of the functionality they describe. Adjustments are simpler to make and validate, and the result is something developers can better grasp. You end up with more accurate documentation and a clearer, more consumable idea of exactly what the business needs.
“In product definition, you need to establish or improve the vision of what you’re building,” Lipson says. “I think prototype-driven requirements are the best way to get there, but what matters is that you do get there.”