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;
Extreme Programming (XP)
Lean software development
Rapid Application Development (RAD)
Dynamic Systems Development Method (DSDM)
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;
Individuals and Interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over Contract negotiation
Responding to change over following a plan
Agile Software Development Principles
The Agile Manifesto for software development is based on the following twelve principles;
Customer satisfaction by early and continuous delivery of valuable software
Welcome changing requirements, even in late development
Working software is delivered frequently (weeks rather than months)
Close, daily cooperation between business people and developers
Projects are built around motivated individuals, who should be trusted
Face-to-face conversation is the best form of communication (co-location)
Working software is the primary measure of progress
Sustainable development, able to maintain a constant pace
Continuous attention to technical excellence and good design
Simplicity—the art of maximizing the amount of work not done—is essential
Best architectures, requirements, and designs emerge from self-organizing teams
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 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, 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;
Limiting Work in progress
Making policies explicit
Using Feedback loops and
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.