What Is It
Design is what you do every time you think of an action to mitigate a risk. And Big Design Up Front is where you do a lot of it in one go, for example:
- Where you think about the design of all (or a set of) the requirements in one go, in advance.
- Where you consider a set of Attendant Risks all at the same time.
Compare with “little” design, where we consider just the next requirement, or the most pressing risk.
Although it’s fallen out of favour in Agile methodologies, there are benefits to doing this sometimes.
How It Works
As we saw in Meet Reality, “Navigating the Risk Landscape”, meant going from a position of high risk, to a position of lower risk. Agile Design is much like Gradient Descent: each day, one small step after another downwards in risk on the Risk Landscape.
In these cases, you have to widen your horizon and look at where you want to go: and this is the process of design. You’re not necessarily now taking steps on the Risk Landscape, but imagining a place on the Risk Landscape where you want to be, and checking it against your Internal Model for validity.
Feedback Loops & Mitigated Risks
The feedback loop for any design is Review and Sign Off.
By allowing lots of stakeholders to review and agree to a design, or select from alternatives, we try to reconcile the needs of lots of stakeholders early on in a project.
To allow for discussion and understanding of the project between multiple parties. This may extend to design being marketing material to help explain the project to potential clients or budget-holders.
To ensure an overall aesthetic or architectural integrity, avoiding the Technical-Debt that you might accrue by building the wrong things first.
Often, by thinking big-picture we can avoid building components that seem like a good next step, but actually aren’t.
Building architects appreciate that their plans might change: Roman ruins might be discovered underneath the site, or the supporting wall might not be as sound as originally thought. The more effort you put into a design, the more will be wasted if it’s wrong. So, how deep should you go? The answer as usual, is keep designing while it is reducing your overall project risk.
- The design might itself take a long time to complete Schedule Risk.
- People stop thinking once they have a design, even when reality obviously deviates from what the design assumed. But the whole point of a plan is that it’s easier to change than the thing you are doing the plan for.
- If your plan starts to become as detailed as the code would be (but doesn’t run) then you’ve made the mistake of overspecification, and you are creating Technical Debt.
Everyone has a great plan until they get hit in the nose - Mike Tyson Fail to plan and you plan to fail - Eisenhower?
Risk-First design example ; building the research indexer
Add Your Star On GitHub to receive an invite to the GitHub Risk-First team.