Simple Design

The word design is from Latin ‘de-‘ meaning remove and ‘signere’ meaning mark.

Simple Design means removing non-valuable system behaviour by adding solution constraints, iteration by iteration until the system interface evolves into what Steve Jobs called the elegance of minimum. Ron Jeffries describes it as the process of adding value by removing that without.

There are many schools of design each with their own pattern languages. XSCALE isn’t concerned with the design language specifics, but the application of Agile principles to enable reliable evolution of design into products that obtain „the elegance of the minimum”. To achieve this a design process is needed that accommodates:

• Whole Board Thinking without which key solution constraints will be missed, leading to over complex designs that fail to meet a user’s basic expectations, and time is lost pursuing blind alleys in solution space that are in fact precluded by known constraints.
• The inherent tension between the desire to perfect product design and the desire to ship imperfect products early enough to open markets and refine design by learning from market analytics. This is not an either/or choice – both are essential.
• The closure of solution constraints as acceptance criteria. We can represent these on a acceptance matrix with themes representing categories of solution constraints and features embodied in spikes. Then behavior driven analysis makes certain we take all design perspectives into account.
• Iterative refactoring is the essential Agile design minimisation process, generating system interfaces without unnecessary feature duplication or clunky, modal user experience design (UX).
• We assume Impact Mapping, user journeys and similar have established a clear definition of the critical numbers that would enable successful definition and delivery of an epic. These numbers scope and act as a starter set of solution constraints.

Simple Design is a tight iterative loop for learning solution constraints and evaluating design options. It is usually carried out during a release’s sprint zero by a squad that includes technical authorities, design authorities and business authorities. This may be just the product squad, or it may include technical portfolio members who are normally involved in delivery or support activities.

1. Design stories each take one of three forms
   • Spikes to be evaluated to discover solution constraints and test customer behavior.
   • Analytics to be implemented to evaluate the behavioral response of customers to the spikes.
   • Refactorings to simplify and integrate the features of multiple spikes to form the basis of another iteration.
3. A weekly sprint cycle where
   • Sprint planning applies behavior driven analysis and Business Bingo to determine priorities for the design stories. Stories that are invalidated by known constraints may be removed from the backlog without reaching “done”.
   • Sprint reviews add, modify or remove solution constraints. As themes based on learnings, they also assess whether the last responsible moment has arrived to settle on a design.
   • Sprint retros focus on rate of learning and enable participants to put new ideas for different design options on the table so long as they at least satisfy the epic’s starter set of constraints.
4. Some design choices must be ratified by the portfolio squad:
   • If the last responsible moment has come and there are still no acceptable design options, the portfolio squad will have to do some release refactoring, possibly deprioritising the corresponding epic and repurposing the product squad.
   • If subject matter expertise in solution space, design space or problem space is lacking, the matter should be raised with the portfolio squad.
   • The portfolio squad should also be notified if the preferred design option can’t integrate with present architectural norms or the portfolio’s non-functional envelope. Unless this is the case, full responsibility for approving the design rests autonomously with the product squad.