3.8 Engineering
Everything until now bought you speed — engineering is where you spend it, turning live specifications into production-ready code one small merge at a time.
In 3.7 Elaboration every feature in the product increment arrived in the increment backlog as a set of INVEST-shaped stories, each with Gherkin scenarios for validation, each live-linked to the design artifacts that model it. The specifications are deep enough to test. The stories are small enough to finish. The dependencies are sequenced.
Introduction
Now we build — and here’s what’s a little different.
Most methodologies treat engineering as the moment the real work starts — the point where design documents get set aside and the team starts improvising. In this playbook it’s the opposite: engineering is where the work gets easy, because everything since 3.3 Identify product increment has been an investment in making this activity fast, calm and predictable. Teams that struggle during the build are almost never struggling with the code. They’re struggling with ambiguity — unclear requirements, untestable acceptance criteria, designs that live in someone’s head. We spent five activities eliminating exactly that ambiguity.
There’s a reframing worth holding on to as you work through this activity: engineering is not where quality gets added. It’s where quality gets proven. The specifications your team formulated in 3.6 and elaborated in 3.7 already define what “correct” means, at every level the system is tested. The engineering activity makes those definitions executable — and then writes the code that satisfies them.
If you’ve been following the Behavior Driven Development arc across the last two chapters, you’ll recognize where we are. Discovery and Formulation happened in 3.6. Elaboration deepened the scenarios in 3.7. This chapter completes the third stage of BDD: Automation — connecting Gherkin to executable test code, so the specifications stop being documents about the product and become part of the product.
Hey, quick favor? Writing this stuff takes real work — and referrals keep the publication alive. If you’re finding the playbook valuable, share it with a friend who’d appreciate the link.
Getting ready to engineer
Like every delivery activity, engineering builds on what came before — and it’s unusually unforgiving about gaps. A missing specification during a workshop costs you an awkward pause. During the build it costs you a stalled story, an improvised design and a defect discovered three environments too late.
Check the definition of ready before the build starts:
The pipeline deserves special mention. Chapter 2.8 Delivery processes & tools built the machinery this activity depends on: ephemeral environments, test batteries, automated security scanning, release orchestration. If your pipeline can’t take a merge from trunk to a production-ready state without a human pushing buttons, stop and fix that first. Everything in this chapter assumes the machinery works.
