Getting Really Good at Agile [Ron Lichty]

From the speaker at the next Engineering Leadership SIG event, April 15, 2010:

The first half of Mike Cohn's book, "Succeeding with Agile: Software Development Using Scrum", isn't so much about how to be successful with agile as how to be successful replacing non-agile with agile, selling agile, and transitioning to agile.Mike Cohn is neither a wild-eyed dogmatist professing the one true way nor an ivory-tower philosopher; he's a pragmatist. He devotes entire chapters to helping scrum evangelists decide whether to start with a pilot or go all-in across the organization, whether to pilot publicly or in stealth, what factors might prevent success, how to swing things your way, how to approach a transition in steps, picking the right first project and first team, and how soon to adopt agile technical practices like simple design, pair programming, TDD, continuous builds, refactoring, and automated testing. He notes from the first chapter that agile implementations are hard and don't always "take" - and explains why. He recommends solutions to the many conundrums and traps that agile teams face.

About midway through the book, as you're reading insights into teamwork, you realize that this book is not just about transitioning to agile but about getting really good at agile - and that you're going to need to read it not just once but come back to it for new insights again and again. The fact is it's stuffed with tips, guides, data, approaches, failures, successes, and helpful hints of every kind.

Part of what makes this book important for me is repeatedly reading observations consistent with my own experience, but drawing on so many more experiences with agile that it results in emergent patterns, as well as in truths that are too often left unsaid. Then there are the surprises that come from reading an author who is remarkably well-read across genres. He does us all the favor of reviewing and summarizing scads of studies and surveys that demonstrate why agile is worth the effort, with data on productivity gains, lower costs, improved employee engagement and job satisfaction, faster time to market, higher quality and, importantly, stakeholder satisfaction gains.

What's the role of a manager of a self-organizing team? One of them, agile gurus seem to agree, is exercising subtle control (as opposed to command-and-control) and Mike provides an entire framework for debugging team problems and influencing their success. This will be one of those chapters I know I'll revisit repeatedly.

In another example, Mike remarkably provides what in essence is a crash course in change, and that chapter alone, while loaded with specifics about making a change to agile, could be used by any technical leader making a technology-and-culture change of any kind. Know why shopping carts were introduced and how shoppers were convinced to use them? Mike does, and effectively uses the example to teach change leadership. How does a leader deal with the skeptics and the saboteurs, the diehards and the followers certain to show up on your teams? How do you sway the uncertain to get on board?

Cohn is practical right down to the challenges from facilities and h.r., the likelihood agile transitions will face waterfall-driven expectations, and strategies for coexisting with other approaches, regulatory standards and processes. Importantly, he provides helpful anecdotes and examples from companies large and small. He's familiar enough with other process changes your company may have attempted to be able to compare and contrast and differentiate the substance and style of scrum from everything that came before.

While Cohn is sometimes unsatisfying - drilling down not quite far enough in sharing what's worked - in its 400-plus pages, it's remarkable how few of these unsatisfying examples there are.

Finally, I should point out that though it may not be immediately obvious, there's one more group of readers for whom this book has enormous value: Agile wannabes who know their current process isn't working. They frequently have heard of agile but have no idea what it looks like or how to sell it. If you're one of those, you also need to read this book. Mike Cohn over and over offers advice and examples and data that will give you aha after aha as you build a picture of what a truly effective process can look like - and how yours could become functional like his.

If you're interested, there's a longer version of this review at:

http://ronlichty.blogspot.com/2010/04/book-review-succeeding-with-agile.html
_________________________________________
Ron Lichty is a "VPE of Fix-It," providing interim and on-demand VP Engineering services to optimize software organizations and efforts. He specializes in solving problems like painfully slow product development, past-due estimates with no delivery in sight, snafus from geographically dispersed teams, scalability stymied by sluggish data integration, productivity bridled by uncertainty, an "order-taking mentality" from teams that should be proactive, and teams unable to break out of research and move on to development and delivery. He also untangles organizational knots, creates roadmaps everyone can follow, builds communications with other parts of the organization, coaches and trains organizations in agile and scrum, and gets teams productive and focused on delivery, quality and customers. Small tweaks, dramatic impacts. He'll be presenting the SDForum's April 15 Engineering Leadership SIG topic on how agile changes the development manager role group in Palo Alto: "If Agile Teams Are Self-Directing, What Do Managers Do?" His book on managing software developers and software development teams, "Managing the Unmanageable: Rules, Tools, and Wisdom for Managing Software People and Projects", is forthcoming.