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.

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.

DSDM

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.

Advertiser Disclosure:
Some of the products that appear on this site are from companies from which QuinStreet receives compensation. This compensation may impact how and where products appear on this site including, for example, the order in which they appear. QuinStreet does not include all companies or all types of products available in the marketplace.

Thanks for your registration, follow us on our social networks to keep up-to-date