In short
Agile is an approach to building software in short cycles, delivering working increments, getting feedback from real users and stakeholders, and adjusting plans based on what was learned, instead of specifying everything up front and building to the specification. Frameworks such as Scrum and Kanban are ways of practising it, designed largely for organisations. A small team needs the values and a few mechanisms: a prioritised backlog, short cycles or continuous flow with work-in-progress limits, a demonstration of working software at a regular cadence, and a habit of asking what to change. The rest is optional and often counterproductive at small scale.
What the manifesto says
In 2001 seventeen software practitioners published the Agile Manifesto, four preferences and twelve principles. The preferences: individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; responding to change over following a plan. The manifesto values the things on the right, but values the things on the left more.
The principles say the rest: deliver working software frequently, in weeks rather than months; welcome changing requirements; work with business people daily; build around motivated people and trust them; measure progress by working software; sustain a pace; keep it simple; let teams organise themselves; reflect regularly and adjust.
That is agile. It is short and it is not a process. Everything that followed was people trying to make organisations do those things, and the machinery they built for that is what most people now mean by the word.
The frameworks, and what scales down
Scrum organises work into sprints with planning, daily stand-ups, reviews and retrospectives, and defines roles: product owner, Scrum master, developers. It gives a large organisation a rhythm and a vocabulary. A small team gets the rhythm from a fortnightly demonstration and drops most of the rest: nobody needs a Scrum master in a team of three, and the daily stand-up is the conversation the team was going to have anyway.
Kanban replaces fixed cycles with continuous flow: a board with columns, limits on how much can be in progress at once, work pulled as capacity frees, and cycle time as the measure. It suits small teams with unpredictable incoming work, such as an agency or a product team also doing support, and it needs almost no ceremony.
Extreme Programming contributed the engineering practices: test-driven development, pair programming, continuous integration, small releases, refactoring. These scale down perfectly, and they are the parts that most improve the software rather than the process around it.
The scaled frameworks for enterprises, SAFe and its peers, have nothing to say to a small team and should not be looked at.
The minimal process
A team of two to five people building software for a client or a product needs:
A single prioritised backlog, owned by one person who decides order, containing items small enough to finish in days. The prioritisation is the product decision, and it is made continuously.
A cadence. Either short sprints, one or two weeks, with a demonstration at the end; or continuous flow with a weekly review of priorities and a demonstration whenever something is ready. Small teams often prefer flow; clients often prefer the predictability of a sprint. Either works if the demonstration happens.
Working software, shown, often. On a staging environment, to the people who will use it or pay for it, with real feedback captured into the backlog. This is the mechanism that makes agile agile; without it, the team is doing waterfall in short pieces.
A board everyone can see, with work-in-progress limited so that things get finished before new things start.
A brief regular retrospective, even fifteen minutes a fortnight, that produces one change to how the team works.
The engineering practices: version control, automated tests, continuous integration, small frequent deploys. These are not optional and they are what let the team change direction without breaking things.
That is the whole process. It fits on a page and it is what ship-small-ship-often means in practice.
What arrives with a framework, and should be refused
Story points and velocity as management metrics, which inflate under observation. Ceremonies attended because the framework has them, producing meetings without decisions. A Scrum master role in a team too small to need one, which becomes a project manager by another name. Detailed sprint commitments treated as contracts, which reintroduces the plan-following that agile was meant to replace. Tooling heavier than the work. And the belief that agile means no documentation, no design and no estimates, which the manifesto does not say and which produces the messes agile gets blamed for.
Working with clients
Clients accustomed to fixed scope and fixed price find agile alarming until they see it: a demonstration every two weeks, the ability to change their minds, and a running product from early on. The arrangement that works is a fixed team for a fixed period with a prioritised scope the client controls, reviews on staging, and honest estimates that are revised as the work reveals itself. The client is the product owner, with real decisions to make at each review, and the team's job is to make those decisions well informed.
The honest summary
Agile for a small team is mostly discipline about the basics: keep the work small, show it often, listen to what comes back, fix how you work, and keep the engineering sound enough that change is cheap. The frameworks are scaffolding for organisations that have lost those habits. A small team that has them does not need the scaffolding, and one that adopts it wholesale usually loses the habits under it. If you would like to see how a fortnightly cadence with staging reviews runs on a real project, book a call; it is how we work with every client.
Common questions
What is agile in simple terms?
Building software in short cycles, delivering working pieces frequently, showing them to real users and stakeholders, and adjusting the plan based on what is learned, rather than specifying everything up front and building to that specification. It comes from a 2001 manifesto of four values and twelve principles; frameworks such as Scrum and Kanban are ways of practising it.
Do small teams need Scrum?
Rarely in full. A small team benefits from Scrum's rhythm, a short cycle ending in a demonstration of working software, and from a retrospective, and can drop the Scrum master role, formal story points and most ceremony. Many small teams prefer Kanban's continuous flow with a weekly priorities review, which keeps the feedback loop with less overhead.
What is the difference between agile and Scrum?
Agile is the set of values and principles about incremental delivery, feedback and responding to change. Scrum is one framework for practising it, with sprints, defined roles and four events. A team can be agile without Scrum, using Kanban or a lighter process, and a team can perform every Scrum ceremony without being agile if it never shows working software or changes course.
How does agile work with a fixed budget?
By fixing the team and the time rather than the scope: the client pays for a defined period of a defined team, controls the prioritised backlog, and reviews working software regularly, so the budget buys the most valuable work in priority order and unfinished lower-priority items are visible rather than hidden. Estimates are given honestly and revised as the work reveals itself.
What are the biggest mistakes small teams make with agile?
Adopting a framework wholesale and running its ceremonies without decisions; treating velocity as a performance metric; skipping the demonstration of working software, which is the mechanism that makes it agile; neglecting the engineering practices such as tests and continuous integration that make change cheap; and believing agile means no design, documentation or estimates.
