24 March 2011
Design Practice

Big design up front

Like most designers and developers we've come to the conclusion that big design up front doesn't work. Six month requirement gathering exercises which result in thousand page specifications don't work. In the time it has taken to produce these requirements the business landscape has almost certainly changed. So new requirements appear and designers and developers are forced to battle scope creep and keep these documents alive while at the same time trying to build something that is ever shifting and changing.

Instead we've seen a move to agile development and an almost zealot backlash against detailed planning of any kind. However just because big design up front doesn't work, that doesn't mean we should ditch design planning altogether. As a race we tend to flip flop between polar opposites rather than exploring the middle ground. So the problem doesnt lie with requirements gathering, design or planning—it's about the amount you do.

Too much planning and you get bogged down in nuances. Sometimes it's just easier and quicker to design something than it is to discuss it. Too much documentation and you end up spending more time managing the documentation than you do managing the design. The converse is also true. Too little documentation and it's easy for large teams to lose their path. It's also easy for the fidelity of the solution to suffer. Just as with too much planning, too little planning leads to inefficiency as work that was done several sprints ago needs to be redone based on decisions made later down the line.

So I don't think the argument should be agile vs waterfall. Instead it's about knowing the skills, abilities and interests of your team and initiating a level of planning which is appropriate for the project at hand. There's no one-size-fits-all approach to developing good products, so I really wish we'd stop chasing the Holy Grail and having holy wars in the process.

Instead let's go back to the core commandments of agile and prefer conversations to documentations, while understanding that in some instances documentation is necesary. Similarly, zero design won't work, while all design may be a fiction. Instead you need to find the right level of fidelity and tweak the smaller issues as you go along.

It's all about balance people, so let's start finding ours.