Over the years I have seen a lot of software development organizations try to become agile. Some have succeeded beyond their wildest dreams and continue to improve to this day. But those are the exceptions. In a more typical scenario, agile development shows some initial success, but once the low-hanging fruit has been picked, it doesn’t seem to deliver that much sustained value over time. The question is, why does sustained success from agile development seem to be so elusive?

I observe three reasons why agile initiatives seem to plateau:

First, agile development is frequently initiated as a grassroots movement to develop better software—it is seen as a “developer thing.” Consequently, development managers and customer organizations are often not on board. This is a mistake, because dramatic improvements from agile development require a different mindset on the part of both development managers and the organizations for which the software is being developed.

Second, some companies have made serious missteps in applying agile—perhaps by developing an unmaintainable code base or creating an unsupportable set of expectations in the minds of development teams or customers. Sometimes an agile implementation follows a simple recipe that is a bad fit to the company needs; sometimes the implementation is perfect for some people in the company (developers, for instance), but it doesn’t take into account the needs of others (testers, for example).

Finally, agile development might be considered a silver bullet—a quick and easy fix to problems that plague software development. In this case, the hard work required to make agile successful is ignored, and when companies come to the realization that agile is not going to be as easy as they anticipated, all too often commitment dissipates.

Initiating and sustaining an effective agile development program is a challenging journey. First, implementation should involve far more than the development team. A broad array of cross-functional impacts should be considered, not to mention the fact that agile might well require a different management approach. Second, the technical practices that agile brings to the table—short iterations, test-first development, continuous integration—are not optional. Ignore them or leave them until later at your own risk. Finally, nothing, not even agile development, will remove the inherent complexity of software development or its nonlinear escalation with size.

In Becoming Agile, Greg Smith and Ahmed Sidky lay out a path to agile software development that addresses the typical failure modes. First, they understand that no environment is perfect, and it is practically impossible to roll out a perfect agile process. To compensate for this reality, Greg and Ahmed suggest numerous ways of pursuing the agile principles within the constraints of your business. The book does not ask you to discard processes that have been successful for you; the authors realize your existing processes may have many positive aspects. They show you how to convene a cross-functional steering committee to guide the agile implementation so that it fits into your organization.

Second, since part of being agile is learning and adapting, Greg and Ahmed show you how to pilot the new approach. They explain how to select a pilot project and how to try out the new ideas and adapt them so they work in your context. Through an extended case study, they show what actually happened in agile deployments they have led. The case study also introduces real personas so you can see how different personality types react to a move to agile.

Finally, Greg and Ahmed dispel the notion that agile is a simple recipe that anyone can learn in a day with guaranteed success. Instead of offering a simple, foolproof formula, this book shows how to thoughtfully introduce agile into a company. After leading you through a readiness assessment to determine the most logical areas to introduce agile, Greg and Ahmed take you through assembling a cross-functional leadership team, identifying the best aspects of your current process, designing more adaptive processes, carefully choosing a pilot, trying and adapting the process, and gradually improving and expanding agile processes over time. This strikes me as a more likely approach to successfully evolve a new development process that fits the company.

The book is full of simple tools that will help people think clearly; it is about readiness, chartering, specifying, estimating, assuring quality, product demonstrations, retrospectives, and so on. By using an extended case study, Greg and Ahmed show you one example of a migration to agile, all the while pointing out other ways to accomplish the same objectives. Their book is neither a recipe nor a set of principles. It is a thoughtful, practical set of steps, presented with commentary and alternatives, about how to become agile. It will help you put together an agile development approach that matches your company needs and has a high likelihood of delivering sustained value over time.

Mary Poppendieck
President, Poppendieck, LLC