A playbook gives us a clearly defined way to execute a plan. It is, literally, our “book of plays,” or tactics and actions for every situation.

This Delivery Playbook provides a set of rules, suggestions, and methods suitable for the execution of a technology development project at scale. It also makes sure customer value is identified, protected, and realized throughout delivery. No customer misunderstandings or disappointments.

The playbook provides detailed steps or “plays” for every activity in our development pipeline. It’s rooted in Domain Driven Design (“DDD”), behavior driven development, and modern engineering. It can be applied with any delivery methodology, including agile methods as well as waterfall.

If you haven’t read the playbook introduction, you might want to start there: It provides a deeper exposition of the benefits of using a playbook.

Audience

• Technology teams can use this playbook to guide their projects and quickly get started delivering high value software.

• Engineers can use this playbook to improve their own skills around successful software delivery, making them stand apart from their peers.

• Anyone interested in learning about engineering delivery will find this a valuable resource, particularly in regard to being thorough and consistent.

Callouts

Occasionally there will be important notes or callouts that don’t fit directly into the narrative of the playbook. These callouts will appear like this:

Callouts bring attention to important information related to the topic at hand.

Guiding principles

The playbook supports a wide variety of technology focused outcomes that encompass product design, software delivery, and business value engineering. At the heart of the playbook are some guiding principles that have shaped it over time:

• All work must address specific business value. This means that the value for any activity is always put “front and center,” and must be part of the process. In other words, we need to know what value is attached to any piece of work, and prioritize it accordingly.

• Specifications must be complete. This means establishing clear guardrails about moving forward. We cannot, for example, begin delivering code when we don't have clear specifications.

• Designs, blueprints, roadmaps, documentation and engineering diagrams are part of the product. We treat them all as first class citizens, equally important as source code. Merge requests can’t be approved without them, because the merge would be incomplete.

• Delivery is highly collaborative and strives for rapid feedback. This means making progress every day, working to commit and share work daily. But we don’t have a “complete whole” until all the pieces are done.

• The only path to higher environments is through automated verification. This means that engineers must test everything, thoroughly. No code can move to a higher environment without proof of success for all acceptance criteria, and nothing is done manually.

• We deliver from day one. This means we start committing immediately, and we build our pipeline from day one, using a “steel thread” approach.

Overall, the playbook is a map. The map is both figurative and literal. It’s figurative in the sense that we can imagine following a map from our starting point (the mobilization phase) to our destination (placing a product in an operating production environment). It’s literal in the sense that we do, in fact, have a visual map to follow: We call it the Delivery Playbook subway map, and it looks a lot like a subway map:

Much like riding a subway train, following the map tends to be somewhat linear. You are going from one place to another. There will be stops (activities) along the way, and sometimes you’ll switch trains. But ultimately, you follow the sequence of activities from start to finish, and you usually don’t skip any of them.

Reading the subway map

The playbook is divided into four phases. These phases correspond to major breaks in any product delivery process: Mobilization, Blueprinting, Delivery and Operations. Within all four phases are 28 separate functional activities addressing the major activities of the delivery pipeline. There is also a separate “pre-mobilization” activity. While very important, since it’s a single activity it doesn’t have a separate phase.

Each activity is represented as a “subway stop.” Subway stops appear as circles on the Delivery Playbook subway map:

The above drawing shows two activities, 2.4 Domain modeling and 2.5 Context mapping, from the subway map. These activities each have their own section in the playbook. A handful of activities are further broken down into multiple sections. For example, current state analysis is one activity that warrants several detailed sections.

Every activity defines inputs and outputs. These represent required information that each activity needs before you can start it, and the information each activity creates for downstream activities. Each activity’s inputs and outputs are described in detail in their respective sections. The subway map gives us a high-level view of these dependencies:

The above drawing shows that the 3.2 Security & governance phase requires information that is created during 3.1 Value mapping. We won’t be able to finish (or possibly even begin) the security and governance work unless we have our value map.

