Agile and Kanban for NGOs: When Flexible Delivery Works (and When It Doesn’t)

“We need to be more agile” is a phrase heard in many NGO offices, often after a project plan has collided with reality. But what does it mean in practice, and does it fit organisations accountable to donors, boards and communities for agreed results? This article takes a balanced look at agile for NGOs: what the main methods actually involve, where they genuinely help, where a traditional planned approach is safer, and how to combine the two.

What agile actually means

Agile is not a single method but a family of approaches that grew out of software development. The Manifesto for Agile Software Development, published in 2001, set out four value statements: individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; and responding to change over following a plan. Importantly, the manifesto says that while there is value in the items on the right, its authors value the items on the left more. Agile does not reject plans, documentation or contracts.

Translated for NGOs, the underlying ideas are:

• Deliver value in small, usable increments rather than one big release at the end.
• Get frequent feedback from the people you serve and adjust accordingly.
• Plan in detail only for the near term; keep the longer-term plan at a higher level.
• Make work and its progress visible to the whole team.
• Reflect regularly on how the team works, and improve it.

These ideas overlap with what the development sector often calls adaptive management: designing programmes that can learn and change course as evidence emerges.

Scrum in a nutshell

Scrum organises work into fixed-length cycles called sprints, typically two to four weeks long. It defines three accountabilities: a product owner, who decides priorities; a Scrum master, who helps the team follow the process and removes obstacles; and the developers, meaning the people who do the work, whatever their discipline. Each sprint has a planning session, a short daily check-in, a review where results are shown to stakeholders and a retrospective where the team improves its way of working. Work waits in a prioritised product backlog until it is pulled into a sprint.

Scrum works best when a team is building something that can be delivered in pieces, such as a website, a database, a mobile app, an e-learning course or a new service, and when the team can protect its time for the length of a sprint.

Kanban in a nutshell

The Kanban method, as developed for knowledge work by David J. Anderson and others, is gentler. It starts from what you do now and improves it gradually. Its core practices are:

1. Visualise the work on a board, with columns for each stage of your workflow and a card for each item.
2. Limit work in progress (WIP) by setting a maximum number of cards in each active column.
3. Manage flow: watch how long items take and where they get stuck.
4. Make policies explicit, such as what “ready for review” means.
5. Use regular feedback loops, such as short daily stand-ups and periodic reviews.
6. Improve collaboratively, making small, evidence-based changes.

There are no prescribed roles or sprints. That makes Kanban particularly suited to teams that deal with a continuous stream of varied requests, such as communications, fundraising, finance or programme support.

Worked example: a communications team Kanban board

Imagine the three-person communications team of a mid-sized environmental NGO. They handle press releases, social media, donor newsletters, the annual report, campaign materials and an endless stream of “quick favours” from colleagues. Everything feels urgent and nothing seems to finish.

They set up a board with these columns and WIP limits:

Column	Meaning	WIP limit
Requests	Every incoming request, unprioritised	None
Ready	Prioritised, with a clear brief, deadline and approver	6
Drafting	Being written or designed	3 (one per person)
Review	With a colleague or subject expert for checking	3
Approval	With the director or partner for sign-off	3
Scheduled	Approved and queued for publication	None
Done	Published or delivered	None

Within a few weeks, the board reveals the real bottleneck. The approval column is always full, with items waiting days for sign-off, while the team starts new drafts to stay busy, which only adds to the pile. Because the WIP limit stops them pulling more work into drafting, the problem becomes visible and discussable. The team agrees an explicit policy with the director: routine social media posts no longer need director sign-off, and a fixed fifteen-minute approval slot is held twice a week for everything else. Lead times fall and the “quick favours” now queue visibly in the requests column, where they can be prioritised against everything else.

Where agile for NGOs works well

• Digital products: websites, donor databases, apps, beneficiary feedback platforms and online courses.
• Communications and campaigns, especially rapid-response advocacy where the agenda changes weekly.
• Fundraising pipelines: tracking grant proposals or major donor approaches from idea to submission.
• Innovation and pilots: testing a new service model with small groups before scaling.
• Monitoring, evaluation and learning teams handling many small analysis and reporting requests.
• Support functions such as IT, HR or finance with steady flows of requests.

