When Rough Design is Good enough
Rough Design Up Front can help create project momentum, shorten the overall development time, reduce risk, and help form a new team. However, deciding when the rough design is good enough for the work of construction to begin, is a crucial milestone in the life of the project. At SPAN we often start a project with an inception workshop. For smaller projects the workshop may be sufficient, but for larger projects, an iteration (or two) elaborating a rough design may be required before construction can commence in earnest.
Starting in the workshop, and continuing after, we collect and refine requirements in two distinct areas: Functional Scope, and Business Objectives.
Functional Scope (Epics and Stories)
Epics and stories collectively describe the functional scope of a solution - they comprise all the intended features and functions. We usually triage the scope into three distinct priorities based on business need and potential to reduce risk. Finer sequencing of the backlog can happen later — at this stage a rough prioritization is all that is needed.
Business Objectives
Business Objectives can be divided into two parts: Solution Capabilities, and Initiative Externalities. As discussed before, setting objectives for agile projects is a useful practice for agile teams. With a little effort, it is possible to frame the entire initiative with meaningful and measurable targets that define success. These targets can also be used to calibrate progress.
Solution Capabilities
Solution Capabilities define essential required performance characteristics of the solution. For example, a new vehicle could have a target set for its fuel efficiency as “twenty one miles per gallon in normal freeway traffic”. For most solutions, it is useful to define a few target values for measurable capabilities. Selecting the right capabilities, defining meaningful target values and measuring them is often challenging. Teams that fail to do this usually fail to deliver the necessary capabilities because they have no target to aim for, and no yardstick to measure success.
Initiative Externalities
All solutions are built in a business or political context. This context can often be summarized as a budget and a timeline made up of externally defined milestones. Design to cost and deliver on schedule is a fact of life for many businesses. Earnings calls, trade shows, and product launch schedules mean that delivering a viable set of features by a specific date is essential for success. Rather than fight these externalities, it is often better to produce a rough design that can plausibly satisfy the most important requirements well within the deadline, and only then evolve the remaining features.
Co-Evolving Requirements and a Rough Design
Creating a rough design is an iterative process with both requirements and design being developed in parallel — it is a negotiation between team members and stakeholders. The design artifacts embody the agreements and decisions that the team has reached. The process of requirements refinement and (re)design continues throughout the life of the project, but knowing when to transition the primary focus from design to construction requires balancing several factors: the maturity of the team, their familiarity with the problem domain, the size and complexity of the project, and the extent to which the requirements can be pre-stated or must be discovered. These variables are usually principal factors in deciding when to begin construction.
The six stages in the evolution of a design for a sophisticated medical work-flow solution. This design had to retain legacy components, shown in yellow. Notice how the yellow components gradually migrated to lower, infrastructure, levels where they could be encapsulated and managed. This design took a team of 6 people 3 weeks to define.
The evolution of a data model over several days. From a hand-drawn diagram on a whiteboard created during a workshop design session to a reasonably detailed model with working notes in Google Drive.
The five stages in the evolution of an architecture for a custom publishing solution for specialized time-series data. Notice how the final diagram is heavily annotated with links to corresponding Jira tickets.
The rough design usually comprises a handful of diagrams that represent a conceptual model of the solution and collectively explain the approach we are taking and how the solution will work. We continually review the rough design against the requirements, all the while asking the following questions:
Does the conceptual model account for system requirements at a reasonable level of abstraction?
- The conceptual model is sufficiently generalized when it can account for all significant epics and stories in a concise way that reduces complexity by consolidating similar features.
- The conceptual model is sufficiently specific when domain-specific concepts are reflected in the design of core components and domain-specific terminology (nouns and verbs) are used consistently throughout the design.Can team members use the design artifacts to explain the solution to stakeholders and each other convincingly?
- How will the solution deliver the required features and functions?
- How will the solution meet its capability targets?
- How can the solution be delivered on time and on budget and thereby meet external milestones?
Starting Construction
Construction can start when these questions can be answered satisfactorily and a backlog of stories and tasks has been prioritized covering the construction of the majority, but not all, of the design. How far we go in defining the backlog depends on the business need. If we are building to cost or building to a deadline we try to define at least 80% of the solution. If the deadline and or cost is less important than some other business outcome, then we may start with as little as 40% of the solution defined.
The design is good enough when:
- the team responsible for building the solution can confidently look each other in the eye and claim they understand what they are about to build (and have a reasonable plan for building it).
- the team feels confident that they can work out, as they go along, what they do not already understand.
Inevitably, during the project, we have to rethink many of our design decisions and plans. We seldom, if ever, implement a design without change, but this does not mean the initial work is wasted — far from it. We change our plan because we have learned valuable lessons, or need to adapt to changing circumstances. The initial preparation makes the inevitable adjustments and reorganization far easier, since the team has already learned to negotiate and compromise with each other, considered and evaluated many alternates, and is armed with a common vocabulary and understanding of the problem domain.
