I have in previous posts (here and here), critiqued commonly used metaphors intended to illustrate Agile philosophy and benefits. Given those critiques, a question left unanswered is, what is a good metaphor for software construction projects? I think of house planning and construction as a suitable metaphor for enterprise system planning and construction.
As motivation to think and act differently, I consider the Winchester Mystery House as a cautionary tale of the house that undisciplined Agile built. In addition to its 24,000 square feet, 10,000 windows, 2,000 doors, 160 rooms, 52 skylights, 47 stairways and fireplaces, 17 chimneys, 13 bathrooms, and 6 kitchens, the house features anomalies such as stairs leading into the ceiling, windows in interior walls, and doors opening to brick walls or precipitous falls. One can imagine the house being built one room at a time, each based on perceived highest customer value at the time, but without any overarching plan for efficiency, holistic utility, discoverability, or a host of other useful design concepts (imagine a guest trying to find their way to a bathroom without a map or a native guide!).
In house construction there are opportunities for a range of planful vs. Agile design decisions and building so that the resulting house has durability and is built efficiently yet has appropriate decisions made just-in-time vs. building a house completely Agilely. Naturally one considers the orientation of the house to the land and its surroundings, and the complete floorplan before construction begins with laying the foundation. Those elements must reflect some but not all of the overall requirements. This ensures that those committed parts of the design meet requirements within known constraints and avoids extremely costly rework at later stages of construction. Decisions can be made later in the construction for elements like cabinetry and fixtures because they can change with some impact to other elements but without major reconstruction. And decisions regarding more cosmetic elements like texture, paint, flooring, window treatments, etc. can wait nearly until the house is finished before they must be decided.
If we apply this approach as a metaphor to software development, we can see a need to partition requirements into categories based on their expected impact on the durability of the design and potential cost of rework. Some requirements will drive key architectural decisions that will permeate the design and so should be discovered and accommodated early. At the other end of the spectrum, some requirements will drive only superficial features of the design and can be discovered and accommodated late or iteratively as suits the project. Other requirements will range between those endpoints and may require some short-term look-ahead in planning or be accepted as sufficiently low-cost to re-factor that some iterative development is appropriate.
Among Agile methods, Scrum, as originally described, supports this type of approach, committing to some fundamental design elements early in what is called the “pre-game phase.” So we might conclude that the metaphor works as a representation of Agile behavior at least to some degree. As with all metaphors it likely misrepresents some aspects of the modeled behavior, but which ones? Where does this metaphor fall short?
