A Practical Guide to Seven Agile Methodologies
by Rod Coffin, Derek Lane
http://www.devx.com/architect/Article/32761
s we near the fifth anniversary of the Agile Manifesto, the shift from Waterfall software
development to Agile methodologies and practices continues to gain momentum. At this
year's Agile 2006 Conference in Minneapolis, MN, there was much discussion about whether
Agile had "crossed the chasm" yet (a la the book "Crossing the Chasm" by Geoffrey A.
Moore), but there was no debate about whether Agile had reached the chasm. Because
proper application of Agile techniques and processes is demonstrating success in greater numbers all the
time—especially in the most difficult situations—interest in adopting Agile is at an all time high.
But once an organization decides to adopt an Agile development regimen, there is still plenty of difficult
research and decision-making to be done. In particular, navigating the various Agile methodologies
available can be confusing to the Waterfall-minded. The most popular Agile methodologies in use today
appear to be Extreme Programming (XP), Scrum, Feature Driven Development (FDD), Lean Software
Development, Agile Unified Process (Agile UP or AUP), Crystal, and Dynamic Systems Development
Method (DSDM). This two-part article will briefly explore the Agile value system, and analyze how these
methodologies manifest these values. Particular care will be taken to highlight the similarities and
differences between each methodology and we will conclude with a brief analysis of the varying business
contexts that may make one methodology more appropriate than others.
Understanding Agile
Agile software development is a style of software development characterized by an emphasis on people,
communication, working software, and responding to change. Its principles are summarized in its seminal
declaration, the Manifesto for Agile Software Development. One of the most notable characteristics of this
manifesto is that it is worded as a value statement and not a concrete plan or process. This underscores
Agile's nature as a style of development consistent with the values laid out in the manifesto.
All Agile methodologies engage in an iterative workflow and incremental delivery of working software in
short time-boxed iterations. An iteration is essentially a small release of software. Generally during each
iteration many activities will occur in parallel, such as requirements, coding, and testing. Iterations are
typically a fixed length (although this length varies between the methodologies) and thus are referred to as
time-boxed. The time allocated to each iteration is sometimes referred to as a cycle time.
Agile methods also differ in the activities and artifacts that they produce. Methodologies that have many
artifacts (or work products) and steps along the way are referred to as higher ceremony. Conversely,
methodologies with less emphasis on these are referred to as lower ceremony. The number of people
involved and the number of "sign offs" also helps to define the amount of ceremony around a particular
methodology. It is important to strike an appropriate balance between the two in any given context.
Extreme Programming
Extreme Programming (XP) is one of the more well known Agile methodologies. As its name suggests it is a
programmer-centric methodology that emphasizes technical practices to promote skillful development
through frequent delivery of working software. Although XP (and Agile methods as a whole) is often
characterized as less rigorous then traditional techniques, this could not be farther from the truth. XP got its
name when its founders asked the question, "what would happen if we took each technique/practice and
performed it to the extreme? How would that affect the software process?" An example of this is the
practice of code reviews. If code reviews are good, then doing constant code reviews would be extreme; but
would it be better? This led to practices such as pair programming and refactoring, which encourage the
development of simple, effective designs, oriented in a way that optimizes business value. In truth, full
adoption of all of XP's practices requires a high level of discipline, teamwork, and skill.
One of the characteristic distinctions between XP and other methodologies is its cycle time and level of
ceremony. XP recommends very short iterations between one and four weeks. XP is also a very low
ceremony methodology. Minimal artifacts in an XP project include story cards, code, and unit tests.
But XP is most commonly known for its technical practices. At the heart of XP are four core values:
communication, simplicity, feedback, and courage. From these values 13 practices are derived. Theses
practices are:
1. Planning Game: Plan work incrementally.
2. Small Releases: Release as quickly as possible to increase time to market, and get feedback as
soon as possible.
3. Metaphor: If possible, define a metaphor for the system being developed. For example, the
shopping cart metaphor is widely used to describe an online ordering system.
4. Simple Design: Use the simplest design that will work for the functionality (user story) being
implemented. Do not design for things that may never actually be used.
5. Testing: Test everything, and try to automate the testing if possible.
6. Refactoring: Instead of designing the entire system up front, design as you go, making
improvements as needed. Change the implementation without changing the interface to the
functionality, and use automated testing to determine the impact of the refactoring.
7. Pair Programming: Programming in teams of two (or three) allow for a discussion to occur in realtime that addresses requirement, design, testing, and programming concerns.
8. Collective Code Ownership: Anyone on the team can make a change to any code at any time.
9. Continuous Integration: The entire code base is constantly being rebuilt, and retested in an
automated fashion.
10. Sustainable Pace: Ideally, team members do not need to work more than 40 hours per week to
meet project deadlines. Burning the midnight oil is chunked by management in favor of consistent,
predictable, repeatable delivery.
11. Whole Team: The team functions as a whole. Members are encouraged to be more generalized
than specialized. Learning about all technologies and requirements is encouraged.
12. Coding Standards: In order to maximize communication, coding standards are defined by the team,
and used to ensure consistent coding practices.
13. Onsite Customer: Having constant and direct access to the customer allows the team to work at the
fastest possible speed.
These practices support one another, as illustrated in Figure 1, and thus care should be taken when
modifying any of them, or deciding not to include one or more of these practices in a project.
Figure 1. XP Practices. The practices in XP support one another and thus care should be taken to understand these
relationships when modifying XP.
Another distinction between XP and other Agile methodologies is its approach to requirements gathering.
The primary requirement artifact in XP is the user story. Visibly, a user story is nothing more than a note
card with a short description on it. But user stories actually are comprised of the card (reminder of promised
functionality), conversations between developers and requirements donors, and tests (all types: unit,
integration, acceptance, etc.).
There are two primary types of planning activities that are referred to in XP parlance as planning games: the
release and iteration planning games. And each planning game is characterized by three phases:
exploration, commitment, and steering.
Release planning begins with the customer writing story cards and prioritizing them. Programmers then
estimate the stories from which a velocity can be derived. Velocity describes how much work the team can
accomplish in any given time frame. The customer then chooses a scope for the release based either on
desired functionality or release date. The steering activities for release planning occur at iteration
boundaries when progress towards the planned release date can be tracked and adjustments can be easily
made.
Iteration planning follows a similar pattern to release planning. Each iteration begins with developers taking
stories and breaking them into tasks. Programmers accept responsibility for tasks and estimating the tasks
that they are responsible for. Each programmer's load is compared to their historical performance to
determine whether anyone is overcommitted and to allow the workload to be balanced across the team.
Throughout the iteration programmers partner to complete tasks by writing unit tests and code. Periodically
throughout the iteration a member of the team checks on the progress of the team and communicates this
information to all team members so adjustments can be made.
There are a small number of roles on an XP project. These include:




