What Does Agile Mean – What Is Agile Methodology?
Fashion? A fad? Or a truly valuable asset? What does it have to do with IT? Can it be used in other industries? This article answers these and other key questions often asked about agile methodologies.
In 2001, a short call for action, the “Manifesto for Agile Software Development” was published, which launched the agile movement. In the more than two decades since, agile has become widespread, and has developed a market of its own, with countless textbooks, training courses, consultants, and in some business areas it has become so inescapable that some organisations have been struggling for more than a decade to at least present themselves as agile.
As a consequence of this process, the perception of agility and agile methodologies has become ambiguous, a long series of failed projects and organisational transformations casting a shadow over its undeniable achievements . Yet, just as the most fashionable trousers are not to blame for being worn by someone whom they don’t fit, agility is perfectly suited to the expectations placed on it – but only if applied in the right environment. So it’s essential to start with the basics: understanding what agile is and isn’t for.
What is agile?
In short, agile is a mindset. A (in 2001) new approach to product development.
At the birth of agility, the software industry was also working with traditional product development methodologies in which planning and implementation (execution, development) are more or less sharply separated. Put simply, it was recognised that in software development, the “think it up first, then do it” approach does not always work, and often requires changes to the original concept during implementation.
The origins of agile are not just a matter of historical interest, but also include the answer to the question: when is it worthwhile to take an agile approach? When planning and implementation cannot be sharply separated. In other words, if there is a strong chance that changes will occur during implementation, an agile approach may be useful.
What can cause a change in the implementation of a well-planned project or product development? Let’s look at some examples!
In a saturated market, with fierce competition, you constantly need to react to your competitors’ ideas and innovations, and need to continuously innovate yourself. Detailed planning can only work in the short term; in the long term, clear objectives but flexible plans are needed.
Hectic legal, political or regulatory environment
If our product has to meet serious standards in an unsteady environment, we need to leave the door open for modifications in the plans so that we can react to any changes.
If the product requires building on knowledge that did not exist before (e.g. physics or chemical research, drug trials, etc.), the plans again cannot be accurate.
The human factor
One of the important lessons of the software industry is that even if you ask the customer what they want, they often don’t know themselves. Henry Ford’s famous saying, “If I had asked customers what they wanted, they would have said a faster horse”, is a reference to this: the customer doesn’t understand product development. They don’t need to understand it. As long as the product doesn’t exist, the customer only has ideas about what they need, what would be good for them. However, as the product evolves, they can be more and more specific about whether it is right for them or how it would be better. Anyone who has renovated a home or built a house will be familiar with this experience.
The human factor (again)
With a large audience, it’s almost impossible to match everyone’s taste. It is no coincidence that many industries rely on continuous testing and measurement to find out which of the envisioned products really appeal to customers and really match the tastes of potential clients. That’s why snack and soft drink manufacturers organise tastings and why production companies measure the ratings of series (and cancel a lot of TV shows after the first season), etc.
In summary, agility is a product development philosophy designed for product development in a volatile environment.
Agile Manifesto – Where does agility originate from?
The basic document on agility is therefore the Agile Manifesto of 2001. The movement was started by managers, innovators and consultants working in the software industry. This is – unfortunately – clear from the text of the manifesto, and has become the root of two common misinterpretations:
– It may suggest that agile can only be used within IT, and more specifically only in software development. As we’ve already shown , this is not the case: agile can be a valuable tool in any volatile environment.
– It can also suggest that all software development should be done in an agile way. This is not the case either. There are environments where (for example, because of risk management or having to cooperate with other industries) accurate up-front planning is not only expected but essential. In such environments, agile would only add unnecessary complexity. It is worth noting, however, that in our experience this situation is much less common than how often it is claimed by those within the organisation who would like to get away from, or even fear the agile transformation.
The text of the Agile Manifesto
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
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.
You can learn more about the detailed interpretation of the manifesto in our Agile and Scrum training.
In addition to these four pairs of values, the Manifesto also defines twelve principles. We highlight one of these, the most innocuous, perhaps even the most ambiguous, because it perfectly sums up the purpose and rigour of agile thinking:
”Working software is the primary measure of progress.”
Agile thinks simply about success. Have you created anything from your product yet? Does it work? Does it do more than, say, a month ago? Has it improved in the last month? Does the customer like it? Is the customer happy with it? These are the main questions in agile. And if the answer starts with “no, but”, agile doesn’t fall for it. No, but we already know whom to call. No, but we’ve already started thinking about plans. No, but we already have three hundred pages of specifications.
Replacing the word “software” in this principle with “product” opens the door to other industries.
Learn more about the detailed understanding of Agile principles in our Agile and Scrum training.
Does the agile organisation plan?
Unfortunately, the rigour of agile, and the fact that the Manifesto values responding to change over following a plan, has also given rise to another misunderstanding: some people think that agile does not allow making plans. Some people did believe this, tried it, of course failed, and then blamed agile for the failure. There were also some who decided against agile because they believed that it would eliminate planning. Let’s clear up this misunderstanding too.
Planning is also a very valuable activity in agile (“while there is value in the items on the right”). However, since agile is designed for development work in a volatile environment, long-term detailed planning in agile does not make sense. Why plan three years ahead when you know that new, unforeseen information may arrive tomorrow? So agile is not against planning, it is only against unnecessary planning (like any other unnecessary activity). Its central idea is to find just the right amount of everything. How far in advance do we need to plan now to be able to adapt to changes on the fly, yet not to end up with a patchwork, badly assembled mess, but with a product of the right quality, giving value to the customer?
What does an agile coach do?
One of the most important tasks of a coach is to help the organisation decide whether and in which areas it makes sense for them to move to agile. It is important to emphasise that an organisation being agile does not mean that it does everything in an agile manner, it does every project and product development in agile, but if it uses the right methodology for every single area and the organisational mindset is based on agile foundations.
If you’re thinking about making the switch to agile and wondering whether your organisation is ready for it, we can help you assess whether it’s right for you.
If the decision is positive, and the preliminary assessment shows that the value to the organisation is likely to be significantly greater than the cost of the transition, the coach will help:
– with the right timing and scheduling of the transition,
– planning the transition,
– leading the transition as a project,
– supporting all participants in the organisation ( teams and individuals, at all levels of the hierarchy) during the transition
– will not let go of the hands of the organisation until they avoid the initial pitfalls and become confident and the agile mindset becomes their basic instinct.
As coaching requires a high level of trust, we aim to ensure that the initial training sessions are delivered by the same coach who will lead the Agile implementation. Depending on the size of the organisation, it may of course be necessary to involve more than one coach in a transformation.
What is Scrum and how is it related to agility?
Agile is a mindset, a philosophy, a manifesto with four pairs of values and twelve principles. This Manifesto alone is not enough to answer practical questions, like OK, so how should we actually do it?
This is why project management methodologies and frameworks have been developed to put agile values and principles into practice. The most commonly used of these is the Scrum framework. You can learn more about Scrum in our Scrum training.