There are two directional flows in the subway map:

• Progressive flow. This flow is shown in blue, and is typically synonymous with moving “forward” toward delivery and operations. This is our day-to-day execution — designing, building, and ultimately delivering.

• Retrospective flow. This flow is shown in orange, and captures learnings and experiences into feedback that we capture by returning to an earlier activity. This is refinement. Examples include adding more fidelity to a design as we learn new details, or implementing a regression test to make sure a defect doesn’t pop up again.

Superimposed arrows help indicate the directionality. The above drawing shows our day-to-day progressive flow moving toward 3.4 Tactical event storming. It also shows there is retrospective opportunity to capture information and learnings during this activity, thus influencing overall outcomes.

The exact mechanism, inputs, and outputs for each activity is discussed in detail within each activity’s respective chapter.

Finally, you’ll notice that each subway stop is numbered. These numbers correspond to the activity’s playbook section numbers. For example, subway stop 3.9 corresponds to section 3.9 Validation:

One more note about subway stop numbers: The order is very intentional: A higher numbered stop will require inputs from lower numbered stops. So, 4.1 Continuous delivery requires that you finish 3.9 Validation and all other lower-numbered activities before proceeding.

How it works

The playbook and the subway map work by providing clear direction regarding activities, information we need to capture, and interactions among and between stakeholders. The specific delivery process given to us by the playbook establishes strong guardrails around what we do and when we do it.

Two way flow

The two flows of information (the progressive and retrospective flow) interact at specific points where we enhance fidelity (capturing learnings and observations that improve clarity of the system). One of the key methods for capturing fidelity is in control processes. A control process is simply a way of checking conditions for some error or failure state, and then taking corrective action. The important detail here is that we have a process built into the playbook wherein we identify and capture our control processes. These become self-regulating guardrails to ensure we stay on track with delivery.

Feedback loops

The overall process has three feedback loops built into it. This allows us to detect change — new information, greater fidelity, errors in the system — and capture that change back into the system. By following the playbook, we actively engage in capturing this feedback to make sure it is never lost.

Quality gates

All of this comes together to create a process with really strong quality gates, which is a fancy phrase for guardrails. The quality gates are checkpoints. These checkpoints protect every activity: By making sure we have the right inputs, that the inputs are complete, and that we use those inputs accordingly. The quality gates happen as we finish an activity, too, as we capture output and send it to the next activity.

This is very similar to the definition of ready and definition of done frequently defined in agile methodologies. In fact, each activity in effect is creating its own counterpart by defining those clear inputs and clear outputs.

Throughout the playbook we’ll refer to our quality gates as our definition of ready, and you’ll see these called out at key points in the playbook. For example, the following is the definition of ready for activity 1.1 Team mobilization:

This structure is what guides the team consistently toward successful outcomes. It does this by rapidly raising awareness of anything that is going “off the rails.” This heightened awareness happens naturally and quickly just by following the playbook.

Inputs & outputs

Each activity described in the playbook has inputs and outputs. These are documented in each activity section. Inputs are prerequisites, or information that you’ll need. For instance, before you can begin strategic event mapping you’ll need to have at least 1-3 proposed use cases or customer journeys (the output of the previous activity). Each activity clearly defines their required inputs, and lists each of the outputs you’ll gain at the end of the activity.

Product delivery process

A delivery process is simply a method for designing, building, and delivering a product. This playbook is a delivery process. It’s one that focuses on customer value first, and as such it aims to foster collaboration, create shared understandings, and build reusable assets across an organization. It also focuses on the fundamentally most important value to the business: Aligning everyone on getting high value product out the door fast.

The benefits of this kind of delivery process are many, and all offer very high value to our business:

Customer focused design

We always create a foundation that is based on customer product vision and customer-inspired user journeys. That foundation stays front-and-center so we don’t lose sight of the important value being delivered.

We stay close to business value by co-creating products through collaboration between technology teams, business teams, and our customer.

