The inherent objective for engineering is to enable and support the business/product goals and strategies by developing, delivering and supporting services for our customers. Yet as businesses grow, in terms of customer base, products, engineers/teams and inherent technological complexity, this task becomes increasingly difficult. While the Agile Manifesto values “individuals and interactions over processes and tools” and “working software over comprehensive documentation,” this approach is less effective at scale.
Enter the Blueprint, a shared document that captures the key problem to be solved, requirements from product and other stakeholders, and a high level design focused on things that could be expensive to change later. Blueprints can save weeks of coding by creating a shared architectural mindset, streamlining cross-organizational knowledge sharing, eliminating redundancy and creating new communications paths. One of the most useful sections of a Blueprint, counterintuitively, is “rejected alternatives,” and the rationale for these, saving valuable time and increasing engineering productivity.
The speaker examines the elements of a good Blueprint, at what points in the engineering process to use and modify them, and why better, more visual communications tools and techniques are one of the best investments you can make.
