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!
Keep reading with a 7-day free trial
Subscribe to Customer Obsessed Engineering to keep reading this post and get 7 days of free access to the full post archives.