Agiles Projektmanagement in der Praxis: Scrum, Kanban, Priorisierung und Skalierung

Was bedeutet agiles Projektmanagement?

Agiles Projektmanagement ist ein Ansatz, der Projekte in kurzen, wiederkehrenden Zyklen plant und liefert. Statt den gesamten Umfang zu Beginn festzulegen und dann gegen diesen Plan zu steuern, wird ein Rahmen aus Zielen, Budget und Zeit gesetzt, innerhalb dessen das Team die Umsetzung schrittweise plant. Nach jedem Zyklus liegt ein nutzbares Ergebnis vor, das mit Nutzenden und Auftraggebern geprüft wird. Die Erkenntnisse fliessen in die Planung des nächsten Zyklus ein.

Dieser Ansatz eignet sich besonders, wenn Anforderungen zu Beginn unsicher sind, sich während des Projekts ändern oder erst durch die Arbeit am Ergebnis klar werden. Das ist bei Software, digitalen Produkten, Kampagnen und vielen Organisationsprojekten der Fall. Er eignet sich weniger, wenn das Ergebnis vollständig bekannt ist und Änderungen sehr teuer wären, etwa beim Bau eines Gebäudes nach fertiger Planung. Viele Projekte liegen dazwischen und kombinieren beide Welten.

Die Norm ISO 21502 nennt agile Ansätze ausdrücklich als mögliche Liefermodelle neben prädiktiven, inkrementellen, iterativen und hybriden ^[6]. Auch die Schweizer Methode HERMES bietet seit der Ausgabe 2022 ein agiles Vorgehen mit eigenem Leitfaden an ^[7]. Agiles Arbeiten ist damit kein Gegenmodell zu etablierten Standards mehr, sondern eine anerkannte Option innerhalb dieser Standards.

Welche Werte stehen hinter agilem Arbeiten?

Im Februar 2001 formulierten 17 Softwareentwickler das Manifest für Agile Softwareentwicklung. Es enthält vier Wertepaare: Individuen und Interaktionen mehr als Prozesse und Werkzeuge, funktionierende Software mehr als umfassende Dokumentation, Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung und Reagieren auf Veränderung mehr als das Befolgen eines Plans ^[1]. Wichtig ist der Zusatz: Die Werte auf der rechten Seite sind wichtig, die auf der linken werden höher eingeschätzt.

Ergänzt werden die Werte durch zwölf Prinzipien, etwa die frühe und kontinuierliche Auslieferung wertvoller Ergebnisse, die Begrüssung sich ändernder Anforderungen, die tägliche Zusammenarbeit von Fachleuten und Entwicklung, ein nachhaltiges Arbeitstempo und regelmässige Reflexion. Obwohl das Manifest aus der Softwareentwicklung stammt, lassen sich die Prinzipien auf viele Arten von Projekten übertragen, in denen Unsicherheit herrscht und Feedback wertvoll ist.

Welche agilen Methoden gibt es?

Scrum ist der verbreitetste Ansatz. Der Scrum Guide beschreibt ihn als leichtgewichtiges Rahmenwerk, das Menschen, Teams und Organisationen hilft, Wert durch adaptive Lösungen für komplexe Probleme zu schaffen ^[2]. Wie Scrum im Detail funktioniert, erklärt der Beitrag Scrum Guide 2020 verständlich erklärt; die Events und ihre Durchführung behandelt Die fünf Scrum-Events.

Kanban verfolgt einen anderen Ansatz: Es gibt keine festen Zyklen, sondern einen kontinuierlichen Fluss. Arbeit wird auf einem Board sichtbar gemacht, die Menge gleichzeitig laufender Arbeit wird begrenzt, und der Fluss wird mit Metriken wie Durchlaufzeit und Durchsatz gemessen. Der Kanban Guide nennt dafür vier minimale Flussmetriken ^[3]. Wie Kanban eingeführt wird, beschreibt der Beitrag Kanban einführen.

Agil oder klassisch: wann passt was?

Die Frage ist selten ein Entweder-oder. Entscheidend sind die Unsicherheit der Anforderungen, die Kosten von Änderungen, die Verfügbarkeit der Fachleute für regelmässiges Feedback und die Erwartungen des Auftraggebers an Planungssicherheit. Je unsicherer die Anforderungen und je günstiger Änderungen, desto mehr spricht für agiles Arbeiten. Je klarer das Ergebnis und je teurer Änderungen, desto mehr spricht für klassische Planung. Eine Entscheidungshilfe mit Kriterien enthält der Beitrag Agil oder klassisch?.

In der Praxis arbeiten viele Organisationen hybrid: Auftrag, Budget, Meilensteine und Abschluss werden klassisch gesteuert, die Umsetzung erfolgt agil. Diese Kombination beschreibt der Beitrag Hybrides Projektmanagement in der Praxis im Hub Projektplanung ausführlich.

Wie entsteht ein guter Backlog?

Im Zentrum agiler Arbeit steht eine geordnete Liste dessen, was das Produkt verbessern soll: der Product Backlog. Seine Qualität entscheidet über den Erfolg. Einträge werden meist als User Stories formuliert, die aus Sicht der Nutzenden beschreiben, was gebraucht wird und warum, ergänzt um Akzeptanzkriterien, die festlegen, wann ein Eintrag erfüllt ist. Wie gute User Stories aussehen, zeigt der Beitrag User Stories schreiben.

Ebenso wichtig ist die Reihenfolge. Der Product Owner ordnet den Backlog so, dass der grösste Wert zuerst entsteht. Methoden wie WSJF, MoSCoW oder RICE helfen, diese Entscheidung nachvollziehbar zu machen. SAFe etwa schätzt WSJF als relative Kosten der Verzögerung geteilt durch die relative Dauer ^[4]. Ein Vergleich der Methoden mit durchgerechnetem Beispiel findet sich unter Backlog priorisieren.

Wie wird in agilen Teams geschätzt und gemessen?

Agile Teams schätzen meist relativ, etwa in Story Points, und leiten aus der beobachteten Geschwindigkeit ab, wie viel in einen Zyklus passt. Andere verzichten ganz auf Schätzungen und arbeiten mit Durchsatz und Durchlaufzeiten. Welche Verfahren es gibt und wann sie passen, vergleicht der Beitrag Agile Schätzverfahren.

Gemessen wird, um zu lernen, nicht um Teams zu vergleichen. Velocity, Burn-up, Durchlaufzeit, Durchsatz und Work Item Age zeigen, wie gut der Fluss funktioniert und wo Arbeit hängen bleibt. Missbraucht als Leistungskennzahl, verlieren sie ihren Wert. Wie Metriken sinnvoll eingesetzt werden, beschreibt der Beitrag Agile Metriken richtig nutzen.

Welche Rituale halten agile Teams in Bewegung?

In Scrum strukturieren fünf Events den Zyklus: der Sprint als Container, Sprint Planning, Daily Scrum, Sprint Review und Sprint Retrospective. Der Scrum Guide legt für einen Sprint von einem Monat Höchstdauern fest, etwa acht Stunden für das Planning und drei Stunden für die Retrospektive ^[2]. Besonders die Retrospektive entscheidet, ob ein Team besser wird. Bewährte Formate mit Anleitung enthält der Beitrag Retrospektive-Methoden.

Wie funktioniert agiles Arbeiten in besonderen Kontexten?

Agenturen und Dienstleister arbeiten mit Kunden, die Budgets und Termine brauchen, und mit Verträgen, die Leistungen festlegen. Scrum lässt sich auch hier einsetzen, braucht aber passende Verträge, eine klare Rolle des Kunden und einen Umgang mit Änderungen, siehe Scrum in Agenturen und Kundenprojekten. Verteilte Teams stellen eigene Anforderungen an Kommunikation und Rituale, siehe Agile Teams remote führen.

Arbeiten mehrere Teams an einem Produkt, braucht es Abstimmung über Teamgrenzen hinweg. Frameworks wie Nexus, LeSS und SAFe bieten dafür unterschiedlich schwere Strukturen; Nexus etwa richtet sich an etwa drei bis neun Scrum Teams ^[5]. Einen Vergleich bietet der Beitrag Agile Skalierung.

Wie wird agiles Arbeiten eingeführt?

Agiles Arbeiten lässt sich nicht verordnen. Erfolgreiche Einführungen beginnen klein, mit einem Team und einem geeigneten Projekt, lernen aus den ersten Zyklen und weiten das Vorgehen schrittweise aus. Führungskräfte spielen dabei eine zentrale Rolle, weil sie Entscheidungsbefugnisse abgeben und neue Formen der Steuerung akzeptieren müssen. Wie das in kleinen und mittleren Unternehmen gelingt, beschreibt der Beitrag Agile Transformation in KMU. Wer sich fachlich weiterbilden möchte, findet einen Überblick unter Scrum-Zertifizierungen.

Welche Missverständnisse über Agilität sind verbreitet?

• «Agil heisst ohne Plan.» Agile Teams planen häufiger, nur in kürzeren Abständen und mit einem festen Rahmen.
• «Agil heisst ohne Dokumentation.» Das Manifest stellt funktionierende Ergebnisse über umfassende Dokumentation, verzichtet aber nicht auf die nötige.
• «Agil ist schneller.» Agil liefert früher nutzbare Ergebnisse und reduziert das Risiko, das Falsche zu bauen; der Gesamtaufwand sinkt nicht automatisch.
• «Scrum ist agil, alles andere nicht.» Scrum ist ein Rahmenwerk unter mehreren; Kanban und hybride Ansätze sind ebenso agil.
• «Wir machen Scrum, nur ohne Retrospektive.» Der Scrum Guide hält fest, dass ein Weglassen von Elementen nicht mehr Scrum ist.
• «Der Product Owner ist ein Gremium.» Der Scrum Guide verlangt eine Person, kein Komitee.

Welche Werkzeuge unterstützen agile Teams?

Agile Teams brauchen ein Board, auf dem Arbeit sichtbar ist, einen geordneten Backlog, die Möglichkeit, Zyklen zu planen, und Auswertungen wie Burn-up oder Durchlaufzeiten. Für Organisationen, die agile Teams mit klassischer Steuerung verbinden, kommen Budget, Zeiterfassung und Statusberichte hinzu. In Flenio lassen sich Aufgaben auf Boards in Zyklen planen und gleichzeitig mit Phasen, Meilensteinen, Budget und Zeiterfassung verbinden. Vorlagen auf flenio.ch, etwa für Sprint Planning und Retrospektiven, erleichtern den Einstieg.

Wie wird in agilen Organisationen über mehrere Ebenen geplant?

Agile Teams planen nicht nur von Sprint zu Sprint. In der Praxis haben sich mehrere Planungsebenen bewährt, die unterschiedlich weit in die Zukunft reichen und unterschiedlich detailliert sind. Ganz oben steht die Produktvision, die beschreibt, warum es das Produkt gibt und wem es nützt. Darunter folgt eine Roadmap mit Zielen für die nächsten Monate, etwa als Product Goals oder Themen. Die Release-Planung legt fest, welche grösseren Funktionsblöcke wann nutzbar werden sollen. Erst auf der Ebene des Sprints oder des Kanban-Flusses wird detailliert geplant.

Diese Ebenen verbinden agile Arbeit mit den Bedürfnissen von Geschäftsleitungen und Auftraggebern, die längerfristige Orientierung brauchen. Wichtig ist, dass die oberen Ebenen bewusst grob bleiben. Eine detaillierte Roadmap über zwölf Monate widerspricht dem agilen Grundgedanken, aus Erfahrung zu lernen, und wird ohnehin mehrfach umgeworfen.

Wie passen agiles Arbeiten, Budgets und Verträge zusammen?

Eine häufige Hürde sind Budgets und Verträge, die einen festen Umfang voraussetzen. Agiles Arbeiten kehrt die Logik um: Budget und Zeit werden festgelegt, der Umfang ist variabel und wird über Priorisierung gesteuert. Für Auftraggeber bedeutet das, dass sie nicht einen vollständig beschriebenen Umfang kaufen, sondern Kapazität eines Teams über eine bestimmte Zeit, mit dem Versprechen, dass das Wertvollste zuerst entsteht. Verbreitet sind Verträge nach Aufwand mit Kostendach, Festpreise pro Sprint oder Release und Rahmenverträge mit Abrufen.

Für Dienstleister und Agenturen ist das ein grundlegender Wechsel in der Kundenbeziehung, der Vertrauen und Transparenz verlangt. Regelmässige Reviews, offene Backlogs und nachvollziehbare Kapazitätsplanung schaffen dieses Vertrauen. Wie das in Kundenprojekten konkret aussieht, beschreibt der Beitrag zu Scrum in Agenturen. In öffentlichen Projekten setzen Vergabeverfahren zusätzliche Grenzen, die schon bei der Ausschreibung berücksichtigt werden müssen.

Welche Rolle spielen Qualität und technische Praktiken?

Agiles Arbeiten liefert häufig und in kleinen Schritten. Das funktioniert nur, wenn jedes Ergebnis die vereinbarte Qualität hat. In Scrum sichert die Definition of Done diese Qualität: Ein Eintrag gilt erst als fertig, wenn er alle Kriterien erfüllt, etwa Tests, Dokumentation und Freigabe. In der Softwareentwicklung kommen technische Praktiken hinzu, etwa automatisierte Tests, kontinuierliche Integration und regelmässige Überarbeitung des Codes. Ohne sie häufen sich mit jedem Zyklus technische Schulden, und das Team wird langsamer statt schneller.

Ausserhalb der Software gilt dasselbe Prinzip in anderer Form: Eine Kampagne braucht Freigabeprozesse, ein Organisationsprojekt klare Kriterien, wann eine Veränderung als umgesetzt gilt. Teams, die Geschwindigkeit über Qualität stellen, erleben nach einigen Zyklen, dass Nacharbeit den Fortschritt auffrisst. Eine sichtbare, gemeinsam vereinbarte Definition of Done ist deshalb eines der wirksamsten Mittel für nachhaltige Agilität.

Was ändert sich für Führungskräfte?

Agiles Arbeiten verändert Führung grundlegend. Statt Aufgaben zu verteilen und Fortschritt zu kontrollieren, setzen Führungskräfte Ziele und Rahmenbedingungen, beseitigen Hindernisse und schaffen ein Umfeld, in dem Teams selbst entscheiden können. Der Scrum Guide beschreibt Scrum Teams als selbstmanagend: Sie entscheiden intern, wer was wann und wie tut. Das gelingt nur, wenn Führungskräfte Entscheidungsbefugnisse tatsächlich abgeben und Fehler als Lerngelegenheit verstehen.

Für viele Führungskräfte ist dieser Wechsel schwieriger als für die Teams. Sie verlieren vertraute Kontrollinstrumente und müssen lernen, über Ergebnisse statt über Aktivitäten zu steuern. Hilfreich sind klare Ziele, transparente Backlogs, regelmässige Reviews und offene Gespräche über das, was nicht funktioniert. Die Seite zu Agile Leadership auf flenio.ch vertieft dieses Thema.

Woran erkennen Sie, dass agiles Arbeiten wirkt?

Agilität ist kein Selbstzweck. Ob sie wirkt, zeigt sich an Ergebnissen: Kommen nutzbare Ergebnisse früher und regelmässiger zu den Nutzenden? Wird seltener am Bedarf vorbei entwickelt? Sinkt die Zeit von einer Idee bis zur Nutzung? Steigt die Zufriedenheit von Kunden und Team? Diese Fragen sind aussagekräftiger als die Zahl der durchgeführten Events oder die Velocity eines Teams. Wer sie regelmässig stellt, merkt früh, ob die Einführung in die richtige Richtung geht oder ob nur Rituale übernommen wurden, ohne die Arbeitsweise zu verändern.

Wie gelingt der Einstieg in drei Schritten?

1. 1Ein geeignetes Pilotprojekt wählen: unsichere Anforderungen, ein motiviertes Team, ein Auftraggeber, der regelmässig Zeit für Reviews hat, und ein überschaubarer Umfang von einigen Monaten.
2. 2Das Team gemeinsam starten: Scrum oder Kanban verstehen, Verantwortlichkeiten klären, Definition of Done vereinbaren, Board und Backlog einrichten und einen festen Rhythmus für die Events festlegen.
3. 3Nach drei bis fünf Zyklen auswerten: Was funktioniert, was nicht, was passen wir an? Erst danach weitere Teams einbeziehen und die Erfahrungen gezielt weitergeben.

Dieser schrittweise Ansatz verhindert die häufigste Ursache für gescheiterte Einführungen: ein flächendeckender Start mit vielen Teams gleichzeitig, bevor die Organisation erste Erfahrungen gesammelt hat. Ein erfolgreiches Pilotprojekt überzeugt mehr als jede Schulung, weil es konkret zeigt, wie agiles Arbeiten im eigenen Umfeld aussieht, und weil es die Fragen sichtbar macht, die im eigenen Kontext tatsächlich gelöst werden müssen, etwa Budgetierung, Verträge oder die Zusammenarbeit mit klassisch arbeitenden Bereichen.

Hilfreich ist zudem, früh eine Person mit Erfahrung einzubinden, intern oder extern, die das Team in den ersten Zyklen begleitet. Sie hilft, typische Fehler zu vermeiden, etwa Events ohne Ergebnis, einen Product Owner ohne Entscheidungsbefugnis oder einen Backlog, der eher eine Aufgabenliste als eine geordnete Sammlung von Wert ist. Eine Checkliste für den Start eines agilen Teams steht auf flenio.ch bereit.

Am Ende entscheidet nicht die Methode, sondern die Haltung: Teams, die regelmässig liefern, ehrlich auswerten und ihre Arbeitsweise anpassen, sind agil, unabhängig davon, ob sie Scrum, Kanban oder eine eigene Mischform nutzen. Die Beiträge dieses Leitfadens geben das Handwerkszeug dafür, mit Quellen, Beispielen und Vorlagen für den Alltag in Teams und Organisationen im DACH-Raum.

Wer neu einsteigt, beginnt idealerweise mit der Frage, ob das eigene Vorhaben überhaupt von agilem Arbeiten profitiert, und liest dazu den Beitrag zur Entscheidung zwischen agil und klassisch. Wer bereits agil arbeitet, findet in den Beiträgen zu Events, Retrospektiven, Priorisierung und Metriken konkrete Ansatzpunkte, um die eigene Praxis zu verbessern.

Alle Beiträge nennen ihre Quellen mit Abrufdatum und werden jährlich fachlich geprüft. Grundlage sind die Primärquellen der jeweiligen Ansätze: der Scrum Guide in der Fassung von 2020, der Kanban Guide, das Agile Manifest, die Wissensbasis von SAFe, der Nexus Guide und der agile Leitfaden von HERMES. Wo Praktiken ausserhalb dieser Quellen beschrieben werden, etwa User Stories oder Retro-Formate, ist das als ergänzende Technik gekennzeichnet.

Agiles Arbeiten im DACH-Raum

Im DACH-Raum ist agiles Arbeiten in der Softwareentwicklung längst Standard und breitet sich in Marketing, Beratung, Verwaltung und Organisationsentwicklung aus. In der Schweizer Bundesverwaltung ist mit HERMES agil ein offizielles Vorgehen verfügbar, das Initialisierung und Abschluss klassisch und die Umsetzung agil gestaltet. In Deutschland und Österreich orientieren sich viele Organisationen an Scrum und an Skalierungsframeworks. Einen Vergleich der Projektmanagementansätze HERMES, PMI und IPMA bietet etwa die ZHAW ^[8]. Die folgenden Beiträge vertiefen die einzelnen Themen.