Measured and improved business outcomes

Instead of focusing on output, teams start by defining outcomes-based metrics up front. By tracking them in real-time, and providing visibility to people across the organization, we achieve high value end results.

Consistent, scalable approach

All teams use the same activities and create the same kinds of artifacts, so that everyone is aligned on definitions. The context around each artifact is clear. This is essentially applying pluggable modularity to our design process.

Modularity increases reusability and flexibility across teams. It smooths interactions with the business and our customer.

Empowering technology ambition

With functional domains aligned to user journeys and services maximized for reuse, we can more easily adopt complex ideas like distributed systems and microservices architecture.

Each domain becomes responsible for cohesive functionality. Modularity in this regard is applied to services, events, and even APIs — driving teams to operate at higher speed and with greater flexibility.

Your foundation & ways of working

Following the playbook means relying on living documentation. This means that the artifacts we create — the designs, documents, specifications, drawings — these are all living and changing as we deliver our product. Typically, artifacts will start out loosely defined and as we dive deeper into specific features, we add more and more careful and exacting detail. Once we have added enough fidelity we can move ahead into delivery.

Included with the playbook are templates and models that you can use as a foundation for execution. For example, in pre-mobilization there are templates for identifying team members, roles, responsibilities, and the like. Later, in the design phase, you’ll find example models for certain architectural stereotypes and specific engineering diagram styles.

Having these templates is important for a few reasons:

• It’s good to have a common understanding regarding documentation and engineering model standards. You don’t want one team member using ER diagrams while another thinks object models or flow charts are the way to go.

• Having templates handy is a great way to jumpstart and accelerate. The team doesn’t have to figure it out on-the-fly, find templates, and adapt each one to make it fit-for-purpose.

• Having models and stereotypes suitable to your project means other teams can benefit. Why make them reinvent the design, documentation, and standards of an event driven system (for example) when those artifacts already exist?

There are important details about how and where you create your artifacts. Having the right tools and platform are essential. Using the wrong tools can lead to confusion, broken designs and artifacts, and misunderstandings across your network of stakeholders.

First and foremost, your tools to support live collaboration. This means multiple people must be able to work on your artifacts simultaneously, using live editing. This facilitates every contributor jumping in and being a part of design. For example, during event storming each person must be free to throw virtual “post-it notes” on the event map. It’s even more important in today’s world of widely distributed remote work, where we all connect over Zoom and everyone opens documents on their screen. Forcing one person to effectively collect comments, collate, and document does not work. Fidelity is lost, interactivity and communication plummets, and individual ownership won’t materialize.

Another very important feature is version control. Artifacts need to have version control. This means being able to revert changes, if necessary, and refer back to older document histories for clarification.

Maintaining references to your designs and documentation is critical. Whatever platform you have, it needs to support immutable references. In other words, when you create a new document, it needs to have a URL that never changes — even if the name of the document or the filing location changes. Document repository structure tends to change over time (as do document names). You can’t have references to important documents breaking. That leads to “lost” artifacts — which would mean your design assets are hard, or impossible, to find.

To recap, make sure your design and documentation tools support:

1. Live collaboration and editing by multiple people at the same time.

2. Version control of every change made to the document.

3. Immutable linking so that a document’s URL won’t change.

If your current tools don’t have these features, look around. There are a lot of great tools that do. Atlassian Confluence and Google Docs are a couple of my favorites for documentation. They both support all of the required features, although Confluence is really the stand-out when it comes to organization and cross-referencing.

When it comes to diagraming tools, Miro is my favorite. It also checks all the boxes, although automatic versioning is limited to 90 days. Unlimited version control in diagramming tools is pretty rare; it’s complicated and relatively expensive to store an infinite history of changes to a drawing.

Adopting the Delivery Playbook

You will realize the best results by adopting the playbook as a team, although individuals will realize strong gains as well, positioning them to share those gains with their team over time.

