Big design up front | March 24, 2011

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.

So 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.

Posted at March 24, 2011 12:29 PM

Comments

Vasilis Dimos said on March 24, 2011 1:26 PM

I couldn’t agree more.
The big upfront design thinking got us more then once into the situation where we delayed product launches to the point where we lost focus and the initial spark. The same goes for quick launches which would need realignments to the total design philosophy some months later. The balance is hard to strike and the only thing that is helping right now is to be very anal about small but complete design and implementation cycles. Break everything into smaller pieces that can fit into a weeks work but are parts of the bigger picture. Instead of trying to redesign the whole site, start with the header or a specific section and go from there…

Rasmus Kalms said on March 24, 2011 1:45 PM

Bigger teams will necessarily require more documentation, wireframes, designs, and what not, while smaller teams can more easily adapt, communicate and keep the pace set throughout the project. It’s also more about setting the right framework for the tasks expected of the developer and/or designer, and let them work within those limitations.

A large project will almost never work under a waterfall model - at least not optimally. You take away the ability to make changes fast. A full agile approach to a small project will often require too much planning, when a small, set-in-stone approach is the sensible thing to do. If your expected turn of delivery is three weeks, you might not need the amount of work an agile approach require.

Also, sometimes - People should just sit down and do their job instead of talking about how to do it.

Sjors said on March 24, 2011 4:11 PM

Reminded me of the amazing Duke Nukem Forever syndrome: http://earok.net/sections/articles/game-dev/theory/duke-nukem-forever-syndrome :)

Rob said on March 27, 2011 9:16 PM

I often see agile being used as an excuse not to do something or a way to cut corners. Such as, “there is no need to spec that out we’re doing agile”.

If your going to embrace a methodology,you better make sure you know what your doing or it will come back to bite you…

Ryan Munger said on March 28, 2011 3:20 AM

Agreed.

As with any aspect of life, to be happy requires balance. Don’t overdo it, but don’t underdo it - either.

I am a huge proponent for being in a detail oriented, agile work environment. I know it’s hard to have both, but that’s where the balance part comes in :)

Great post Andy!

Joshua Kelly said on April 2, 2011 11:54 PM

I mostly agree with you Andy. In larger development environments (at least the one I’m in), project planning consumes a tremendous of time and energy on the part of project managers, sales people, and developers alike. And, yeah, it’s a problem.

But there’s something fundamentally challenging about dealing with huge projects for corporate clients. I’ve seen endless conversations, empty promises, and failed deliverables because of failures in the planning process.

One other important factor to consider is the legal fall back that good documentation can often provide in corporate settings.