Customer—The customer creates and prioritizes the stories that need to be implemented. Because
the customer sets the priorities she controls what will be delivered in any given release and can
control the release date by adding and removing stories.
Programmer—Programmers collectively estimate stories, but individually accept responsibility for
tasks which they estimate, write tests, and code.
Coach—The coach monitors the software development process, mentors team members on XP
process and techniques, and focuses the team's attention on potential problems or optimizations.
Tracker—The tracker monitors the progress of the team and alerts them when adjustments to the
schedule or a re-balancing of tasks might be required.
Scrum
A common misconception is that Scrum is an acronym: SCRUM; not so. Scrum is named after the Scrum in
Rugby, which is a mechanism to restart the game after an accidental infraction - such as the ball going out
of bounds. It's the general idea of a team huddling together to move the ball toward the goal.
Scrum is a project management framework for managing Agile projects. Its primary goal is to deliver
software that, after each and every iteration, provides the highest business value. Scrum is based on a 30day iteration called a "Sprint." Technically Sprints can be either two or four weeks, but the generally
accepted default is usually four weeks.
A fundamental Scrum principal is that project teams should be self organizing. This means that team
members don't follow a prescriptive plan or set of tasks, but organize themselves initially based on the
goals for the Sprint, and subsequently on a daily basis through daily scrum meetings. Recommended team
size is from four to nine members.
Every day at the same time, the project team meets to discuss the project. Members are expected to stand
during the entire meeting to encourage short meetings. Meetings are targeted to complete in 10 to 15
minutes. Each member in turn answers three questions:
1. What did I do since the last Scrum meeting?
2. What do I plan on doing between now and the next Scrum meeting?
3. Do I have any roadblocks?
This report is not a status meeting. In other words, team members do not report on what percent a task is
done. They report on what work they did, why it was being done, and whether it has been completed or not.
When something is encountered that is impeding progress, it is considered a roadblock. As roadblocks are
reported, the team decides how to handle them, including escalating them immediately to the appropriate
channel.
When multiple teams are involved in a project, a hierarchy of daily scrum meetings may occur, sometimes
referred to as a Scrum of Scrums. An example would be where three teams are involved in working on
three separate but related Sprints. Each team would hold their daily Scrum, and then one member from
each team would convene together for an additional Scrum to make sure team coordination occurs.
Information from this additional Scrum is fed back into the separate team Scrums the following day.
Scrum also defines only a small numbers of roles on the team:
—The Product Owner is responsible for representing the customer or user of the product
the team is building. Ideally this is the actual customer, but when the customer is not available for a project,
this role is filled by someone representing the customer's interests; he or she is also responsible for being
the liaison between the project team and the customer.
—Scrum originated as a way to deal with troubled or emergency projects. The person
brought in to refocus the project team is called a Scrum Master. This role is primarily to facilitate, report, and
focus the team on the highest priority work and to remove any roadblocks that may impede team progress.
Certification training for Scrum Masters exists, supporting three different levels of practice.
—All other members of the team are considered general team members. This includes
developers, architects, project managers, testers, database administrators—everyone. The team concept is
important to Scrum and only the key roles of Scrum Master and Product Owner are called out.Scrum uses
the term "backlog" to refer to a list of items that are related. Three backlogs are defined by the Scrum
process: product backlog, release backlog, and sprint backlog.
The product backlog is a list of all the requirements to deliver the product. These are usually defined at a
high level, and include estimates used to scope the Sprint Backlogs. The Release Backlog is pulled from
the Product Backlog, which contains requirements. This list must be in priority order, with each entry on the
list having a unique priority. Here, each requirement also includes a more granular estimate than that given
in the product backlog.
At the start of each Sprint, the project team breaks down items from the Release Backlog, starting at the top
(most important), and adds these into the Sprint Backlog. Once enough items have been selected to fill the
Sprint, the Sprint Backlog is locked. Estimates include total time to complete each item, including but not
limited to analysis, design, coding, testing, documentation, etc.
There is another item related to Backlogs that is key to Scrum. The Burndown Chart (see Figure 2) is used
to indicate the number of remaining Sprint Backlog items yet to be completed in the current Sprint. A daily
record is maintained showing the team's progress in achieving the goal of the Sprint.
At the end of a Sprint, the team meets with any interested stakeholders to demonstrate what work has been
completed, and to evaluate priorities for the next Sprint. In addition, any outstanding roadblocks are also
discussed, as well as their impact and possible solutions.
One final note is that since Scrum focuses on the project management aspects of a project and specifies no
technical practices, it integrates well with other Agile methodologies. It is commonly combined with XP, but
will work with other approaches as well.
Figure 2. Scrum Burndown Chart.
A Scrum Burndown Chart helps to provide visibility of the progress of the team and the work remaining. The straight line
represents an ideal iteration where work is completed in a perfectly steady and evenly distributed manner. The more erratic
line represents the work that is actually completed over time by the team.
Lean Software Development
While most of us might joke that Lean Software Development (a.k.a.: Lean) is a new way to lose unwanted
pounds and keep them off, that wouldn't be far from the truth. Lean is a methodology that aims to trim the
fat from the software process, starting with requirements, and including how business looks at the systems
they request.
Derived from the Lean Manufacturing processes that companies such as Toyota have perfected over the
past couple of decades, Lean's goal is to meet the challenge of defining, building, and delivering complex
software systems that are exactly what the business really needs to stay competitive. Lean is similar to
Scrum in that it focuses much more on the project management aspects of software development rather
than the technical ones, specifically targeting the cost and ROI attributes of a project.
Lean pays a good deal of attention to gathering the "right" requirements. Requirements are measured
based on their impact to the business, and must be defined in clear, complete, and verifiable ways.
Incomplete, missing, wrong, unverifiable, and conflicting requirements are filtered out during the
requirement process.
Due to this focus on requirements, the Customer plays an absolutely vital role in the Lean process. From a
manufacturing point of view, it helps to think of Lean as being similar to new product development; this
helps to crystallize the role and value that the Customer plays. Constant feedback from the Customer about
the business value and functional requirements being addresses by the development team is a core
component of the Lean approach.
Based on a wealth of quantitative metrics, Lean realizes that many projects fail due to their configuration
and management. Projects with a silo'd, isolated, or "not my problem" attitude will face swift changes when
Lean steps in. Lean attempts to also address resource issues such as the team not having the right skill
sets, not enough team members, or too much turnover. In this sense Lean is very "root cause"-oriented.
Where some methodologies enforce strict definition between team roles, Lean prefers a more crossfunctional approach. Team members are not only cross trained on functional and technical aspects of the
system, they also team up with various team members to understand the business value for system
features, and the business problems the system is expecting to solve.
Lean Manufacturing evolved from the work of Dr. W. Edward Deming's Total Quality Management (TQM),
which can be boiled down to two main concepts:
1. Process is important.
2. People build and improve the process.
TQM has been refined for almost half a century now and has proven itself in the manufacturing realm. TQM
is very metric intensive, and metrics play a big part of Lean Software Development as well.
A newer addition to the Lean Software Process is the Theory of Constraints (by Eliyahu M. Goldratt, et. al.),
which is comprised of two primary tenants as well:
1. Identify constraints.
2. Improve/remove constraints.
The Theory of Constraints is a body of knowledge on how to effectively manage business organizations as
self-contained systems.
Lean Software Development promotes seven Lean principles. The methodology revolves around these
principles, and all other aspects of Lean are designed to reinforce them. The seven principles are:
1. Eliminate Waste: Eliminate anything that does not add customer value.
2. Build Quality In: Validate and re-validate all assumptions throughout the process. If a metric or
practice no longer has value, discard it.
3. Create Knowledge: Use short iterative cycles to provide quick, constant feedback to ensure the
right things are being focused on.
4. Defer Commitment: Don't make decisions until enough is known to make the decision—a sound
understanding of the problem and the tradeoffs of potential solutions is required.
5. Deliver Fast: Minimize the time it takes to identify a business problem and deliver a system (or
feature) that addresses it. (a.k.a. time to market).
6. Respect People: Empower the team to succeed.
7. Optimize the Whole: Use cross-functional teams to keep from missing important, possibly critical
aspects of the problem and of the system designed to solve it.
Again, since Lean focuses on the project management aspects of a project and specifies no technical
practices, it integrates well with other Agile methodologies, such as XP, that focus more on the technical
aspects of software development.
Feature Driven Development
While most Agile methodologies start with a handful of principles or a specific set of processes, the center
of Feature Driven Development (FDD) is the domain model. Creating a model of the domain is the
foundational step for FDD, which requires collecting domain knowledge from all domain experts (sometimes
called Subject Matter Experts or SMEs), and integrating this knowledge into a unified model (or set of
models) representing the problem domain. Once this model and any other requirements have been
evaluated, a rough plan is drawn up to determine what resources will be needed to build the masterpiece. A
small set of features are identified for a team to work on for a period of time recommended to last no more
than two weeks. Once the initial set of features is delivered, another set is tackled. Multiple teams can work
in parallel on different sets of features, with all activity being tracked on a per feature basis.
The basic unit of work in FDD is a feature, which is defined as a small, client-valued function expressed in
the form:
<action><result>[of|to|for|from]<object>.
This expression can be restated as: an action, causes a result, to an object. The section in the brackets is
optional to make the feature easier to read. An example of a feature is: Calculate the monthly interest rate
for an adjustable rate mortgage. Here "calculate" is the <action>, "monthly interest rate" is the <result>, and
"an adjustable rate mortgage" is the object participating in this feature.
Features can be combined into Feature Sets, and Feature Sets can be aggregated into Subject Areas.
Requirements are usually gathered in a top down approach, defining all the Subject Areas for the system,
breaking these down into Feature Sets, and eventually down into Features, from which tasks can actually
be defined and estimated. Feature Sets typically reflect a business activity, and Subject Areas commonly
correspond to general business practices. Some possible Feature Sets are "Making a Deposit," "Making a
Withdrawal," "Viewing an Account Balance," all of which may be part of the "Managing an Account" Subject
Area.
FDD specifies five specific processes that are to be followed, in this specific order:
1.
2.
3.
4.
5.
Develop an Overall Model
Build a List of Features
Plan by Feature
Design by Feature
Build by Feature
Again, it is important to understand that absolutely everything is planned, built, managed, and tracked on a
per-feature basis. Other units such as feature sets and subject areas are available for higher level planning
and reporting, but the key universal unit is the feature.
FDD relies on specific roles and responsibilities more than almost any other Agile methodology. FDD also
tends to move away from shared ownership of code and artifacts that other Agile methods promote, and the
team roles reflect this. The nine roles defined for FDD are:
1. Project Manager—Responsible for all administrative aspects of the project, including the financial
and reporting ones.
2. Chief Architect—Responsible for the overall design of the system, including running all design
sessions, code reviews, and technology decisions.
3. Development Manager—On the hook for the daily development activities. Coordinating the
development team and their activities, and dealing with resource issues.
4. Chief Programmer—A senior developer involved in ongoing design and development activities, and
is assigned to be responsible for one or more Feature Sets.
5. Class Owner—A developer who works under the direction of a Chief Programmer to design, code,
test, and document features as they are implemented.
6. Domain Expert—Any business related stakeholder who can define required features that the
system should provide. These would include clients, users, and various analysts; anyone who has
knowledge of how the business works that could impact the system.
7. Tester—Responsible for verifying that each feature performs as defined.
8. Deployer—Deals with not only the actual deployment of code to various environments, but also the
definition and/or conversion of data from one format to another.
9. Technical Writer—Responsible for creating and maintaining all the online and printed
documentation that a user will need for the final system.
FDD uses several unique and specific mechanisms to report project activity and progress. The least unique
of these is the feature list and the task list. Many Agile methodologies use some sort of list to track
requirements and work done on requirements. In FDD, these lists all correspond to a specific feature.
Capturing exactly where a feature is in its development cycle is done using a table that tracks six specific
milestones:
1.
2.
3.
4.
5.
6.
Domain Walkthough
Design
Design Inspection
Code
Code Inspection
Promote to Build
These milestones are tracked by the date each is completed and by the Chief Programmer responsible for
that specific feature.
Feature milestones are rolled up into a table showing feature sets. This allows project stakeholders to see
how the project is progressing. Things can be rolled up into subject areas as well if there is value in doing
so. Completed features are also tracked across the entire project using a line graph. This graph shows the
cumulative total by day or week of all features that have been completed.
The final group of reports is the Feature Set Progress Report, which is very unique to FDD (see Figure 3).
This report is color coded and shows each Feature Set in the project, what percent complete it is, how
many features are in each area, the name of the Chief Programmer for each Feature Set, and the month
and year when each is targeted to be completed.
Figure 3. Feature Set Progress Report.
The Feature Set Progress Report illustrates progress of feature development in each subject area. Light green Feature Sets
are in progress and on schedule, dark green Feature Sets are completed, and grey Feature Sets are behind schedule.
Agile Unified Process
The Unified Process (UP) is an iterative and incremental software development process framework. It is
often considered a higher ceremony process because it specifies many activities and artifacts involved in a
software project. As a process framework there are several adaptations, the most popular being the
Rational Unified Process (RUP) from IBM. The Agile Unified Process (AUP) is an Agile adaptation of the UP
formalized by Scott Ambler and written about by others including Craig Larman. Ambler succinctly
summarizes AUP as "serial in the large, iterative in the small, [and] delivering incremental releases over
time."
Risk management plays an important role in AUP projects. AUP stresses that high-risk elements be
prioritized early in development. As a means to this end, a risk list is usually created early on and
maintained throughout the development process. Additionally, AUP stresses the early development of an
executable architectural baseline. This architectural core is developed during the Elaboration phase to
validate key requirements, assumptions, and address technical risks.
In describing AUP as "serial in the large," Ambler refers to the four major phases of a UP project: inception,
elaboration, construction, and transition. These phases occur in serial and each concludes when a specified
milestone is achieved.




