How much architecture does an agile team need up front? Most agile methods are surprisingly silent when it comes to this question. Scrum regards architecture as an issue the team has to deal with on its own discretion — and thus does not include any advice. In Crystal Clear: A Human-Powered Methodology for Small Teams, Cutter Senior Consultant Alistair Cockburn suggests having a lead designer who is responsible for creating the system architecture description — “usually fairly early in the first iteration” — but also emphasizes that “the architecture will probably evolve” and gives two strategies to help evolving: Walking Skeleton and Incremental Rearchitecture.
XP finally suggests using a metaphor to keep up the technical vision of the system; unfortunately, one of the most neglected practices of XP. XP also relies heavily on refactoring to evolve the architecture in addition to unit tests to scaffold it. In the second edition of his book Extreme Programming Explained, Cutter Senior Consultant Kent Beck finally introduced the architect as a role in the XP team, emphasizing that,
Architects sign up for programming tasks just like any programmer.
Consequently, whenever there is an open space on agile development, the architecture question comes up invariably: “How much architecture do we need up front?” My standard answer to this question is: “31 square feet.” Since the answer is not obvious, I will explain it a little bit further.
First, we have to understand that there is no software system without an architecture. The architecture may be adequate or not, it may meet your nonfunctional requirements or not, it may be helpful or troublesome, it may be obvious or extremely dodgy, but it always exists. There is no way to build software without building an architecture. But of course, there are millions of well-trodden paths toward extremely bad architectures.
The second insight is that there is only one place where the true architecture of a system resides: the code. You may have tons of PowerPoint presentations about “your architecture” or not a single one: in any case, it is only the architecture living in the code that determines the nonfunctional behavior of your system, such as maintainability, readability, performance, scalability, and so on. Therefore, architects not walking in the code up to their waists are similar to nannies refusing to meet children — and as helpful.
This also means that there can be nothing like an up-front architecture before coding starts: no code, no architecture. All you can have is an up-front vision of the architecture, a goal you’re heading for. The vision may be very coarse, like the XP metaphor, or extremely detailed, like the 200-page architecture document I wrote back in 1993 for my first crashed project.
So we have to rephrase the initial question: How much up-front architectural description does a team need to create a software system with a helpful architecture? Today, many architectural choices are already made by frameworks and application servers, so there is no longer any need to deal with all the details of database access, transaction handling, and all this stuff in many projects. But every project needs a domain vision — an idea shared and followed by the whole team about the structure of the core domain classes and how they interact. A good architecture consists of only a handful of classes, maybe six or 10. Everyone in the teams is on a first-name basis with these classes, and everyone knows under which classes’ umbrella new, smaller classes belong. The structure of these core classes is quite stable and usually not subject to refactoring.
The size of a standard white board is 31 square feet. This should be sufficient to capture a UML-like diagram of these classes as it was developed very early in the project. The white board should be easily accessible in the team space and this should be the place where architecture and design discussions are conducted. For many projects this is sufficient unless they have extra documentation requirements, in which case I suggest writing the architecture description document quite late based on what you extract from the code. If you are surprised by what you find, you may have an interesting issue to talk about during your next retrospective: not only the fact that the vision may have gone astray, but particularly the fact that you were not aware of the problem earlier when you worked on the code.