Each year, members of our community present new methods of building and maintaining software. It is our task to be open-minded, learn, and think. We must always look at our people and the product we are building before we decide which process or method to use.
Several notable people have recently presented new ways to build software products. James A. Highsmith has shown us his adaptive method (ASD) in "Adaptive Software Development." Kent Beck introduced eXtreme Programming (XP) in "Extreme Programming Explained." Both of these books are well known and highly praised.
Highsmith contends that the biggest challenge is working in high change environments. His adaptive cycle is a circle of collaborate-speculate-learn. This differs from the iterative cycle of plan-build-revise. The emphasis is on an adaptive organization instead of an optimizing one. Emergence or arrival of the fittest is more important than optimization or survival of the fittest.
Beck's XP describes a team approach emphasizing small releases, a shared story, continuous testing, continuous integration, refactoring, paired programming, simple design, and on-site customer participation. Beck encourages good practices taken to the extreme.
ASD and XP are excellent, and the two short paragraphs above do not serve them well. ASD and XP are process models. Whoa! Many people disdain the "P" word. Highsmith and Beck show us another way to make software; a way to work without all the heavy Capability Maturity Model (CMM) bureaucracy process stuff, don't they? These books are "antiprocess," aren't they?
No. ASD and XP are process models in that they describe what people do to build and maintain software products.
ASD and XP, like all process models, are not the best choice for every situation. For example, Highsmith compliments the process-heavy CMM for complicated products. "The CMM is a wonderful optimization model... Optimization works in a complicated world." Highsmith's book emphasizes complex situations and the superiority of ASD for them.
Beck points out some cultural situations that prevent XP from working. "You probably could not run an XP project with a hundred programmers. Nor fifty. Not twenty, probably. There are projects whose (large) size and (short) time require such large numbers of programmers.
Our job as project managers and leaders is to put these new approaches, these new twists on process, into our toolkit. Having a tool is meaningless; using a tool correctly is what is important. We must understand where and when the tools are appropriate.
The basic people, process, and product situation has not changed (see "The Software Project Manager's Handbook" mentioned later). People apply a process to build a product. Sometimes our organization dictates what process we use. Sometimes we can choose the process depending on our people and product.
We must observe our people and our product and choose the best process accordingly.
Dwayne Phillips has worked as a software and systems engineer with the US government since 1980. He has written "The Software Project Manager's Handbook, Principles that Work at Work," IEEE Computer Society, 1998. He has a Ph.D. in electrical and computer engineering from Louisiana State University. He can be reached at d.phillips@computer.org.