Inception—The goal of inception is to develop a shared understanding of the scope of the new
system and to define a candidate architecture.
Elaboration—The goal of elaboration is to expand the team's understanding of the system
requirements and to validate the candidate architecture.
Construction—During construction the development of the system is completed.
Transition—During transition system testing is completed and the system is deployed to production.
AUP is "iterative in the small" in that each phase is divided into one or more iterations. AUP disciplines are
a subset of UP disciplines and include: model, implementation, test, deployment, configuration
management, project management, and environment. During most iterations, all of the seven disciplines of
AUP occur in parallel (see Figure 4). Each discipline represents an activity that drives the project closer to
achieving its vision.
Figure 4. Phases and Disciplines of the Unified Process.
AUP is an implementation of the Unified Process which tailors it by selecting only seven disciplines (model, implementation,
test, deployment, configuration management, project management, and environments).
Image courtesy of IBM.
Crystal
Crystal is not actually a methodology itself, but a family of methodologies that vary based on the size and
complexity of the project. Crystal is the name given by its creator, Alistair Cockburn, to the entire family of
methodologies. Each specific methodology in the family is named after a color corresponding to the
geological crystal's hardness, representing that project's size and criticality. While Cockburn eludes to the
possibility of a spectrum of methods, so far the only implementations we are aware of are: Clear, Yellow,
Orange, Orange Web, Red, and Maroon.
While these flavors of Crystal share many elements, it should be noted that they are not intended by
Cockburn to be upward or downward compatible. If a project starts as a Crystal Clear project it should not
expect to transition to a Crystal Maroon project. The founder implies that should the project turn into a
Maroon project, the project should adopt the characteristics and practices of a Maroon project, and not
expect to "grow" the prior Crystal Clear practices over time.
Regardless of which Crystal implementation you choose, you will find seven key principles at the heart of
each:
1. Frequent Delivery: Project owners/customers can expect deliverables from the team(s) every
couple of months. On larger or more critical projects the deliverables may not go into production but
stakeholders will see intermediate versions and be able to provide feedback.
2. Continual Feedback: The entire project team meets on a regular basis to discuss project activities.
The team also meets with stakeholders regularly to make sure the project is heading in the
expected direction and to communicate any new discoveries that may impact the project.
3. Constant Communication: Small projects expect the entire team to be in the same room, while
larger projects are expected to be co-located in the same facility. All projects expect to have
frequent access to the person(s) defining the requirements.
4. Safety: Crystal is somewhat unique in its focus on the safety aspect of software development. This
comes in two forms. One is the safe zone that team members must have to be effective and to
communicate truth during the project without fear of reprisal; this is true of most Agile
methodologies. The other form of safety that only Crystal recognizes is that the purpose of each
software project is not the same and that some software projects are affect the safety of their endusers. For example, a space shuttle system is much more critical than a recipe organizer.
5. Focus: Team members are expected to know the top two or three priority items each member
should be working on and should be given time to complete them without interruption.
6. Access to Users: As with most Agile methods, Crystal expects that the project team will have
access to one or more users of the system being built.
7. Automated Tests and Integration: Crystal has various capacities for verification of project
functionality. Controls must be put in place to support versioning, automated testing, and frequent
integration of system components.
Some key Crystal concepts are project size and criticality. Size is defined as the number of people involved
in a project—nothing too earth shattering here, except that as the team size grows Crystal changes to add
more formality to the structure, artifacts, and management of the project.
Criticality is defined as the potential for the system to cause damage. In other words, a life support system
that malfunctions could cause a lot more damage than a video game that won't let you save your game. As
project criticality increases the rigidity of the project needs to increase as well to ensure the expected
demands can be delivered.
Figure 5 depicts how to determine which Crystal methodology to use for a project. As the project size
increases (moves to the right of the diagram), the harder the project, and hence a more comprehensive
(darker color) of Crystal is necessitated. As the criticality of a project increases (moves from the bottom to
the top of the diagram), aspects of the methodology need to be put in place to accommodate the additional
requirements, including the artifacts generated by the team; however criticality does not affect the color of
Crystal used.
The letters in the cells represent the criticality of the project as follows:




