Prototyping software and wireframe tools lets design get a few iterations ahead of development—so everyone can work faster and smarter.
If rapid, iterative prototyping is a great way to experiment, innovate, and then validate an idea before committing to code, why is prototyping sometimes viewed as unwelcome by Agile teams? This was a recent topic of discussion with Bryan Lipson, the Director of Product at iRise.
“When Agile was a little less broadly rolled out, and people were earlier in their transformation process, there was some resistance to prototyping,” Bryan says. “I think the idea was that we’ll just build code and that we won’t need a prototype—we’ll validate with running code. But I think people have seen that this is still very expensive and creates a lot of waste.”
Doing UAT with running code, but in two or four-week increments? That, he says, is still a lot of time to burn just to learn you’ve gone down the wrong path and need to rework.
“I think the more advanced shops are leading the charge with prototyping, using that as a way to validate that they’re on the right path to begin with,” Bryan says. “The course correction will be less significant—and we’re seeing prototyping become a more common idea. If you look at the Scaled Agile Framework, in fact most Agile methodologies, the recommendation now is that design runs a few iterations ahead of development.”
Companies are realizing iterating in code is very expensive, which makes validating product ideas and concepts in the definition phase, before coding, more attractive.
Shuffling 400 user stories
Even in the most Agile of environments, there’s still a certain amount of upfront definition, design and scoping that needs to be done. It’s a vision we like internally, to be sure, but how do these challenges play out in the real world?
“We’ve seen organizations that try to do Agile by taking the 400-page spec and just chopping it into 400 one-page specs and called those user stories,” Lipson says. “A lot of organizations are still struggling because they’re using scrum and sprints, but still find it difficult to figure out where all the requirements go.”
And while there are practitioners who imagine a world of development without requirements documents, Lipson says we can’t all live in that world.
“Take the healthcare industry, where you have clients that deal with the thousands of FDA regulations that impact a particular project,” he says. “You can’t write that down on the back of a sticky note and have it map back to actual system-level requirements, much less capture all of that in a coherent way that people can understand and consume.”
Enter the prototype: It’s a better way to validate that that story, the new feature, the new function, the new report is in fact going to satisfy the user need. Requirements management, whether using only the tools in iRise or synching it with the ALM tools you already use like Jira or TFS, is still very much part of the process. But because you’re gathering them in-context with the prototyping, they’re easier to create, understand, and far more accurate.