Which flavour of Agile would you like?

Just as the numerous flavours of Ice-cream, Agile Software development too comes in several flavours. The choices can be equally confusing and when faced with too many options we settle for the one we know most about which tends to be Scrum.

The purpose of this article is to introduce you to different Agile approaches to Software development and illustrate their suitability for initiatives. Subsequent articles will expand on each of these approaches.

Agile approaches are essentially iterative, incremental and adaptive. They are also considered lightweight and flexible compared to the traditional methods that tend to be rigid, heavyweight, heavily governed, planned in detail right up-front and micro-managed.

Projects that are best suited for an Agile approach are typically characterised by aggressive development deadlines, a high degree of uncertainty about requirements, high probability of changes to the requirements and a high degree of complexity. Accordingly, it is not necessary to use Agile approaches on projects or initiatives that have been executed repeatedly by the same team (Nothing unique about the product or team), like an assembly line.

A list of the most common Agile approaches;

1. Scrum

2. Kanban

3. Extreme Programming (XP)

4. Lean software development

5. Rapid Application Development (RAD)

6. Crystal

7. Dynamic Systems Development Method (DSDM)

8. Feature driven development

Most of these Agile approaches evolved from 1991 onwards. Although they evolved before the “Agile Manifesto” was published, they align well to the values and principles outlined in the Manifesto.

Agile Software Development Values

The Agile Manifesto for software development is based on the following four relative values;

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

Agile Software Development Principles

The Agile Manifesto for software development is based on the following twelve principles;

1. Customer satisfaction by early and continuous delivery of valuable software

2. Welcome changing requirements, even in late development

3. Working software is delivered frequently (weeks rather than months)

4. Close, daily cooperation between business people and developers

5. Projects are built around motivated individuals, who should be trusted

6. Face-to-face conversation is the best form of communication (co-location)

7. Working software is the primary measure of progress

8. Sustainable development, able to maintain a constant pace

9. Continuous attention to technical excellence and good design

10. Simplicity—the art of maximizing the amount of work not done—is essential

11. Best architectures, requirements, and designs emerge from self-organizing teams

12. Regularly, the team reflects on how to become more effective, and adjusts accordingly

As with any initiative, concept or framework the Software development community too is also divided in their acceptance or liking for Agile approaches. There are as many Agile sceptics and disbelievers as there are Agile enthusiasts and proponents. In the opinion of this author, the scepticism and dislike for Agile exists primarily because people associated with software development have not tried to read and understand the above Agile values and principles. Their opinions tend to be based on misguided perceptions and ignorance.

Jim Highsmith, one of the authors of the Agile Manifesto said it best when he wrote this;

“The Agile movement is not anti-methodology, in fact many of us want to restore credibility to the word methodology. We want to restore a balance. We embrace modelling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment. Those who would brand proponents of XP or SCRUM or any of the other Agile Methodologies as "hackers" are ignorant of both the methodologies and the original definition of the term hacker.”

The Agile Frameworks (Popular ones)

The section below provides a summary of each of the eight approaches and their characteristics. It is not intended in this article to provide details for each of the flavours. Details of each framework will be covered as separate articles in future.

Scrum

Scrum is an iterative and incremental Agile software development framework suited for three to nine developers, a Scrum Master and a Product Owner. The term Scrum was introduced by two Japanese Organizational theorists, Hirotaka Takeuchi and Ikujiro Nonaka in the context of Product Development in 1986. In the early and mid 1990’s, Ken Shwaber and Jeff Sutherland adopted Scrum for the field of Software development.

Scrum teams typically breakdown work into one to four-week cycles called Sprints. The objective is to deliver working software at the end of each sprint cycle. The key Scrum practices are;

• Backlog Grooming (Arranging and clarifying requirements in terms of priority)

• Sprint Planning (A session at the beginning of every sprint to determine the work to be delivered in the sprint and planning the delivery)

• Daily Scrum (A short 15 min daily catch up of the development team to determine progress and uncover obstacles that impact completion of work as planned)

• Sprint Review (A meeting at the end of every sprint to determine what work has been completed against the acceptance criteria for completion)

• Sprint Retrospective (A meeting at the end of every sprint to determine what’s working and what’s not in the development process and to try out new or different approaches or ideas)

Kanban

Kanban, in the software development context, is an approach that visualises flow of work to balance demand (Requirements or work items) with available capacity. Work is visualized across all team members using a physical or electronic kanban board. (kanban in Japanese means signboard). Kanban is a pull-based system which aims to limit work in progress and eliminates over production. The six general practices of Kanban are;

1. Visualization

2. Limiting Work in progress

3. Flow Management

4. Making policies explicit

5. Using Feedback loops and

6. Collaborative or experimental evolution

Extreme Programming (XP)