C: Comfort
D: Discretionary Money
E: Essential Money
L: Life
The numbers in the cells (along the bottom of Figure 5) represent the upper size of the project team. For
teams up to six, the Crystal Clear methodology works fine. For teams of seven to 20, Crystal Yellow will
introduce mechanisms to help manage the additional team size. For teams of 75 or 80 members, Crystal
Red should do the trick. A project of one to six folks working on an atom splitter need a tad more in the way
of checks and balances than the same size team creating yet another web site for their garage band.
Figure 5. The Crystal Family of Methodologies.
One characteristics of Crystal is its intentional scaling to projects based on size and criticality. The larger a project gets (from
left to right), the darker the color.
Due to the bulk of the published data focusing on Crystal Clear and Crystal Orange projects, we will include
some specifics of each of these methodologies. For more information on other methodologies in the Crystal
family, see the references provided at the end of this article.
Crystal Clear
Roles vary across the Crystal methodologies as the size and criticality of the project increases. In other
words, Clear has the fewest defined roles and Maroon has the most. The minimum defined roles for Crystal
Clear projects are:



Sponsor
Senior Designer
Programmer
Crystal Clear expects that all team members will be working in the same room together. Support for more
complex communication is not specified. The most important role is the Senior Designer, who is expected to
be capable of making all the technical decisions that need to be made. Roles of project manager, business
analyst, tester, etc. are shared among all team members.
Working software is expected to be delivered every two to three months. The team can work in smaller
iterations if desired, but the expected release is every 60 to 90 days.
Crystal Clear requires minimal documentation, as project milestones are commonly the actual software
delivery, not written documents. The team is responsible for defining any additional artifacts that they
produce, and for defining their own coding standards, testing practices, etc.
Crystal Orange
As you would expect, the number of roles increases greatly for Orange projects. Roles can vary depending
on the organization, but typically they include the traditional roles of Architect, Sponsor, Business Analyst,
Project Manager, etc.
Because there is a greater need for verification in larger projects, specific care is taken to make sure more
structure is put in place around the overall process, as well as a larger emphasis on testing, as each
subgroup within the team is expected to have a tester.
Crystal Orange projects are described as typical medium-sized projects.
Working software is expected to be delivered every three to four months. The team can work in smaller
iterations if desired, but the expected release is every 90 to 120 days.
Crystal Orange defines a set of specific deliverables:








