Dr. Dobb's Journal November 2002
When asked what kind of programming I do, my reply is "I work at moving things from the state of the art to the state of the practice, from bleeding edge to leading edge." Agile methodologies target this area, which Jim Highsmith calls "exploratory programming" in Agile Software Development Ecosystems. In the methodologies and stories in this book, I find many of my own successes and failures—and how to use them to improve software development. Needless to say, I like Agile Software Development Ecosystems. I like the understanding of the past it provides, the insight into the present, and suggestions for the future.
Agile methodologies (AMs) are lightweight processes for teams working in turbulent, changing environments. AMs are partly a reaction to the excessive and inappropriate use of heavyweight processes like ISO 9001 and SEI's CMM. Anything promoted as the universal solution is going to be overhyped. AMs are also a response to the increasing pace of change.
Agile Software Development Ecosystems principally consists of interviews with major agile software developers and descriptions of their methodologies. This is congruent with the agile practices that emphasize people over process. Stories are an explicit part of several AMs.
I love good teaching stories and this book is full of them. Some are prescriptive—"we did this, and it worked or not."
Put four to six people who exhibit good citizenship [behavior toward each other] in a room, and you will get software out. Playing well together is the bottom line.
—Alistair Cockburn
But my favorite stories are descriptive—"this is what a master looks like"—as in the following example:
The best manager I ever had was at the Stanford linear accelerator lab. I worked in the control room. This guy spent all his time making Heathkits. Everybody complained how lazy he was and why he didn't do this or that. But everything was always on time; if you needed parts, they were there. Personality clashes got resolved instantly. I've always wished I wasn't 20 years old when it happened so I could appreciate that this guy was absolutely masterful. He kept everything running absolutely smoothly. So that's my aesthetic as a coach. If I do everything perfectly, then my contribution is totally invisible to the team. The team says, "We did this."
—Kent Beck
The middle sections of the book dragged on as prescriptive (telling), outweighing the descriptive (showing). My interest revived near the end as Highsmith discussed the "meta-ideas" or philosophy common to most of the agile methodologies: "documentation is not understanding," "formality is not discipline," and the like. He covers various axes where generalized heavyweight processes and agile methodologies lie. For example, extreme programming (XP) is low formality (few formal reviews) and high disciple (pair programming is continuous review). Alistair Cockburn's Crystal methodology is high tolerance (substitution of equivalent practices is allowed) and XP lower tolerance. Heavyweight processes are generally thought of as low tolerance, but there are several good articles in the book discussing how to integrate agile practices into CMM and ISO 9001.
Among the principles agilists espouse is that one size doesn't fit all, and any methodology must be adapted to local conditions—corporate culture, team size, requirements uncertainty and volatility, location diversity, and so on. Cockburn's Crystal methodology explicitly matches practices to team size and project "criticality"—comfort, discretionary money, essential money, life, and the like.
So who is Agile Software Development Ecosystems written for? Software developers, their managers, and perhaps anyone who does creative work in a team. Having some experience helps in understanding the points made, and having the raw materials to try out practices make the principals concrete.
The ideal reader is someone who has been through several projects with both no process and a heavyweight process, who knows their strengths and failures, and is looking for a better way. A columnist (not at this magazine), who should know better, stated that he was sure pair programming didn't work, though he had not tried it. I tried XP's test-first programming (write the test before the code) and love it—it is more powerful than it looks. Writing the test first makes the requirements real and then the code is easier to write, and usually passes on the first test. This was not my usual experience. Now I'm working on adopting other agile practices and deciding which agile methodology to explore in depth.
In short, Agile Software Development Ecosystems is a good survey for anyone looking for a methodology to adopt. Highsmith covers a half dozen methodologies (Scrum, DSDM, Crystal, FDD, LD, XP, and ASD). Unless you are extremely well read on the subject, there will be some methodologies here that you haven't heard of.
DDJ