What these have in common is that requirements are uncertain or changing, work can be delivered in pieces, and early feedback is valuable.

Where a planned approach is safer

• Construction and infrastructure: you cannot iterate on half a borehole. Sequence, technical standards and procurement rules matter more than frequent change.
• Fixed-date events: a conference, a distribution or a training course with a fixed date is better scheduled with a work breakdown structure and critical path.
• Heavily regulated or contract-bound work, where scope, budget lines and deliverables are fixed by the grant agreement and changes require formal approval.
• Safety-critical activities, such as security operations or medical procedures, where agreed procedures must be followed every time.
• Large procurement with tendering rules that require full specifications up front.

Question	Leans towards agile	Leans towards planned
Are requirements clear and stable?	No, they will emerge	Yes, well defined
Can the work be delivered in usable pieces?	Yes	No, only valuable when complete
How costly is a change late in the work?	Low	High
Can users give frequent feedback?	Yes	Rarely
Does the contract fix detailed deliverables?	Outcomes fixed, detail flexible	Detail fixed
Is a stable team available?	Yes, dedicated	Shifting, part-time or contracted

The hybrid approach most NGOs end up with

In practice, many NGOs combine approaches. The logframe, budget and high-level schedule provide the fixed frame agreed with the donor: the outcome, the main outputs, the end date and the money. Inside that frame, individual workstreams can be managed flexibly. A livelihoods programme might use a critical path schedule for procurement and training events, while its digital marketplace component is built in two-week sprints and its communications team runs a Kanban board.

To make a hybrid work:

• Agree which elements are fixed (outcome, budget ceiling, contractual deliverables, compliance rules) and which can flex (specific activities, sequencing, features).
• Build regular learning moments into the plan, such as quarterly reviews, where evidence is used to adjust activities.
• Keep a change log so that you can explain to auditors and donors what changed, when and why.
• Translate sprint or Kanban progress into the language of your donor reports: outputs delivered, indicators moved, lessons learned.

Talking to donors about flexible delivery

Some donors actively encourage adaptive management; others are more cautious. Either way, describe your approach in terms of results and accountability, not jargon. Explain how you will decide what to change, who approves changes, how they will be documented and how the donor will be informed. Propose budget flexibility within the rules of the grant, and show that your monitoring system will provide the evidence for each adjustment. A well-reasoned, transparent approach is far more persuasive than a request to “be agile”.

How to tell whether it is working

Agile methods should earn their place with evidence, not enthusiasm. A few simple measures, tracked from the start, will tell you whether flow is improving:

• Lead time: how long an item takes from request to done. Falling lead times usually mean less waiting.
• Throughput: how many items the team finishes each week or sprint.
• Blocked items: how many cards are stuck, for how long, and why.
• Stakeholder satisfaction: a quick check with colleagues, partners or users on whether they are getting what they need sooner.

Review these at each retrospective and use them to decide what to change next, rather than relying on impressions.

Common mistakes

• Agile as an excuse for no plan. Flexible teams still need clear goals, priorities and deadlines.
• Adopting ceremonies without the purpose. A daily stand-up that becomes a thirty-minute status report helps nobody.
• No WIP limits. A Kanban board without limits is just a colourful to-do list.
• No real product owner. If priorities are set by whoever shouts loudest, the backlog becomes meaningless.
• Ignoring the contract. Changing activities that the grant agreement fixes, without approval, can create eligibility problems.
• Forcing agile onto unsuitable work. Construction, fixed-date events and tendering usually benefit more from careful upfront planning.

A two-week starter plan

1. Choose one team with a steady flow of varied work, such as communications or grants.
2. Map how work currently flows, from request to completion, and turn the stages into board columns.
3. Put every current piece of work on the board as a card, including the “quick favours”.
4. Agree initial WIP limits, roughly one or two items per person in each active column.
5. Hold a fifteen-minute stand-up each morning around the board, focusing on blocked items.
6. After two weeks, hold a retrospective: what improved, what got stuck, what will you change?

Choosing the right delivery approach starts with solid project foundations, which our Project Management Fundamentals workshop provides. For scheduling, change requests and resource optimisation, see Advanced Project Management Tools & Techniques. Want help setting up a board for your own team? Our small-group coaching can get you started, or contact us to talk it through.