Requirements Document
Release Sequence (Schedule)
Project Schedule
Status Reports
UI Design Document (if project has a UI)
Object Model
User Manual
Test Cases
As with Crystal Clear, the team is responsible for defining their own standards and guidelines for the
artifacts they deliver.
Dynamic Systems Development Method
The Dynamic Systems Development Method (DSDM) was developed in the UK in the mid to late 1990s by
folks with a business—not a technical—perspective. The process is now managed by the DSDM
Consortium and is probably the most popular Agile methodology in practice in the UK. DSDM is technically
considered to be a framework, and the framework is versioned—and releases are managed—by the
Consortium.
DSDM is one of the heavier Agile approaches available. It was originally developed as an extension to
Rapid Application Development (RAD), incorporating best practices from the business-oriented founders.
DSDM projects consist of three phases (see also Figure 6):


Pre Project: Things that need to occur before the project begins.
Project Lifecycle: The actual project occurs. This phase is broken into five stages:
o Feasibility Study
o Business Study

o Functional Model Iteration
o Design and Build Iteration
o Implementation
Post Project Phase: Things that need to occur after the project has been completed.
Figure 6. DSDM Lifecycle. The three phases of a DSDM project involve a lot of steps.
DSDM is founded on nine principles. These principles are:
1.
2.
3.
4.
5.
6.
7.
8.
9.
Active user involvement is imperative.
The team must be empowered to deliver.
Frequent delivery is key.
The primary criterion for acceptance is the delivery of functionality that meets the current business
needs.
Iterative and incremental delivery is essential.
All changes during the project lifecycle are reversible.
Requirements are baselined at a high level.
Integrated testing during the entire project lifecycle is expected.
Collaboration and cooperation between all stakeholders is essential.
Given the business roots of DSDM, it should not surprise you that DSDM has a focus on delivering
functionality on time and on budget. To accomplish this, it is understood that each project will be split into
chunks, with each chunk having a specific number of features, budget, and time. If a project is running out
of time or budget (since they are both fixed), the least important features are dropped and considered for
future projects. Features (requirements) are prioritized using the following rules:




