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.
Agile methodology vs waterfall
You can think of agile and waterfall as two opposing ends of a spectrum. Agile focuses on speedy progress based on constant communication with the customer, and uses a working product (such as software), as its measure of progress.
Waterfall is a much more traditional methodology, relying on extensive planning, then follows a linear development method that only delivers a working product at the end of the project.
Both approaches have their advocates and critics, and here we’ll go into some more detail on their advantages and disadvantages below – again using software development as an example.
While most developers lean one way or the other, many choose to be less dogmatic and tweak the approaches as they see fit.
Agile methodology focuses on building software quickly based on customer requirements, then adjusting it according to customer feedback before moving on to the next step in development.
An agile project starts by defining the key features of the software the customer wants. These are called ‘user stories’ and developers group them into ‘iterations’, based on priority. Working in sprints, the team aims to complete each iteration within a set timespan, usually measured in weeks. The aim of each sprint is to produce working software the user can try out, then recommend adjustments so it better suits their needs.
But the end of the project doesn’t mean all features are built. Agile projects can run out of time, meaning developers must either agree with the customer to do without some features that remain incomplete, or extend the project (and pay more money) to deliver them.
A waterfall development project follows a traditional, linear approach. The first stage is scoping out users’ requirements, which can be an extensive process. Because developers won’t produce working software for customers to try out mid-project, they want to understand up front exactly what users want the software to look like.
Then, the developers will design the software, giving themselves a detailed template to work from. By working from a plan, the idea is that the actual development process, which comes next, will be smoother and hit fewer obstacles.
Once they’ve built the system, developers enter the testing stage - this is where they make sure the software actually works. This sees developers debug the system, sometimes involving users who try it out. After that, the developers go into maintenance mode, installing, supporting and maintaining the software on behalf of the customer.
Pros and cons of agile methodology and waterfall
Agile’s biggest advantage is that it involves customers at every stage of development. With users constantly providing feedback on working software, the project is much more likely to end up meeting their needs, which may develop as the project progresses. Unlike waterfall, if a customer requests a change, agile developers can easily make it.
This approach also delivers software more quickly to customers, making it ideal for projects in which speed is of the essence.
Another advantage in agile methodology is the concept of continuous improvement, in which lessons learned in one iteration inform work on the next iteration.
Agile methodology cons
However, agile projects are intensive for customers. Their involvement is required throughout, so the customer must be able to spare stakeholders, who must be enthusiastic and engaged about the project. Agile projects can fall apart if the customer isn’t interested in working closely with developers.
Agile’s other disadvantage is that, because of the strict sprint deadlines, sometimes the overall project can end incomplete. Customers must either just accept the reduced scope of the project, or pay more to get the developers to finish everything they had planned to complete.
By focusing on quality over speed, waterfall is well-suited to less urgent projects with customers who know exactly what they want their software to do. The extensive testing period can result in fewer bugs when the project is complete.
Waterfall’s strict linear process means a project is likely to be finished on time and within budget, and with regular milestones it is easier for both developers and customers to track its progress.
In waterfall development, once the course is set there is no deviating from it. Unlike agile methodology, waterfall doesn’t involve customers every step of the way, but scopes out their requirements only at the start of a project.
This means the waterfall approach works best when customers have clear ideas about what their software needs to do. If users have only a vague idea, or the project takes a long time to deliver, the finished software often won’t need users’ requirements, which may change over the course of the project.
Similarly, once a waterfall project hits the testing phase, it’s very hard to make changes to the software. Customers will have to pay more money and wait longer if they want to make changes this late.
To avoid this, waterfall developers sometimes build in customer feedback points between the stages outlined above, to adjust the project as they go.
Related: Top 5 Agile tools