7 Books Every Agile Coach Must Read
“I want to be an Agile Coach” is a question I often get from aspiring Scrum Masters and Agile Coaches. The discussion often leads me to recommend them one or more books. These books have helped me immensely on my agile journey to develop a distinct coaching perspective and style. So these 7 are really what I end up recommending to most people. While practices and techniques you will learn in these books will serve you well, the magic is really in the mindset that evolves.
Happy reading !!
The Principles of Product Development Flow: Second Generation Lean Product Development
“…the dominant paradigm for managing product development is wrong. Not just a little wrong, but wrong to its very core.” says Reinertson. This book changed the way I understood product development. It was a fundamental shift. In bringing ideas from lean manufacturing, telecommunication networks, transportation systems, military doctrine, and others, Reinertson provides the science behind the practices in this book effortlessly going into the methods.
Special Note: This is not an easy read. Take your time reading, absorbing, and reading again. I have a personal discipline of reading a chapter or two once every six months. Every time there are new insights.
Gems from this book:
“Since high capacity utilization simultaneously raises efficiency and increases delay cost, we need to look at the combined impact of these two factors. We can only do so if we express both factors in the same unit of measure, lifecycle profits. If we do this, we will always conclude that operating a product development process near full utilization is an economic disaster.”
“In our factories, we create flexibility by paying more to workers who can work at more stations on a production line. We value flexibility, and we pay for it. In contrast, most product development organizations exclusively reward specialization.”
“What should we change in our product development process? Eliminate waste? Increase quality? Raise efficiency? Shorten cycle time? The key to answering this question is to step back to a more basic question: Why do we want to change the product development process? The answer: to increase profits.”
Cinderella and the Coach — the Power of Storytelling for Coaching Success!
Stories allow people to connect to a message in more profound, meaningful ways. Lisa Bloom beautifully conveys the power of stories for transformational success. There are some great stories in this book, and Lisa convincingly demonstrates why stories work. As an agile coach, the ability to engage our clients, teams, and leaders we work with is critical. Stories provide the perfect medium for that.
Gems from this book:
“Stories are the way that we most often, most truthfully and most urgently show up in the world. Are you telling the story that serves you best?Well, next time you find yourself in the middle of a story, make it a good one!”
“As a Story Coach you can deepen and enhance the coaching process with the rich world of Storytelling. Each story becomes a gift, an opening into a world of creative imagination where great wonders and magic are the reality. As we look at more story elements, we learn how to create this magic and weave it into the coaching process.”
“As I draw this to a close, I know that you may remember that Storytelling builds relationships. You probably won’t remember its’ advantages in parenting and coaching. But I’m sure you’ll remember the Magic Glen and the boys running home with the promise of ice-cream. We always remember the story.”
Introduction to Disciplined Agile Delivery: A Small Agile Team’s Journey from Scrum to Continuous Delivery
Disciplined Agile Delivery (DAD) Framework provides practical and pragmatic advice towards scaling agile. The book discusses best practices across the entire lifecycle — requirements, architecture, delivery, and governance. I have found the DAD approach a helpful starting point for traditional enterprises getting their first taste of agile. More so in places where we have a mix of small to medium-sized teams delivering many solutions. DAD approach choosing the correct practices for context fits well in those scenarios.
Special Note: My journey with DAD began with the Disciplined Agile Delivery: A Practitioner’s Guide to Agile Software Delivery in the Enterprise several years ago, much before PMI took over the DAD framework and published this book. However, I wanted to suggest to you the most updated version.
Gems from this book:
“Many organizations are struggling to be successful with mainstream agile methods such as Scrum. Sometimes, the impulse is to give up and try the next great thing such as Lean or Scaled Agile Framework (SAFe®). The reality is that the source of failure of existing agile adoptions can often be traced to either the misapplication of core agile principles or a naïve approach to scaling agile and the need to address enterprise concerns.”
“One of the reasons why DAD is quickly growing in popularity is that it acknowledges how organizations that are effectively scaling agile are really doing things. We think that it is important to clear up some of the misconceptions regarding the hype of agile purism versus what we have found to be really happening based on both our hands-on experience with many clients around the world and our comprehensive industry research.”
“One of the great advantages of agile and lean software development is the wealth of practices, techniques, and strategies available to you. This is also one of its greatest challenges, because without something like the DAD, it’s difficult to know which practices to choose and how to fit them together. Worse yet, many teams new to agile will treat a method like Scrum or SAFe as if it’s a recipe, ignoring advice from other sources and thereby getting into trouble.”
The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win
A novel that teaches you DevOps. Can it get better than that? The narrative is engaging and the insights deep. Having worked in “crisis” projects several times, I could relate to Bill, the IT manager at Parts Unlimited. This book shows us that IT work has more in common with manufacturing than we may have imagined.
Special Note: If you enjoy this one, take a shot at “The Goal” too.
Gems from this book:
“technical debt’ that is not being paid down. It comes from taking shortcuts, which may make sense in the short-term. But like financial debt, the compounding interest costs grow over time. If an organization doesn’t pay down its technical debt, every calorie in the organization can be spent just paying interest, in the form of unplanned work.”
“I’ve seen this movie before. The plot is simple: First, you take an urgent date-driven project, where the shipment date cannot be delayed because of external commitments made to Wall Street or customers. Then you add a bunch of developers who use up all the time in the schedule, leaving no time for testing or operations deployment. And because no one is willing to slip the deployment date, everyone after Development has to take outrageous and unacceptable shortcuts to hit the date.”
“until code is in production, no value is actually being generated, because it’s merely WIP stuck in the system.”
How Google Tests Software
This book provides an interesting perspective into how Google worked to “build quality in” into their software development efforts.
Contrary to what you may expect, this book does not give you the details of how Google actually tests. However, it does an excellent job of conveying their mindset and approach. It articulates how developers are a crucial part of any test strategy (unlike the way many see testing to be sole responsibility of “testing teams”)
Gems from this book:
“Small tests lead to code quality. Medium and large tests lead to product quality.”
“Boring work is generally delegated by creative people (for obvious reasons) and flows downhill to people uncreative enough to do it out of duty or necessity. Be really afraid of boring work! It says something about you and your propensity to take whatever is given. It’s a sign of your missing ambition.”
“Specifically, engineering roles that enable developers to do testing efficiently and effectively have to exist. At Google, we have created roles in which some engineers are responsible for making other engineers more productive and more quality-minded. These engineers often identify themselves as testers, but their actual mission is one of productivity. Testers are there to make developers more productive and a large part of that productivity is avoiding re-work because of sloppy Development. Quality is thus a large part of that productivity.”
The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses
Eric Ries defines a startup as an organization dedicated to creating something new under conditions of extreme uncertainty. While the levels of uncertainty might vary between organizations, the “build-measure-learn” approach that Eric advocates is helpful in the VUCA world, we are operating in. Validated learning that relies on rapid scientific experimentation and measuring actual progress rather than vanity metrics helps us build products closer to market needs.
Gems from this book:
“We must learn what customers really want, not what they say they want or what we think they should want.”
“As you consider building your own minimum viable product, let this simple rule suffice: remove any feature, process, or effort that does not contribute directly to the learning you seek.”
“The big question of our time is not Can it be built? but Should it be built? This places us in an unusual historical moment: our future prosperity depends on the quality of our collective imaginations.”
Kanban: Successful Evolutionary Change for Your Technology Business
Putting up a board with cards is not Kanban. There is a lot to Kanban, as you will discover once you dive into this book. This book provides excellent insights into the Kanban Method — an evolutionary approach to organizational change. The non-disruptive yet practical approach has helped hundreds of organizations. I have particularly found it apt in complex scenarios where change cannot simply be “forced in” regardless of the top leadership commitment. It needs to be evolutionary, and this book shows you how.
Gems from this book:
“choose to use Kanban as a method to drive change in your organization, you are subscribing to the view that it is better to optimize what already exists, because that is easier and faster and will meet with less resistance than running a managed, engineered, named-change initiative. Introducing a radical change is harder than incrementally improving an existing one.”
“if there is no explicit limit to work-in-progress and no signaling to pull new work through the system, it is not a kanban system.”
“David, we have been around your building and we’ve seven kanban boards. Each one is different! Each team is following a different process! How can you possibly cope with this complexity?’ My answer was always a dismissive ‘of course! Each team’s situation is different.”
I hope you like this list, and it helps you. Cheers. Thanks for reading it all :)
