Design Stories - A bridge between roles
This idea has been forming among our architecture group this week and I think it has enough potential to open up for public discussion. I'm hoping to get some good criticism and references to prior art I can draw on.
Overview:
Traditional stories provide a solid structure for understanding what value a given set of work is supposed to accomplish (i.e. Analysis). They do not provide a good means of giving a team guidance on HOW that is to be accomplished. On the other end, we have a great set of practices from XP and other sources that provide a means of creating very good code through pairing, co-located teams, etc.
Unfortunately, there is a gap present in most organizations. Where do you create a consensus about the architectural metaphor, that set of patterns and approaches that allows a good application to scale beyond a single team. Things like SOA can pull that decision making process out to the extremes, where there's a small body at the top working with services as a language, and teams that then take individual responsibility for their parts, but that doesn't extend to UI-intensive applications or to the deep complexity inherent in some domains. The core of the message is that Agile doesn't "do" detailed designs. There's a good reason for that: Detailed designs traditionally create a large transaction cost for each unit of work going through the system. When you've reduced batch sizes, the transaction costs become a higher portion of the overall per-item cost, thus making the detailed designs painful.
The design story template is used as the next layer beyond an XP-sized analysis story. It provides a mechanism for crafting highly focused design with minimal transaction costs. It also allows for training other members of the team on the design approaches as a core part of creating the design. In essence, each design becomes the process of filling out a small, defined template in the same manner as writing an FDD feature name or writing a BDD story. The part of this that is most interesting to me is that the design story follows a standard order starting with most generic (the story-level goal) and proceeds to the very detailed (what methods need created). Because of this, the architect [1] may stop writing at any point and allow a developer to write the remaining elements. In our organization, it will be reviewed, and the last line will frequently be left off. In others, the architect may stop after the third line and let a highly capable team member take care of the rest with no further interaction. It is entirely by intent that this template includes aspects that are typically left to the developer and starts with items that are usually left to the analyst or project manager.
This is a bridge between the value vision and the implementation, and provides a clear path towards training developers to handle harder, more abstract aspects as a part of their work and in a manner that is clearly relevant to their work.
Story:
In order to improve the user's perceived performance through a reduction of RAM usage,
we need to load preview quality images for the current page only.
This requires to make changes to page display behavior in the client,
using the established page mediator pattern through the page mediator factory,
to provide interactions between the project model's page changed event and the placement rendering
by creating a mediator named CurrentPageImageVisibilityMediator,
and writing the handler ProjectModel_CurrentPageChanged event that uses an ImageLoad asynchronous command to change the quality of the displayed image if the current page has become visible or ceased being visible.
Template:
In order to [goal of the story],
we need to [Decomposed software change supporting story].
This requires us to make changes to [the architectural/design components]
using [Identified patterns and approaches specific to the team/product]
to provide [specific interactions with existing components of this system]
by creating [specific class names to implement the patterns]
and writing [specific method names and behaviors]
Goals:
This came out of a few needs at Inkubook.
- Developers wanting to grow in their craft and learn the design and architecture roles
- Architects wanting to maintain enough control of the system's shape, but be able to effectively delegate
- Keep batch sizes small, thus needing to
- Minimize the transaction costs of each batch.
- Different developers have different abilities, and the approach needs to scale to any of them.
- Need to identify responsibilities without overwhelming the process
- The need to provide meaningful review early in the design process
Influences:
There were a number of easily identifiable previous influences on how I was thinking, such as:
- Communication pattern of "Describe a need, then ask to have it described back to you"
- My understanding of FDD the concept of a Design Memo
- Knowledge of BDD's "examples" notation
- Desire to fit with an XP or BDD style "story" format and feel
- The concept of the cone of uncertainty
Shu Ha Ri
[2] A good description of Shu Ha Ri can be found here. To summarise, the concept comes from the Japanese martial art Aikedo and refers to the three stages of learning.
Shu is the first stage, where the student is imitating and following the master’s steps
Ha is the second stage, where the student is showing understanding, and breaking away from the master’s steps
Ri is the final stage, where the student is showing mastery and fluency by creating their own steps
Mapping the concept of Shu Ha Ri into this story template, I believe that developers will be able to progress through all three stages for each of the lines in the template, at times in parallel. I want to do more evaluation of the androgogical aspects of using this sort of progression for teaching our craft more effectively, but that is something for another day.
Notes
[1] I'm saying "architect" in the sense of "the person whose job is to define the approach used in designing the application and for teaching that approach to the various teams involved". I understand the role changes based on system size and organizational structure.