Guide to Seven Agile Methodologies

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.
  

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 end-users. 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.
   

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
  

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.

• 
  Sponsor
  
• 
  Senior Designer
  
• 
  Programmer
  

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
  

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:
  
  • 
    Feasibility Study
    
  • 
    Business Study
    
  • 
    Functional Model Iteration
    
  • 
    Design and Build Iteration
    
  • 
    Implementation
    
• 
  Post Project Phase: Things that need to occur after the project has been completed.
  

DSDM is founded on nine principles. These principles are:

1. 
   Active user involvement is imperative.
   
2. 
   The team must be empowered to deliver.
   
3. 
   Frequent delivery is key.
   
4. 
   The primary criterion for acceptance is the delivery of functionality that meets the current business needs.
   
5. 
   Iterative and incremental delivery is essential.
   
6. 
   All changes during the project lifecycle are reversible.
   
7. 
   Requirements are baselined at a high level.
   
8. 
   Integrated testing during the entire project lifecycle is expected.
   
9. 
   Collaboration and cooperation between all stakeholders is essential.
   

• 
  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.
  

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.

Each methodology has its own unique strengths and weaknesses that make each more appropriate in certain contexts.

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.

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' 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.

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

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.