Getting started: Using the Delivery Playbook
Uncovering the playbook's structure, navigating the subway map, and following the playbook to unlock high value features quickly.
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:
If you use the referral button below, you’ll earn free premium access to Customer Obsessed Engineering. Just three referrals will earn a free month!
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:
Live collaboration and editing by multiple people at the same time.
Version control of every change made to the document.
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:
There’s a complete table of contents in Everything you need to know
For a more detailed catalogue of content, check out the index
If you find Customer Obsessed Engineering and the Delivery Playbook valuable, please share it with your friends and coworkers.
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.