The developers who gathered to develop the Agile Manifesto were not just theorists; they were dedicated practitioners, who went on to create development methods based on the agile principles.

Ken Schwaber and Jeff Sutherland were the originators of the Scrum methods we’ve reviewed. Kent Beck, Ward Cunningham, and Ron Jefferies, also signers of the Agile Manifesto, are codevelopers of Extreme Programming, which many associate with the idea of agile software development. Alistair Cockburn, another signer of the Agile Manifesto, is the architect of the Crystal methods and is an author of influential works on Use Cases. Manifesto signer Jim Highsmith has been the chronicler of the agile movement and has done the most to migrate agile concepts from the software to the project management community.

In previous project management columns, we discussed some principles of agile development and looked at the Scrum agile methodology in detail. Now we’ll explore each of these variants of agile methods and discuss criteria for selecting one approach or another based on the project at hand.

Extreme Programming (XP)

XP has received the lion’s share of interest among agile methods. XP drew attention because it converged with many of the practices that developers were discovering in real project work and because its initial successes, including the well-known Chrysler Comprehensive Compensation project, coincided with the Internet movement, with its need for an approach geared to speed-to-value and exploratory, innovative projects.

XP is unique among the agile methods surveyed here because it is focused on software development, and it is not presented as a project methodology. XP doesn’t scale to teams larger than 10 or so, and it’s not well suited to virtual or dispersed teams.

XP is presented as a series of principles that agile developers should follow. These elements include the following:

  • The planning game: A recurrent workshop in which developers and customers interact in order to create and refine the “stories” that describe their project.
  • Small releases with high-value elements: “Every release should be as small as possible, containing the most valuable business requirements.” – Kent Beck
  • Metaphor: The overall idea of the project; the broad goal told as a narrative or story to keep the technical jargon to a minimum and build a collaborative vision between developers and customers.
  • Simplicity: The ideal of simplicity is central to XP. The delivered product itself should be simple, delivering the needed features in the simplest manner without trying to speculate about the bells and whistles that might be useful sometime in the future. The use of methodology and technique should be simple too; XP developers avoid documentation, other than stories and test cases, unless there’s a convincing demonstration of their value to the customer. XP practitioners strive for elegance and simplicity in their actual coding practices, which leads us to refactoring.
  • Refactoring: Refactoring is the optimization of the internal code and architecture of software, and it’s a key element of XP. It’s also a response to one of the hazards of iterative design, the danger that the separate iterations will be poorly integrated and internally incompatible. Refactoring is a disciplined approach to rebuilding system internals to ensure simplicity, elegance, and compatibility.
  • Pair programming: Pair programming takes the concept of software inspections and walk-throughs to the next level. Rather than periodic reviews, the key insight of pair programming is that two skilled practitioners can review and optimize each other’s code and each other’s coding practices, as they work toward the customer’s goal.
  • Testing: The vital difference between XP testing practices and traditional practices is that XP insists that test cases for all features be developed up front, with the stories.
  • Continuous builds: Going beyond the “daily build” that’s a common practice in many commercial software companies, XP practitioners prefer the continuous build, ensuring compatibility and functionality continuously as the product is created.
  • Sustainable development: A reaction to the 70-hour week “death march” project that many developers have experienced, the 40-hour-week standard that XP espouses is consistent with the agile philosophy that creative developers do their best work when they’re committed, energized, clear, and focused.
  • Available customer: XP calls for the customer to be completely integrated with the development team; available to review features, builds, and tests; and to review, assess, and optimize the product as it evolves.

XP’s broad exposure, and the debate it has engendered, has given the project management and software development communities the chance to consider these ideas and to explore their applicability to their work.

Dynamic System Development Model (DSDM)

Developed in 1994, DSDM is the oldest of the recognized agile frameworks. DSDM was developed as a structured approach to Rapid Application Development, a popular methodology of the early 1990s. It incorporated many of the fundamental concepts of iteration, incremental delivery, and customer collaboration that typify the agile methods that have become popular since the Agile Manifesto was published.

The DSDM Consortium defines DSDM as “a project delivery framework that aids the development and delivery of business solutions to tight timescales and fixed budgets.” It is focused on the concept that customers can’t foresee all the detailed workings of their system or product in advance. The DSDM Manual informs us that “the current step need be completed only enough to move to the next step,” a nice distillation of the incremental, iterative approach common to agile methods.

DSDM is unique among methodologies in that it follows a Consortium model, with members paying an annual fee (of about $2,000 a year) to remain members and retain access to the licensed use of the methodology. As such, it has the most developed training, support, templates, tools, and accreditation services of the agile methods (although Scrum, with its Scrum Master series of certifications, is close). The consortium structure has also, however, been a factor in DSDM’s slow adoption.

