The agile approach is full of tensions and contradictions. For example, the first line of the agile manifesto states that the agile approach values “individuals and interactions over processes and tools” [1], yet agile methods stress following extremely prescriptive processes and emphasize using particular tools and methods more than many other approaches. Of course, such tensions and contradictions surface when agile methods are used, leading to the need for expert advice.
Cohn offers very detailed and extensive advice about how to make agile methods (particularly Scrum, the most popular agile method) work. The advice is extensive indeed: the book assumes close familiarity with agile methods (especially Scrum), and focuses mainly on managerial rather than technical issues. Although the result is rather dry when read from start to finish, it is ultimately a valuable resource for practitioners facing particular sorts of problems.
The book is divided into five parts. Part 1 addresses issues surrounding getting Scrum started in an organization, including motivating the change, strategies and techniques for making the transition, altering the organization to support the change, and choosing projects. Part 2 is about dealing with individuals during the transition to Scrum. It offers advice about overcoming resistance to the new regime, new and changed roles, and new and changed technical practices. Part 3 discusses teams--how big they should be, what their attitudes should be, how they should be led, what work they need to do, and how they should do it. The latter topic goes into the Scrum process in some detail, including managing the product backlog (which is the prioritized list of jobs that teams must take on as they develop or maintain software), working through a sprint (the period during which a team prepares a new potential product release), planning, and achieving and maintaining quality. Part 4 discusses organizational issues that arise when Scrum is adopted, including using Scrum with large projects, working with distributed teams, fitting agile methods in with traditional methods, and dealing with human resources, facilities management, and project management offices. The final part of the book recommends ways to measure the progress of a transition to agile methods.
Each of the 21 substantive chapters has a short but pithy annotated bibliography of relevant literature. There is a comprehensive bibliography at the end of the book and an adequate index.
Cohn’s attitude is pragmatic, and he includes advice about how to deal with problems arising from agile methods that were not often acknowledged in the past, such as difficulties with team coordination, resistance to the process and its techniques, and the need to produce documentation. In addressing these issues, Cohn makes good use of the literature on organizational change, teamwork, and leadership, and more use of the software engineering literature than has been the usual practice in discussions of agile methods. His advice is also largely based on his and other consultants’ experiences, so there is anecdotal evidence as well as some research to back up his recommendations.
Cohn has written a useful and comprehensive reference that proposes ways to deal with many of the managerial problems developers encounter when introducing and using agile methods, especially Scrum. It will help both developers and managers make a successful transition to Scrum.
