In our white paper “Sprint Zero: Where Your Software Project Begins”, we talk about the planning and preparation phase of our Agile software development process. As you may have noticed, one of Sprint Zero’s most striking features is its short duration. This often raises questions.

Some people assume that Agile is undertaken at the expense of architecture, that software is merely thrown together on the fly without adequate design effort. But is this “zero architecture” assumption really valid?

To answer this question, we need to define “architecture”, a term that invariably conjures images of detailed blueprints spread out on large tables. But what is it really?

In our white paper “The Importance of Software Architecture”, we define architecture as “a plan that describes significant systems decisions from a variety of perspectives, all of which are aligned with business goals”.

So architecture describes a set of important decisions…

Do all of architecture decisions need to be made in advance?

For traditional waterfall development—a sequential, big-bang approach that’s front-loaded with extensive design activities and exhaustive requirements gathering —the answer is “yes”. (Cue the montage of architects pouring over a mountain of blueprints, desperately hoping they haven’t missed anything.)

For Agile, the answer is “no” because its iterative process allows you to make decisions when you need to make them. But you still make the decisions! The architecture is not left to chance.

Does Agile mean zero architecture?

No! Agile means better architecture because decisions are made at the right time, with the right information. No guessing. No crystal ball required. So one final question:

Do you think IBM or Google would embrace a zero architecture approach?

No, of course not. But they have embraced Agile—and so have we.

(Cue the montage of Agile architects calmly building great software. Fade out.)