Extreme Programming (XP) is an approach intended to improve software quality and responsiveness to changing customer requirements through frequent releases in short development cycles. XP was created by Kent Beck around 1996.

XP characterises four basic activities of the software development process as the building blocks for creating any software product.

1. Coding

2. Testing

3. Listening

4. Designing

The 12 common practices of XP, arranged into 4 groups are;

1. Fine-scale Feedback

2. Pair Programming

3. Planning game

4. Test-driven development

5. Whole team

6. Continuous process

7. Continuous integration

8. Refactoring

9. Small releases

10. Shared Understanding

11. Coding standards

12. Collective code ownership

13. Simple design

14. System metaphor

15. Programmer welfare

16. Sustainable pace

Lean Software Development

Lean software development is a conceptual framework that has borrowed principles from lean manufacturing (adapted from the Toyota Production System). Lean Software Development was popularized by Mary and Tom Poppendieck. The Lean concept primarily focuses on reducing or eliminating waste.

Lean Software development can be summarised by seven principles;

1. Eliminate Waste

2. Amplify learning

3. Decide as late as possible

4. Deliver as fast as possible

5. Empower the team

6. Build in Integrity

7. See the whole

Rapid Application Development (RAD)

RAD was initiated by Barry Boehm and further developed by James Martin at IBM in 1991 and the approach puts less emphasises on planning and more focus on the process of software development. Unlike the Waterfall method, RAD emphasises adaptability and the benefits of adjusting requirements to the knowledge gained as the project progresses. RAD uses prototyping as a key technique instead of detailed specifications. As an Agile approach, it is particularly well suited to software development driven by user interface requirements.

The RAD process can be grouped into four distinct phases;

1. Requirements planning phase (combines the elements of system planning and system analysis phases of the traditional systems development lifecycle or SDLC)

2. User design phase (Users interact with analysts to develop prototypes and models)

3. Construction phase (Programming and Application development)

4. Cutover phase (Data conversion, Testing, User Training, etc)

Although RAD looks similar to the traditional or Waterfall approach, it differs significantly in the emphasis on user interaction and prototyping.

Crystal

Crystal is probably the most lightweight of all Agile approaches and was created by Alistair Cockburn in the early 1990’s, one of the authors of the Agile Manifesto discussed in earlier sections.

The Crystal family comprises of several approaches called Crystal Clear, Crystal Yellow, Crystal Orange, etc. Each of these approaches named after colours are tailored for factors such as team size, system criticality and project priorities.

Crystal focuses on the following six aspects more than the process element;

1. People

2. Interaction

3. Community

4. Skills

5. Talents

6. Communications

There are seven common properties across the Crystal family;

1. Frequent delivery

2. Reflective Improvement

3. Close communication

4. Personal Safety

5. Focus

6. Easy access to expert users

7. Technical environment with automated tests, configuration management and frequent integration

Dynamic Systems Development Method (DSDM)

DSDM originated in 1994, as an Agile approach that sought to introduce discipline to the RAD approach. After many revisions, it became a framework of its own for project management and solution delivery rather than on just software development. DSDM covers the whole product lifecycle and is one of the few Agile approaches that emphasises strong governance. The present day DSDM has evolved into an iterative and incremental approach that embraces continuous involvement of the user / customer throughout the Product lifecycle.

DSDM constrains cost, quality and time right upfront through a concept of prioritisation of scope called MoSCoW features (Must have, Should have, Could have and Won’t have features in the delivered product).

Eight principles underpin the DSDM approach;

1. Focus on the business need

2. Deliver on time

3. Collaborate

4. Never compromise quality

5. Build incrementally from firm foundations

6. Develop Iteratively

7. Communicate continuously and early

8. Demonstrate control

Feature Driven Development (FDD)

Feature driven development is another iterative and incremental software development approach that blends several industry practices into a cohesive whole. FDD was created by Jeff De Luca in 1997 for a large banking application development project. FDD is a model driven short-iteration process consisting of five activities;

1. Develop overall model (High level walkthrough of the system scope and context)

2. Build feature list (Decompose the model into a list of features or client-valued functions, like User Stories)

3. Plan by feature (Development plan by feature including work allocation to developers)

4. Design by feature (Detailed sequence diagrams including methods and classes for the features list )

5. Build by feature (Development of code for the classes and testing)

Summary

This article introduced the various flavours of Agile including the similarity and differences. Some approaches such as XP focus on the practices, while others such as Scrum and Kanban focus on managing the flow of work. Approaches such as FDD support activities for requirements specification and development, while others such as DSDM and RUP cover the full development life cycle. It is also important to distinguish Agile frameworks / approaches from Agile practices. Practices such as Test-Driven Development or Pair Programming are practices that support many Agile approaches but are not approaches in themselves.