Prototyping Insights from a Guy Who Writes Requirements

Prototyping by Todd Zaki Warfel

Since I finished reading Prototyping: A Practitioner's Guide by Todd Zaki Warfel, I've been rethinking everything except what color I'm going to paint my house this summer. Specifically I've been mulling the entire concept of requirements, process, and communication among the various groups who collaborate to make products.

Three opposing forces meet in the conference room battlefield regularly: Team SDLC, Team Legacy, and Team That's Not What I meant. Team SDLC has roots entrenched in a theoretical model developed when punch cards gave us joy. The SDLC mindset is based on the fact requirements drive everything. By "requirements" I mean a document of some sort that can either be well-written or, as I've seen of late, an Excel spreadsheet wishlist.

Team Legacy, while similar to Team SDLC, refuses to rethink anything unless it has to do with a variation of the phrase "We've always done it this way." Team Legacy is the enemy of actually getting things done.

Finally, Team That's Not What I Meant is full of people who have no real way to communicate to developers what they want. All they can tell you is after they see it graphically, they complain. When this happens the other two teams remind them dutifully that they did sign off on requirements.

Those of us in the development world who try to avoid any camp and want to actually accomplish something fight the process. That's the simple beauty of prototyping as an alternative to requirements. Todd's book articulated an idea that had been tickling the back of my brain for years: requirements suck. You can dress them up, give them lessons in manners, and even try to make them feel like part of the group, but requirements will always remain a CYA way of making sure everything has a central document to go to when they disagree.

Recently, I've seen firsthand how requirements are used to the advantage of one team over another. If you can suck all of the ego out of any meeting and get people to admit they all work together for a common purpose, you might find out that all the teams are simply having problems communicating. Building prototypes forces people to think more logically about where information comes from, who is putting the design together, and most importantly it communicates to the technical and non-technical alike what the end product will look like.

It's really that simple and I'm ashamed I didn't put this all together before I picked up Todd's book. But sometimes it takes somebody else to water that brain seed to help you see what's really wrong with your processes.  If you are involved in the development process in any way, order a copy of Prototyping from Rosenfeild Media and start getting people on board with rethinking requirements altogether. You might actually get some real work done.

Related articles by Zemanta

• The Process Toolbox, part eight: Prototyping (konigi.com)

Popularity: 5% [?]