From an individual perspective, the playbook offers you everything you need to deliver with confidence, documenting all of the phases and activities along the way. Where a team relies on the wider, varied experience of its members, individuals can leverage the playbook, making sure important steps aren’t missed and filling in knowledge gaps with the depth the playbook provides.

Teams will find the playbook increases collaboration and understanding for everyone by adding depth, creating clear guardrails that allow each individual to move more quickly, and driving high-communication activities to ensure a better, shared understanding of the system.

Your organization benefits too, whether adopting the playbook at an individual level or a team level. It ensures customer value is identified, protected, and realized throughout delivery. You’ll also find the playbook creates better coordination and improved organizational knowledge, both of which lead to acceleration.

What to bookmark

The Delivery Playbook offers a lot of resources. Finding your way can be a little intimidating at first. Here are a few bookmarks to get you started:

• The Delivery Playbook launch page

• There’s a complete table of contents in Everything you need to know

• For a more detailed catalogue of content, check out the index

Getting started: Pre-mobilization

Publication details

Accessing the Customer Obsessed Delivery Playbook online

Paid subscribers can access the Customer Obsessed Delivery Playbook online, either from this link or by clicking ‘Playbook’ in the menu bar on the Customer Obsessed Engineering home page.

If you’re a free subscriber, you will have access to previews of most chapters, as well as select full chapters as they are released.

Can my organization get the complete Customer Obsessed Delivery Playbook?

Yes, absolutely! Check out the colophon for details on options available to your organization.

If you find Customer Obsessed Engineering and the Delivery Playbook valuable, please share it with your friends and coworkers.

Share Customer Obsessed Engineering

One of my many passions is making sourdough bread. Every single day, I spend a little time baking bread — or, more precisely, every morning I “feed” my sourdough starter. And at least twice a week I bake something using that starter. Right now my favorites are ciabatta and a mixed-grain sourdough boule. But sometimes I’ll mix it up and make biscotti, or a nice polenta loaf (which, if you haven’t tried, is a delicious, hearty bread with enough corn meal to give it a satisfying crunch and golden color).

You’d think with the amount of time I spend baking, I’d have it down. After all, bread is usually just flour, water, salt, and a bit of starter. Sure, sometimes you do something a little more elaborate, maybe a couple different kinds of flour, or some olive oil — but bread is basic.

But it’s actually not. Even something as simple as bread can be surprisingly complex. The myriad types of flour and mixing percentages, the levain, how long to let the autolyse sit, warm and cold proofing, different baking techniques… so, I don’t do it from memory. I use a playbook. My playbook is The Perfect Loaf, by Maurizio Leo, and it makes baking bread a delight.1

An engineering playbook

Just like I use a cookbook when baking bread, I rely on an engineering playbook when building software. I’ve been doing this for about 40 years now, a lot longer than baking bread. Again you might think I’d have it down, right?

But building software is complex, and even after 40 years I go back to my playbook again and again.

Here’s the thing: Every single time we use the playbook, the project goes well. And nearly every time we don’t use the playbook, something goes wrong. And every time it goes wrong, it reminds us: Use the playbook.

Trying to deliver software without a playbook is like trying to win the World Cup without a game plan. Or an elite operations unit going into battle without a tactical manual.

Use the playbook. It makes it possible to effortlessly deliver software that delights customers.

What is a playbook?

A playbook is your strategic and tactical delivery plan. It provides an overall roadmap for the entire delivery lifecycle. It encompasses the “what” as well as the “how.” Most importantly, it’s yours. It’s a playbook that you adapt and craft to your specific situation, and likely evolve over time as you find better ways to deliver.

How is a playbook different from a methodology?

An engineering playbook is not a methodology. A playbook should work equally well across methodologies — agile, scrum, kanban, waterfall. Think of the methodology as an operating framework that you’ll slot your playbook into. The playbook focuses on:

1. What are you building? Your playbook provides a path to current and future state analysis, so you can accurately define what you are building.

