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.
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!
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:
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.
Using the playbook
If you’re new to the Delivery Playbook, start by reading:
How to use a playbook coming soon!
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.
FREE PREVIEW: If you aren’t a subscriber, check out chapter 2.2 Roadmaps & OKRs. The playbook has over 32 full chapters, plus supporting articles, project templates, and references!
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.
Forward
Boss Logic dates back to the mid-90’s. At that time, we were a small startup building digital document management solutions on the NeXT Computer platform in Objective C and Sybase. I loved the team and that amazing time in Silicon Valley working with Steve Jobs, and have kept the name ever since.
12 reasons to level-up your team with a delivery 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.
Plagued with problems getting to delivery? Solve them with a “steel thread."
A steel thread is a technique for delivering an architecturally complete feature to production while getting rid of all the risky bits very quickly. Usually in just a few of sprints. It's hands-down the most effective project delivery approach I’ve ever used.
How to create impact with your customer (and why so many projects miss the mark)
An introduction and case study in creating customer value. This article provides a foundational understanding of Value Stream Engineering and what Customer Obsessed Engineering is all about.
My formula for running a successful workshop (or any other meeting)
Workshop planning is essential. There's good reason: Delivering any product demands high-functioning collaboration. Every meeting depends on being well prepared. Having the right input, the right stakeholders, and the right expectations. Here's how I make sure it comes off smoothly.
The 30-minute guide to Domain Driven Design: A secret weapon to solve tough problems
Domain driven design can be your “secret weapon” to do better. That's why we use it in the Delivery Playbook. Learn how it fixes your customer perception problems, aligns technology with business, and defends against complexity.
Getting started: Using the Delivery Playbook
A playbook gives us set of rules, suggestions, and methods suitable for the execution of a technology development project at scale. In this chapter we'll uncover the playbook's structure, learn about navigating the subway map, and how to follow the playbook to unlock high value features quickly.
Pre-mobilization
Those of you who have been reading for a while know I’m a diver and a sailor. While I’m not a paraglider, all of these activities have one very important thing in common: Preparation. Preparation is key, and failing to prepare in any of these activities can end very badly.
Mobilization
Activities conducted in the run-up to a project, such as team selection, onboarding, kickoff calls, and problem space analysis.
1.0 Mobilization (phase 1)
Mobilization is the first phase in the playbook. It focuses on getting the team organized, and starting project discovery: Building a product vision, creating strategic goals, and establishing your product value stream.
1.1 Team mobilization
Having the right people in the right room is crucial to the success of your project. You need a team that is able to handle all aspects of delivery, but you also need to set them up for success.
1.2 Current state analysis
Unless you’re launching a greenfield project with no existing architecture, you need a thorough understanding of the legacy product. Documenting that understanding is a precursor toward a future state.
1.3 Product vision
Wouldn’t it be wonderful to always feel pulled into the future, pulled toward an aspirational goal and future state? If you can paint that picture, your product vision will pull your team. It eliminates ambiguity by imagining and defining your future, and the guardrails to get there.
1.4 Business capabilities & functions
One of the hardest things about creating a product is defining exactly what it is. This is foundational. If we can't agree on "what," then deciding "how" is impossible to achieve. Creating your product capabilities and functions is all about creating a story that fills in this picture. It’s a very crucial step.
Blueprinting
Implementation of overarching architectural designs, and establishing a target state architecture.
2.0 Blueprinting (phase 2)
Blueprinting is the second phase of the playbook. It focuses on solidifying your product strategy, developing your roadmap, and creating blueprints for your product: Event maps, designs and architectural drawings. Your roadmap aligns product and business priorities, so you know what to deliver first.
2.1 Product strategy
Too many product teams build without adequately understanding the themes that support a successful product. Technical execution is the easy part: The hard part is figuring out what's so compelling that customers will sign up and give you their credit card number.
2.2 Roadmaps and OKRs
This chapter is about measuring success. Specifically, it’s about turning the objectives you’ve chosen for your project into action that can be measured. The bit about measuring is particularly important because if you can’t measure well, it’s inevitable your project will fail to some extent or another.
2.3 Strategic event storming
We need to discover how this new thing works, explore its complex inner workings, discover the details of what makes it unique and worth implementing. We have to create value for our customer. Strategic event storming will reveal a lot about your product, its features, and what you need to deliver.
2.4 Domain modeling
A “domain” is a well defined, related sphere of influence and knowledge. It does not share responsibility or ownership with any other domain. Domain modeling is the identification of independent domains that are fully decoupled or only loosely coupled to other domains.
2.5 Context mapping
Context mapping is all about avoiding entanglement: Creating greater efficiency with smaller, more capable components, better APIs, purpose-built data sets, and easily reasoned about services.
2.6 Target state architecture
Methodically approaching your conceptual model of the future and the technologies that fulfill that future is crucial if you want to achieve or surpass your project goals.
2.7 Architecture foundation
Your architecture foundation should be immutable. It’s the bedrock on which everything is built, enabling your team to create new capabilities while providing some safety guardrails and direction.
2.8 Delivery processes & tools
This chapter is about how you build and deliver software. Where will you integrate security in your delivery pipeline? Will your team use ephemeral environments? What SAST tools will you use, and will you do “canary releases?” How will you manage releases?
2.9 Functional architecture
Defining your functional architecture is the last step in the Blueprinting phase. In a way, it’s all about “buttoning up” the architecture you’ve been creating up to this point — it should feel good, kind of like wrapping up all the artifacts we’ve defined and putting a pretty bow on.
Delivery
Creating detailed technical specifications, engineering work, and building a product increment that is ready for production.
3.0 Delivery (phase 3)
Delivery is the third phase of the playbook. It's an iterative cycle focusing on identifying the next high-value product increment, elaborating design, engineering the product, and delivering. Protecting product value, security, governance and your value stream engineering is part of the phase.
3.1 Value mapping
Properly understanding feature value, risks and rewards informs prioritization. It gives you the means to take control of your work and deliver fast with crystal clear, unambiguous decisions.
3.2 Security & governance
You don't have to be a security genius to deliver secure, compliant applications. You do need a roadmap and clear tactical plan. This chapter goes deep on building a secure system. It includes an overview of security and compliance standards, templates, and a systematic approach for security adoption.
3.3 Identify product increment
Choosing what to build next is often hard. How do you balance a small, fast-moving feature with making a big impact? How can it be “feature complete” and also a piece of the whole?
3.4 Tactical event storming
3.5 Modeling
Delivering customer value with Behavior Driven Development
3.6 Specification
3.7 Elaboration
3.8 Engineering
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 of 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
col·o·phon
Organizational access to the complete playbook. Team enablement and training services. Group discounts and team purchase. Playbook copyright and ownership marks. Reproduction rights.
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 Playbook and web site are copyright © 2011-2024, Boss Logic LLC, 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?
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.