of emergent design, and keep our technological debt low, is the Scrum Retrospective.
Retrospectives are enablers of emergent behavior via the three pressures of innovation, selection, and conservation. Biological life adapts to its environment over time through these same three pressures: mutation creates new traits in an organism, and its survival (or not) within its environment selects for the chance to conserve its own traits by passing them on to its offspring (or not). Given enough iterations of this process, characteristics emerge - in ways which no human could imagine ahead of time - that enable the organism's perfect adaptation to its environment. [iv]
Retrospectives enable this same effect for the development team, their process, and their product, with three traditional questions. Asked as a matter of rote behavior with the answers then filed away never to be seen again, these questions at best produce an improvement for one Sprint, and at worst are little more than a chance for the Team to vent.
Applied correctly, these simple questions evolve an Agile process that works perfectly for the team and enables it to thrive amidst the complexity of its environment. By "correctly," we mean that the Retrospective enables selection, conservation, and innovation not just for one Sprint, but repeatedly across multiple "generations" of the Team:
- Ask "what went well." The ScrumMaster should ask the Team what it needs to repeat such good effects; obtain formal licenses for the tools that were used on a trial basis and worked well; share successful behavior with other teams... in short, work to conserve these good team traits.
- Ask "what didn't go well," as a way to select out traits that hurt the Team, and for each "didn't go well" item, be sure to ask:
- "What could we change to improve this issue?" For each "didn't go well" item, the Team innovates to identify actions it can own, or that the organization must own. Team-owned changes either become Backlog Items, or behaviors of which the ScrumMaster must keep the team aware. Organization-owned changes become Organizational Impediments which the ScrumMaster must work to resolve.
We can incorporate these same selective pressures when it comes to architectural decisions. The following design questions can be asked as part of the usual Retrospective, or they can be conducted during a separate Design Retrospective:
- Ask "what part of the design (code) delivered value?" The best designs are often those that are birthed out of refactoring which, by its nature, implies design should be iterative. These portions of the code should be held up as "adding value."
- Ask "what part of the design (code) should not survive?" The Team targets those parts of the system which made it difficult for team members to add value.
- For each item that made it hard for the Team to work, ask "what can we change in the design, or add to the design, to achieve the current needs of the business within good design standards?" The Team applies its innovative powers toward the problem of adding value beyond that of system features, and generates work to do in future Sprints.
As for output from these design questions, it should be up to the Team to determine if having a Design Story or having a Design Task for each Story works better. Teams will differ on how they like to work. The important part is not the mode of capture for the design, but how much value in the end that the design has delivered.
The team should also be allowed to choose how to apply the design questions at the retrospective: