We explain the agile methodology approach to managing projects and processes.
The agile methodology prioritises speed of delivery, collaboration between different business units (such as marketing and IT) and adaptability over more traditional approaches such as 'waterfall'.
In fact, agile methodology has been around for several years in the software development world, and while we’ll use that sector as an example here, it’s an approach that can be – and is – used widely across business.
First described in 2001 (though the concept has been around longer than that), agile methodology is a response to a sequential style of software development where the business states its requirements, and IT delivers software to meet them. Because of the top-down nature of this method, the resulting software can fail to meet users’ needs, which may have evolved since the start of the project.
Instead, agile methodology focuses on incremental development, prioritising testing and user feedback in order to adjust the software to suit new or changing user requirements, ensuring the product remains relevant and useful. In general, proponents believe agile delivers projects faster, cheaper, and most importantly, ends up with software that meets users’ needs.
Self-described ‘agile warrior’ Jonathan Rasmusson calls the methodology a “time boxed, iterative approach to software delivery that builds software incrementally from the start of the project, instead of trying to deliver it all at once near the end”.
Agile methodology principles
The Agile Manifesto, set out in 2001, outlines the key principles underpinning the concept:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
In short, agile methodology favours speed of delivery, testing, and continuous feedback. Its core principles support this. They are:
- Early delivery, creating shippable software in two-week ‘sprints’
- Responding to changing requirements
- Measuring progress with working software as the metric
- Collaboration between business people and developers through face-to-face conversations
- Simplification - not making software overly complex
- Small, self-organising teams that regularly reflect on best practices
How does an agile process work?
Agile divides a project into smaller parts, called ‘user stories’. Each one of these is a desired feature the user wants in the software. Developers work through these user stories as you might a to-do list, working out which to prioritise and grouping them into iterations, with estimated deadlines for each iteration (usually around two weeks).
Once an iteration is complete, developers should have a potentially shippable product users can test. This means agile projects create something simple that they can then iterate on based on users’ feedback, making the software better suited to users’ needs while minimising complexity.
It means that developers don’t often start work with a full set of requirements, but instead discover new requirements through user feedback that they can then adapt their software to meet.
The sprint duration is always fixed. That ensures developers and users can regularly review the project’s direction and keep it on track. However, it also means that a project can run over schedule, unless developers decide to reduce its scope and ambition.
Types of agile methodologies
While agile describes a mindset and a clear philosophy for creating new products such as software, it materialises in many different forms that take slightly different approaches to agile projects.
Probably the most popular one is scrum, an approach that Scrum Alliance describes as bringing the concepts of agile development beyond the IT team and into management. In this model, a scrum master leads the work but achieving the business goal is a team responsibility.
Another popular agile methodology is XP, which stands for Extreme Programming. This model sees the focus on the technical side of things, rather than the business side. According to Mountain Goat Software, XP sprints are about half as short as scrum sprints (two weeks maximum, rather than up to a month), while XP also is more flexible about changing or adjusting goals mid-sprint.
Agile advocates who don't subscribe to Scrum or XP will tend to favour Lean Software Development, a methodology coined in 2003 and based on seven principles, which generally favour a back-to-basics approach that cuts out anything but the necessary features to deliver a product as quickly as possible while meeting customers' needs and allowing the business-aligned developers to take charge, rather than managers.
Of course, not all developers subscribe to the agile methodology. Some follow the more traditional ‘waterfall’ methodology that is used widely in business.
Next: we explain the differences between agile and waterfall.
