Book review: Succeeding with Agile by Ron Lichty

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, mechanisms he calls Improvement Communities that along with a more global Enterprise Transition Community can both spread scrum across your enterprise and debug adoption issues, ways to use scrum to manage the transition to scrum, 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 provides helpful anecdotes of two highly visible companies that, when waterfall stopped being effective, tried getting more rigorous about it, which turned out to just make things worse - then finally yielded and tried agile and got visible benefits almost immediately.

Yet he also notes from the first chapter that agile implementations are hard and don't always "take" - and explains why.

He also 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. (Have you seen the study of pair programming that shows it an effective way to counter Brooks' Law - the one about adding programmers to a late project making it later? Or the study of the negative impact of multitasking on productivity? Or the one showing productivity of teams larger than seven plummeting? Or the one that shows R&D teams do need new members to stay vibrant - but only at the rate of one very 3-4 years!)

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. 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.

It is good to have in print solutions to the many conundrums and traps that agile teams face:

* How to deal with work that seems indivisible into sprints

* How to make user experience, architecture and database design part of sprints, not separate waterfall efforts

* How to make testers part of the team and testing part of the team's work

* How to hold a hard line against mid-sprint change - and what to do when you can't ("abnormal termination", followed by immediate planning for a new sprint - never extend a sprint nor change its flavor!)

* Avoid the anti-pattern of doing design in one sprint, handing off to development in the next, handing off to QA in the third - designers, developers and testers should be working together in a sprint to solve, develop and deliver complete stories within a single sprint timebox

* How to deliver visible functionality every sprint even when you're mostly developing unobservable features (and why you want to)

* Figuring out how to get a slice of working application functionality every sprint (not just components, libraries or layers)

...and so many others.

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:

* Agile is not successfully implemented by fiat, without support from the folks at the front lines, but similarly it's not successful as a groundswell without senior management support. Check. Seen both.

* Agile is not a set of rules to be followed to the "T" but has to be adapted uniquely to each organization where it's implemented. It requires an iterative "provoke and observe" approach. Check. Seen that one.

* Furthermore, attempting to turn software development into a set of rules is counterproductive for the very reason that you need to keep questioning rules to get continuous improvement. Check.

* Yes, agile teams plan (and often more accurately than teams using a sequential process)

* While enormously rewarding, it's also a real challenge for developers to take on and deliver working software by the end of each of Scrum's short, focused, timeboxed sprints. Yup.

* Scrum transitions almost all need not only an identified sponsor, but a champion who will allot it time.

* "Testers often must learn how to test a system without as much reliance on documentation." Ouch.

* When piloting an organization's first Scrum projects, the pace will initially be less predictable than with the organization's prior approach to software development (and you should be clear about that up front with stakeholders).

* Similarly, consider early calculations involving velocity to be suspect (and communicate that, too, to stakeholders).

* Most teams will overestimate how much they will achieve in their first sprint.

* A good ScrumMaster does not end very many days with impediments left unaddressed.

* It's not a slam-dunk to make a team lead or a project manager the scrummaster. Directing the team will fail; facilitation, not command-and-control, is the managerial behavior to reward.

* A team's sprints should all be the same length to let the team benefit from a regular cadence and make sprint and release planning easier.

* One of the most striking changes for programmers and testers on a scrum team is that they can no longer sit in their cubicles and wait to be told exactly what to do. The words "Hand me the perfect spec" or "Hand me the perfect requirements doc" represent an abdication of responsibility. Each programmer and tester needs to be thinking about the product and asking questions about each feature and how it adds to or detracts from the overall product. It's hard for testers to transition to testing a moving target on the fly. But they need to. Everyone on the team is responsible for the ultimate success of the project in the broadest sense.

And then there are the surprises that come from reading an author who is himself remarkably well-read across genres. In a chapter on Distributed Teams, he reprints part of a table that compares country cultures five ways - speaking truth to power, importance of team unity / comfort with individualism, need to achieve, tolerance for uncertainty, and long-term orientation - that gave me aha's just scanning the chart.

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?

Yet Cohn is sometimes unsatisfying as well - drilling down not quite far enough in sharing what's worked:

* "Hold individuals accountable... employees need to know they will be held accountable for applying the new skills the organization is paying them to acquire." Great, but what mechanisms have been most effective in doing so? And which that seemed like a good idea initially turned out to reward the wrong behavior?

* "Set reasonable targets... Rather than asking a team to 'start doing test-driven development,' the ScrumMaster should ask the team to develop one feature that way in the next sprint... encourage teams to select realistic, actionable targets." Been there. Ever watched a team select everyone else's feature as the one to develop in a new way? I have. The NIMBY response of coding. (NIMSOC? - Not in My Section of Code.) Again, a little more "how" would be useful.

* "Prepare in this Sprint for the next," he exhorts, but while giving a notion of what to accomplish pre-next-sprint, he fails to give a picture of what that looks like - the mechanics of interrupting this sprint for next sprint's business.

* To scale Scrum, he offers multiple approaches, one of which is sharing team members between feature and component teams, an intriguing and seemingly useful approach about which he writes only two short paragraphs. It desperately cries out for an example.

But in its 400-plus pages, it's remarkable how few of these unsatisfying examples there are.

He doesn't limit himself to the Scrum framework but devotes a chapter to the technical practices that arose out of XP: Test-Driven Development, Refactoring, Collective Ownership, Continuous Integration and Pair Programming.

Mike is practical right down to identifying the non-product groups that must nonetheless change or loosen their strictures for you to succeed at agile, from facilities letting you hang cards and charts on the walls, to h.r. valuing and rewarding teamwork over individual contributions, to finance and marketing's expectations regarding project delivery prediction. And to recognizing the likelihood that many agile transitions in the real world will face waterfall-driven expectations at the beginning (e.g., no funding without a project plan and specs) or at the end (the heave-ho to QA). Or even that agile will be coexisting with and collaborating with waterfall teams simultaneously. He charts courses for each. He clearly has had to resolve questions and objections from all quarters: he devotes a chapter to coexisting with other approaches, with regulatory standards and with customer mandates like ISO 9001 and CMMI. (Software house Systematic, "... after approximately two years at Level 5, decided to also adopt Scrum. It reports that [CMMI and Scrum] complemented each other well: 'Scrum now reduces every category of work (defects, rework, total work required, and process overhead) by almost 50% compared to our previous CMMI Level 5 implementation while maintain the same level of process discipline.' ")

Equally pragmatically, Mike doesn't just give the "what," but explains why his recommendations have value, and closes sections by walking through common objections and how he and others have countered them. Importantly, Mike includes examples from companies ranging from SalesForce, IBM and Google to lesser-known companies of how they have tackled their transitions to scrum. 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.

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.