What's below the Surface of the Agile Design Iceberg
Since the early days of agile, there has been a healthy debate about the arguably diminished role of design in agile methods, and it remains a contentious issue today. But looking for guidance on the web can be frustrating until you realize there are two distinct types of design being discussed, each with its own relationship to agile. Knowing how these design perspectives relate and clarifying their roles can help agile teams determine the appropriate emphasis on design.
As agile development partners with the customer, there is a tendency to focus on the design of the user experience (UX). UX design focuses on the GUI and the manner in which the user accesses and interacts with the application.
The other, more architectural interpretation of design covers the structuring of the solution into components and their interfaces, interactions, and integration into the required solution.
The two facets of the solution design are closely related, and the trusty pyramid shown below can help represent these separate layers of design abstraction. The pyramid also serves to identify the level of design visibility that is provided to those outside the core development team. What results can be considered a design “iceberg,” with a “watermark” representing the demarcation between what is made visible to users and what is kept undocumented and internal to the development team.
At the top level, there is little question that agile principles integrate easily with UX design. It is a critical aspect of any software product, and it is, naturally, where the user can have strong views. Further, GUI prototypes can quickly and easily be turned into working software, delivering on one of agile’s core promises.
Software architecture, the next level in the pyramid, is where agile’s approach to design deviates from the traditional top-down approach. While design is integral to achieving agile’s aims of simplicity, actually documenting an evolving and emergent design has been actively resisted by agile developers as a vestige of plan-driven development.
But it is also clear that making difficult design decisions too visible could invite unproductive discussion and debate, and guiding an emergent design can be challenging. The lack of design visibility at the architectural level is further compounded by the reluctance of agile developers to adopt the Unified Modeling Language, even as designers have taken to agile modeling.
The result of this confusion is a tendency to miss capturing this layer of design and to focus on the detailed design represented in software code. While that may be appropriate, it presents a barrier when communicating design decisions to nondevelopers. But any decision the team makes on capturing the design is fine, so long as it stays within the team and below the line—or “underwater,” in iceberg terms.
The important question is whether there is value in making the architectural design visible. When a team is working in isolation, the benefit is debatable; but when there are constraints or interfaces with which multiple teams have to work, it can pay to expose more of the design iceberg. This would allow teams working on separate aspects of the solution to have visibility of the design decisions so they can better adjust and coordinate their development efforts.
Whether to have design visibility dialled up or down is really a question of the need to communicate with others outside the team—people who may have to see more than just the tip of the iceberg.
