Continuous design in Agile development

Ron Jeffries of XP fame:

“If I’ve got six months to build a system, then I’ll spend six months building it. I’ll also spend six months designing it, and another six months testing it. The good news is that it’s the same six months”.

Seems like the best (and obvious) thing, right? Build the design based on your knowledge, which you acquire as you work on the project and encounter problems and design choices.

But begs the question: Is there a place for an Architect in an Agile environment and is there any value in an architecture document?

An architecture document is a system design that answers key design problems and breaks the system down into manageable and extensible components. I’ve worked on big arch documents in the past when working in waterfall environments – looking back, it’s easy to see that we spent a lot of time agonizing over design decisions that couldn’t be properly answered until much of the code was written. So continuous design is good.

But how do you document it in a continuous fashion? We used to create Word documents but that seems like too much work if you are going to be changing it often as you will be re-arranging the document all the time. A Wiki? Some bespoke Agile tool? UML tool?

Or do you not document it at all? Is Javadoc (or your language’s equivalent) enough along with some auto-generated class diagrams? Perhaps the test cases will document the functions of the system and avoid the need for Sequence diagrams? After all, once the code is done, the tests pass and the system is released, what’s the architecture design document for? It can only be a reference tool for people coming onto the project later on.

Many people have said that an Agile design document should have “Just enough in it to get the job done”. Great in theory but a tough one to do – what’s just enough?