Agile Software Development in the Large: Diving Into the Deep [Paperback]

Reading the title, I expected this book to cover both experiences and some techniques to help make agile processes either scale to large projects or at least integrate well with either diverse agile processes in a large organization or agile and non-agile processes. Unfortunately, there was none of that. Most of the anecdotal stories seemed to be of teams of no more than about thirty people, and most of the details just seemed to be to have a customer around, keep iterations short, and have retrospectives and act on them. All good tips, but hardly different from the usual advice. Maybe it was unrealistic to expect to hear about how to handle multiple hundred to low thousand person teams and the interactions.

All of that said, this is still a very approachable, readable book about general agile development. It's light enough to prove an easy introduction for folks not familiar, and it's careful not to just be a primer on Scrum or XP. But if you're looking for a book on scaling up, this isn't it.

1) This book provides an excellent perspective on the issues and challenges of adapting "Agile Processes" for use on large programs. To date, most literature addressing use of eXtreme Programming (XP), for example, state that this method is intended for use by small development teams. Note that this book doesn't focus on XP as "the only way" to do Agile Development; the book is intended to be "method neutral" and it achieves this end. The summaries at the end of each chapter provide valuable reinforcement for the lessons-learned in that chapter.

2) The introduction provides some interesting philosphical discussion regarding how one might consider approaching Agile Development on large teams, and provides initial thoughts on how to scale up proven agile processes for large teams.

3) Chapter 2, "Agility and Largeness", discusses a number of "generalities" that must be considered when trying to work a large project with a large team, using Agile methods. The author identifies several important issues that must be addressed (e.g., communication issues in large teams that cannot be co located). In addition, this chapter contains an excellent discussion of factoring.

4) Chapter 3, "Agility and Large Teams" addresses the "people issues" associated with scaling Agile methods to large projects. gain, communication is addressed, along with team building. Suggestions are provided about how to implement "virtual teams" on a large, agile project.

5) Chapter 4, "Agility and the Process" seems to be, to an ex process engineer at least, the heart of this book. Objectives, feedback, and planning are discussed in depth, and the use of regular retrospectives is suggested (in contrast to an end-of the-project "post-mortem). Tips are given to help you get started, and the importance of a "culture of change" is identified and discussed.

6) Chapter 5, "Agility and Technology" provides some interesting thoughts on how state-of-the-art technology can be a hindrance, and how state-of-the-practice technology can assist a project, whether agile or not.

7) Chapter 6, "Agility and the Company" provides valuable insight into how corporate cultures and structures can help and hinder agile development in the large. The perspectives on planning and control, and QA are interesting, to say the least. I won't offer any hints except to say that this chapter makes VERY interesting reading, especially to a person (like myself) with an extensive QA and testing background. The only thing I didn't see addressed in this chapter, which I saw in a recent article in Better Software magazine, was the difficulty of applying a corporate reward structure to Agile Teams.

8) In Chapter 7, Ms. Eckstein wraps up the book with a report on a large project she assisted (or more than that) starting up with agile processes. This chapter also makes very interesting reading, and offers some significant lessons that Ms. Eckstein and the company she was working with learned.

A couple of minor areas I'd have liked to see addressed or modified, though maybe this is due to her viewpoint from the European software development culture. Ms. Eckstein uses the terms "testing" and "quality control" interchangeably. That's generally not true in the US, "QC" is usually a suborganization within Quality Assurance, and testing is usually a separate organization. Also, her experience seems to be that QC/testing comes in at the end of a project. That's not the way we generally do things in more mature, enlightened companies (like Lockheed Martin Transportation & Security Solutions) in the US. But in summary, the book is well-done and a good read for any project manager who'd like to do development in an agile manner, on a large project.

Buy this book, and read through it carefully if you're considering using Agile processes on a large project. It's well worth the investment. Ms. Eckstein and Dorset House have put together another excellent offering for the software community.

Most other titles on Agile Software Development repeat the mantra about lightweight processes and how they are only applicable for small teams of a dozen or so. This book is different. It sets out to offer the advice of someone who has been running software projects with over hundred people using an agile process -- to help others succeed in the same.

While there aren't any hard numbers and the like, a formula to make a silver bullet, there's plenty of sound advice starting from structures to help scale up an agile process, the challenges one will encounter while scaling, and the peopleware issues evident in large, often distributed projects as well as large companies in general, with all the associated bureaucracy and policies. The discussions about building teams around features versus components, for example, and the division into domain teams and technical service teams are useful reading for someone facing such decisions.

Also, this book does not expect you to know the slang of agile software development. It's written so that a manager familiar with software development -- but not necessarily agile software development -- has no problem understanding what the author is trying to pass on.

What's missing from this book -- something one might wish to get support for, facing a larger than usual agile project -- is the deeper coverage of techniques to facilitate things like emergent architecture across a distributed development team. The project report from a 170-member software project was not quite as detailed as I would've hoped. Detailed case studies are something I am personally very interested in reading.

In summary, while the advice in this book is relatively abstract, and you might think it doesn't have that much to offer if you are already familiar with Agile Software Development in general, I would certainly not dare to risk a large project by NOT reading this book.

› Go to Amazon.com to see all 6 reviews  4.3 out of 5 stars