DSDM is an interlocking set of processes, each of which is iterative and incremental. While the model is complex and daunting, it is basically a three-step iterative model, consisting of Modeling, Design-Build, and Implementation phases. Once mastered, it has been proven to have some significant benefits in speed, team productivity, customer satisfaction, and product fitness for its visualized use. More detail on the individual processes is available at the DSDM Consortium’s Web site.

DSDM contrasts with some agile methods by its strict enforcement of “timeboxes,” with preset start and end dates and with a preselected team. Functionality may change, but the delivery date does not. This strict time management is a reaction to the ubiquitous problem of missed delivery dates for new software and products.

DSDM employs a strict method for prioritizing requirements, which categorizes features as “must have, should have, could have, want to have (but won’t this time).” Since functionality can change but time and team composition don’t, DSDM’s emphasis on feature priorities helps teams focus on the features that deliver business value and relentlessly drive for efficiency and simplicity.

DSDM is a noteworthy example of a methodology that was developed prior to the release of the Agile Manifesto but has evolved significantly to be consistent with the ideas generated by the agile community.

Crystal Methods

Alistair Cockburn, the developer of the collection of methodologies known as Crystal Methods, says that he developed Crystal Methods to “get rid of this aberration called software engineering.” Engineering, he says, gives us questions like “Is our model accurate?” instead of the more interesting questions such as “Is our product meeting the customer’s needs?” and “Do we have our goals aligned as a team?” In line with Cockburn’s emphasis on these questions, Crystal Methods is primarily focused on communication, with special focus on interaction, community, people, and skills.

As noted, Crystal Methods is a collection of methodologies based on two fundamental assumptions: (1) teams can streamline their process as they work and become a more integrated, optimized team and (2) projects are unique and dynamic and require methods that are specifically designed for each effort. Another theme that has run through Cockburn’s work from his first articles to his current Crystal Methods development work is the concept of product development as a game, a cooperative, interactive activity that should be designed in a way that stimulates the creativity of all participants.

Crystal Methods recommend a specific methodology for each project based on three critical factors: communication density (more people means more communication channels and increased complexity), system criticality, and project prioritization. The smaller the team, the more likely it can just retire into a conference room and build the product, without a lot of status reporting, knowledge transfer, or written documentation. As the team size increases, the number of communication “artifacts” like written notes, necessarily increases, and Crystal Methods enable that increase by presenting different methodologies and processes for different projects.

Lean Development (LD)

In 1989, Professor James Womack and consultant Daniel Jones published Lean Thinking, a survey of the lean manufacturing techniques that helped create the “Japanese miracle” of the late 1980s and early 1990s. They chronicled the ideas of lean manufacturing, with their focus on eliminating waste, creating a smooth “flow” of work on the factory floor, and expecting workers to contribute high skill levels and an ownership mentality. These concepts helped Toyota, the exemplar of these techniques, vault over the traditional giants of the automotive industry.

Lean manufacturing theories were highly influential in the creation of LD. Bob Charette, while not a signatory of the Agile Manifesto, has developed a methodology that has many commonalities with those mentioned so far. Similar, though distinct, ideas have also been put forward by Mary Poppendieck and Tom Poppendieck in their book Lean Software Development (we focus on Charette’s version here).

LD emphasizes four key success factors that clearly illustrate its compatibility with other agile methods:

  • Create visible customer value rapidly,
  • Build change-tolerant software,
  • Create only necessary functionality and no more,
  • Adopt aggressiveness, stubbornness, and belief in meeting stretch goals.

Like Scrum, LD is more of a project management environment than simply a software development one; it consists of three distinct phases: start-up, steady-state, and transition / renewal. Rather than the daily “Scrum,” it recommends a time-boxed “whirlpool” that, like all agile methods, includes the analysis, design, test, and build activities in each iteration.

Lean development is important not just for its conformance to the ideals of agile development but because the underlying philosophies of lean manufacturing have been accepted by business leaders worldwide, and so come with existing acceptance. This makes introduction of agile methods in a lean framework more easily accepted and presents a strategic framework that executives are likely to accept with less resistance.


There are other agile variants we haven’t explored here, including Feature Driven Development and Jim Highsmith’s Adaptive Software Development. Some agile variants, like Scrum, are primarily focused on the project management element of product development, while others, like XP, are software centric. The agile ideas outlined here have not just created debate and discussion but have led to the crafting of a variety of disciplined, complete methodologies that bring the theories into real-world practice.

More about agile methods on TechRepublic