Choose your WoW - Second Edition

A Disciplined Agile Approach to Optimizing Your Way of Working

Scott Ambler, Mark Lines

• Publisher: Project Management Institute
• Year: 2022
• ISBN:
  9781628257557
• Edition: 2
• Topic: Betriebswirtschaft
• Subtopic: Projektmanagement

Hundreds of organizations around the world have already benefited from Disciplined Agile Delivery (DAD). Disciplined Agile® (DA™) is the only comprehensive tool kit available for guidance on building high-performance agile teams and optimizing your way of working (WoW). As a hybrid of the leading agile, lean, and traditional approaches, DA provides hundreds of strategies to help you make better decisions within your agile teams, balancing self-organization with the realities and constraints of your unique enterprise context. This book: •Provides a foundation for enterprise agility, value streams, and a disciplined approach to DevOps;•Is a pragmatic application of agile, lean, and traditional techniques for your enterprise-class environment; •Overviews a strategy for teams to evolve a fit-for-purpose, flexible WoW that still supports a consistent governance strategy for leadership; and •Makes a perfect study guide for Disciplined Agile certification. Why "fail fast" (as the agile industry likes to recommend) when you can learn quickly on your journey to high performance? With this book, you can make better decisions based upon proven, context-based strategies, leading to earlier success and better outcomes.

Chapter 1

Choosing Your WoW!

A man's pride can be his downfall, and he needs to learn when to turn to others for support and guidance.—Bear Grylls

Key Points in This Chapter

•Disciplined Agile Delivery (DAD) teams have the autonomy to choose their way of working (WoW).

•You need to both “be agile” and know how to “do agile.”

•Software development is complicated; there's no easy answer for how to do it.

•Disciplined Agile® (DA™) provides the scaffolding—a tool kit of agnostic advice—to Choose Your WoW™.

•Other people have faced, and overcome, similar challenges to yours. DA enables you to leverage their learnings.

•You can use this book to guide how to initially choose your WoW and then evolve it over time.

•The real goal is to effectively achieve desired organizational outcomes, not to be/do agile.

•Better decisions lead to better outcomes.

Welcome to Choose Your WoW, the book about how agile software development teams, or more accurately agile/lean solution delivery teams, can choose their WoW. This chapter describes some fundamental concepts around why choosing your WoW is important, fundamental strategies for how to do so, and how this book can help you to become effective at it.

Why Should Teams Choose Their WoW?

Agile teams are commonly told to own their process, to choose their WoW. This is very good advice for several reasons:

•Context counts. People and teams will work differently depending on the context of their situation. Every person is unique, every team is unique, and every team finds itself in a unique situation. A team of five people will work differently than a team of 20, than a team of 50. A team in a life-critical regulatory situation will work differently than a team in a nonregulatory situation. Our team will work differently than your team because we're different people with our own unique skill sets, preferences, and backgrounds.

•Choice is good. To be effective, a team must be able to choose the practices and strategies to address the situation that they face. The implication is that they need to know what these choices are, what the trade-offs are of each, and when (or when not) to apply each one. In other words, they either need to have a deep background in software process, something that few people have, or have a good guide to help them make these process-related choices. Luckily, this book is a very good guide.

•We should optimize flow. We want to be effective in the way that we work, and ideally to delight our customers/stakeholders in doing so. To do this, we need to optimize the workflow within our team and in how we collaborate with other teams across the organization.

•We want to be awesome. Who wouldn't want to be awesome at what they do? Who wouldn't want to work on an awesome team or for an awesome organization? A significant part of being awesome is to enable teams to choose their WoW and to allow them to constantly experiment to identify even better ways they can work.

In short, we believe that it's time to take back agile. Martin Fowler recently coined the term “agile industrial complex” to refer to the observation that many teams are following a “faux agile” strategy, sometimes called “agile in name only” (AINO). This is often the result of organizations adopting a prescriptive framework, such as the Scaled Agile Framework (SAFe®) [SAFe], and then forcing teams to adopt it regardless of whether it actually makes sense to do so (and it rarely does), or forcing teams to follow an organizational standard application of Scrum [ScrumGuide; SchwaberBeedle]. Yet canonical agile is very clear; it's individuals and interactions over processes and tools—teams should be allowed, and better yet, supported, to choose and then evolve their WoW.

You Need to “Be Agile” and Know How to “Do Agile”

