Don’t listen to 37signals
From ‘Getting Real‘ by 37signals;
“…success isn’t the only thing you’ll find in the details. You’ll also find stagnation, disagreement, meetings, and delays. These things can kill morale and lower your chances of success.”
“Forget about locked-in specs. They force you to make big, key decisions too early in the process. Bypass the spec phase and you’ll keep change cheap and stay flexible.”
If you haven’t read ‘Getting Real‘ I highly recommend it.
I greatly enjoy the book and appreciate much of the content, but I have to wonder if the “agile” attitude to design is so easily accepted because it encourages laziness. If planning is distasteful to you then saying, “Screw specs we don’t need em!” is extremely easy. It’s probably not beneficial though.
Saying specs are unnecessary and they prevent ‘agile’ work is akin to throwing the baby out with the bath water. A well thought out plan prevents problems. If you’re in an environment that says the spec is the golden rule which cannot be broken, then throwing out specs, for a while, may be a good idea.
If you find yourself constantly modifying features, encountering delays based on client expectations, or are in a continual state of crisis, it might be worth your time to develop some preventative maintenance.
Agile is defined as, ‘Being able to move quickly and easily.’ Agility can be achieved by a lack of planning, sometimes. Most of the time this is not the case. If you’ve got a development team that’s worked together for years, has some sort of a psychic mind meld, or you’re just one person working on a personal project, you may be able to launch faster without specifically defining your product.
However, if you’re working on a team without a telepathic connection, I’d recommend you take the next best route. Write out a game plan. If you don’t have someone who’s capable of writing a decent spec, hire one. Having a good plan will only enhance your agility.
Make the spec agile, change it when you need to. You’ll never be able to anticipate every issue that will arise in a project, but planning for what you can anticipate will save you from unnecessary deliberation and disagreement. Don’t sacrifice the agility that having a well written spec can provide, embrace it.
Here are several great articles to get you started.
Marshall is slightly crazy. You can read about his adventures in Europe at the incredibly entertaining LazyVoice.com
June 20th, 2008 at 10:47 am
I can’t (and don’t) speak for 37signals but I have worked in, managed, trained and coached Agile teams for years. He’s the thing with Agile development and planning: we plan all the time. Summed over the life of a decent sized project we probably plan a lot more than a (so-called) plan-following team would. Because we plan all the time.
We plan the whole project. We plan each release within the project. We plan the iterations within each release. We plan each day’s work, daily. We plan our next line of code.
And specifications! We specify everything in great detail, often a good long time before it gets built. We get our users to write hundreds, thousands, of executable specifications (some sentimental old-timers call them “tests”). These are very detailed, very precise. And we do automated checking of our system against those specifications many, many times a day.
Specify, plan, check, plan, specify, plan, check on and on it goes. It’s a miracle that we get any time to write code. And when we do, we do so only under strict adult supervision.
If you find yourself constantly modifying features, encountering delays based on client expectations, or are in a continual state of crisis (do you notice 37signals doing this?) then whatever your process is called you’re doing it wrong. A well-run Agile team doesn’t experience this, and they don’t have anything like a traditional spec written by some third party who’s capable of writing a “decent” one, and they certainly don’t have any sort of mind-meld.
There are plenty of successful Agile teams around now. They tend to be friendly. Why don’t you go visit one and see how they really work?
June 21st, 2008 at 1:24 am
Keith, thanks for your thoughtful reply. I hope I didn’t come across as unfriendly. My goal was not to alienate anyone with this post, rather to suggest that organization is essential to agility. A specification is merely one tool that can encourage organization and effective communication. How you achieve that organization will vary from team to team. In hindsight I probably ought to have been clearer about that.
I also should clarify that I would not suggest a team run out and hire someone who can write to start churning out specifications for them. Anyone writing a spec ought to be highly involved in the projects they’re organizing.
I think 37signals does fantastic work. The post title was meant to be tongue in cheek. I appreciate everything of theirs I’ve used and read. I am however worried that the material I was quoting could be misinterpreted as an admonition to abandon planning.
June 21st, 2008 at 3:04 am
Hi Marshall. I wouldn’t say that you’ve come across as unfriendly. More as ill-informed to the point of not making any sense. For instance, Agility can not be achieved by a lack of planning at any time. And I’d be amazed if anyone in the Agile community claimed that it could.
I wouldn’t care so much if the Agile brand weren’t part of the way I make my living. But it is, so I tend to get a little bit ticked off when it’s used in public like this as the label for some straw man “sloppy approach I disaprove of”.
June 23rd, 2008 at 9:12 am
I can certainly see why you feel that way. My apologies.
If you’d ever be interested in doing some articles on Agile development I’m sure EC would be honored to post them here.