Agile Project Management for Small Teams, Without the Jargon

Agile project management is a way of running work in short cycles: you deliver something usable early, show it to the people it is for, and change the plan based on what you learn, instead of fixing the whole plan up front and delivering once at the end. It comes from the 2001 Agile Manifesto, which values people, working results, customer collaboration and responding to change. Scrum and Kanban are the two best-known ways to practice it. For a small team you need less than either one’s full rulebook: one ordered list of work, a short weekly planning conversation, a habit of finishing before starting, and a regular look back at what to change.

Where agile comes from

According to the Manifesto’s own history page↗ (opens in a new tab), seventeen people met on February 11-13, 2001, at The Lodge at Snowbird ski resort in Utah, looking for common ground between the lightweight software methods they each practiced.

What they agreed on fits in four lines. The Manifesto for Agile Software Development↗ (opens in a new tab) says they have 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.

The sentence after the list is the one people forget: “while there is value in the items on the right, we value the items on the left more.” Agile does not throw away plans, documents or contracts. It says that when they conflict with delivering something that works for the customer, the working result wins.

The principles, translated for any team

The Manifesto comes with twelve principles↗ (opens in a new tab) written for software, but most of them carry over to any team that makes things for other people. Six do most of the work on a small team:

• Deliver early and often. The principle says “from a couple of weeks to a couple of months, with a preference to the shorter timescale.” For a small team, aim for something a customer can see every week or two.
• Welcome changing requirements, even late. A plan that cannot change is a guess you have committed to.
• Business people and the people doing the work talk daily. Not through a ticket system and a handoff document, but directly.
• Working results are the primary measure of progress. Not hours logged, tasks opened or slides presented.
• Simplicity, “the art of maximizing the amount of work not done,” is essential. The best way to finish sooner is to build less.
• At regular intervals, reflect on how to become more effective, and adjust. This is the principle most teams skip, and the one that makes the others improve.

The agile approach vs traditional project management

Traditional, plan-driven project management, often called waterfall, works through phases in order: gather all the requirements, design, build, test, deliver. It suits work where the result is well understood up front and change is expensive, such as a building, a regulated system with a fixed specification, or a contract with a fixed scope. The agile approach works in repeated small cycles, each producing something usable. It suits work where nobody knows the right answer yet: a new product, a feature customers have not tried, anything where the first version will teach you what the second should be.

Many small teams end up in between: a rough plan with a few dated milestones, delivered in small agile cycles. That is a reasonable place to be. The mistake is using the word “agile” to mean “no plan.”

Scrum and Kanban, in one line each

• Scrum: the Scrum Guide↗ (opens in a new tab) sets fixed Sprints of a month or less, with a Product Owner, a Scrum Master and Developers, and set events for planning, a daily check, review and retrospective.
• Kanban: the Kanban Guide↗ (opens in a new tab) defines a strategy for optimizing the flow of value by visualizing the workflow, actively managing the items in it and improving it, with no required roles or meetings.

Which suits your team is its own question, answered in Kanban vs Scrum. The hybrid is covered in what is Scrumban, and the Scrum roles in what does a Scrum Master do and product owner vs project manager.

A light cadence for a team of two to ten

You do not need to adopt a framework to work in an agile way. This weekly rhythm covers the principles above in about two hours of meetings a week:

1. Keep one ordered list. Everything the team might do goes on it, and one named person decides the order. If two people can reorder it, nobody can.
2. Monday, 30 minutes: plan the week. Pick the few items you expect to finish from the top of the list, and say what “done” means for each. Agree what the week is for in one sentence.
3. Every day, five minutes or a written note: what moved, what is stuck, who needs help. Skip it on days when the board already says all of that; daily standup covers when to skip.
4. Finish before you start. When someone is free, they help finish an item in progress before pulling a new one. Kanban WIP limits explains why this matters more than any meeting.
5. Friday, 30 minutes: show and reflect. Show what was finished to someone who asked for it, then spend ten minutes on one thing to change next week. Write the change down.
6. Once a month: look further ahead. Reorder the whole list, drop what no longer matters, and check it still points at the goals you care about.

Order of work:    one list, ordered by Dana; ask Dana to change it
Planning:         Monday 10:00, 30 min
Check-in:         written, by 10:00 each day, in the team chat
In progress:      at most 2 items per person
Done means:       tested, deployed, customer told
Review + retro:   Friday 3:00, 30 min; one change per week

Keep it for two months before judging it. The cadence improves itself through the Friday reflection, and it takes a few weeks to show.

Advantages of agile project management, and its limits

The advantages follow from the principles. You find out you are building the wrong thing after a week, not after a quarter. Customers see progress, so they trust the team and give better feedback. Less work is wasted on features nobody uses, because the list is reordered as you learn. And problems in how the team works surface at every retrospective rather than at the post-mortem.

The limits are real too. Agile needs someone who can decide the order of work and is available to do it; without them, short cycles just deliver the wrong things faster. It fits awkwardly with fixed-price, fixed-scope contracts, where the customer has already paid for a specific result. And a team that holds all the meetings but never ships in small pieces has the cost of agile without the benefit.

When some of the team are AI assistants

Short cycles suit AI assistants well: a clear, small task with a written definition of done is exactly what an assistant does best. Two things need care. An assistant will start many things at once unless a limit is written down, and it cannot judge whether its own work is really finished, so a person should check before an item counts as done. Kanban for AI agents and how to write a task for an AI agent cover both.

Running this cadence on fenbs

fenbs is a simple task board built for this kind of light agile work, shared by people and AI assistants. Its four lanes map onto the cadence directly: To Do is the ordered list, Next Up is this week’s plan, In Progress is what is being worked on, and Completed is what you show on Friday. Each task is a feature, an enhancement or a bug, with a priority from 1 to 10 and a plan, a test status and test notes, so “done means” has a home. Add many lets you paste a list from a planning meeting in as tasks, and Copy as Markdown copies the board as text for the Friday review.

The working agreement belongs on the Decisions and rules page: each item is a rule decided by a person, and every connected AI assistant reads the rules before it starts. History shows who moved what, which is what the monthly look-back needs. Be clear about the gaps: fenbs has no sprints, no WIP limit setting, no due dates and no burn-down charts. A limit is a rule you write down, not a setting the board enforces.