The Software Development Death Cycle

Does this look like your development cycle?

All is joy and celebration on the product management side when the project begins. Then comes the iterations as the marketing requirements document is passed back and forth with engineering. (BTW, is it just me or does it seem we lose about 1/3 of the project's useful development time in this phase?) Then engineering goes to work and produces something they send to QA. The product manager sees it and goes postal. Well, been there!

I worked at a place where there was a product manager--let's call him Dave--that kept stirring the pot in QA when he got a glimpse of the UI coming out of development. The design and development team wanted to take out a contract on him. "How do we keep Dave out of the process that late in the game? He's creating too much churn."

I saw the problem differently--why were we disappointing Dave, the guy who brought us the work to begin with? I could understand if we were disappointing the customer, after all , they hadn't written the requirements, Dave had. I could understand if we were disappointing our partners, after all , they hadn't written the requirements, Dave had. But how was it that we were disappointing Dave?

I concluded it was the requirements process itself that was failing. It relied on words, and words were screwing the deal. As a technical communicator, that was a harsh realization, but I have come to learn the following:

• Gopen and Swan are right when they say "We cannot succeed in making even a single sentence mean one and only one thing; we can only increase the odds that a large majority of readers will tend to interpret our discourse according to our intentions. "
  
• Words, then, create the illusion of agreement.
  
• And my own realization is that any time words are a problem, more words are never the solution.

So we decided to quit trying to solve the requirements problem by writing better requirements. Instead we moved UI design to the front of the design process and made it a collaborative conversation among the product manager, the UX designers, and the developers. I've since had the opportunity to play with this model and improve it. More importantly, I keep re-validating that it works.

OK, here's how it works.

1. Start with a list of the requirements, doesn't have to be pretty or even very good. It's a conversation starter.
2. Sit in a room with a product manager, UX designer, and a developer and start creating a scenario that illustrates a requirement. Make it an explicit example. Who is the user, what's the problem he's trying to solve, imagine how our product would fit in. Tell the story and draw pictures (wireframes).
3. Do that for all the requirements or at least for the most important.
4. Have the developers size the solutions.
5. Let Product Management select from the solutions as much as the development bandwidth will allow.
6. Go forth and code.

That model can be iterated down to as small a granularity as you want. For example, do it for the top two "we know we gotta have this" and get the dev team coding while you sort through the rest of the requirements.

Here's why this works:

• The value that project managers bring is that they understand the problem space. Detailed requirements documents tend to end up being solution oriented--takes them out of their sweet spot.
  
• Developers design better solutions when you clue them in up front what the problem space is. Treat them like architects and not like carpenters.
  
• UX folks can model a product's behavior and validate it with stake holders and users with little to no code (that equates to fast and cheap).
  

I work in an Agile group now, and if we have a particularly snarky problem, we will put it in a design spike. That is a dev cycle in which we don't put a bunch of engineers on it. We iterate the concepts until product management, development, and UX come to consensus on an approach that is saleable, buildable, and usable.

No big magic, but the core ingredients are not substitutable:

• Early in the process
  
• Collaborative among product management, development, and UX