Comparing Agile Methodologies

Purpose of this post is to  compare  different Agile methodologies and compare their respective strengths and weaknesses.

Scrum

Strengths

1. Can be used together with an existing practice
2. Accommodates feedback opportunities in teams that are self-motivated
3. Supports customer involvement and direction
4. Focuses on the business value of a project
5. Contains a certification process

Weaknesses

1. The only process supported is project management
2. No technical practices are defined
3. Time-consuming, especially when customizing priorities for requirements

DSDM

Strengths

1. Demands a high level of testing – a minimum of one tester is required on every team
2. Focus is on business value
3. Clearly defines the importance of every requirement in an iteration
4. Stakeholder expectations defined at the start of every project – specifies that every requirement may not be able to be fulfilled

Weaknesses

1. Very heavyweight and demanding
2. High level of user involvement required
3. Requires a high level of documentation and specifies various work products for every project phase
4. Reference material monitored by a consortium – fees are charged to access resources

XP

Strengths

1. Requires rigid technical practices
2. Estimates owned by develops
3. Features owned by customers
4. Supports regular feedback sessions
5. Popular, especially in the US

Weaknesses

1. Customers needed onsite
2. Minimal record keeping - Verbal communication and code are used to document feedback and progress
3. New users may find this method difficult to understand in terms of software architecture and design

Lean

Strength

1. Can be used together with an existing practice
2. Main objective is the project ROI.
3. Keeps project waste to a minimum
4. Supports cross-functional teams

Weaknesses

1. No technical practices are defined
2. Metrics collecting is constant
3. Theory of Constraints can be difficult to understand and implement

AUP

Strengths

1. Contains multiple artifacts and disciplines
2. Can be adapted to large projects
3. Supports a distributed team environment by using good documentation practices
4. Bases priorities on levels of risk

Weaknesses

1. Too many guidelines can slow project progress
2. Team dynamics are neglected
3. Documentation is very formal

FDD

Strengths

1. Accommodates the need for multiple teams
2. Monitors all project elements according to its features
3. Contains design by feature and build by feature aspects that are simple to implement
4. Can be adapted to suit large teams and projects

Weaknesses

1. Does not support shared or team ownership of code; rather, individual code ownership is encouraged
2. Iterations are poorly defined
3. Model-centric aspects can impact systems if no models are in place

Crystal

Strengths

1. Can be scaled according to project size and criticality
2. Supports life critical projects
3. Cross-functional teams created in proportion to the project size
4. Considers the "human" element of the project support structure
5. Demands a high level of testing – a minimum of one tester is required on every team

Weaknesses

1. Each project has to be tailored individually, according to its size and structure in order to fulfil Crystals requirements for that particular type of project
2. Does not support adaptations mid-project – not upward or downward compatible