MUST have this requirement.
SHOULD have this requirement if at all possible.
COULD have this requirement if it can be delivered without major impact.
WOULD like to have these requirements if there is enough time remaining.
The MUST, SHOULD, COULD, and WOULD are commonly represented with the MoSCoW acronym.
DSDM purports that user feedback on requirements is crucial, and it places a lot of weight on prototypes
created early in the project phase. These are used to refine requirements and clarify expectations of all
stakeholders.
DSDM does not dictate the testing approach a project team should use, but does mandate that testing be
performed throughout the project lifecycle phase. Testers must be involved in all aspects of the lifecycle
phase to make sure all testing opportunities are maximized.
Workshops are used to provide a forum for all stakeholders to discuss the project requirements and
functionality. They can be held as often as needed. Modeling is similar to Workshops, but held by the
technical team members to create and communicate the technical aspects of the system, as well as other
aspects of the system that can benefit from visual models, such as the business domain.
Due to the fixed controls of DSDM, a configuration management system that controls various aspects of a
project is a requirement.
DSDM appears to set the upper boundary of project size to six teams of six people for each team. There
may be instances of larger team sizes, but we were unable to find documentation supporting them.
Because DSDM was founded on business best practices, you should be aware that DSDM also
recommends it not be used for safety critical systems. This would include systems such as life support,
toxic waste management, nuclear reactors, etc.
Comparison
Each of the methodologies considered in this article have unique strengths and weaknesses (see Table 1).
Table 1. Methodology Strengths and Weaknesses
Each methodology has its own unique strengths and weaknesses that make each more appropriate in
certain contexts.
XP




