Agile Requirements

James Shore, in his blog – Successful Software, writes about the requirements process, and in particular, an Agile approach – his recent post lists the set of articles that he has written on the subject.

In the first of his articles, he talks about how the software-definition process should move from the general to the specific. Basically, the focus should narrow as time moves on, from an initial vision, to a set of features, to stories, and ultimately to specification. He makes the point that you should wait until the last responsible moment before each narrowing of focus – not the last possible moment. The concept of a responsible moment was introduced by Mary and Tom Poppendieck in their book Lean Software Development: An Agile Toolkit for Software Development Managers.

One of the key points that enables James’ approach is “tight collaboration” between the program manager and the developers. He talks about the miracles that can happen when you have this, as conversations can cause time to miraculously appear in the schedule. And his use of the toaster analogy is spot on.

For example, if the product manager asks for the toaster to automatically pop up the toast when it’s done, programmers might say that’s really expensive. And when the product manager asks why, the programmers can say, “Well, popping up the toast is easy; that’s just a spring. But detecting when the toast is done–that’s new. We’ll need an optical sensor and some custom brownness-detecting software.”

This gives the product manager an opportunity to ask, “But what about all those other toasters out there? How do they know when the toast is done?”

The programmers respond: “They use a timer. But that doesn’t really detect when the toast is done. It’s just a kludge.”

To which the product manager says, “That’s okay! Our customers don’t want a super toaster. They just want a regular toaster. Use a timer just like everyone else.”

And the programmers say, “oh, okay. Well, that won’t be expensive at all.”

The key takeaway is that you must have a program manager who can interact with, and understand developers well enough to ask questions like “why is X so expensive?”. This is just one manifestation of the switch hitter archetype, the tech-savvy stakeholder, doing his job. In an awkward (non-agile) development process, your switch hitter may have to rely on reviews of design documents and documented assumptions to identify when money is being spent that shouldn’t.

Ultimately, it’s collaboration with the development team. And you have to rely on the developers to (be able to) tell you what assumptions they are making in their estimates / approaches. But unless they are really good – you also have to ask them. And for any non-trivial project, this means a ton of collaboration. And that’s a good thing.