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 ‘Getting Real‘ for a while now. They’ve just released a book. I’ve just bought it and, now that I’ve finished reading my Tim Winton book (review coming soon!), my bus reading is going to get a whole lot more work related as I plough through their 171 page manifesto.
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?
:)
Technorati Tags: functional+specifications,, process,, methodology,, specifications,, documentation,, 37+Signals,, Getting+Real
and also, a side issue … can the DEVELOPERS *really* cope? In my experience, they usually prefer to have EXACTLY what they need to do mapped out…
(Prepared to be shot down in flames)
M
There are large parts of agile methodologies that I REALLY like: small teams, short/rapid iteration cycles to quickly test (and cheaply fail if necessary), and the “light” documentation load. Note – “light”, not non-existent. Although I believe that the work should be in small but useful chunks, and put together in a modular fashion (think asynchronous, loosely-coupled service orientation), there HAS to be a ‘big picture’. Somebody has to be able to articulate a vision, or some desired endpoint (it doesn’t have to end up that way, but if it changes you have to know WHERE you are changing, WHAT you are changing, and WHY). The user stories (as a requirements-gathering exercise) have to demonstrate how they contribute to the final picture, but in my experience can never be complete and comprehensive enough, nor static enough, to be cast in concrete as a “functional specification” – you have to give the client something to trash quickly so that they can crystallise their thinking.
@Melissa – depends on the developers. Small teams of smart people will usually find their way without needing monosyllabic explanations and micro-instructions!
“Where resources jump on and off projects in response to upcoming deadlines, can this be achieved without specs and sitemaps?”
*cue hysterical laughter* Oh please. You’ve seen how well we cope when we _do_ have specs and sitemaps.
I think it depends on the developers, but it also depends on the developers environment.
Some problems that we tend to have in agencyland are:
a) constant interruptions. Developers don’t have a chance to get into a zone where they can really concentrate on the task at hand. Its a wonder they get any work done at all. They’re expected to jump on and off projects all through the day, and field all kinds of questions from all and sundry. (note: this is not unique to developers – designers and producers and others all suffer from this).
b) disincentive. Often, the focus on the project is marketing, not technical. Speed to market and creative execution is paramount. Technical excellence (or even writing great quality code that can be used again and is valuable).
c) stupid timelines/budgets. Often, even if a project does set out with a goal to write totally sexy code, the budget or time constraints make this unfeasible. In the end, the best you can do is hack something together as quickly as possible that looks, at least on the surface, that it works… for now.
That’s a whole other set of challenges though.
Here a question… (or two):
How do you manage the scope of a project with a client using agile methods?
How do you reach a clear enough agreement on where the finish line is that you can send them an invoice when you get there? (assuming you’re working on a milestone and not a retainer model).