Why we work with agile methodology

Where agility comes from

In 2001, seventeen software developers met in Snowbird, Utah, to talk about something they had all observed separately: traditional project management methods didn’t work well for building software. Out of that meeting came the Agile Manifesto (Manifesto for Agile Software Development), a short text that ended up defining how much of the industry works.

The manifesto is not a methodology or a set of rules. It is four values and twelve principles. The values say that, while the items on the right have value, we value the items on the left more:

• Individuals and interactions over processes and tools.
• Working software over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.

It is important to read it carefully: it doesn’t say that documentation, plans or contracts are useless. It says that when the two sides are in conflict, the left side should win.

The problem it solves

To understand why this is a good idea, you have to understand the model it replaced. Waterfall development organises a project into sequential phases: first everything is specified, then everything is designed, then everything is programmed and, at the end, it is tested and delivered. On paper it is orderly. In practice it has a structural flaw: all the feedback arrives at the end, when most of the time and budget has already been spent.

And feedback at the end is expensive for a very simple reason: software is a product that nobody can fully specify in advance. The client discovers what they really need when they see the product working. Developers discover the technical difficulties when they work on them. The market changes while the project moves forward. In an eighteen-month waterfall project, all these discoveries are made when it is already too late to react without redoing work.

Short cycles, small risk

The agile answer to this problem is to work in short iterations, usually one to four weeks, with each one ending with working software in the client’s hands. One of the twelve principles says it literally: working software is the primary measure of progress, not approved documents or completed phases.

This change has a chain of consequences:

• Risk is fragmented. If an iteration goes wrong, two weeks are lost, not eighteen months. Conceptual mistakes are caught while they are still cheap to fix.
• The client validates against reality, not promises. Seeing a feature running generates much more useful feedback than reviewing a hundred-page specification document.
• Priorities can change. Since the plan is reviewed at every iteration, absorbing a change of priorities is the system working as intended, not a crisis. The manifesto makes this an explicit principle: changing requirements are welcome, even late in development.
• Value is delivered from the start. The client doesn’t wait until the end to have something useful: the most important features are built first and can go into production before the project is finished.

People who talk to each other

The second pillar is less technical and more human. The manifesto puts individuals and interactions first because most problems in a software project are not about tools: they are about communication. Misunderstood requirements, unverified assumptions, decisions made without the person who had the information.

This is where practices like direct and frequent conversation between business and technical teams come from (another principle asks them to work together daily), along with small self-organising teams and the retrospective: stopping at regular intervals to think about how to work better and adjust. This last one is perhaps the most powerful idea in the manifesto, because it turns the way of working into something that is also iterated and improved, just like the product.

What agile is not

Two common misunderstandings are worth clearing up. The first is that agile does not mean improvising. Planning happens constantly; what doesn’t happen is pretending that a detailed one-year plan will survive contact with reality. The second is that agile is not synonymous with any specific framework. Scrum, Kanban and Extreme Programming are implementations of the manifesto’s values, each with its own tools. You can follow Scrum to the letter and not be agile at all, if the ceremonies are performed empty of content.

In summary

Agile methodology works because it accepts an uncomfortable truth about software development: uncertainty cannot be eliminated, only managed. Instead of trying to predict everything at the start, it builds a system that learns fast, with short iterations, constant feedback and working software as the only reliable measure, and that can change direction when it learns something new. Almost twenty-five years later, the manifesto’s four values are still the best short description of how good software gets made: not by following a perfect process, but by collaborating, delivering often and adapting.