RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


A Practical Guide to Seven Agile Methodologies, Part 2 : Page 4

You know that adopting an Agile methodology is the right thing to do, but trying to sort out all the different methodologies is a major research endeavor. How to know which one is right for your organization? In this two-part article, you'll learn all the ins and outs of the seven most popular methodologies so you can pick the one that's best for you. In part 2, we cover AUP, Crystal, and DSDM.

Each of the methodologies considered in this article have unique strengths and weaknesses (see Table 1). (Read part 1 of this article to refresh your memory on XP, Scrum, Lean, and FDD.)

Table 1. Methodology Strengths and Weaknesses
Each methodology has its own unique strengths and weaknesses that make each more appropriate in certain contexts.

Strengths Weaknesses
  • Strong technical practices.
  • Customer ownership of feature priority, developer ownership of estimates.
  • Frequent feedback opportunities.
  • Most widely known and adopted approach, at least in the U.S.
  • Requires onsite customer.
  • Documentation primarily through verbal communication and code. For some teams these are the only artifacts created, others create minimal design and user documentation.
  • Difficult for new adopters to determine how to accommodate architectural and design concerns.
  • Complements existing practices.
  • Self organizing teams and feedback.
  • Customer participation and steering.
  • Priorities based on business value.
  • Only approach here that has a certification process.
  • Only provides project management support, other disciplines are out of scope.
  • Does not specify technical practices.
  • Can take some time to get the business to provide unique priorities for each requirement.
  • Complements existing practices.
  • Focuses on project ROI.
  • Eliminates all project waste.
  • Cross-functional teams.
  • Does not specify technical practices.
  • Requires constant gathering of metrics which may be difficult for some environments to accommodate.
  • Theory of Constraints can be a complex and difficult aspect to adopt.
  • Supports multiple teams working in parallel.
  • All aspects of a project tracked by feature.
  • Design by feature and build by feature aspects are easy to understand and adopt.
  • Scales to large teams or projects well.
  • Promotes individual code ownership as opposed to shared/team ownership.
  • Iterations are not as well defined by the process as other Agile methodologies.
  • The model-centric aspects can have huge impacts when working on existing systems that have no models.
  • Robust methodology with many artifacts and disciplines to choose from.
  • Scales up very well.
  • Documentation helps communicate in distributed environments.
  • Priorities set based on highest risk. Risk can be a business or technical risk.
  • Higher levels of ceremony may be a hindrance in smaller projects.
  • Minimal attention to team dynamics.
  • Documentation is much more formal than most approaches mentioned here.
  • Family of methodologies designed to scale by project size and criticality.
  • Only methodology that specifically accounts for life critical projects.
  • As project size grows, cross-functional teams are utilized to ensure consistency.
  • The "human" component has been considered for every aspect of the project support structure.
  • An emphasis on testing is so strong that at least one tester is expected to be on each project team.
  • Expects all team members to be co-located. May not work well for distributed teams.
  • Adjustments are required from one project size/structure to another in order to follow the prescribed flavor of Crystal for that project size/criticality.
  • Moving from one flavor of Crystal to another in mid project doesn't work, as Crystal was not designed to be upward or downward compatible.
  • An emphasis on testing is so strong that at least one tester is expected to be on each project team.
  • Designed from the ground up by business people, so business value is identified and expected to be the highest priority deliverable.
  • Has specific approach to determining how important each requirement is to an iteration.
  • Sets stakeholder expectations from the start of the project that not all requirements will make it into the final deliverable.
  • Probably the most heavyweight project compared in this survey.
  • Expects continuous user involvement.
  • Defines several artifacts and work products for each phase of the project; heavier documentation.
  • Access to material is controlled by a Consortium, and fees may be charged just to access the reference material.

Table 2 compares the methodologies discussed in this article, and attempts to provide a very high level indication of which approaches might be more suitable for a particular project, depending on the project's specific circumstances. The table illustrates which conditions favor (√), discourage (X), or are neutral (-) with respect to the specific conditions listed.

Table 2. Methodology Comparison.
The information presented here is not meant to be representative of any scientific metrics, nor even specifically of the stated goals of each methods' inventors. However it is representative of the authors' first-hand experiences helping various teams adopt these methodologies, in whole or in part. In this sense it is very practical, and is intended to be informative as to how successful the adoption of each method has actually been.

Condition XP Scrum Lean FDD AUP Crystal DSDM
Small Team X X -
Highly Volatile Requirements - - X
Distributed Teams X X X
High Ceremony Culture X X - - -
High Criticality Systems X - - - - X
Multiple Customers / Stakeholders X - - - X

Table 3 depicts the authors' interpretation of the goal of each methodology expressed as a simple phrase.

Table 3. High-level methodology description.
A single phrase can sum up the intent of each methodology's founder.

Methodology Summarizing Phrase
XP Simplicity
Scrum Prioritized Business Value
Lean Return on Investment (ROI)
FDD Business Model
AUP Manage Risk
Crystal Size and Criticality
DSDM Current Business Value

Two ways of categorizing the appropriateness of any Agile method to a given environment are project size and criticality. Although this doesn't provide a complete view of the appropriateness of an Agile method in a context, it does provide a very good general description of the fit. Alistair Cockburn has developed a scale based on these characteristics for comparing methods. In Figure 4 we have attempted to plot the various methods covered in this article based on our experience and observation.

Figure 4. The Cockburn Scale. The authors' evaluation of the appropriateness of each of the covered methods based on their experience and observation and illustrated via the Cockburn scale.
As Figure 4 hopefully shows, XP is generally most appropriate on smaller, highly dynamic projects although many of its practices can provide value when combined with other management methodologies. XP has also been scaled to companies with hundreds of developers, but handling large projects is a customization a company has to make—it is not inherent to the XP process due to it’s intense focus on constant, quick feedback and simplicity.

AUP provides a higher ceremony process that may be appropriate for larger teams, distributed teams, and systems of higher criticality. If the adopting corporate culture is likely to change slowly from a Waterfall-like process, AUP would be a good choice to "ease" into an Agile mindset.

Scrum and Lean are frameworks that focus on how to manage the overall process, maximize business value, and reduce waste. Because Scrum and Lean do not specify technical practices, either can complement methodologies that do, such as XP or a company's existing methodology.

DSDM is a heavier and more formal flavor of Agile, and is very business centric. It compares in many ways to AUP, but focuses on current business value as opposed to risk.

Crystal offers a range of methodologies to choose from, each varying by project size and criticality. As the project size and/or criticality increases, Crystal adds mechanisms to support the additional burden of larger teams and higher degree of safety required by more critical projects.

Finally, FDD is an interesting mix. It can function as a complete Agile process, or can be combined with Scrum, Lean or XP to produce a customized integration of techniques.

The important point is that no methodology, Agile or otherwise, is meant to be taken verbatim. It must be customized in the context in which it is being applied in order to increase the rate of adoption and the opportunity for success.

Rod Coffin is an agile technologist at Semantra, helping to develop an innovative natural language ad hoc reporting platform. He has many years of experience mentoring teams on enterprise Java development and agile practices and has written several articles on a range of topics from Aspect-Oriented Programming to EJB 3.0. Rod is a frequent speaker at user groups and technology conferences and can be contacted via his home page.
Email AuthorEmail Author
Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date