What Is Agile? The Meaning, the Manifesto and How Small Teams Use It

Agile is a way of working in which a team delivers in small, usable pieces, shows each piece to the people it is for, and changes the plan based on what it learns. Instead of deciding everything up front and delivering once at the end, you deliver something real in the first week or two and keep adjusting. The word comes from the 2001 Manifesto for Agile Software Development, which sets out four values and twelve principles. Agile itself is not a method with rules; Scrum and Kanban are methods for practicing it.

Agile meaning: three ways to define it

Most confusion about agile comes from people using the word at different levels. Pick the definition that fits who is asking:

• For a manager: agile means you get something you can use every week or two, and you can change your mind about what comes next without derailing the project.
• For the team: agile means one ordered list of work, small pieces that are really finished, and a regular habit of looking at what went wrong and changing it.
• For a customer: agile means you see progress early, your feedback changes what gets built, and you are not surprised at the end.

All three say the same thing from different seats: short cycles, real results, and a plan that listens. If a definition of agile leaves out learning from what you delivered, it has left out the point.

The four values, in brief

The Manifesto for Agile Software Development↗ (opens in a new tab) is short. Its authors wrote that they had 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

It ends with the line that matters most: “That is, while there is value in the items on the right, we value the items on the left more.” Processes, documents, contracts and plans still count. When they get in the way of delivering something that works for the customer, the thing that works wins. Each value, the twelve principles behind them and what each looks like on a task board are in the Agile Manifesto, explained.

Is agile a methodology?

People search for “agile methodology” more than for agile itself, so it is worth being precise. Agile is a set of values and principles, not a process. It names no roles, no meetings and no tools. The methods people usually mean when they say “agile methodology” are the ways of putting those values to work:

• Scrum: the Scrum Guide↗ (opens in a new tab) calls it “a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems,” with Sprints of one month or less. As of September 30, 2026, the 2020 edition is the current guide.
• Kanban: a continuous flow of work with limits on how much is in progress, and no fixed cycles or required roles.
• Scrumban and XP: a hybrid of the two, and a set of engineering practices such as testing first and pairing.

Scrum’s roles, events and artifacts are explained in what is Scrum. Choosing between the methods is its own question: Kanban vs Scrum compares the two, what is Scrumban covers the hybrid, and project management methodologies compared puts the whole family in one table. How a team runs projects day to day in an agile way is in agile project management.

What agile is not

Agile gets blamed for a lot of things it never asked for. The Manifesto’s own history page↗ (opens in a new tab), written by Jim Highsmith for the authors, heads off most of them: “The Agile movement is not anti-methodology, in fact, many of us want to restore credibility to the word methodology.”

• Not “no plan.” The same page says “We plan, but recognize the limits of planning in a turbulent environment.” An agile team plans a little ahead, often, instead of all at once.
• Not “no documentation.” It says “We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes.” Write what someone will read.
• Not a set of meetings. A team can hold every standup and retrospective and still deliver once a quarter. The meetings are there to support small deliveries, not to replace them.
• Not a promise of speed. Agile finds out sooner when you are building the wrong thing. That saves time over a project, but a single feature does not get built faster.
• Not only for software startups. The US government’s Digital Services Playbook, written to help government build digital services, tells teams to build the service using agile and iterative practices↗ (opens in a new tab), shipping a minimum viable product “no longer than three months from the beginning of the project.”
• Not the opposite of every fixed plan. Some work really is better planned up front; agile vs waterfall covers when.

An example: one small team’s first two weeks

Here is agile at its smallest. A bakery in Austin wants online cake preorders, and a team of three builds it: the owner, a part-time developer and the counter manager. Instead of specifying the whole ordering system, they write one goal and ask what the thinnest useful version is. This is their board at the end of week one:

Goal: a customer can preorder a cake for pickup without calling the store.

Completed    FET-1  Menu page with this week's five cakes
In Progress  FET-2  Order form: one cake, name, phone number
Next Up      FET-3  Pick a pickup day and time
             BUG-4  Menu photos load slowly on phones
To Do        FET-5  Pay a deposit online
             ENH-6  Text reminder the day before pickup
             FET-7  Loyalty points

In week two, FET-2 and FET-3 are finished and the counter manager tells ten regular customers about the page. Four order. Three of them phone anyway to ask for a message written on the cake. So a new task, “Add a message for the cake,” goes straight to the top of Next Up, and loyalty points drop to the bottom, because nobody asked. That reordering, based on what real customers did, is what agile means. The first version took two weeks, not two months, and the team learned the most important missing feature from people using it.

A small-team version you can start Monday

You do not need to adopt a framework, hire a coach or buy anything to try this. Hold one hour-long meeting on Monday, then keep five habits for a month.

10 min  Write the goal in one sentence a customer would understand.
15 min  List everything you might do toward it. One line each.
10 min  One person orders the list. Everyone else argues, then stops.
15 min  Find the thinnest first version someone outside the team can use
        within two weeks. Everything else waits.
10 min  Agree what "done" means for a task, and when you will show it.

1. Keep one ordered list, and one person who orders it. If everyone can reorder it, nobody does.
2. Pull from the top. When someone is free, they take the next task, not the most interesting one.
3. Finish before you start. Help get a task to done before opening a new one.
4. Show it. Every week or two, put what is finished in front of someone it is for, and write down what they said.
5. Change one thing. At the end of each week, pick one thing about how you work to do differently, and write it down.

If the list grows long and the order stops making sense, a user story map lays the work out by what users do, so you can see which small slice to build first. When a month is up and you want a fuller rhythm, with a weekly planning slot and a one-page working agreement, agile project management has one.

Running it on fenbs

fenbs is a simple task board shared by people and AI assistants, and its four lanes fit the habits above: To Do is the ordered list, Next Up is what you pull next, In Progress is what is being worked on, and Completed is what you show. Every task is a feature, an enhancement or a bug, with a priority from 1 to 10, a plan, and a test status with test notes, so “done” has a place to be written. Add many pastes the list from your Monday meeting in as tasks, and Copy as Markdown copies the board as text for the show-and-tell.

The “done means” line and your one change a week belong on the Decisions and rules page: a person decides each rule, and every connected AI assistant reads the rules before it starts. History records who moved what. Be clear about what is missing: fenbs has no sprints, no due dates and no WIP limit setting. A limit is a rule the team writes down and keeps, not something the board enforces.