Know the Difference: A Quick Guide to Agile Software Development Methodologies

From tiny startups to massive Fortune 500 corporations, it seems like everyone these days is interested in making their software development more “agile.” The four main tenets of the “Agile Manifesto,” written in 2001, are:

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

While these are all admirable goals, the way that they’re put into practice can differ tremendously from organization to organization. Here’s a look at just a few of the most popular agile software development methodologies.

Scrum

One of the most popular agile frameworks is Scrum. In this system, a designated “product owner” works with the development team to build a “product backlog” of features to add and bugs to fix. This backlog becomes the sole focus of the next “sprint,” a defined length of time during which this work must be completed. The backlog’s contents are ranked by priority and cannot be changed once the sprint has begun. After the conclusion of a sprint, the backlog is examined and adjusted for the next sprint.

Lean and Kanban

Lean software development is an evolution of the lean system for product manufacturing, which was first developed at Toyota in the 1970s. The seven principles of lean software development are:

• Eliminate waste
• Build quality in
• Create knowledge
• Defer commitment
• Deliver fast
• Respect people
• Optimize the whole

Kanban is a method closely related to lean that encourages developers to continuously deliver the most important features for the software. The team places cards on a real or virtual board in order to visualize the project’s current state, and adds new cards only when current features have been completed to make room for them.

Extreme Programming (XP)

Extreme programming is one of the oldest and best-defined agile methodologies. Like other agile methodologies, XP aims to continuously deliver high-quality software at regular intervals. The XP methodology is based on five values:

• Simplicity
• Communication
• Feedback
• Respect
• Courage

XP also has rules for its implementation, sorted into five stages: planning, managing, designing, coding, and testing. Some of these rules include daily standup meetings, pair programming for production code, frequent small releases, and an emphasis on unit tests.

Crystal

The Crystal family of agile methodologies were first developed in the mid-1990s. Crystal is subdivided into different “colors”–such as clear, yellow, orange, red, and maroon–denoting different strategies to be used depending on the importance of the project. Regardless of color, all Crystal methodologies are organized around seven unifying principles:

• Frequent delivery of usable code
• Reflective improvement
• Osmotic communication
• Personal safety to voice your concerns
• Focus
• Easy access to expert users
• Technical environment with automated tests, configuration management, and frequent integration

Dynamic Systems Development Method (DSDM)

The DSDM Consortium was founded in 1994 to fix some of the issues with Rapid Application Development (RAD), another software development framework that was fairly loose. As a result, the consortium established nine key principles for the DSDM methodology:

• Involvement of end users
• Team empowerment
• Frequent releases
• Business-driven development
• Incremental development
• Openness to change
• High-level initial requirements
• Development-testing integration
• Collaboration and cooperation

DSDM emphasizes that the software must ultimately be useful for business needs and objectives. It divides features into four groups with different priorities:

• Must have
• Should have
• Could have
• Won’t have (for now)

Feature-Driven Development (FDD)

Feature-driven development is a high-level agile methodology, allowing you to implement other lower-level methodologies alongside it. As the name suggests, FDD is a feature-oriented methodology. FDD defines roles such as project manager, chief architect, chief programmer, and class owner, as well as a series of work phases to be followed for each feature: walkthrough, design, inspection, coding, testing and build. There are eight best practices for FDD:

• Domain object modeling
• Developing by feature
• Individual class ownership
• Feature teams
• Inspections
• Regular builds
• Configuration management
• Reporting and visibility of results.