1. Product development is complex. As IT professionals, we get paid a lot of money because what we do is complex. Our WoW must address how to approach requirements, architecture, testing, design, programming, management, deployment, governance, and many other aspects of software/product development in a myriad of ways. And it must describe how to do this throughout the entire life cycle from beginning to end, and also address the unique situation that our team faces. In many ways, this book holds up a mirror to the complexities faced by software developers and provides a flexible, context-sensitive tool kit to deal with it.

2. Agile industrial complex (AIC). Martin Fowler, in a conference keynote in Melbourne in August 2018, coined the phrase “agile industrial complex” [Fowler]. He argued that we are now in the era of the AIC, with prescriptive frameworks being routinely imposed upon teams as well as upon the entire organization, presumably to provide management with a modicum of control over this crazy agile stuff. In such environments, a set of processes defined by the chosen framework will now be “deployed”—whether it makes sense for your team or not. We are deploying this, you will like it, you will own it—but don't dream of trying to change or improve it because management is hoping to “limit the variability of team processes.” As Cynefin advises, you can't solve a complex problem by applying a simple solution [Cynefin].

3. Agile growth greatly exceeded the supply of experienced coaches. Although there are some great agile coaches out there, unfortunately their numbers are insufficient to address the demand. Effective coaches have great people skills and years of experience, not days of training, in the topic that they are coaching you in. In many organizations, we find coaches who are effectively learning on the job, in many ways similar to college professors who are reading one chapter ahead of their students. They can address the straightforward problems but struggle with anything too far beyond what the AIC processes inflicted upon them deign to address.

• False promises. You may have heard agile coaches claim to achieve 10 times productivity increases through adoption of agile, yet are unable to provide any metrics to back up these claims. Or perhaps you've read a book that claims in its title that Scrum enables you to do twice the work in half the time [Sutherland]? Yet the reality is that organizations are seeing, on average, closer to 7–12 % improvements on small teams and 3–5 % improvements on teams working at scale [Reifer].

• More silver bullets. How do you kill a werewolf? A single shot with a silver bullet. In the mid-1980s, Fred Brook taught us that there is no single change that you can make in the software development space, no technology that you can buy, no process you can adopt, no tool you can install, that will give you the order of magnitude productivity improvement that you're likely hoping for [Brooks]. In other words, there's no silver bullet for software development, regardless of the promises of the schemes where you become a “certified master” after two days of training, a program consultant after four days of training, or any other quick-fix promises. What you do need are skilled, knowledgeable, and hopefully experienced people working together effectively.

• Process populism. We often run into organizations where leadership's decision-making process when it comes to software process boils down to “ask an industry analyst firm what's popular” or “what are my competitors adopting?” rather than what is the best fit for our situation. Process populism is fed by false promises and leadership's hope to find a silver bullet to the very significant challenges that they face around improving their organization's processes. Most agile methods and frameworks are prescriptive, regardless of their marketing claims—when you're given a handful of techniques out of the thousands that exist, and not given explicit options for tailoring those techniques, that's pretty much as prescriptive as it gets. We appreciate that many people just want to be told what to do, but unless that method/framework actually addresses the real problem that you face, then adopting it likely isn't going to do much to help the situation.

• It embraces your uniqueness. This book recognizes that your team is unique and faces a unique situation. No more false promises of a “one-size-fits-all” process that requires significant, and risky, disruption to adopt.

• It embraces the complexity you face. This book effectively holds up a mirror to the inherent complexities of solution delivery, and presents an accessible representation to help guide your process improvement efforts. No more simplistic, silver bullet methods or process frameworks that gloss over the myriad of challenges your organizations faces, because to do so wouldn't fit in well with the certification training they're hoping to sell you.

• It provides explicit choices. This book provides the tools you need to make better process decisions that in turn will lead to better outcomes. In short, it enables your team to own their own process, to choose their way of working (WoW) that reflects the overall direction of your organization. This book presents a proven strategy for guided continuous improvement (GCI), a team-based process improvement strategy rather than naïve adoption of a “populist process.”

• It provides agnostic advice. This book isn't limited to the advice of a single framework or method, nor is it limited to agile and lean. Our philosophy is to look for great ideas regardless of their source and to recognize that there are no best practices (nor worst practices). When we learn a new technique, we strive to understand what its strengths and weaknesses are and in what situations to (not) apply it.

1. Disciplined Agile Delivery (DAD) in a Nutshell. This section works through fundamental strategies to choose and evolve your way of working (WoW) and the Disciplined Agile mindset, overviews DAD, describes typical roles and responsibilities of people on DAD teams, describes a process goal/outcome-driven approach that makes your process choices explicit, and shows how DAD supports several life cycles that share a common governance strategy.

2. Successfully Initiating Your Team. This section is a reference lookup for agile, lean, and sometimes traditional techniques for initiating a solution delivery team/project in a streamlined manner. The trade-offs of each technique are summarized so that your team can choose the most appropriate techniques that you can handle given the situation that you face. Better decisions lead to better outcomes.

3. Producing Business Value. Similar to Section 2, this is also a reference lookup describing a large collection of techniques available to you that are focused on construction of a software-based product solution.

4. Releasing Into Production. You guessed it, this is a reference lookup for techniques for successfully releasing your solution into production or the marketplace.

5. Sustaining and Enhancing Your Team. This section is a reference lookup for techniques that are applicable throughout the entire life cycle, such as strategies to support the personal growth of team members, strategies to coordinate both within your team and with other teams, and strategies to evolve your WoW as you learn over time.

6. Parting Thoughts and Back Matter. A few parting thoughts, an appendix describing the rest of the DA tool kit, an appendix describing a respectable certification strategy for DA practitioners, a list of abbreviations, references, and an index.