2. How will you build it? The details of the implementation are realized in specifications — the playbook creates standards, templates, and architectural stereotypes that explain the “how.”

Playbooks are tailored to the needs and preferences of the team. As you’ll see as we go through my playbook, there is ample opportunity to substitute the design principles, preferred artifacts, and different approaches your team decides to use.

The “Customer Obsessed Delivery Playbook”

I’ll typically just refer to the “playbook,” but this is a Delivery Playbook as defined by Customer Obsessed Engineering. This introduction explains what my Customer Obsessed Delivery Playbook is and provides a high-level overview of the entire playbook.

My playbook covers a lot of territory. It’s divided into four major sections: Mobilization, Blueprinting, Delivery and Operations. It needs to be comprehensive, so that no matter where you are in the delivery cycle, you can look at the playbook and know what’s next. It covers things like:

1. Team mobilization and strategy

2. Planning

3. Quality gates (entry / exit criteria)

4. Requirements gathering

5. Value mapping strategy

6. Architectural foundation and North Star vision

7. Target state architecture

8. Design specifications

9. Validation and verification strategies

10. Engineering models

11. Delivery models

12. Monitoring and operations

The above is a very shortened version of the table of contents for my playbook, a rolled up version that hits on the major highlights.

I’ll be releasing about two playbook chapters a month. Each chapter will be available to paid subscribers in full. Free subscribers will have access to partial chapters and a few select complete chapters.

My playbook is a strategic and tactical guide, and includes numerous examples in the form of templates, documents, diagrams, and recommendations.

How the playbook ups your game

The playbook is fundamental. It gives you an edge most teams don’t have. A small number of organizations take it to heart, and those are the top performers in the industry. Accenture is a company that believes deeply in following playbooks — a process, a formula for success. It’s served Accenture well: Over 120 countries, about 9,000 clients, and roughly 743,000 employees and counting.

The playbook is about reliable, repeatable execution. Let’s think about that for a minute: How would projects go if you could count on reliably executing, every single time, without fail? How will your customer feel when you reliably deliver exactly what was promised, no disappointments, no misinterpretations?

The Customer Obsessed Delivery Playbook focuses this reliable, repeatable execution on the customer. I do this by including value stream engineering in the playbook. It’s a technique for making sure customer value is identified, protected, and realized throughout delivery. No customer misunderstandings or disappointments.

My playbook has been developed and vetted with well over 100 customers. It’s been validated and continuously improved over the past 20+ years. Along the way, it’s been co-created with experiences gained at Lightbend, Accenture, and others.

Twelve reasons to use the playbook

Consistently following the playbook delivers many benefits, some of which I’ve summarized here. As we dive into the chapters, we’ll also explore where things go wrong when steps in the playbook are by-passed, and how to keep that from happening.

1. Don’t miss important details. The playbook provides a roadmap to follow, an easy step-by-step guide, and puts guardrails in place. For example, before transitioning from Mobilization to Blueprinting, we need a product vision, sufficient core solutions identified, 1-3 user journeys, a team with enough dedicated time (and a few other things).

2. Decisions are clear, decisive, easier. With a complete roadmap that spells out how to execute, we avoid second guessing and missteps. For example, before moving into technical design, we know that user journeys and use cases need to be discussed with the customer. The customer becomes involved at all the right points along the delivery pipeline, giving both us and the customer confidence.

3. Move faster with confidence. The clarity gives us confidence. We can accelerate because we have the roadmap, we know the inputs, and by following that map repeatedly we gain confidence.

4. Become more consistent in execution, which drives repeatability. The playbook gives us specific inputs and outputs at each stage. The outputs from a prior stage are needed in subsequent stages (most of the time, but there is quite a bit of flexibility too). It’s a functional model, and really drives consistency across projects. Having all of the necessary steps, inputs, and artifacts — not to mention well-designed templates and stereotypes — allows us to execute with professionalism. We aren’t re-inventing the wheel on the fly for each customer. Instead we’re executing well-defined, repeatable steps.