Scott's daughter, Olivia, is 11 years old. She and her friends are some of the most agile people we've ever met. They're respectful (as much as 11-year-old children can be), they're open-minded, they're collaborative, they're eager to learn, and they're always experimenting. They clearly embrace an agile mindset, yet if we were to ask them to develop software it would be a disaster. Why? Because they don't have the skills. Similarly, it would be a disaster to ask them to negotiate a multimillion-dollar contract, to develop a marketing strategy for a new product, to lead a 4,000-person value stream, and so on. They could gain these skills in time, but right now they just don't know what they're doing even though they are very agile. We've also seen teams made up of millennials who collaborate very naturally and have the skills to perform their jobs, although perhaps are not yet sufficiently experienced to understand the enterprise-class implications of their work. And, of course, we've seen teams of people with decades of experience but very little experience doing so collaboratively. None of these situations are ideal. Our point is that it's absolutely critical to have an agile mindset, to “be agile,” but you also need to have the requisite skills to “do agile” and the experience to “do enterprise agile.” An important aspect of this book is that it comprehensively addresses the potential skills required by agile/lean teams to succeed.

The real goal is to effectively achieve desired organizational outcomes, not to be/do agile. What good is it to be working in an agile manner if you're producing the wrong thing, or producing something you already have, or are producing something that doesn't fit into the overall direction of your organization? Our real focus must be on achieving the outcomes that will make our organization successful, and becoming more effective in our WoW will help us to do that.

Accept That There's No Easy Answer

What we do as professionals is challenging, otherwise we would have been automated out of jobs by now. You and your team work within the context of your organization, using a collection of technologies that are evolving, and for a wide variety of business needs. And you're working with people with different backgrounds, different preferences, different experiences, different career goals, and they may report to a different group or even a different organization than you do.

We believe in embracing this complexity because it's the only way to be effective, and better yet, to be awesome. When we downplay or even ignore important aspects of our WoW, say architecture for example, we tend to make painful mistakes in that area. When we denigrate aspects of our WoW, such as governance, perhaps because we've had bad experiences in the past with not-so-agile governance, then we risk people outside of our team taking responsibility for that aspect and inflicting their non-agile practices upon us. In this way, rather than enabling our agility, they act as impediments.

We Can Benefit From the Learnings of Others

A common mistake that teams make is that they believe that just because they face a unique situation, that they need to figure out their WoW from scratch. Nothing could be further from the truth. When you approach and develop a new application, do you develop a new language, a new compiler, new code libraries, and so on, from scratch? Of course not, you adopt the existing things that are out there, combine them in a unique way, and then modify them as needed. Development teams, regardless of technology, utilize proven frameworks and libraries to improve productivity and quality. It should be the same thing with process. As you can see in this book, there are hundreds, if not thousands, of practices and strategies out there that have been proven in practice by thousands of teams before you. You don't need to start from scratch, but instead can develop your WoW by combining existing practices and strategies and then modifying them appropriately to address the situation at hand. DA provides the tool kit to guide you through this in a streamlined and accessible manner. Since our first book on DAD [AmblerLines2012], we have received feedback that while it is seen as an extremely rich collection of strategies and practices, practitioners sometimes struggle to understand how to reference the strategies and apply them. One of the goals of this book is to make DAD more accessible so that you can easily find what you need to customize your WoW.

One thing that you'll notice throughout the book is that we provide a lot of references. We do this for three reasons: First, to give credit where credit is due. Second, to let you know where you can go for further details. Third, to enable us to focus on summarizing the various ideas and to put them into context, rather than going into the details of every single one. Our approach to references is to use the format: [MeaningfulName], where there is a corresponding entry in the references at the back of the book.

DA Knowledge Makes You a Far More Valuable Team Member

We have heard from many organizations using DA—and they permit us to quote them—that team members who have invested in learning DA (and proving it through challenging certifications) become more valuable contributors. The reason, to us, is quite clear. Understanding a larger library of proven strategies means that teams will make better decisions and “fail fast” less, and rather “learn and succeed earlier.” A lack of collective self-awareness of the available options is a common source of teams struggling to meet their agility expectations—and that is exactly what happens when you adopt prescriptive methods/frameworks that don't provide you with choices. Every team member, especially consultants, is expected to bring a tool kit of ideas to customize the team's process as part of self-organization. A larger tool kit and commonly understood terminology is a good thing.

The Disciplined Agile (DA) Tool Kit Provides Accessible Guidance

One thing that we have learned over time is that some people, while they understand the concepts of DA by either reading the books or attending a workshop, struggle with how to apply DA. DA is an extremely rich body of knowledge that is presented in an accessible manner.

The good news is that the content of this book is organized by the goals, and that by using the goal-driven approach, it is easy to find the guidance that you need for the situation at hand. Here's how you can apply this tool kit in your daily work to be more effective in achieving your desired outcomes:

•Contextualized process reference

•Guided continuous improvement (GCI)

•Process-tailoring workshops

•Enhanced retrospectives

•Enhanced coaching

Contextualized Process Reference

As we described earlier, this book is meant to be a reference. You will find it handy to keep this book nearby to quickly reference available strategies when you face particular challenges. This book presents you ...