Doing Agile Right – A Book Review
I try to do what I can to keep up with the new agile books being released so that I can maintain the popular blog, The 5 Best Agile Books of 2022. All the recommended books on that list are books that I have read and most are books that I rely on, recommend, and gift all the time.
Doing Agile Right was published in 2020 by three principals of the consulting firm Bain & Company. That put me off a little at first, thinking that it might just be a fancy sales brochure. Thankfully I found that there wasn’t a lot of self-promotion going on in the book. I actually found the book very helpful and believe it will make the list of best agile books when I update it this year.
The full title of this book is Doing Agile Right: Transformation Without Chaos. It was authored by Darrell Rigby, Sarah Elk, and Steve Berez. Those are not household names in agile circles though I have heard of Rigby. He has partnered with Scrum co-creator Jeff Sutherland for various articles and podcasts over the years. Based on some of the companies included in the book, I imagine that Rigby works pretty closely with Sutherland.
Who is this book for? The authors state that the book is for senior leaders in large organizations. I would agree and recommend the book to those leaders who are curious about agile. Even experienced leaders will find it helpful as a pretty comprehensive list of considerations for succeeding with agile ways of working.
A secondary audience would be agile coaches and transformation consultants. The ideas and principles that are provided are applicable no matter what your transformation goals are.
Here is the outline of the chapters of the book:
- How Agile Really Works
- Scaling Agile
- How Agile Do You Want to be?
- Agile Leadership
- Agile Planning, Budgeting, and Reviewing
- Agile Organization, Structure, and People Management
- Agile Processes and Technology
- Doing Agile Right
Key Takeaways from Doing Agile Right:
#1 – Doing Agile “Right”
At first, the title put me off. It just sounded harsh that there was only one “right” way to do agile. After all, who are they to say there is a right and wrong way to do agile? Even the “doing agile” part struck me as odd at first. As a coach, we try to draw a distinction between ‘doing agile’ which is mindless adherence to a practice and ‘being agile’ which is about thinking and behaving in ways that support agility.
But after reading the book, I think by “right” the authors mean to not waste your time and money doing things in unproductive ways. For example, they recommend that organizations experiment and learn, rather than lazily copying what others have done (ahem, Spotify).
#2 – Scaling Agile
Chapter 2 focuses on what it means to scale agile. I like that the authors didn’t focus on just creating lots of agile teams. Or copying the existing organization structure into some sort of mold-like Scaled Agile Framework (SAFe) or magically creating squads, tribes, and guilds.
Instead, the authors emphasized that the real scaling goal should be to create an Agile Enterprise. That is something completely different than agile at scale and requires a fundamental rethinking of the organization.
Agile at scale focuses on improving the performance of agile teams while allowing bureaucracy and innovation efforts to coexist. Agile enterprises, in contrast, focus on creating agile business systems: they transform bureaucracy and innovation efforts into symbiotic partners that collaborate to deliver better results.
— Doing Agile Right
#3 – Agile vs. Bureaucracy
Before reading this book I had thought of bureaucracy as a big negative. I hadn’t really considered that there might be value in controls, hierarchy, division of labor, and standard operating procedures. I always envisioned bureaucracy as the domain of the pointy-haired boss from Dilbert.
After learning more, I realize that it doesn’t need to be one or the other. It doesn’t need to be all Frederick Taylor or all Agile Manifesto. There is value in each and together they can serve a purpose. The key is to strike a balance so that team innovation and creativity is unleashed while still delivering customer value in predictable ways and keeping promises.
#4 – Breadth of Coverage
Another aspect of the book that I found helpful was the breadth of coverage. It is appropriately broad to serve the needs of the target audience of senior executives in large companies. Like the book Unlocking Agility by Jorgen Hesselberg, it provides an inventory of things to explore in your organization to help agile succeed.
You won’t find a lot of details about how to lead an agile team, run a daily Scrum, or write a user story. If you are a senior leader looking for that type of information, perhaps you will want to look up ‘micromanager’ in the dictionary. Instead, the book focuses on the benefits of agility, the pitfalls and hype to avoid, and the major considerations for an organization heading toward agility.
#5 – Realistic
Unlike some books that hype agile ways of working, I found the book rather realistic in its description of the benefits of agile as well as the pitfalls. It doesn’t paint a rosy picture that everything is going to be just swell when you try to transform. Instead, the authors provide plenty of caution.
For example, companies should avoid copying what has worked for others. Instead, they should run their own experiments to test and learn. They will be better off with that first-hand knowledge than anything that other organizations can provide.
They also include when things go south including what they called the three toxic mistakes. Consider the case of ING Bank in the Netherlands. ING’s attempt at a big bang agile transformation was chaotic and left employees fearful and disillusioned.
Other real-world examples are sprinkled liberally throughout the book. Many of these are from public companies that you would recognize such as 3M, Saab, Dell Computer, SAP, and Bosch.
#6 – Agile Planning and Budgeting
Another key takeaway for me was the chapter on Agile Planning and Budgeting. I’ve read a few other books on this topic including Beyond Budgeting. I don’t think this topic gets enough attention.
Finances are the center of power and control in most organizations. And in my experience, it is the last area to transform to agile ways of working in most companies. If ever.
New agile teams will often run up against rigid annual planning cycles and the project paradigm and it often hinders true business agility. Those planning cycles and projects reflect the goal of certainty and predictability that drives most finance organizations.
I would say that for all but the top leaders in organizations, the budgeting process is not something they can control! But that doesn’t mean it isn’t important. Or that should not try to change it to be more agile.
Here are some ideas from the Planning and Budgeting chapter that I found useful:
- Use real customer input to inform plans. Rather than starting with a grand vision based on a bunch of assumptions, plans should be developed from the bottom up based on conversations with real customers.
- Fund persistent agile teams rather than projects. This is a really important idea and one that most large corporations struggle with. It is hard to let go of projects – things that have a set start and finish – and instead focus on long-standing teams.
- Be flexible enough to be able to accommodate new, high-value initiatives. Most organizations plan their budgets for the year and lock them in, making change difficult. Agile organizations have flexible planning processes that can fund new, high-value initiatives midstream.
- Revisit plans frequently. Agile organizations apply short feedback cycles to the planning process just as they would for software development. They continuously ask if the initiative is delivering the desired outcomes and question whether further investment is warranted.
#7 – Persistent, Cross-Functional Agile Teams
One of the things that I liked about the book was the importance of agile teams. And not just the temporary “team” that is tossed together with part-time people. The authors repeatedly point out the need for persistent teams that are fully dedicated. This is after all the basic building block of agile ways of working.
Some organizations struggle with this idea. “We don’t have enough people to have dedicated teams” is what they tell me. What they are really saying is, “We are trying to do more work than our current level of staffing will support.” You can check out my related post on this if you want to hear me rant.
The authors actually recommend that you Learn to Love Agile Teams! Those responsible for teams should be familiar with agile and support teams to be self-managing. For executive leaders, they suggest creating an agile team from the executive leadership.
#8 – Real Life Agile Examples from Recognizable Companies
Senior leaders often ask me for examples of similar organizations where agile has proven valuable. I find that applicable case studies are not as prolific as I would like. Which is surprising.
One would imagine there would be plenty of success stories and case studies available for agile. The reality is that the most popular examples and readily available materials are not applicable to senior leaders in large corporations. For example, Spotify gets lots of attention for their squads and tribes. But they were a startup leveraging agile from the beginning and most of what they did is just not going to work in a large, existing organization.
As I mentioned before, the book provides numerous examples of agile application from companies that are household names. The examples cited in the book include Dell Computer, Tesla, Amazon, Bosch, Saab’s Grippen Fighter, SAP, John Deere and many others.
A Few Things I did not agree With
While discussing process innovation in Chapter 7, the authors encourage open-market competition for capabilities. This means that you would have multiple teams creating the same capability working in competition with each other. Or that you would offer internal customers the choice of leveraging other vendors for capabilities produced by internal teams.
It sounds like a good idea on paper but my own experience with this type of competition back at IBM was that it fostered politics and unnecessary infighting between units. And allowing internal customers the option to go to the marketplace often creates shadow IT groups that cause integration, support and long-term continuity problems.
Another very minor thing that struck me was in the introduction of the book. The authors describe agile teams as fast-moving:
Agile—the business philosophy that relies on fast-moving, self-managing teams for innovation—has officially entered the mainstream of corporate management.
— Agile Done Right
What bothered me about this? Well, I know it is nit-picking but are agile teams really fast-moving? I think that is part of the misunderstanding about agile ways of working. For a Senior leader looking for a quick fix, the idea of moving fast may sound appealing. (Didn’t Mark Zuckerberg famously say to “Move Fast and Break Things.”). I don’t think it is actually about moving fast; it misses the point.
Instead of moving fast, I think of agile teams as 1) focused, 2) working on the outcomes that matter most and not wasting time on what doesn’t matter and 3) working at a sustainable pace. I know that statement is not as succinct as “fast-moving”. But better to be working on the right things in a focused and sustainable way than chasing your tail and trying to catch your breath.
Bottom Line for Doing Agile Right
I recommend Doing Agile Right. It is an easy read with plenty of stories of actual companies with positive and sometimes negative experience with agile. It serves as an inventory of considerations for senior leaders. The guidance will help senior leaders succeed and avoid the mistakes others have made.