Scrum
Lean
Strengths
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.








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.





Complements existing practices.
Focuses on project ROI.
Eliminates all project waste.
Cross-functional teams.





Weaknesses
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.
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.
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.
FDD




AUP




Crystal





DSDM




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.

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.

Family of methodologies designed to
scale by project size and criticality.
Only methodology that specifically
accounts for life critical projects.
As project size grows, crossfunctional 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.

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.










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.
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.
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.
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 method’s inventors. However it is representative of the authors' firsthand 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 7 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.
Anout the authors:
* Rod Coffin is a Senior Consultant at Valtech Skill Development, a group that guides clients through large
scale adoption of modern development processes and technologies. He is primarily involved in mentoring
teams on enterprise Java development and Agile practices. He has written several articles on a range of
topics from Aspect Oriented Programming to EJB 3.0. He helped to found the Oklahoma City Java Users
group where he is a frequent presenter.
* Derek Lane is an Enterprise Architect with Countrywide Financial Corp. He has worn various hats in his
career including mentor, coach, architect, manager, developer, trainer, methodologist and resident Open
Source Zealot. Lane is a contributor to various projects as author, presenter, and technical reviewer,
including his role as co-author for the upcoming book, 'EJB3 In Action' (Manning).
Lane is the Founder of both the Oklahoma City Java User Group (OKCJUG) and the Dallas/Fort Worth,
Texas MicroJava User Group; and has been active as a member, presenter, and mentor for over a decade
at various technology user groups across the Midwest and Southern U.S.