What is Agile?
Some names don’t help you. Apple. Scrum. Sky. Nothing in the name gives you much of a clue what the idea is about or what product is being sold.
Other names spell it out. Agile belongs in the latter group. Agile is all about being – well – agile.
Agility is defined as the ability to respond rapidly to change. In the case of a body, that means being able to change direction and position while maintaining balance and control – no surprise that football players require agility. For software development, the idea is not too different. Agile attempts to help organizations work in a way that will enable them to be flexible, to respond swiftly to opportunities and threats and to change direction in response to new information. Drilling down to the software engineering level, we see the concept reflected in practices which are all designed to emphasize flexibility: evolving requirements, fast feedback loops, cross-functional teams, iterative development, incremental delivery. Or as Wikipedia rather more formally defines Agile, ‘It is a conceptual framework that promotes foreseen interactions throughout the development cycle.’
That’s the aim. In the 1990s many organizations and individuals felt that software development processes were failing to keep pace with business necessity – either because of a growing need for more complex IT or the opportunities offered by the dotcom era.
In many cases, traditional project management and development methods seemed to be failing. Now described as ‘waterfall’, most processes relied on up front planning, detailed specifications and hand-offs between different work-flow processes. Although intended to control cost, schedule and scope, because waterfall struggled to cope with changing circumstances, projects often ended up with uncontrolled costs and delays.
Agile was developed as a more ‘lightweight’ approach in response to these problems. The term ‘Agile’ is a fairly elastic one, embracing a broad family, including Scrum, XP and a series of shared approaches that don’t go by any particular name. In 2001, a group of 17 software and technology experts published the Agile Manifesto – a document which sought to define the general principles and characteristics of this type of software development. The Manifesto begins, ‘We are uncovering better ways of developing software by doing it and helping others do it.’ It goes on to list what it values, and the 12 principles that underpin the Agile working approach. Read the Manifesto here.
In over a decade, the ideas have grown in popularity and have been adopted by numerous organizations. While some changes or adaptations have been suggested to parts of the manifesto, in general, most practitioners of Agile would agree that they continue to share its philosophy.
Stripped of the exaggerated claims and embellishment that is often loaded onto it, Agile is revealed as fairly straightforward advice for those who need flexibility in the face of relentless change. Unfortunately for Agile, much of this highly practical and common-sense approach has become enmeshed in dogma and process. Rather than focusing on flexibility, books and courses that offer a ‘one-size-fits-all’ solution have inadvertently created inflexible processes that reproduce many of the problems of waterfall.
What Agile is not
From the slightly cult-like claims that Agile is a ‘way of life’ to those who accuse Agile of being a cynical, money-making industry, the name has gathered some heavy baggage. It might be easier to agree what Agile is not:
Agile is not a software engineering process. Unlike XP, Agile contains no explicit engineering practices. Agile ensures quality through a fast feedback loop driven by delivering working software to customers.
Agile is not a set recipe. The idea as we have described it, and as it is laid down in the Agile Manifesto, is more of a philosophy than a prescription to follow. That means ‘doing Agile’ is not easy. Just as telling a child, ‘be good’, will not necessarily ensure perfect behavior, so saying ‘deliver working software frequently’ holds few clues to how you will do it. One reason why so many methods and practices have proliferated is that everyone has a different take on how. Scrum, for example, provided a clear framework for small teams, that was enormously helpful for some types of development, although it is not suitable for all projects or organizations.
Agile is not a silver bullet. Implementing Agile ideas often means taking some rather difficult decisions and changing much of how the business currently operates, from approval processes to release plans. These changes are rarely easy to make. Resistance is likely to be high, which is why so many Agile transformations actually act on only a small slice of the business (typically software creation itself). This limited objective explains why the resulting improvements are equally limited.
If you want to learn more about how Agile works in practice, check out our Learn services and VFQ Education: the first work-based learning programme that helps you apply the concepts within your own context.
Additional Insights
Embracing uncertainty when making technology investments
Make overcoming transformation fatigue your unfair competitive advantage
The five key areas of transformation fatigue
