First of all, a reminder: My book, Building The Agile Database, is finally out, and is available through Technics Publications and Amazon.com. My thanks to all of you who attended my presentations at TDWI in San Diego, and at CA’s ERWorld virtual conference last month. I’ve really enjoyed talking with you, listening to your stories and answering your questions about Agile data development.
One of the questions I’m most often asked (and one of the greatest concerns that data management professionals have about Agile) is whether an Agile approach abrogates the need for a clear requirements definition up front. A second and related question is whether Agile abrogates the need for up-front architecture and design activities.
My standard response to the first question is that Agile doesn’t eliminate the need for clear requirements up front. It only eliminates the need to have all requirements clearly defined up front. I make this point in my book, derived from my experience as a carpenter and landscaper. On a construction or landscaping job, you usually don’t have all the requirements defined up front, but you have a clear idea of what you (or the clients) want the end product to look like, you know the rules about how to design and build things (including any relevant building codes and local ordinances), and you have enough of the requirements defined up front to at least be able to begin work. As you progress in the job, some requirements might change, circumstances might change (for example, the clients might discover that things cost more than they thought, and need to scale back a bit on what they want), or your understanding of the requirements might change. At each step, you evaluate what you’ve done so far, figure out what needs to be done next (including changes to what you’ve already done), and then you proceed to the next step. It’s OK for things to change, as long as each step brings you closer to the completion of the project and as long as the cost of the changes and iterations can be managed.
My standard response to the second question is that everything requires a certain amount of up-front architecture and design; again, you need to make a decision about how much up-front architecture and design is “good enough” to enable you to begin work.
Agile developers are fond of the following quote from Craig Larman: “Architecture is a bad metaphor. We don’t construct our software like a building, we grow it like a garden.”1 But anyone who has done both construction and landscaping (as I have) knows that a certain amount of up-front architecture and design is essential to the success of any endeavor, including both buildings and gardens. You don’t, for example, want to site a vegetable garden in an area that doesn’t get adequate sun or where the soil drainage is poor. You don’t want to put a patio or decorative pond in an area that will be under six inches of water in the winter or put shade plants next to a steel-sided building that radiates 105 degree heat in the summer.
Both builders and landscapers start their work by creating architectural sketches of the property involved, noting the areas of sun and shade, the path of the sun across the property at different times of the year, the direction of the prevailing wind, areas of high and low elevation, direction of water drainage, areas of well-draining and poorly-draining soil, slopes, major landmarks (buildings, streams, ponds, large trees), and so on. They then sketch in the work to be done (i.e., the building or garden features), updating the designs as work progresses. This up-front architecture and design work serves three major purposes:
First, it captures the scope and constraints of the project, so that impossible or impractical customer requirements are immediately identified before too much work is put into implementing them. A building architect may have to tell a client that the house can’t be built close to an unstable slope or that a six-car garage can’t be built where the drain field for the septic system needs to go.
Second, it provides the framework (context) in which the customer’s requirements can be captured and understood, so that everyone involved (the stakeholders) is on the same page about is to be done (“Yes, that’s right; I want a flagstone path to go between those two cedar trees, and end at a gazebo at the back of the shade garden.”). This allows requirements to be easily and accurately communicated to the people who will do the actual construction.
Third, it serves to mitigate major areas of risk in the project. For example, if building is going to be done on or near a slope, a geological engineer will need to be hired to examine the slope, evaluate its stability, and recommend measures that will need to be taken (for example, concrete-and-steel pilings and improved drainage) before construction can safely proceed. Not identifying and mitigating major risk factors at the beginning of a project is a blueprint for an expensive (and embarrassing) failure; I’ve seen any number of very expensive homes slide down slopes and be totally destroyed!
So, the “building” and “garden” metaphor is, to me, a false comparison. These metaphors don’t really reflect a choice between doing architecture and design, or not doing architecture and design. You need to do architecture and design! It’s just a question of how much architecture and design needs to be done, as well as when, where, how often, and by whom. As I say in my book, it’s important to understand what architecture and design actually are, and what value they contribute to a project (rather than simply dismissing them as “Big Design Up Front”). Only then can sensible decisions be made about how much of each to do, and when (and how often) this work should be done.
NOTE: I’d like to make this a dialogue, so please feel free to email questions, comments and concerns to me. Thanks for reading!
References:
-
Larman, Craig. “Large-Scale Agile Design and Architecture: Ways of Working”. March 18, 2011 (http://www.infoq.com/articles/large-scale-agile-design-and-architecture).
