Emergent Design: Leveraging Agile Retrospectives to Evolve Your Architecture


all questions together or a separate Design Retrospective. However, to those teams who fear that not all team members are capable of understanding architectural issues during, we point out that asking all six questions together is an opportunity for the Team to help those who may not be up to speed (see Figure 2).


Figure 2: Evaluting Value and Debt Via Design Retrospectives


Note that the six questions at the Sprint Retrospective, or three questions plus three more at the Design Retrospective are not quite enough on their own to evolve process and design. Some kind of "heredity" or Team memory must be maintained. Whether on a wiki or on the Team planning board, each of the Team decisions must be kept visible. There should be opportunity at the next Retrospective to review the changes that were made and see if they helped, harmed, or had no effect. And the process repeats, Sprint after Sprint, perfectly adapting the Team's process - and the system design - to its environment.

The Architect as Technical Product Owner

Agile principles encourage us to deliver demonstrable product. If reducing technological debt is important, the entire product must include not just system features, but also the capability to produce those features according to shifting business needs (see Figure 3). Briefly, this means considering "the product" beyond the usual definition of the features of the software. Instead, the "entire product" must be viewed as the composite of the software's features, the software's design (which helps the Team make new features), and other capabilities. [v]


Figure 3: Viewing the "Entire Product"


This view implies a shift of roles for the Architect away from designing the overall solution and leaving the coders to fill in the blanks. The Architect must think beyond assembling pieces developed by "mere coders" into a unified whole. Nor should the Architect be content to use UML diagrams, patterns, or high-level component design to constrain how the coders will work. All these behaviors smack of Big Design Up-Front, and will lead to the unhappy situation of technological debt being created before the software even exists.

Rather, the Architect should be thought of as the Technical Product Owner, with ongoing responsibility for limiting technological debt to the business. Just as a Product Owner is responsible for answering questions on what the system's capabilities should be, and sets priorities based incremental estimates of ROI, the Technical Product Owner should be responsible for specifying what the capabilities of the system design should be, and setting priorities on work which will improve the Team's ability to add new features.

We have actually seen a user story written in this spirit: "as Bob the Frustrated Operations Guy, I want Engineering to be able to swap in different file output components, so that the system can generate different file formats without waiting for a months-long software development cycle."

A caveat about this new Technical Product Owner role for the Architect: the ScrumMaster must pay attention to the dynamic between the Product Owner and the Technical Product Owner. When we use Agile methods, the Team must move as a unit and make decisions together. Just as QA staff are the part of the Team focusing on quality, the Architects are the part of the Team focusing on good design. But they are still part of the Team.

Two failure modes to watch for are the Subordinate Technical Owner and Dueling Product Owners. In the case of the Subordinate Technical Owner, design work is continually deferred in order to get "just one more feature" into the system. We

About the author

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.