everyone I know who loves agile-type methodologies has three things in common:
- they work in a small team. Like, less than 10 people. Usually less than 5.
- they don’t have to do monthly profit reports to management
- they don’t have (external) clients.
That kind of environment makes it really easy to love a methodology where you don’t have to accurately define the scope of a project (what the client is going to ‘get’ at the end), and where iteration and collaboration is a way of life.
Consequently, over the last 12 months or so I find myself getting into lots of heated discussions with people over the value of functional specifications. The cool kids say that func. specs. are a waste of time, that they are creativity killers, and that there is no place for them in application design and development today.
I love the sound of that. Hell. I’d love to ditch functional specs if I thought it would give a good outcome. I don’t like writing them. Does anyone like writing them?!
But, can my clients cope without documentation? Without bits of paper that they rarely read but that allows them to feel comfortable throughout the development process – makes them feel that there is a process, there is a scope, and that we have it all under control. Tells them what they’re going to get for their money.
Can an agency with a large, multidisciplinary team working on multiple projects cope without documentation? Where resources jump on and off projects in response to upcoming deadlines, can this be achieved without specs and sitemaps?
I do agree that now is a great time to re-evaluate our methodologies and see how we can be more efficient, creative, user centred, and responsive.
Some of the loudest cheerleadeers for the ‘anti-documentation’ corner is the crew at 37 Signals. They’ve been talking up their development methodology, which they call ‘
i like the way that they work a lot. It sounds like a great place to work and it would be great to spend more time designing and testing and less time documenting.
What I’m looking for, as I read this eBook, is methods that I can bring back to my work environment. An environment that’s not a startup and not building the next best 2.0 application.
I’m hoping that I can get to the end and draft my own new methodology… the working title to date is ‘getting realistic’. What do you think?