The value of Big Design up Front

April 28, 2009 by Mendelt Siebenga

Lets start my first article on AgileSoftwareDevelopment.com with a controversial title. Just to get your attention. You're still reading? See! It works!

I often see teams, even teams that claim to be doing agile spend several weeks or even months at the start of a project doing requirements, analysis, design and planning. BDUF is a habit many people find hard to give up. Team members instinctively feel there's something of value in that first stage of a project they'll lose when they just dive in and start creating software. That value is not in the documentation they deliver, but it's something they do during those activities that they forget to do later on. Lets look at a typical project to see what people do during that first phase that makes it valuable.

In traditional projects the change in dynamics is often quite obvious. At the start of a project the team has energy. The analyst talks to clients and stakeholders, the architects meet with the developers, managers meet with everyone to make plans and get estimates.

Three months later the situation is quite different. The analysts has moved on to a new project and is only available to the team for a few hours a week. The architects have finished their design documents, the manager only wants status reports, the developers are behind their workstations in crunch mode and the schedule is slowly starting to slip.

The value teams get from the big design phase is not in the documentation like people often seem to think. In fact it's quite the opposite. The documentation actually causes them to stop doing what made that first phase of the project so energizing. The value is in communication. But as more documentation is written the need for communication seems to be less and less, as communication stops the team is unable to react to setbacks and deadlines start to slip.

This is an important observation to make when you want to make a team like this more agile.

I'm not saying we should just keep doing big design up front, I think this is a wasteful practice. But before dropping it and forcing a team to work iteratively we should look at the value it brings and try to reintroduce that value through other means. Teams have to communicate before they can iterate. This can be done by introducing practices like daily stand-ups, pair programming and getting a customer on the team. Only then will the team be ready to drop big design up front.

Permalink