Book Review: Succeeding with Agile

August 10, 2010

Succeeding with Agile: Software Development Using ScrumSucceeding with Agile: Software Development Using Scrum by Mike Cohn

This book provides an excellent, detailed, pragmatic view of adopting Scrum by someone who has years of experience in guiding organizations in their Scrum implementations. The book is organized into five parts:

Part I – Getting Started

Part II – Individuals

Part III –Teams

Part IV –The Organization

Part V – Next Steps

The book begins by talking about patterns for adopting Scrum, progressing into discussing how Scrum will impact individuals, teams, and the organization as a whole. In general, Succeeding with Agile serves as an excellent guide to understanding and managing change that Scrum development will present.

Do you want to introduce Agile development gradually, or do you want to use an all-in approach? Do you want a public display of agility or do you desire a “stealth” approach? Mike Cohn fully explores these questions, complete with the benefits and trade-offs to consider as you make your decision.

When it comes to managing change, Mike notes that, “Successful change is not entirely top-down or bottom-up. A process like Scrum must include elements of top-down and bottom-up change.” In addition, Mike points out that, “Scrum has long tentacles and will reach into many areas of the organization. Adopting Scrum is pervasive, and it will have implications to the organization that reach far outside the software development department.”

My company is in the midst of dealing with Scrum's tentacles. The development organization is adopting Scrum across the board, but the rest of the organization needs to become a part of the change – we’re beginning to see signs of mismatched expectations and issues with our development organization interacting with the rest of the company.

Mike’s coverage of the nature and issues with change is invaluable. He includes a good discussion on roles of those on a Scrum team and how Scrum teams should go about working together. This includes the mechanics for Scrum, but other well-grounded insights and observations that will help make your Scrum adoption more successful.

For example, his assessment of the need for technical practices echoes the observation of the industry, which is gradually moving towards a Scrum/XP hybrid to achieve complete success. Mike states, “I’ve observed teams who in sprints, conduct good sprint planning and review meetings, never miss a daily Scrum, and do a retrospective at the end of each sprint. They see solid improvements and may be as much as twice as productive as they were before Scrum. But they could do much better.

“What these teams are missing – and what stops them from achieving even more dramatic improvements – are changes to their technical practices. Scrum doesn’t prescribe specific engineering practices, but it does require teams to deliver high-quality, potentially shippable code at the end of each sprint. If teams can do this without changing their technical practices, so be it. Most teams, however, discover and adopt new technical practices because it makes meeting their goals much easier.”


Truer words couldn't be spoken! Scrum doesn’t prescribe technical practices, and we’ve been working towards introducing more technical practices to our Scrum development in response to the need to produce “better software, faster.” We’ve seen how Scrum improves the development process, but technical practices can really put a team over the top in terms of improving productivity. One of our teams recently refactored code that was surrounded by automated unit tests, allowing the refactoring exercise to be performed with much higher confidence and speed than would have been possible by relying on manual testing alone.

Leading and influencing self-organized, self-directed teams is another area that is discussed in the book. Mike quotes Philip Anderson from the Biology of Business: “Self-organization does not mean that workers instead of management engineer an organization design. It does not mean letting people do whatever they want to do. It means that management commits to guiding the evolution of behaviors that emerge from the interaction of independent agents instead of specifying in advance what effective behavior is.”

As a manager, “guiding the evolution of behaviors” can be tricky territory, particularly if you are used to defining and specifying everything yourself and are now attempting to make a change by feeling your way through the process. Mike Cohn comes to the rescue with sound advice, including a discussion on Containers, Differences, and Exchanges, where:

A container is some boundary within which self-organization occurs. (e.g., physical, amount of autonomy)

A difference exists between individuals.

Transforming exchanges influence how a team organizes in response to a challenge.

If you are experiencing problems, Mike points out that leaders can influence how a team or teams self-organize by adjusting containers, amplifying or dampening differences, or altering exchanges.

The ultimate goal of Agile development (in my opinion) is to create an adaptive and responsive organization, one that is self-organized and self-adapting. The trick is that you can’t completely design it up front, and Mike again quotes Philip Anderson, who says, “Self-organization proceeds from the premise that effective organization is evolved, not designed. It aims to create an environment in which successful divisions of labor and routines not only emerge but also self-adjust in response to environmental changes. This happens because management sets up an environment and encourages rapid evolution towards higher fitness, not because management has mastered the art of planning and monitoring work flows.”

As organizations move to self-organized teams, there will be changes that everyone must understand and work through. Management will do less planning and oversight of the work; and contrary to some thinking, there will be work for management to perform. Mike devotes a couple of chapters to the issues of teamwork and leading and influencing self-organizing teams that are well worth reading in their own right.

Evolving organizations also need to be learning organizations, and not rushing itself to the point of making stupid mistakes. Mike Cohn makes an assertion that I’m in complete agreement with: “An organization that favors long-terms success will be more likely to invest in training, support working at a sustainable pace, be willing to allow employees time to explore novel ideas, and will not exchange meeting a near-term deadline for unmaintainable code.”

The latter half of the book discusses topics such as scaling Scrum, distributed teams, and the role and impacts that Scrum places on entities such as Human Resources, Facilities, and the Project Management Office. Again, worth a read as you progress down the agile road.

Overall, I found this book to be an excellent resource. If you are starting out with Scrum, this book will provide a wealth of information to refer to on your Agile journey for years to come. We’ve been at Scrum for three and a half years now, and I found plenty of useful information in this book. I’m expecting that I’ll need to refer to portions of this book in the future myself, as we haven’t gone down all of the paths outlined in this book, including scaling Scrum and working with distributed teams. But if we do, this book provides a solid, single point of reference.

It’s also a good book to review from time to time, and I plan to as we continually strive to tweak and improve what we’re doing. As Mike Cohn pointed out, “There can be no end state in a process that calls for continuous improvement.”