3.0 Delivery (phase 3)

Phase 3: Creating detailed technical specifications, engineering work, and building a product increment that is ready for production.

Introduction

Delivery is the third phase of the playbook. This phase is an iterative cycle that focuses on identifying the next high-value product increment, elaborating design, engineering the product, and delivering.

Protecting product value is also an important theme. Accordingly, security, governance and value stream engineering topics are covered here.

Delivery activities occupy the “north east” corner of the subway map.

There are nine activities included in Delivery:

  1. Value mapping
  2. Security & governance
  3. Identify product increment
  4. Tactical event storming
  5. Modeling
  6. Specification
  7. Elaboration
  8. Engineering
  9. Validation

It’s worth noting that “delivery” (or deployment) is not on the list, which may seem odd. The playbook models delivery as the first activity in phase 4, Operations. In this regard, development and operations share responsibility for getting software into production. Many responsibilities for operating the software and sustaining continuous delivery fall to both Delivery and Operations.

Overall goals

The objective during Delivery is to identify the next high-value increment of software and get it into production. This means carefully considering features, weighing the value of those features, and selecting features of high value to the customer.

After identifying the next product increment, necessary fidelity is added to your design artifacts. Tactical event storming adds more detail about how technology fulfills the business processes. Specifications and engineering diagrams are added — but only where needed and helpful. There’s no point in over-designing.

Once the engineering specifications are of suitable quality, the build starts, we apply value stream engineering and validation at each step, and we deliver. Delivery into production happens in the Operations phase, but it’s entirely automated — the transition from development into production should take a matter of minutes.

After moving a feature into production, we iterate: selecting the next increment, and getting it into production.

Delivery is intended to move quickly. That means working in small increments, not “feature trains” or monolithic releases. Getting “just enough” into production is very important, even if it’s a small feature. It’s how we create agility and respond quickly to new information. The companion article on using a steel thread talks more about what “just enough” is.

Phase 3 stage gate

Delivery starts with two activities: value mapping and identifying a product increment. These two activities are co-dependent — you can’t choose an increment if you haven’t evaluated the feature’s value.

Before beginning Delivery, make sure you’re ready. This definition of ready helps ensure you’ve got everything you need to proceed:

If any preconditions haven’t been met, go back to Blueprinting and wrap them up.

Activity sequence

As shown in the subway map, you may find it suitable to conduct some activities in parallel or in a non-linear sequence.

If you’re just getting started with Delivery, you’ll want to begin with one of these activities: