Am 21. Januar 2026 fand das Online-Seminar „Agil zum Ziel – Projektmanagement für NGOs“ im Rahmen der Reihe NGOplus statt. In dieser Veranstaltung mit ca. 120 Teilnehmenden drehte sich alles darum, wie gemeinnützige Organisationen mit agilen Methoden effektiver und flexibler Projekte managen können. Dieser Nachbericht fasst die wichtigsten Erkenntnisse praxisnah zusammen – von typischen Problemen traditioneller Projektplanung über das Wesen von Agilität bis hin zu konkreten Methoden (Scrum, Kanban) und Tipps für den Einstieg ins agile Arbeiten. Ziel ist es, NGO-Praktiker*innen zu inspirieren, agile Ansätze auszuprobieren, um letztlich Projekte mit mehr Wirkung umzusetzen.
Anmerkung der Redaktion
Agilität bringt neue Begriffe mit sich – von Scrum über Sprint bis Product Canvas. Diese stammen meist aus der IT‑ und Wirtschaftswelt, lassen sich aber gut auf den Arbeitsalltag von NGOs übertragen.
Dieser Text nutzt bewusst die üblichen Fachbegriffe, um die Konzepte korrekt darzustellen. Um den Zugang zu erleichtern, haben wir ein Glossar erstellt, das zentrale Begriffe nicht nur erklärt, sondern auch in einfacher Sprache übersetzt und mögliche Alternativen für die interne Nutzung vorschlägt: etwa statt „Sprint“ den Begriff „Zwei-Wochen-Rhythmus“ oder statt „Product Owner“ einfach „Verantwortliche*r fürs Ziel“.
Das Glossar soll als Orientierungshilfe dienen. Falls ein Begriff unklar bleibt, lohnt sich ein Blick dorthin oder eine weiterführende Recherche. Wichtig ist ohnehin nicht, wie man es nennt, sondern dass es funktioniert.
Sprint (Arbeitsphase / Etappe / Projektabschnitt)
Ein kurzer, klar abgegrenzter Arbeitsabschnitt (oft 1–2 Wochen). Am Ende steht ein sichtbares Zwischenergebnis.
Sprint Planning (Arbeitsplanung / Etappenplanung)
Planungstreffen zu Beginn der Arbeitsphase.
Team und Zielverantwortliche legen Ziel und Aufgaben für die Etappe fest.
Daily Scrum (Tagesabstimmung / Kurzabstimmung)
Kurzes tägliches Abstimmungstreffen im Team (meist 10–15 Minuten). Alle synchronisieren den Stand und benennen Hindernisse.
Sprint Review (Ergebnisbesprechung / Zwischenbilanz)
Treffen am Ende der Arbeitsphase zur Sichtung der Ergebnisse. Rückmeldungen von Beteiligten helfen, die nächsten Schritte zu schärfen.
Sprint Retrospective (Rückblick / Reflexionsrunde / Lernrunde)
Interne Teamrunde zur Verbesserung der Zusammenarbeit. Was lief gut, was bremst uns, was ändern wir konkret ab der nächsten Etappe?
Backlog Refinement (Aufgabenpflege / Aufgabenklärung / Priorisierung)
Regelmäßiges Durchgehen und Schärfen der Aufgabenliste. Aufgaben werden verständlicher, kleiner, besser priorisiert und umsetzbar gemacht.
Product Backlog (Aufgabenliste / Projektliste / Vorhabenliste)
Zentrale, priorisierte Sammlung aller Anforderungen und Ideen. Dient als „Quelle“ für die Planung der nächsten Etappen.
Sprint Backlog (Arbeitsplan / Etappenplan)
Die Aufgaben, die für die aktuelle Arbeitsphase ausgewählt wurden. Damit steuert das Team, was in dieser Etappe konkret umgesetzt wird.
Increment (Arbeitsergebnis / Zwischenergebnis)
Das am Ende einer Etappe fertiggestellte Ergebnis.
Es ist so weit „fertig“, dass es genutzt, gezeigt oder getestet werden kann.
User Story (Nutzungsanforderung / Anforderung)
Kurze Beschreibung eines Bedarfs aus Sicht der Nutzer*innen. Hilft, Aufgaben an Nutzen und Zielgruppen auszurichten.
Definition of Done (Erledigt-Kriterien / Qualitätskriterien)
Gemeinsame Vereinbarung, wann etwas wirklich „fertig“ ist. Schafft klare Qualität und verhindert halbfertige Ergebnisse.
Agile (beweglich / anpassungsfähig / flexibel)
Arbeitsweise, die Lernen und Reaktion auf Veränderung ermöglicht. Planung und Umsetzung passieren in kurzen Zyklen mit regelmäßiger Anpassung.
Iteration (Wiederholungsrunde / Arbeitszyklus)
Eine wiederkehrende Schleife aus Planen, Umsetzen und Auswerten. So wird das Ergebnis Schritt für Schritt besser und passender.
Timebox (fester Zeitrahmen)
Eine Aktivität hat ein klares Zeitlimit (z. B. Meeting = 15 Minuten). Das erhöht Fokus und sorgt für Tempo statt Endlosrunden.
Commitment (Verbindlichkeit)
Gemeinsame Zusage, wofür das Team in einer Etappe steht. Heißt nicht „Überlastung“, sondern klare Zuschnitte und Prioritäten.
Transparency (Offenheit / Transparenz)
Alle sehen, woran gearbeitet wird und wie der Stand ist. Das schafft Vertrauen und macht Entscheidungen nachvollziehbar.
Inspection (Überprüfung)
Regelmäßiges Hinsehen: Passt der Kurs noch? Stimmen Qualität und Fortschritt? Probleme werden früh erkannt, nicht erst am Projektende.
Adaptation (Anpassung / Weiterentwicklung)
Konsequenzen aus der Überprüfung ziehen und den Plan anpassen. So bleibt das Projekt realistisch und wirksam, auch wenn sich Bedingungen ändern.
Velocity (Arbeitsgeschwindigkeit / Umsetzungstempo)
Orientierungswert dafür, wie viel ein Team pro Etappe schafft.
Dient der Planung – nicht als Leistungsdruck oder Vergleich zwischen Teams.
Wenn der perfekte Plan scheitert – Probleme klassischer Projektlogik in NGOs
Gleich zu Beginn der Veranstaltung wurde deutlich, warum klassische Projektplanung in einer dynamischen Welt an Grenzen stößt. Anhand einer Fallgeschichte der fiktiven NGO „GrünWandel e.V.“ zeigte sich: selbst ein perfekter Plan ist kein Garant für Erfolg, sondern kann im Gegenteil zum Stolperstein werden.
Im Januar startet das GrünWandel-Team hochmotiviert in eine neue Kampagne zum Thema „Flächenversiegelung stoppen“. Es gibt ein ausführliches Kick-off-Meeting, alle Inhalte und Meilensteine für zwölf Monate sind akribisch geplant. Das Team fühlt sich erleichtert: Endlich gibt es einen detaillierten Fahrplan mit klaren Zielen, einem Gantt-Diagramm, fixem Budget und Kommunikationsplan bis Dezember. „Wenn wir nur konsequent unseren Plan einhalten, kann nichts schiefgehen“, lautet das Credo. Der Plan vermittelt Sicherheit, Ordnung und Kontrolle. Was soll da noch passieren?
Doch bereits im März klopft die Realität an: Eine neue Studie und öffentliche Debatte rücken plötzlich das Thema Hitzeschutz in Städten in den Mittelpunkt. Die sorgfältig geplante GrünWandel-Kampagne droht an Relevanz zu verlieren. Die Kommunikationsreferentin merkt im Teammeeting an, dass überall nur noch über Hitze und Stadtklima gesprochen wird, während das eigene Thema kaum Aufmerksamkeit hat. Trotzdem entscheidet sich das Team, am ursprünglichen Kurs festzuhalten: Man habe das Thema doch fachlich sauber hergeleitet und könne jetzt nicht einfach alles umwerfen. Schließlich sei man schon mitten in der Umsetzung. Der schöne Plan bleibt also unverändert bestehen, obwohl das Umfeld sich gewandelt hat.
Im Mai zeigen sich erste Risse: Ein wichtiger Kooperationspartner steigt aus dem Projekt aus und die Zusage für eine zweite Fördertranche steht noch aus. Zudem verliert das Ehrenamts-Team zunehmend den roten Faden: Einige Freiwillige fragen sich, wofür wir das eigentlich gerade machen, wenn sich der Kontext so verändert hat. Die Stimmung ist angespannt. Dennoch reagiert die Projektleitung nach dem Motto: Jetzt bloß keine Panik, wir müssen umso strikter am Plan festhalten, sonst verlieren wir komplett die Übersicht. Mit anderen Worten: Die Unsicherheit wird mit noch mehr Kontrolle beantwortet.
Im Juli läuft die Kampagne schließlich. Allerdings mit enttäuschenden Ergebnissen. Die geplanten Social-Media-Posts erreichen weit weniger Menschen als üblich, die Resonanz bleibt aus. „Es ist halt Sommerloch, das wird schon“, tröstet man sich. Doch insgeheim ahnen einige Teammitglieder, dass das Problem tiefer liegt: Vielleicht passt das gewählte Kampagnenthema einfach nicht mehr zur aktuellen öffentlichen Debatte. Trotzdem fühlt sich das Team gefangen im eigenen Korsett: „Wir können das jetzt nicht mehr ändern: Flyer sind gedruckt, Termine stehen, Inhalte vorbereitet. Also ziehen wir es durch.“ So läuft die Kampagne weiter ihrem wenig wirkungsvollen Ende entgegen.
Erst im September, als der Frust groß ist, stellt eine neue Kollegin namens Gerda die entscheidende Frage: „Warum verteidigen wir unseren Plan so sehr? Geht es nicht eigentlich darum, Wirkung zu erzielen, statt recht zu behalten?“ Dieser Satz lässt das Team innehalten. Gerda findet ein treffendes Bild: „Wir arbeiten an unserer Kampagne wie an einem Bauprojekt. Dabei verändert sich um uns herum doch ständig die Gesellschaft.“ Diese Erkenntnis sitzt. Den GrünWandel-Leuten wird klar, dass ihr rigoroser Planungsansatz sie unbeweglich gemacht hat. Der wichtige Wendepunkt: Anstatt stur einen überholten Plan abzuarbeiten, muss die Organisation lernen, flexibler auf Veränderungen zu reagieren, ohne das Ziel aus den Augen zu verlieren.
Die GrünWandel-Geschichte verdeutlichte typische Probleme klassischer Projektlogik:
- Trügerische Sicherheit durch Planung: Ein langfristiger Plan gibt vermeintlich Halt, kann aber Scheinsicherheit erzeugen. Wenn man sich zu sehr an einen Plan klammert, wird er zum Selbstzweck. Man folgt dem Plan um des Plans willen und verliert das eigentliche Wirkungsziel aus dem Blick.
- Unflexibel bei Veränderungen: Gesellschaftliche oder organisationsinterne Rahmenbedingungen ändern sich oft schneller als gedacht (neue Trends, politische Entwicklungen, Partner springen ab, Finanzierungslücken etc.). Starre Pläne lassen wenig Raum, darauf zu reagieren. Chancen können verpasst und Risiken nicht rechtzeitig entschärft werden.
- Motivationsverlust im Team: Wenn Freiwillige und Mitarbeiter*innen merken, dass ihre Arbeit ins Leere läuft oder an der Realität vorbeigeht, schwindet die Motivation. Klassisches Projektmanagement bietet selten Räume, das Vorgehen grundsätzlich zu hinterfragen oder anzupassen. Die Folge: Frust macht sich breit.
- Kontrollillusion statt Lernen: Nach klassischer Logik versucht man Probleme durch noch strengere Kontrolle zu beheben („noch enger am Plan bleiben“). Doch das kuriert nicht die Ursache, sondern verschließt die Augen vor nötigen Kurskorrekturen. Lernen aus Erfahrung findet kaum statt, weil Abweichungen als Scheitern interpretiert werden und nicht als Chance zur Verbesserung.
Die Konsequenz: In einem komplexen, sich wandelnden Umfeld, und genau das ist der Alltag vieler NGOs, stößt rigide Planung an ihre Grenzen. Stattdessen braucht es einen Ansatz, der auf Veränderung vorbereitet ist, Lernschleifen zulässt und das Team befähigt, frühzeitig gegenzusteuern. Genau hier kommt das agile Projektmanagement ins Spiel.
Was bedeutet Agilität wirklich? – Haltung statt Methode
Angesichts der geschilderten Probleme wird klar: Die Lösung liegt nicht einfach in einer neuen Projektmanagement-Methode, sondern vor allem in einer veränderten Haltung. Oft wird „agil“ mit bestimmten Tools oder Prozessen gleichgesetzt (z. B. Daily Stand-ups, Scrum Boards). Doch der Kern von Agilität ist ein Mindset, das auf kontinuierliches Lernen und Anpassen setzt. Agilität bedeutet: offen für Neues sein, Mut haben zum Ausprobieren und bereit sein, aus Fehlern zu lernen.
Im Fall von GrünWandel e.V. hieß das Umdenken: Vielleicht ist nicht zu wenig Planung unser Problem, sondern die Illusion, wir könnten alles im Voraus planen. Agile Haltung bedeutet, Unsicherheit anzuerkennen und als gegebenen Zustand zu akzeptieren. Statt monatelang in Stein zu meißeln, was passieren soll, fragt ein agiles Team: „Was ist jetzt gerade der beste nächste Schritt, um unserer Vision näherzukommen?“ Man plant also kurzfristiger, probiert bewusst etwas aus, schaut sich die Resultate an und justiert dann den Kurs.
Dieses Vorgehen folgt dem einfachen, aber effektiven PDCA-Zyklus (Plan – Do – Check – Act), dem Herzstück agilen Arbeitens:
- Plan (Planen): Formuliere eine Annahme oder Hypothese. Was glauben wir, erreicht eine bestimmte Maßnahme? (Beispiel: „Wir glauben, dass wir mit kurzen Social-Media-Videos jüngere Unterstützer gewinnen.“)
- Do (Tun): Führe einen kleinen Test durch. Statt gleich die ganze Jahreskampagne umzukrempeln, setzt man einen Pilot oder Prototyp um, z. B. einen einzelnen Video-Post als Experiment oder eine Mini-Aktion im kleinen Rahmen.
- Check (Überprüfen): Schau ehrlich auf die Ergebnisse. Was ist wirklich passiert? Kommen die Videos an? Wie ist das Feedback der Zielgruppe? Hier ist wichtig, tatsächlich hinzuschauen, selbst wenn das Ergebnis anders ausfällt als erhofft.
- Act (Anpassen): Ziehe Konsequenzen aus den Erkenntnissen. Hat die Idee gezündet, wird sie beibehalten oder ausgeweitet. Wenn nicht, wird die Maßnahme angepasst oder verworfen. Dann beginnt der Zyklus von vorn mit einer neuen Annahme.
Anstatt also ein Jahr lang blind einen Plan durchzuziehen und erst am Ende zu merken, dass man am Ziel vorbeigeschossen ist, sorgt der PDCA-Ansatz für permanente kleine Kurskorrekturen. Agilität heißt nicht, ins Chaos zu stürzen: Agil heißt, häufiger zu entscheiden, schneller zu lernen und früher zu korrigieren. Genau das betonte Gerda im GrünWandel-Beispiel: Agil zu arbeiten bedeutet nicht weniger Planen, sondern anders Planen – mit der Bereitschaft, Pläne regelmäßig zu hinterfragen und auf Wirkung hin zu optimieren.
Entscheidend ist dabei die Teamkultur. Agile Organisationen fördern ein Umfeld, in dem Feedback willkommen ist, Experimente erlaubt sind und Fehler als Lernchancen gelten. Hierarchien treten zugunsten von mehr Eigenverantwortung zurück: Teams organisieren sich weitgehend selbst, immer orientiert am gemeinsamen Ziel. Führungskräfte agieren mehr als Coaches denn als Anweiser. Kurz: Agilität ist eine gemeinsame Haltung, ständig besser werden zu wollen, und das im Sinne der Sache, für die die NGO steht.
Das agile Dreieck: Werte, Prinzipien und Methoden
Das agile Mindset besteht aus drei Ebenen, die wie ein Dreieck aufeinander aufbauen. Siehe Abbildung 1 „Agiles Dreieck“. Am Fundament stehen Werte, darauf aufbauend Prinzipien und an der Spitze Methoden. Je stärker die Werte und Prinzipien verankert sind, desto wirkungsvoller greifen die gewählten Methoden. Es zeigt, dass Agilität weit mehr ist als das Befolgen bestimmter Prozesse. Erst wenn Werte und Prinzipien im Team verankert sind, entfalten agile Methoden ihre volle Kraft.
- Werte (Fundament): Das agile Manifest betont vier Grundwerte: Menschen und Zusammenarbeit sind wichtiger als starre Prozesse und Werkzeuge; Arbeitsresultate bzw. Wirkung zählen mehr als perfekte Dokumente; Zusammenarbeit mit der Zielgruppe steht über formalen Vertragsverhandlungen; und das Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans. Diese Werte dienen als Leitstern. Sie geben Orientierung, wenn Unsicherheit herrscht und Entscheidungen getroffen werden müssen.
- Prinzipien (Mitte): Aus den Werten leiten sich Prinzipien ab, die das tägliche Handeln prägen. Dazu gehören unter anderem: früh und regelmäßig Nutzen liefern, Veränderungen willkommen heißen und positiv nutzen, kontinuierlich reflektieren und verbessern, interdisziplinär zusammenarbeiten sowie Selbstorganisation vertrauen. Sie richten den Blick auf das Wesentliche: ständiges Lernen, kurze Feedbackzyklen und die Stärkung von Teamverantwortung.
- Methoden (Spitze): Auf dieser Basis lassen sich verschiedene Methoden wählen, die zur jeweiligen Situation passen. Bekannte Beispiele sind Scrum (Selbstorganisation in kurzen Sprints), Kanban (Arbeit sichtbar machen und den Fluss steuern), Design Thinking (nutzerzentrierte Problemlösung) oder Soziokratie (gleichberechtigte Entscheidungsfindung). Diese Werkzeuge sind flexibel einsetzbar. Sie dürfen jedoch nicht zum Selbstzweck werden, sondern sollen die zuvor genannten Werte und Prinzipien unterstützen.
Agile Methoden im Vergleich: Scrum und Kanban im NGO-Kontext
Agilität als Haltung manifestiert sich häufig in konkreten Methoden oder Frameworks. Zwei der bekanntesten Ansätze sind Scrum und Kanban. Beide stammen ursprünglich aus der Software- und Industriewelt, lassen sich aber erfolgreich auf NGOs und soziale Projekte übertragen. Wichtig ist zu verstehen, worin sich Scrum und Kanban unterscheiden und wann welche Methode Sinn ergibt.
Scrum (aus dem Rugby entlehnt, bedeutet „Gedränge“) ist ein Rahmenwerk, das iterative Entwicklungszyklen nutzt, um komplexe Aufgaben Schritt für Schritt zu bewältigen. Statt einen detaillierten Gesamtplan zu verfolgen, arbeitet ein Scrum-Team in kurzen Abschnitten, sogenannten Sprints (oft 1–4 Wochen). Am Anfang jedes Sprints plant das Team, was es bis Sprint-Ende erreichen will, am Ende wird das Erreichte überprüft und Feedback eingeholt. So entsteht eine schnelle Lernschleife: Hypothese → Umsetzung → Feedback → Anpassung – genau der PDCA-Gedanke in der Praxis. Siehe Abbildung 2 „Scrum“.
Ein Scrum-Team besteht aus klar definierten Rollen:
- Der Product Owner übernimmt die Verantwortung für die inhaltliche Ausrichtung des Projekts. In NGOs könnte man sagen: er/sie vertritt die Wirkungsperspektive. Der Product Owner priorisiert, welche Aufgaben den größten Wert bzw. Wirkung bringen und als Nächstes angegangen werden.
- Der Scrum Master fungiert als Prozessbegleiter oder Coach. Er achtet darauf, dass die Scrum-Regeln eingehalten werden und das Team produktiv arbeiten kann. In der Praxis moderiert der Scrum Master Meetings, beseitigt Hindernisse und schützt das Team vor Überlastung.
- Das Entwicklungsteam (bei NGOs einfach das Projektteam) erledigt die inhaltliche Arbeit. Wichtig: Das Team organisiert sich weitgehend selbst. Es entscheidet gemeinsam, wie viel es im Sprint schaffen kann und wie die Aufgaben umgesetzt werden. Alle Teammitglieder ziehen an einem Strang.
Scrum besteht aus festen Artefakten: Sie dienen dazu, die Arbeit nachvollziehbar zu machen und den Fortschritt messbar zu halten. Sie unterstützen das Team dabei, sich auf das Wesentliche zu konzentrieren, flexibel auf neue Erkenntnisse zu reagieren und nach jedem Sprint ein Stück wertvolle Arbeit zu liefern.
- Product Backlog: Das Product Backlog ist die zentrale, fortlaufend gepflegte Liste von allem, was zur Verbesserung des Produkts benötigt wird. Es ist die Quelle aller Arbeiten des Scrum‑Teams und wird laufend verfeinert. Items werden beschrieben, priorisiert und in kleinere Einheiten zerlegt. Nur Items, die im Backlog ausreichend vorbereitet sind, können in einem Sprint eingeplant werden.
- Sprint Backlog: Aus dem Product Backlog wählt das Team für jeden Sprint die Aufgaben aus, die in diesem Sprint umgesetzt werden sollen. Diese Items, der Sprint Goal (das „Warum“) sowie ein konkreter Plan für die Umsetzung bilden zusammen das Sprint Backlog. Es ist ein transparentes, aktuelles Arbeits‑Board, das während des Sprints laufend aktualisiert wird und allen Teammitgliedern zeigt, was noch zu tun ist und was bereits erledigt wurde.
- Increment: Am Ende jedes Sprints entsteht mindestens ein Increment – ein nutzbarer, funktionsfähiger Teil des Produkts, der auf den vorangegangenen Inkrementen aufbaut. Alle Inkremente müssen der gemeinsam definierten „Definition of Done“ entsprechen; nur dann gelten sie als „fertig“ und können veröffentlicht oder Stakeholdern präsentiert werden.
Für jedes Artefakt gibt es zudem eine feste Verpflichtung (Commitment), die die Transparenz und den Fokus der Arbeit sicherstellt:
- Product Backlog → Product Goal: beschreibt den langfristigen Zweck des Produkts.
- Sprint Backlog → Sprint Goal: ein klares Ziel für den aktuellen Sprint.
- Increment → Definition of Done: verbindliche Qualitätskriterien, die jedes Increment erfüllen muss.
Scrum bringt einige feste Rituale (auch Zeremonien) mit sich, die dem Team Struktur geben:
- Sprint Planning: Zu Beginn eines Sprints plant das Team gemeinsam, welche konkreten Ergebnisse es bis Sprintende erreichen will. Dafür bedient es sich aus einem priorisierten Product Backlog – einer Liste aller anstehenden Aufgaben/Ideen, sortiert nach Wichtigkeit (der Product Owner pflegt diese Liste). Für das GrünWandel-Team könnte im Backlog z. B. stehen: „Landingpage zur Kampagnenidee veröffentlichen“, „verschiedene Facebook-Narrative testen“, „Partnerorganisationen ansprechen“ usw. Das Team wählt aus diesem Backlog die Items aus, die es im kommenden Sprint realistisch bearbeiten kann. Daraus wird das Sprint Backlog (die To-dos für diesen Sprint). Ergebnis des Sprint Planning ist auch ein Sprint-Ziel, z. B.: „Wir wollen in zwei Wochen herausfinden, welches Kampagnen-Narrativ bei unserer Zielgruppe am besten ankommt.“ Dieses Ziel fokussiert die Teamenergie.
- Daily Stand-up (Daily Scrum): Ein tägliches kurzes Meeting (ca. 15 Minuten im Stehen – daher „Stand-up“), in dem jedes Teammitglied kurz teilt, woran es gerade arbeitet, was geschafft wurde und wo eventuell Hindernisse sind. Ziel: Alle synchronisieren sich, Probleme werden früh erkannt. NGO-Tipp: Wenn täglich zu viel ist, kann man Stand-ups auch 2–3 Mal die Woche durchführen (z. B. Mo/Mi/Fr), um einen ähnlichen Effekt mit weniger Aufwand zu erzielen.
- Sprint Review: Am Ende des Sprints präsentiert das Team die erzielten Ergebnisse, idealerweise in nutzbarer Form. Hier geht es nicht um einen trockenen Bericht, sondern ums Zeigen: z. B. eine funktionierende Landingpage-Demo, ein Test-Bericht der Social-Media-Posts oder ein anderes greifbares Ergebnis. Wichtiger Bestandteil ist das Feedback von Stakeholdern – seien es Kolleg*innen, Ehrenamtliche, Partner oder (falls möglich) sogar ein paar Personen aus der Zielgruppe. Das Team erfährt so unmittelbar, was gut ankam, was noch fehlt oder anders gemacht werden sollte. Sprint
- Retrospektive: Ebenfalls zum Sprintabschluss (oft direkt nach dem Review oder am Folgetag) schaut das Team auf die Zusammenarbeit selbst. Was lief im letzten Sprint gut? Was lief schlecht oder hat genervt? Und vor allem: Was wollen wir im nächsten Sprint konkret anders machen, um besser zu werden? Die Retro dauert meist 30–60 Minuten. Entscheidend ist, dass am Ende 1–2 Verbesserungsmaßnahmen für den nächsten Sprint festgehalten werden (und nicht 10, damit man sich wirklich darauf fokussiert).
Durch diese festen Sprint-Zyklen ermöglicht Scrum dem Team, regelmäßig verwertbare Ergebnisse zu liefern und sich ständig zu verbessern. Im NGO-Kontext eignet sich Scrum vor allem, wenn:
- das Projekt komplex ist und Neues entwickelt werden muss. Zum Beispiel eine Kampagne, deren Erfolg von vielen unbekannten Faktoren abhängt, oder ein neues Bildungsangebot, das erst nach und nach entsteht. Man weiß zu Beginn noch nicht alles – Scrum hilft, schrittweise Klarheit zu gewinnen.
- regelmäßige Zwischenergebnisse sinnvoll sind. Wenn man laufend liefern kann (z.B. alle zwei Wochen eine kleine Verbesserung, einen Inhalt, ein Teilprodukt), bleibt die Dynamik hoch und der Nutzen für die Zielgruppe steigt kontinuierlich. Für eine digitale Plattform etwa könnte alle paar Wochen ein neues Feature live gehen.
- Feedback gebraucht wird. NGOs arbeiten oft wirkungsorientiert – es ist wichtig, früh zu testen, ob Maßnahmen ankommen. Scrum fördert genau das: Immer wieder Feedback einholen und ins weitere Vorgehen einfließen lassen.
- ein engagiertes Team von 3–8 Personen kontinuierlich zusammenarbeitet. Scrum ist ein Teamansatz; wenn ein Kernteam regelmäßig Zeit für das Projekt hat, entfaltet es seine Stärken. (Falls man hingegen ein einmaliges Event „nach Schema F“ organisiert, ist Scrum Overkill – da tut es ein simpler Plan oder ein Kanban-Board.)
Scrum mag zunächst nach viel Zeremonie klingen, doch viele NGOs haben bereits Elemente davon ausprobiert – etwa eine Retro am Projektende (Lesson Learned) oder Wochen-Check-ins. Der Wert von Scrum liegt in der Regelmäßigkeit dieser Zyklen. Iterativ arbeiten heißt, große Aufgaben in machbare Etappen zu unterteilen, aus jedem Schritt zu lernen und flexibel weiterzuarbeiten. Für Organisationen, die oft mit knappen Ressourcen große Wirkung erzielen müssen, ist das ein enormer Vorteil: Man verschwendet weniger Zeit auf dem falschen Weg, weil man früh merkt, wenn etwas nicht funktioniert.

Abbildung 2: Scrum
Während Scrum eher einem strukturierten Rhythmus folgt, ist Kanban (japanisch für „Tafel/Signalkarte“) ein flexibles System zur Arbeitsorganisation, das vor allem den Workflow visualisiert und steuert. Kanban kommt aus der Produktionssteuerung (Toyota) und hat ein zentrales Werkzeug: das Kanban-Board. Auf diesem Board, ob physisch an der Wand oder digital mit Tools wie Trello, Planner o. ä. – werden alle anstehenden Aufgaben als Karten festgehalten und entlang eines Prozesses geschoben. Klassische Spalten sind z. B. „To Do“, „In Arbeit“ und „Erledigt“. Das Team sieht auf einen Blick, was anliegt, woran gerade gearbeitet wird und was fertig ist. Siehe Abbildung 3 „Kanban-Board“.
Der Clou bei Kanban: Man limitiert die Anzahl der Aufgaben, die gleichzeitig in Arbeit sind (Work-in-Progress-Limit). Zum Beispiel kann man vereinbaren, dass nie mehr als 3 Tasks gleichzeitig „In Arbeit“ sein dürfen. Warum? Weil zu viel Parallelarbeit zu Überlastung und langen Durchlaufzeiten führt. Kanban fördert also Fokussierung: Erst abschließen, dann Neues anfangen.

Abbildung 3: Kanban-Board
Im NGO-Alltag passt Kanban besonders gut, wenn die Arbeit eher kontinuierlich und variabel ist statt in definierten Projektphasen abläuft. Typische Szenarien:
- Viele laufende Aufgaben gleichzeitig: Das Team jongliert dauerhaft diverse Themen (z. B. Pressearbeit, Veranstaltungsorganisation, Mitgliederservice, spontane Anfragen). Ein Kanban-Board hilft, diese Vielfronten-Arbeit sichtbar zu machen und besser zu steuern.
- Ständig kommen neue To-Dos rein: In NGOs tauchen oft ad hoc Aufgaben auf, z. B. ein Förderantrag muss kurzfristig geschrieben werden, ein politischer Aufruf erfordert schnelle Reaktion etc. Kanban ist flexibel: Neue Karten können jederzeit ins Board hinzugefügt und priorisiert werden, ohne erst auf den nächsten Sprint warten zu müssen (wie es bei Scrum der Fall wäre).
- Unklare Prioritäten vermeiden: Durch die Visualisierung sieht jeder, was gerade Prio hat. Das Team kann sich leichter abstimmen: Was ist wirklich wichtig, was kann warten? Das Board dient als gemeinsame Quelle der Wahrheit und verhindert, dass Dinge untergehen.
- Arbeit mit externen oder wechselnden Beteiligten: Kanban ist weniger formal als Scrum und erfordert keine festen Teamstrukturen oder Meetings. Auch wenn Ehrenamtliche sporadisch mithelfen oder Teammitglieder wechselnde Kapazitäten haben, bleibt das Board ein stetiger Orientierungspunkt, an dem man anknüpfen kann, sobald jemand wieder verfügbar ist.
Kanban hat keine vordefinierten Rollen oder Zyklen. Es ist mehr eine kontinuierliche „Fließband“-Art des Arbeitens. Dennoch empfiehlt es sich, auch in Kanban einen Rhythmus für regelmäßige Reflexion einzubauen, z. B. wöchentliche Team-Updates oder alle paar Wochen eine Retro –, damit die kontinuierliche Arbeit nicht zum Hamsterrad wird, sondern ebenfalls Lernmomente bietet. In Kombination mit Kanban spricht man hier gern von Kaizen (japanisch für „Verbesserung“): Das Team schaut regelmäßig auf seine Prozesse und sucht nach Wegen, effizienter und stressärmer zusammenzuarbeiten. So bleibt Kanban nicht nur eine Aufgabenverwaltung, sondern wird auch Teil einer agilen Haltung.
Scrum oder Kanban – was ist nun „besser“? Diese Frage stellt sich so pauschal nicht. Beide haben ihre Stärken:
- Scrum eignet sich, wenn man etwas Neuartiges schafft und dabei in planbaren Etappen vorgehen kann. Es bietet klarere Rahmen (Sprint-Struktur), die helfen, diszipliniert Ergebnisse zu liefern und nicht dauernd alles umzuwerfen. Dafür ist Scrum weniger spontan, weil man idealerweise einen Sprint durchzieht, bevor man neue Aufgaben einstreut.
- Kanban glänzt in Umfeldern, in denen Flexibilität und Durchlaufgeschwindigkeit zählen. Es schreibt kaum etwas vor, außer dem Visualisieren und Begrenzen von Aufgaben. Dafür muss das Team eigenständig darauf achten, sich genug Feedback und Verbesserungsloops einzubauen.
In der Praxis schließen sich beide nicht aus. Einige NGOs kombinieren Elemente: z. B. arbeiten sie in Projekten mit Scrum-Sprints, nutzen aber parallel ein Kanban-Board für allgemeine Teamaufgaben und als Überblick. Wichtig ist, dass die Methode zur Arbeitsrealität passt. Agilität ist kein Selbstzweck. Scrum und Kanban sollen helfen, die Arbeit besser zu organisieren, damit am Ende mehr Wirkung für die Zielgruppe erzielt wird.
Product Canvas: agile Planung von Vision bis User Story
Nach der Gegenüberstellung von Scrum und Kanban richtet sich der Blick nun auf die strategische Ebene der agilen Arbeit. Während Scrum und Kanban vor allem operative Frameworks sind, die die tägliche Zusammenarbeit und den Workflow steuern, braucht es im agilen Umfeld auch ein klares Bild davon, wohin ein Projekt führen soll. Planung findet im Agilen nicht weniger statt. Sie geschieht nur anders: iterativ und immer in Verbindung mit den Beteiligten.
Ein geeignetes Instrument hierfür ist das Product Canvas. Siehe Abbildung 4 „Product Canvas“. Es handelt sich um ein kompaktes, aber inhaltsreiches Tool, mit dem ein Team festhält, was das Produkt ist und wie es strategisch positioniert wird. Der Canvas hilft, Outcome‑Metriken zu identifizieren, bereitet die Erstellung einer gemeinsamen Produkt‑Roadmap vor und erleichtert das Management des Backlogs und der Releaseplanung. Seine Rolle ist klar: Er speist sowohl die Produkt‑Roadmap (strategisch) als auch den Product Backlog (taktisch). Damit überbrückt der Canvas die Lücke zwischen langfristiger Vision und operativem Arbeiten.
Von der Vision zur Umsetzung: strategische und taktische Ebenen verbinden
Mit dem Product Canvas definieren NGOs strategische Leitlinien, die anschließend über die Roadmap in eine langfristige Abfolge von Meilensteinen übersetzt werden. Die Roadmap beantwortet Fragen wie: Welche Epics werden wir in den nächsten Quartalen angehen, um unsere Wirkung zu erreichen? Parallel dazu entsteht der Product Backlog mit kurz‑, mittel‑ und langfristigen Einträgen (User Stories), die in Sprints umgesetzt werden. So lässt sich sicherstellen, dass operative Entscheidungen (z. B. im Scrum‑Sprint) stets auf die strategischen Ziele einzahlen.
Auf diese Weise zeigt der Canvas, dass agile Planung keine starre „Master‑Roadmap“ ist, sondern ein kontinuierlicher, iterativer Prozess: Vision, Zielgruppen und Wirkungswege werden immer wieder überprüft und angepasst. Das Ergebnis ist eine transparente Verbindung zwischen dem, was eine NGO langfristig bewirken will, und den konkreten Schritten, die dafür im Alltag notwendig sind.
Die folgende Darstellung zeigt ein leeres und ein ausgefülltes Product Canvas (angelehnt an Roman Pichler) als Beispiel für die Kampagne „Stadt. Grün. Zukunft.“:


Alltagstauglich agil: So gelingt der Einstieg ins agile Arbeiten
Neue Begriffe und Methoden können einschüchternd wirken, gerade in Organisationen, die wenig Berührung mit Management-„Sprache“ haben. Daher lautete eine der Botschaften des Seminars: Agilität muss nicht kompliziert oder theorielastig sein. Man kann klein anfangen, ohne gleich das ganze System auf den Kopf zu stellen. Hier sind einige Ansätze, wie der Einstieg niedrigschwellig gelingt:
Kein Fachjargon, mehr Ausprobieren In J.K. Rowlings Geschichten wird der böse Voldemort oft „Der, dessen Name nicht genannt werden darf“ genannt, um die Angst vor dem Wort zu nehmen. Ähnlich kann man es mit agilen Buzzwords halten. Begriffe wie „Scrum“, „Sprint“ oder „Kanban“ schrecken manche Teams zunächst eher ab, weil sie nach großem Umbruch klingen. Die Empfehlung: Einführung agiler Arbeitsweisen nicht als verkopftes Methodentraining verkaufen, sondern einfach als „neue Formen der Zusammenarbeit“ ausprobieren. Die Methode muss anfangs gar keinen Namen haben – wichtiger ist, dass das Team die Erfahrung macht, anders zu arbeiten. Zum Beispiel kann man sagen: „Lasst uns doch mal versuchen, unsere Aufgaben auf einer Wand sichtbar zu machen, damit wir besser den Überblick haben.“ Man muss dafür nicht sofort den Begriff Kanban erklären oder einen Lehrvortrag halten. Oder: „Lass uns am Ende des Monats 20 Minuten nehmen, um zu schauen, was im Team gut lief und was wir verbessern können.“ – ohne es gleich „Retrospektive“ zu nennen. Die Idee ist, spielerisch und ohne Dogmen an Neues heranzugehen. Die Theorie kann später immer noch folgen, wenn das Bedürfnis da ist.
Anstatt eine große agile Transformation auszurufen, empfiehlt es sich, mit kleinen Experimenten zu starten. Fragen Sie im Team: Wo haben wir im Alltag gerade einen Schmerzpunkt oder Engpass? – Genau dort kann ein agiler Impuls ansetzen. Beispiele:
- Zu viele endlose Meetings? → Experiment: Für die nächsten 4 Wochen sind alle Besprechungen auf 30 Minuten begrenzt (Timebox). Nach einem Monat schaut man gemeinsam: Hat uns das geholfen, effizienter zu werden?
- Kommunikationschaos per E-Mail? → Experiment: Vier Wochen lang führen wir morgens ein kurzes Stand-up-Meeting ein und sehen, ob sich der E-Mail-Stau dadurch verringert.
- Unklare Aufgabenverteilung? → Experiment: Testweise nutzen wir ein einfaches Aufgabenboard (Pinnwand oder digitales Tool) für ein Projekt und verfolgen, ob es Transparenz und Verantwortlichkeit erhöht.
- Motivationstief im Team? → Experiment: Wir probieren einen monatlichen Mini-Rückblick (Retro) aus, um offen über Frust und Verbesserungsideen zu reden.
Wichtig ist, das Experiment gemeinsam als Team festzulegen, einen klaren Zeitraum zu definieren (z. B. 4 Wochen) und hinterher auszuwerten. Was hat sich verändert? Hat es das Problem gelindert? Wenn ja, kann man den neuen Ansatz beibehalten; wenn nein, hat man zumindest etwas gelernt und probiert etwas anderes. Solche Mikro-Experimente fühlen sich für alle Beteiligten sicher an, weil sie zeitlich begrenzt sind und keinen endgültigen Charakter haben. Doch schon nach wenigen Runden merkt das Team: Wir haben aktiv unseren Arbeitsprozess gestaltet – das ist bereits agiles Arbeiten, ohne dass man es anfangs so genannt hat.
Nichts überzeugt mehr als Erfolgserlebnisse. Wenn ein Team einen neuen Ansatz ausprobiert hat und davon profitiert, sollte das im NGO-Alltag geteilt werden. Das kann informell passieren („Seit wir montags ein Aufgaben-Board nutzen, läuft unsere Absprache viel besser!“) oder organisiert (z.B. im Teammeeting kurz erzählen, was man getestet hat und wie es lief). Solche Geschichten nehmen anderen die Scheu und erzeugen einen Nachahm-Effekt. Vielleicht bekommt ein anderes Projektteam Lust, auch mal eine Retro zu versuchen, wenn es hört, dass es bei Kolleg*innen X und Y viel gebracht hat. Agilität verbreitet sich idealerweise durch internes Best Practice – es muss nicht von oben verordnet werden.
Drei Phasen zur agilen NGO – systematische Einführung auf Team-, Organisations- und Strukturebene
Neben den kleinen Alltagsverbesserungen wurde im Seminar ein 3-Phasen-Modell vorgestellt, mit dem eine NGO schrittweise agiler werden kann. Dieses Modell adressiert verschiedene Ebenen – vom einzelnen Team bis zur gesamten Organisationsstruktur:
In Phase 1 geht es darum, in einzelnen Teams agile Routinen zu etablieren, die schnell zur Normalität werden. Ziel: Das tägliche Arbeiten soll effizienter, transparenter und lernorientierter werden – und das ohne großen Aufwand. Einige bewährte Schritte in Teams:
- Regelmäßige Retrospektiven einführen: Einmal im Monat (oder zumindest quartalsweise) hält das Team inne und reflektiert: Was lief in letzter Zeit gut? Was nervt oder hindert uns? Was wollen wir konkret ändern bis zum nächsten Mal? So eine Retro muss kein Mammut-Workshop sein. 30 Minuten reichen oft schon, wenn alle offen sprechen dürfen. Entscheidend ist, immer mindestens eine konkrete Verbesserungsmaßnahme zu vereinbaren und beim nächsten Treffen nachzuhalten. So entsteht ein Zyklus kontinuierlicher Verbesserung innerhalb des Teams.
- Transparenz durch Task-Boards („Teamtafeln“): Für alle im Team sollte sichtbar sein, wer woran arbeitet und welche Projekte gerade laufen. Eine einfache Tafel im Büro oder ein digitales Dashboard (Trello-Board, Planner, Miro-Board, Excel-Liste – egal was) schaffen Überblick. Wenn Aufgaben und Zuständigkeiten offen liegen, entlastet das auch die Teamleitung. Es führt zu weniger Mikromanagement, weniger Nachfragen, weil vieles selbsterklärend auf dem Board steht. Zudem können Teammitglieder proaktiv helfen, wenn sie sehen, irgendwo stockt es.
- Meetings standardisieren: Agile Teams verbringen ihre Meeting-Zeit möglichst sinnvoll. Dazu gehört, dass jede Besprechung ein klares Ziel hat, pünktlich beginnt und endet (Timeboxing!) und Ergebnisse dokumentiert werden. Für wiederkehrende Sitzungen lohnt es sich, feste Rollen zu verteilen, z. B. führt abwechselnd jemand als Moderator*in durch das Meeting, jemand anders schreibt Protokoll. So wird verhindert, dass „Dauersitzungen“ sich zerfasern oder nur eine Person alles dominiert. Über die Zeit gewöhnt sich die Gruppe daran, effizienter zu tagen, was allen Zeit spart und die Ergebnisse verbessert.
Diese Maßnahmen mögen unspektakulär klingen, doch genau darum geht es: Agilität automatisch Teil des Arbeitsalltags werden lassen, nicht als Extra-Belastung obendrauf. Wenn Teams retrospektiv arbeiten, visuell planen und diszipliniert kommunizieren, legen sie damit das Fundament für eine agile Kultur.
Hat sich in einzelnen Teams agiles Arbeiten bewährt, steht als Nächstes die gesamte Organisation im Blick. Phase 2 zielt darauf ab, aus vielen einzelnen agilen Inseln eine lernende Organisation zu formen. Maßnahmen auf dieser Ebene:
- Interne Austauschformate schaffen: Unterschiedliche Teams und Abteilungen sollten miteinander in Dialog über neue Arbeitsweisen treten. Formate wie „Agile Lunch“ oder „Lean Coffee“ bringen Kolleg*innen aus verschiedenen Bereichen locker zusammen. Dabei gibt es keine feste Agenda, aber die Absicht, voneinander zu lernen. Jeder bringt Themen oder Fragen ein, z. B. „Wie macht ihr das mit den Teamtreffen?“ oder „Wir haben XY ausprobiert, hier unsere Erfahrungen…“. Ein weiteres kreatives Format ist die „Fehlerküche“: Teams berichten in kurzen Slots darüber, was sie ausprobiert haben, was nicht geklappt hat und was sie daraus gelernt haben. Ziel solcher Formate ist es, eine positive Fehlerkultur zu fördern und zu zeigen, dass Experimente ok sind und auch Misserfolge wertvolle Learnings liefern. Ebenso hilfreich: Projektmarktplätze, wo agile Pilotprojekte ihre Ergebnisse intern vorstellen (5 Minuten pro Projekt). Das sorgt für bereichsübergreifende Inspiration.
- Community of Practice (CoP) aufbauen: Nicht jedes Team wird sich von selbst auf den agilen Weg machen. Es hilft, wenn es Treiberinnen* in der Organisation gibt. Eine kleine CoP Agilität – z. B. 3–5 engagierte Kolleg*innen aus verschiedenen Bereichen. Sie kann sich regelmäßig treffen, um Erfahrungen auszutauschen, gemeinsam Vorlagen oder Checklisten zu entwickeln und andere mitzuziehen. Diese Leute werden zum internen Kompetenzzentrum Agilität. Sie müssen keine Vollzeit-Agile-Coaches sein, aber sie dienen als Ansprechpersonen für agile Methoden, teilen Literaturtipps, organisieren mal einen internen Workshop etc. So bleibt das Wissen nicht isoliert, sondern verbreitet sich.
- Führungskräfte einbeziehen und schulen: Eine Organisationskultur ändert sich nur, wenn die Führung mitzieht. In Phase 2 sollten daher auch Leitungsverantwortliche sensibilisiert werden: Was bedeutet agile Führung? Hier geht es oft um einen Wechsel weg von der Kontrolllogik („Ich muss alles überwachen und absegnen“) hin zur Unterstützungslogik: „Wie kann ich meinem Team helfen, erfolgreich zu sein?“. Schulungen oder Austauschrunden für Führungskräfte können Themen behandeln wie Vertrauen in Teams, Delegation, Umgang mit Unsicherheit. Wenn Vorgesetzte verstehen, dass Agilität nicht Chaos, sondern zielorientiertes Self-Management bedeutet, können sie es aktiv fördern, etwa indem sie Freiräume gewähren und Erfolge sichtbar anerkennen. Wichtig: Agile Arbeitsweisen, die Teams für sich entdecken, sollten von der Führung wohlwollend beachtet und belohnt werden (z. B. in Vereinsversammlungen oder Rundmails lobend erwähnt). Nichts demotiviert mehr, als wenn innovative Ansätze ins Leere laufen, weil die Chefetage sie ignoriert.
In Phase 2 geht es zusammengefasst darum, agile Prinzipien in die DNA der Organisation übergehen zu lassen. Wissensaustausch, bereichsübergreifendes Lernen und eine unterstützende Führungskultur machen aus vereinzelten Experimenten eine Bewegung, die die ganze NGO erfasst.
Die dritte Phase widmet sich den formalen Rahmenbedingungen. Jetzt wird Agilität quasi „offizieller Bestandteil“ der Organisationsprozesse und -strukturen. Einige Ansatzpunkte:
- Agile Elemente in Projektabläufen festschreiben: Wenn neue Projekte geplant werden, sollte der PDCA-Gedanke von Anfang an eingebaut sein. Zum Beispiel kann man in jedem Projektplan oder -auftrag standardmäßig Reflexionspunkte vorsehen: fixe Termine, an denen das Team inne hält und den Kurs überprüft. Auch Feedback-Schleifen mit Stakeholdern sollten fest eingeplant sein. Ebenso sollten Projektziele immer wirkungsorientiert formuliert werden, nicht als starre Outputs (also Ziele statt Maßnahmen definieren). Selbst wenn man weiterhin in manchen Bereichen klassisch nach Plan vorgeht (z. B. feste Deadlines für Events), kann man hybride Ansätze nutzen: etwa einen klassischen Phasenplan („Wasserfall“) mit agilen Teilprojekten ergänzen, wo es sinnvoll ist. Die Hauptsache: Agilität wird nicht dem Zufall überlassen, sondern methodisch eingeplant.
- Personal- und Kompetenzentwicklung nutzen: Agile Fähigkeiten kann man entwickeln. Daher gehören Themen wie „Agiles Projektmanagement“ oder „Moderation von Retrospektiven“ ins interne Fortbildungsprogramm. Mitarbeitende, die dafür brennen, können als Multiplikator*innen ausgebildet werden – sei es durch externe Trainings oder Learning-by-Doing als Scrum Master in einem Pilotprojekt. Die Organisation sollte solche Weiterbildungen aktiv fördern. Neue Mitarbeiter*innen kann man in der Einarbeitung gleich mit agilem Mindset vertraut machen, um die Kultur zu festigen.
- Agile Kultur sichtbar machen: In Phase 3 darf die Organisation ruhig offiziell kommunizieren, wofür sie kulturell steht. Es könnte etwa eine interne Kampagne oder Leitlinie geben mit dem Motto „Wie wir zusammenarbeiten wollen“, in der Prinzipien wie Offenheit, Feedback und Experimentierfreude betont werden. Erfolgsgeschichten agiler Projekte können in internen Medien (Newsletter, Intranet) geteilt werden. Eine Wissensdatenbank (Wiki oder SharePoint) sammelt Tools, Checklisten und Praxisbeispiele, damit jede*r schnell Anregungen findet. Durch solche strukturellen Maßnahmen wird Agilität vom Nischenthema zum integralen Bestandteil der Organisationsidentität.
Die drei Phasen zeigen: Agile Transformation ist ein Prozess auf vielen Ebenen. Man fängt im Kleinen an (Teams), skaliert die Lernkultur nach und nach auf die ganze Organisation und passt schließlich die formalen Strukturen an, damit Agilität nachhaltig trägt. Wichtig ist, jede Phase bewusst zu gestalten und nicht zu früh mit großen Strukturänderungen zu beginnen, bevor die Kultur bereit ist. Denn Agilität lebt zuerst in den Köpfen und im täglichen Miteinander. Die besten neuen Prozesse nützen nichts, wenn die Haltung dahinter fehlt.
Konkrete Tipps für den agilen Alltag – was man morgen ausprobieren kann
Abschließend noch einmal einige praktische Tipps und Formate, die sich im NGO-Kontext als unkomplizierte Einstiegspunkte bewährt haben. Diese Ideen lassen sich sofort (und kostenlos) ausprobieren. All diese Tipps eint, dass sie niedrigschwellig sind. Man braucht keine zusätzliche Finanzierung, keine neue Software (zur Not tut’s ein Whiteboard oder Notizzettel) und kein monatelanges Training. Wichtig ist nur die Bereitschaft, als Team etwas Neues zu probieren und regelmäßig zu reflektieren.
Einfacher Hebel mit großer Wirkung. Legt für jede Besprechung eine feste Dauer (z. B. 30 oder 45 Minuten) fest und haltet euch dran. Das schärft den Fokus und respektiert die Zeit aller. Fangt pünktlich an, hört pünktlich auf.
Stellt euch 2–3 Mal pro Woche 10 Minuten zusammen (gerne im Stehen), in denen jedes Teammitglied kurz sagt: Was steht heute/diese Woche an? Wo brauche ich Hilfe? Diese knackigen Updates verbessern die Koordination immens und ersetzen viele E-Mails.
Hängt eine Tafel auf oder nutzt ein digitales Board, um alle laufenden Aufgaben zu tracken. Jeder sieht sofort, welche To-Dos es gibt und woran gearbeitet wird. Das schafft Transparenz und ein gemeinsames Verantwortungsgefühl.
Bucht euch einen fixen Termin pro Monat für eine Mini-Retrospektive. Agenda ganz einfach: Was lief zuletzt gut? Was lief nicht gut? Was wollen wir im nächsten Monat anders machen? Durch diese Routine etabliert ihr Kontinuität im Lernen und Verbessern.
Ladet zu einem informellen Austausch ohne feste Agenda ein, z. B. einmal im Quartal bereichsübergreifend. Themen werden zu Beginn gesammelt und dann in lockerer Runde besprochen (mit Timer, damit man pro Thema z. B. 5 Minuten hat und dann optional verlängert). Dieses Format fördert spontane Ideen und Vernetzung, perfekt um agiles Gedankengut intern zu verbreiten.
Wenn ihr ein Experiment durchgeführt habt (sei es noch so klein) und es zeigt Wirkung, teilt das Erfolgserlebnis! Macht es in der nächsten Teamsitzung bekannt oder schreibt einen kurzen Beitrag im Intranet. Sichtbare Quick Wins nehmen Skeptikern den Wind aus den Segeln und motivieren alle, weiter auszuprobieren.
Fazit
Agiles Projektmanagement ist kein Hexenwerk, sondern im Kern ein kultureller Wandel hin zu mehr Flexibilität, kontinuierlichem Lernen und Empowerment der Mitarbeitenden. Für NGOs, die mit begrenzten Ressourcen arbeiten, ist Agilität besonders wertvoll: Sie ermöglicht, schneller auf Veränderungen zu reagieren, Prioritäten sinnvoll zu setzen und den Fokus stets auf die zu erzielende Wirkung zu richten. Der Weg dorthin muss nicht mit radikalen Umbrüchen gepflastert sein. Oft genügen kleine Schritte, die jede*r gehen kann. Beginnen Sie im Kleinen, bleiben Sie dran, und beobachten Sie, wie Ihr Team nach und nach agiler denkt und handelt. So kommt man „agil zum Ziel“ – im Sinne der guten Sache, für die Ihre Organisation steht.
Wenn Sie Unterstützung auf dem Weg zur agilen Organisation wünschen, begleiten Sie unsere Coaches gerne. Mehr dazu auf agathe-hilft.de.