5. Collaboration is much easier. Gone are the days where each team is “doing their own thing.” Disparate teams that share a playbook are able to work together in a streamlined fashion. Each team knows exactly where the other is and what’s needed next. Having common artifacts — the same approach to design and documentation for instance — means sharing resources is easier. A single stereotype becomes a reusable tool for every team.

6. Delegation is easy. Leveraging the functional model — known inputs, specific steps to follow, and known outputs — makes it much easier to split work across the team (or even between teams). For example, one team can confidently take on specification design while another tackles a North Star architecture, because both teams use event maps as inputs. Everything is spelled out, even to the detail that these tasks can be parallelized.

7. Customers always get the most important thing next. This is because value mapping activities and value stream engineering is built into the playbook. For example, customer workshops are used to identify the relative value of product features. Value mapping exercises guide very intentional decisions about build versus buy, and repurposing or adapting existing technology. Value mapping highlights the relative cost of features, pushing customers to prioritize the most impactful things rather than asking for everything at once. At the same time the cost in terms of time to market is highlighted, creating drive for small, rapid iterations.

8. Problems are caught before they become crises. Risk is proactively managed using guardrails and quality gates. Each stage has a series of quality checks (such as having models that are understood by the customer before beginning specification). These gates establish clear expectations and statements of responsibility up-front, and prevent moving forward if there’s risk. The entire project team (including the customer) is deeply involved in these decisions so there are no surprises. It leads to very early and very high awareness if anything is going off-track.

9. Roles and responsibilities are explicit. During mobilization, the entire team is identified. Gaps in knowledge, skill or capability are identified and addressed. Each individual’s availability, involvement, responsibilities and accountability is spelled out clearly (for example, the RACI matrix mentioned below).

10. Team and customer communication is greatly enhanced. The playbook is very rich in communication, partly because of shared activities and checkpoints, and partly because of the high degree of collaboration that it enables. As a result, awareness of the overall project soars, responsibilities are much more clear, and artifacts (such as documents, designs, specifications, code) are more clear.

11. Team efficiency is put front and center, acting as a multiplier. A good playbook establishes visibility into wasted effort, and pushes it out of the project. We’ll use techniques like waste walks to identify effort that is less than optimal and eliminate it. For instance, time wasted waiting for slow server builds, or manual processes that could be automated, will be captured and made highly visible. With the cost of waste made visible, eliminating it will be prioritized.

12. Customer confidence soars. Your customer will simply love it when they see a confident team executing at speed. With a mature playbook you have a mature and well-vetted interaction model with the customer. There are specific activities that require the customer. For example, during Mobilization team dynamics are established, such as ceremonies, meeting cadence, RACI models, so everyone knows what’s required of their role. Later, event mapping exercises and user journey development tightly involve the customer in the design. Those interactions and artifacts are provided in detail so you can show the customer what they will expect ahead of time.

Getting started

I’ll be publishing a new playbook chapter every few weeks. The first step is to start following along. Each chapter will include practical steps for implementing your own playbook. I’m glad to have you along for the journey!

If you’d like to get a taste for some of the methods, techniques, and stories that accompany the playbook, take a look at this post on delivering using a steel thread. Or, just dive right into the playbook’s getting started chapter!

Next chapter: Getting started

Publication details

Accessing the Customer Obsessed Delivery Playbook online

Paid subscribers can access the Customer Obsessed Delivery Playbook online, either from this link or by clicking ‘Playbook’ in the menu bar on the Customer Obsessed Engineering home page.

If you’re a free subscriber, you will have access to previews of most chapters, as well as select full chapters as they are released.

Can my organization get the complete Customer Obsessed Delivery Playbook?

Yes, absolutely! Check out the colophon for details on options available to your organization.

If you find Customer Obsessed Engineering and the Delivery Playbook valuable, please share it with your friends and coworkers.

