Agile Explained: The Principles, and What Goes Wrong in Practice

Agile is a set of principles about how to develop software under uncertainty: work in small increments, get real feedback, and change the plan when the feedback says so. Everything else — ceremonies, boards, roles, certifications — is machinery built to serve those principles, and it is entirely possible to run all the machinery and get none of the benefit.

That gap is the subject of this guide. The principles are neither complicated nor controversial. Living with their consequences is.

What it actually asks for#

Small increments that work. Not phases of a large thing, but something usable, sooner. This is the mechanism by which everything else functions: without working software, feedback is opinion.

Feedback from reality. Real users, real data, real conditions. A demo to internal stakeholders is a status report with slides that move.

A plan that changes. Not "no plan" — a plan that is updated as you learn. A plan that never changes is either extraordinary luck or a plan nobody is comparing to reality.

Decisions close to the work. The people doing the work decide how it is done. Where every technical decision routes through someone outside the team, iteration speed is capped by that person's calendar.

Sustainable pace. In the original principles and consistently ignored. Teams under permanent pressure stop refactoring, stop writing tests, and their delivery rate falls a few months later — by which time nobody connects the two.

Agile versus "we do standups"#

The visible practices are the easy part to adopt and the least useful in isolation. A useful diagnostic is to ask what would happen if the following were true, because in a genuinely agile setup each is normal:

• A stakeholder sees the software every two weeks and asks for something different
• The team says a planned item is no longer worth doing
• Scope is reduced to hold a date, and the sponsor is comfortable with that
• A release goes out without a change advisory board meeting
• The roadmap for six months out is deliberately vague

Where those provoke a crisis, you have adopted the ceremonies without the operating model. The standup runs, the board is groomed, and the annual plan is still fixed in scope, date and budget — which is the one combination the principles say cannot hold.

Where transformations stall#

At the delivery team's boundary. The team iterates; funding is annual, procurement takes three months, governance requires a full specification at gate two, and releases require a committee. The team is agile inside a system that is not, and absorbs the friction as overtime.

In fixed scope, date and budget. Something has to flex. Agile flexes scope. Where all three are fixed by contract, the negotiable variable becomes quality, silently, and it is repaid over the following year.

In the absence of a real product owner. Someone must decide what is most valuable next, be available to answer questions, and be trusted to say no. A proxy who must escalate every decision makes the team's iteration speed equal to their approval speed.

In estimates used as commitments. The moment a forecast becomes a promise, estimates inflate, scope is defended rather than discussed, and the information the numbers were meant to carry is gone.

In "agile" as a cost-reduction programme. It is a way of managing uncertainty and reducing the cost of being wrong. Teams that adopt it expecting to deliver the same scope faster conclude within a year that it does not work.

How to tell whether it is working#

Not by ceremony compliance or velocity. By outcomes:

• How long does an idea take to reach a user? The single most informative number.
• How often do you release? Frequency is a proxy for batch size and confidence.
• What proportion of what you build gets used? The uncomfortable one, and the one agile is supposed to improve.
• How quickly do you recover from a bad release?
• Does the plan change in response to feedback? If it never changes, feedback is not reaching the plan.

Velocity is a capacity-planning aid for one team. Comparing it across teams, or setting it as a target, converts it immediately into a number that goes up and means nothing.

Where it is a poor fit#

Honest cases exist. Work with genuinely fixed, well-understood requirements and heavy regulatory verification gains less from iteration. Systems where an increment cannot be delivered usefully — some hardware, some migrations — need a different rhythm. Contracted work with fixed scope and penalties fights the model at every step, and lightweight hybrids usually serve better.

The pattern worth avoiding in all of these is adopting the vocabulary while the operating model stays unchanged, which produces the overhead of both approaches and the benefits of neither.

A realistic starting point#

Pick one team and one product. Get to a working increment every two weeks, shown to real users. Give the team a product owner with decision authority and the ability to release without a committee. Measure time from idea to user, before and after.

Then fix whatever that measurement exposes — usually approval steps, environment availability, or a dependency on another team. Those constraints are the actual transformation. Certifying everyone does not move them.

FAQ#

Is agile the same as scrum?#

No. Agile is the set of principles; Scrum is one framework implementing them, and Kanban is another with quite different mechanics. Many teams run something in between, which is fine if it is a deliberate choice rather than a framework decaying.

Do we still need documentation?#

Yes. The principle values working software over comprehensive documentation — a statement of priority, not permission to write nothing. Durable facts still need a home: interfaces, business rules, decisions and their reasoning. What agile removes is documentation produced to pass a gate and never read again.

How do we do fixed-price contracts?#

With difficulty, and better with a different shape: fix the budget and timeframe, vary the scope, and agree a mechanism for changing priorities. Where scope must be fixed, expect a change process and price the uncertainty honestly rather than pretending it is absent.

What about long-term planning?#

Plan at decreasing resolution: detailed for the next few weeks, thematic for the next quarter, directional beyond that. The mistake is not planning ahead; it is planning at the same level of detail for month one and month eighteen, then treating both as commitments.

Who is accountable when a team self-organises?#

The team is accountable for delivery, the product owner for what is built, and management for the system the team operates in. Self-organisation concerns how the work is done, not whether it is done. Where accountability feels unclear, it is usually because one of those three roles is vacant.

Our stakeholders will not engage every two weeks. What now?#

Then feedback is not available, and iteration will not deliver its benefit. This is a real constraint worth naming explicitly rather than working around. Sometimes the answer is a smaller group of genuinely engaged users; sometimes it is accepting a longer cycle and being honest that you are trading away the main advantage.

Is it worth hiring an agile coach?#

If they change the system around the team — funding, governance, dependencies, release path — yes. If their remit is to improve the team's ceremonies, the constraint was almost certainly not there, and the team will politely absorb the training and continue as before.

Related Articles#

Compare the two most common frameworks in Scrum and Kanban, set the boundary in the Project Charter, and handle scope movement through Change Management.

What else is coming for Agile