What Is Agile?

Agile is one of the most-used and most-abused words in software. To understand it, separate two layers: the mindset (Agile) and the frameworks that try to embody it (Scrum, Kanban, XP, and so on). This course covers both, but it starts with why Agile exists at all.

The Problem Agile Solves

Through the 1980s and 90s, large software projects were typically run as Waterfall: gather all requirements, design the whole system, implement, test, deliver. The pipeline took 12 to 36 months, and the result rarely matched what the customer actually needed by the time it shipped — because the customer's understanding of the need had also changed.

Common failure modes:

• Months of design before any working code exists.
• Late integration: hundreds of components meet for the first time near the end.
• "Big bang" releases where success or failure is binary.
• Stakeholders see nothing real until the end and discover misunderstandings too late.
• Change requests are treated as failures of the spec rather than facts about reality.

The Agile Reaction

In February 2001, seventeen practitioners met at a ski resort in Utah and wrote the Manifesto for Agile Software Development. They came from existing lightweight methods — Extreme Programming, Scrum, DSDM, Crystal, FDD — and agreed on a short statement of shared values.

The next lesson covers the manifesto in detail. The core idea: optimise for the ability to change direction rather than for the ability to predict the future.

Agile Is a Mindset

Agile is not a methodology. It is a set of values that shape how a team thinks about work:

• Working software in small, frequent increments beats lengthy specification.
• Direct conversation beats indirect documentation when it can be afforded.
• Adapting to change beats sticking to an outdated plan.
• Customer collaboration beats arms-length contract negotiation.

You can implement those values with Scrum, Kanban, XP, or your own bespoke approach. Or you can run a perfect Scrum cadence and still be deeply un-Agile because the values aren't there.

Frameworks Inside the Mindset

Most software organisations use Scrum, Kanban, or a hybrid ("Scrumban"). This course focuses on Scrum, with a chapter each on Kanban and scaling.

What Agile Is Not

• Not "no planning." It is continuous, evidence-based planning instead of one giant up-front plan.
• Not "no documentation." Documentation that helps users and future maintainers is valuable; specs that nobody reads after week one are not.
• Not "do whatever the loudest stakeholder asks today." A Product Owner protects priorities and trade-offs.
• Not a guarantee of speed. Agile teams typically deliver value sooner and more steadily, not necessarily more total output per quarter.

Common Anti-Patterns ("Dark Agile")

• Story-point sweatshops. Velocity becomes a quota; engineers inflate estimates to look fast.
• Stand-up status meetings. Reporting up to a manager instead of coordinating across the team.
• Backlog-as-graveyard. Hundreds of stale tickets nobody triages.
• Mini-Waterfall sprints. Two-week mini-projects with no inspection or adaptation between.
• Death by ceremony. So many meetings the team can't think.

If you have seen these, that is what your colleagues mean when they roll their eyes at "Agile." It is not Agile failing — it is the mindset missing.

Where Agile Genuinely Shines

• Product development under uncertainty about user needs.
• Software where the cost of change is low (good test coverage, CI/CD).
• Teams of 3–9 people with end-to-end ownership.
• Organisations willing to make decisions on data rather than schedules.

Where Agile Is a Bad Fit

• Hardware projects with month-long manufacturing turnarounds.
• Safety-critical systems with regulatory documentation requirements (though hybrid approaches exist).
• Pure operations work — Kanban or ITIL fits better.

Cert Mapping

The next lesson covers the Agile Manifesto itself — the four values and twelve principles that anchor everything that follows.