Share Customer Obsessed Engineering

Introduction

The Delivery Playbook is a way to design and deliver software that makes sure customer value is identified, protected, and realized throughout delivery. No customer misunderstandings or disappointments.

If you haven’t read it, the introduction explains why every team needs a playbook — and the Delivery Playbook has been proven with hundreds of companies. It will raise your team’s and your organization’s abilities dramatically. Most importantly, it will enable you to delight your customers.

What to bookmark

The Delivery Playbook offers a lot of resources. Finding your way can be a little intimidating at first. Here are a few bookmarks to get you started:

• The Delivery Playbook launch page

• Everything you need to know (the table of contents)

• The index (this page), a more detailed catalogue of content

The “subway map”

You’ll likely want to bookmark the subway map as well. It provides a visual map of the entire Delivery Playbook, it’s four phases, and their respective 28 activities.

• The “subway map”

Using the playbook

If you’re new to the Delivery Playbook, start by reading:

• How to use a playbook

• 12 reason to level up your team with a delivery playbook

From there, I’d recommend reading through each chapter in sequence. It more-or-less follows the natural development lifecycle.

If you’ve been using the playbook for a while now, you’ll likely want to treat the following chapters as reference material. I strongly recommend making it “required reading” for your entire team, so everyone is on the same page. You’ll find the subway map an excellent reminder of flow, and each chapter will give you the context you need during delivery.

Chapter Index

The playbook is divided into six chapters: An Introduction, four chapters about the playbook phases, Mobilization, Blueprinting, Delivery, and Operations, and a References chapter. The four playbook chapters have numbered sections for easy reference. A glossary of terms is in the References chapter.

Introduction

If you’re new to the Delivery Playbook, start here. These chapters provide an important foundation in core concepts.

Mobilization

Activities conducted in the run-up to a project, such as team selection, onboarding, kickoff calls, and problem space analysis.

Blueprinting

Implementation of overarching architectural designs, and establishing a target state architecture.

Delivery

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

Coming soon

• 3.8 Engineering coming soon!

• 3.9 Validation

  • Quality engineering versus testing

  • Test batteries as a path to higher environments

  • Testing for value delivered with Behavior Driven Development

Operations

Ensuring security and compliance is “fit-for-purpose,” delivering a product increment, and capturing feedback into the design process for future increments.

• 4.0 Operations (phase 4 introduction)

• 4.1 Continuous delivery

  • Canary releases & feature flags

• 4.2 Compliance

• 4.3 Review

• 4.4 Release

• 4.5 Monitoring

  • Observability will make everything easier

• 4.6 Incident capture

References

Publication details

I have questions…

I’d be delighted to talk with you and answer them! Please feel welcome to join the Customer Obsessed Engineering chat here on Substack. I’ll usually get back to you within a business day.

Can I reproduce the Delivery Playbook?

The Customer Obsessed web site, all content and the Delivery Playbook are copyright © 2011-2026, Boss Logic, Inc., all rights reserved. Unauthorized reproduction is prohibited. Organizations interested in reproducing or adapting the Playbook can contact Boss Logic directly.

Can my organization get the complete Delivery Playbook?

Yes, absolutely! Check out the colophon for details on different options available to your organization.

Can I expense my subscription?

You bet! I think that’s a great idea. If you need a starting point, try reaching out to your manager with this template.

And by the way, there are fantastic group discounts. Maybe your company wants to sponsor your whole team?

Get 23% off a group subscription

To learn more about programs for your organization, check out the colophon.

If you find Customer Obsessed Engineering and the Playbook valuable, please share it with your friends and coworkers.

Share Customer Obsessed Engineering

Getting started

The Delivery Playbook is a way to design and deliver software that makes sure customer value is identified, protected, and realized throughout delivery. No customer misunderstandings or disappointments.

If you haven’t already done so, take a look at these articles to get started. If you have, then dive right in to the table of contents, below.

Introduction

• Forward

• How to use a playbook

• The “subway map” — a visual map of the playbook

• Chapter index — detailed descriptions of each chapter

Design thinking

• 12 reasons to level-up your team with a delivery playbook

• Plagued with problems getting to delivery? Solve them with a “steel thread”

• How to create impact with your customer (and why so many projects miss their mark)

• My formula for running a successful workshop (or any meeting)

• Stakeholder management 101: My customer isn’t listening, what do I do now?

• The 30-minute guide to Domain Driven Design: A secret weapon to solve tough problems

• Value stream engineering in a nutshell

• Product teams really do outperform: bringing the receipts

Table of contents

Mobilization

• Pre-mobilization

• 1.0 Mobilization (phase 1 introduction)

• 1.1 Team mobilization

• 1.2 Current state analysis

  • My boss wants a risk management plan; what is it and how do I get one?

• 1.3 Product vision

• 1.4 Business capabilities & functions

Blueprinting

• 2.0 Blueprinting (phase 2 introduction)

• 2.1 Product strategy

• 2.2 Roadmaps & OKRs

• 2.3 Strategic event storming

  • Do you understand your customer? Subtle word choices lead us into a lot of trouble

• 2.4 Domain modeling

  • The 30-minute guide to Domain Driven Design (part 1)

  • The 30-minute guide to Domain Driven Design (part 2)

• 2.5 Context mapping

• 2.6 Target state architecture

• 2.7 Architecture foundation

• 2.8 Delivery processes & tools

  • When should you think about security?

  • Planning ahead with an AI readiness plan: How AI will impact software development and security

  • Ephemeral environments are the best way to fight “waste gremlins”

• 2.9 Functional architecture

Delivery

• 3.0 Delivery (phase 3 introduction)

• 3.1 Value mapping

  • How to deliver more customer value than your competitors

  • Value stream engineering in a nutshell

  • A definition of done is only half the story

  • Why we shouldn’t hide complexity

• 3.2 Security & governance

  • Why you need a zero trust architecture

• 3.3 Identify product increment

  • The “magic” of just enough estimation

• 3.4 Tactical event storming

• 3.5 Modeling

  • Applying marble & sequence diagrams

  • Using “declarative thinking” to establish stronger controls

• 3.6 Specification

  • How to fix a $25 bug before it becomes a $37,500 problem

• 3.7 Elaboration

• 3.8 Engineering (coming soon!)

• 3.9 Validation

  • Quality engineering versus testing

  • Test batteries as a path to higher environments

  • Testing for value delivered with Behavior Driven Development

Operations

• 4.0 Operations (phase 4 introduction)

• 4.1 Continuous delivery

  • Canary releases & feature flags

• 4.2 Compliance

• 4.3 Review

• 4.4 Release

• 4.5 Monitoring

  • Observability will make everything easier

• 4.6 Incident capture

References

• Glossary

• Col·​o·​phon

Publication details

I have questions…

I’d be delighted to talk with you and answer them! Please feel welcome to join the Customer Obsessed Engineering chat here on Substack. I’ll usually get back to you within a business day.

Can I reproduce the Delivery Playbook?

The Customer Obsessed web site, all content and the Delivery Playbook are copyright © 2011-2026, Boss Logic, Inc., all rights reserved. Unauthorized reproduction is prohibited. Organizations interested in reproducing or adapting the Playbook can contact Boss Logic directly.

Can my organization get the complete Delivery Playbook?

Yes, absolutely! Check out the colophon for details on different options available to your organization.

Can I expense my subscription?

You bet! I think that’s a great idea. If you need a starting point, try reaching out to your manager with this template.

And by the way, there are fantastic group discounts. Maybe your company wants to sponsor your whole team?

Get 23% off a group subscription

To learn more about programs for your organization, check out the colophon.

If you find Customer Obsessed Engineering and the Delivery Playbook valuable, please share it with your friends and coworkers.

Share Customer Obsessed Engineering