Solche Rückmeldungen tauchen häufig erst einige Wochen nach der Einführung einer neuen Methode oder eines Frameworks auf. Am Anfang verbessert sich vieles: Die Transparenz steigt, Prioritäten werden klarer, Abstimmungen strukturierter. Doch mit der Zeit zeigt sich, dass nicht jede Aufgabe gleich gut funktioniert. Manche passen perfekt in Iterationen, andere lassen sich schlicht nicht planen.

Das liegt selten daran, dass das Team falsch arbeitet. Meist liegt es daran, dass im Projekt mehrere Arten von Arbeit gleichzeitig existieren. Genau an diesem Punkt beginnen viele Teams, Elemente aus Scrum und Kanban zu kombinieren.

Warum ein Framework allein oft nicht ausreicht

Scrum strukturiert komplexe Entwicklung. Kanban stabilisiert den kontinuierlichen Arbeitsfluss. In der Realität treten beide Gegebenheiten oft gleichzeitig auf.  Ein Team entwickelt neue Funktionen und reagiert gleichzeitig auf Fehler, Rückfragen oder kurzfristige Anforderungen. Wird alles in Sprints organisiert und diese Planung geschützt und beibehalten (wie in Scrum gute Praxis ist), kann eine sofortige Reaktionsfähigkeit nicht gegeben sein. Wird alles frei behandelt, kann Chaos und Arbeitsstau entstehen. Weder Scrum noch Kanban geben abschließende Orientierung, wie sich dieses Spannungsfeld auflösen lässt – hier braucht es Kombinationsgeist mit Fingerspitzengefühl für die individuelle Situation eines Teams.

Beispiel aus der Praxis

Ein Softwareentwicklungs-Team arbeitet in zweiwöchigen Sprints an neuen Features. Gleichzeitig trudeln täglich Bugmeldungen und dringende Kundenanfragen ein. Die Folge: Der Sprint wird ständig gestört, Sprintziele werden regelmäßig verfehlt – nicht weil das Team schlecht arbeitet, sondern weil zwei unterschiedliche Arbeitstypen mit demselben Ansatz gesteuert werden.

Hybride Arbeitsweisen entstehen genau so häufig aus praktischer Notwendigkeit. Wie die grundsätzliche Entscheidung zwischen den beiden Ansätzen getroffen werden kann, zeige ich im Artikel Scrum oder Kanban: Wann passt welcher Ansatz?

Häufig geistert der Begriff “Scrumban” für die Kombination von Scrum mit Kanban umher – doch wofür steht dieser?

Was Scrumban eigentlich bedeutet

Scrumban ist kein eigenständiges Framework mit Zertifizierung und Regelwerk. Der Begriff entstand ursprünglich als Übergangsstrategie für Teams, die von Scrum zu Kanban wechseln wollten und hat sich seitdem als Beschreibung für eine ganze, eher undefinierter Klasse hybrider Arbeitsweisen etabliert.

Was Scrumban in der Praxis meint, oder zumindest meinen sollte (wenn der Begriff sorgfältig verwendet wird): Planung bleibt bestehen, aber Aufgaben bewegen sich kontinuierlich durch den Prozess. Iteration und Flow schließen sich nicht aus – sie werden bewusst verbunden. Eine gute Einführung in die Grundunterschiede zwischen beiden Ansätzen bietet übrigens der Vergleichsartikel Kanban oder Scrum.

Merksatz: Scrumban ist idealerweise kein Kompromiss zwischen zwei Methoden, sondern eine bewusste Entscheidung: Welche Arbeit braucht Struktur – und welche braucht Fluss?

Wie Scrumban konkret aussehen kann

In der Praxis zeigen sich wiederkehrende Muster. Hier sind drei, die besonders häufig auftauchen:

Muster 1: Sprints mit Kanban-Visualisierung

Ein Team plant weiterhin in zweiwöchigen Iterationen. Die Arbeit wird jedoch nicht nur als Sprintziel betrachtet, sondern als Fluss visualisiert. Das Board zeigt, wo Aufgaben stehen und wo sich Arbeit staut. WIP-Limits (Begrenzung der gleichzeitig erledigten Arbeit) verhindern, dass einzelne Arbeitsschritte überlaufen.

Der Vorteil: Die Planung bleibt stabil, Engpässe werden früher sichtbar – noch während des Sprints, nicht erst in der Retrospektive.

Beispiel aus der Praxis

Ein Produktteam nutzt ein Sprint-Board mit Atlassian Jira, setzt sich aber zusätzlich WIP-Limits pro Spalte. In der dritten Woche fällt auf: In der Spalte „In Review“ stauen sich regelmäßig 5–6 Aufgaben. Das Team reduziert den WIP-Limit auf 3 und etabliert ein tägliches kurzes Review-Pairing. Die durchschnittliche Umsetzungszeit sinkt in der Folge messbar, da sich der Fokus im Sprint auf einzelne Themen erhöht.

Muster 2: Zwei parallele Bereiche auf einem Board

Ein Entwicklungsteam arbeitet in Sprints, während Support- oder Betriebsarbeit kontinuierlich erfolgt. Beides läuft über ein gemeinsames Board – aber in getrennten Abschnitten (“Swimlanes”). Neue, ungeplante Aufgaben können so aufgenommen werden, ohne die gesamte Sprintplanung zu gefährden.

Der Effekt: Weniger Diskussionen über „unterbrochene Sprints“, mehr Klarheit über tatsächliche Kapazität. Das Team weiß von Anfang an und plant dies ein: Ein Teil der Kapazität gehört dem Unvorhergesehenen.

Beispiel aus der Praxis

Ein Kundenplattform-Team reserviert in jedem Sprint bewusst 20% der Kapazität für dringende Ad-hoc-Aufgaben. Diese laufen auf dem Board in einer eigenen Spur. Ergebnis: Die Feature-Entwicklung bleibt planbar, und Kundenanfragen werden trotzdem schnell bedient – ohne dass beides miteinander konkurriert.

Muster 3: Schlanke Meetings – aber kein Wegfall

Viele Teams behalten kurze tägliche Abstimmungen bei, reduzieren aber starre Routinen. Retrospektiven finden beispielsweise monatlich statt nach jedem Sprint und werden so effektiv abgehalten, dass zusätzliche Abstimmungen reduziert werden können. Planung bleibt erhalten, Feedbackzyklen ebenso – aber besser angepasst an den Rhythmus der Arbeit.

Wichtig: Das bedeutet nicht, Meetings einfach wegzulassen. Es bedeutet, sie an den Arbeitsfluss bestmöglich anzupassen. Für verteilte Teams ist das ein besonders relevanter Hebel – mehr dazu im Artikel 5 Tipps für Remote-Teams.

Quick-Check: Wann welche Anpassung sinnvoll ist

Hier eine Übersicht, die bei der Entscheidung helfen kann, ob und wie ein hybrides Modell mit Elementen aus Scrum und aus Kanban sinnvoll ist:

Kein Kriterium allein ist entscheidend. Wichtig ist der Gesamtblick: Wie viel der täglichen Arbeit ist planbar – und wie viel nicht? Alles, was nicht eindeutig beantwortet werden kann, sondern irgendwo dazwischen: Hier können Kombinationen der Elemente aus Scrum und Kanban besonders wirksam sein (Hinweis: Dazu am besten eine gute Begleitung in Form eines erfahrenen Coaches suchen).

Faustregel: Wenn mehr als 30% der täglichen Arbeit nicht aus dem Sprint-Backlog stammt, lohnt es sich zu prüfen, ob die aktuelle Arbeitsweise noch zur Realität des Teams passt.

Praxisbeispiel: Wenn Planung auf Realität trifft

Ein Unternehmen entwickelt eine neue Kundenplattform. Das Team arbeitet zunächst streng nach Scrum – jede Aufgabe im Sprint geplant, das Sprintziel fest definiert.

Nach einigen Wochen zeigt sich: Täglich kommen Sonderfälle. Kundendaten müssen kurzfristig angepasst werden, bestimmte Nutzer brauchen sofortige Lösungen. Die Sprintplanung wird regelmäßig gestört – obwohl das Team effizient arbeitet.

Das Team entscheidet sich nicht gegen Scrum, sondern für mehr Transparenz:

• Features bleiben geplant und laufen im Sprint wie bisher
• Dringende Aufgaben erhalten eine eigene Swimlane mit einem WIP-Limit von 2
• In der Sprintplanung wird bewusst ein Puffer von 15–20 % eingeplant
• Die Retrospektive analysiert regelmäßig das Verhältnis von geplanter zu ungeplanter Arbeit

Die Folge: weniger Konflikte über Prioritäten, ein realistischerer Blick auf den Arbeitsaufwand und ein Team, das endlich aufgehört hat, sich für „unterbrochene Sprints“ zu entschuldigen.

Wann eine Kombination aus Scrum und Kanban besonders sinnvoll wird

Eine Kombination hilft besonders, wenn mehrere Arbeitsmodi gleichzeitig existieren:

• Produktentwicklung plus Wartung
• Projektarbeit plus Support
• Planbare Releases plus kurzfristige Anforderungen
• Neuentwicklung plus laufender Betrieb

Je stärker ein Produkt in den Betrieb übergeht, desto häufiger entsteht diese Mischung. Strenges Festhalten am Framework wie zu Entwicklungsbeginn wirkt sich dann oft nicht flexibel oder nicht genug an die Situation angepasst aus. 

Wichtig: Es geht nicht darum, Regeln etwa von Scrum einfach wegzulassen. Es bedeutet, verschiedene Arten von Arbeit sichtbarer zu machen und bewusst zu steuern.

Teams sollten sich regelmäßig folgende Fragen stellen:

• Welche unserer Arbeit ist planbar – und welche ist reaktiv?
• Wie viel Kapazität braucht jede Arbeitsart?
• Welche Meeting-Formate passen noch zu unserem Rhythmus?
• Wo entstehen Engpässe – und woran erkennen wir sie frühzeitig?

Nicht weniger Struktur ist das Ziel – sondern passende Struktur. Wer verschiedene Elemente einführt und kombiniert, sollte das explizit besprechen und dokumentieren, damit alle im Team dieselbe Vorstellung davon haben, wie zusammengearbeitet wird.

Fazit

“Scrum oder Kanban” ist selten die eigentliche Frage. Diese lautet vielmehr: “Welche Art von Arbeit haben wir gerade und was braucht sie?”

Planbare Entwicklung profitiert von Struktur. Kontinuierliche Aufgaben profitieren von Flow. Viele Teams brauchen beides gleichzeitig – und genau dafür bietet eine Kombi aus Scrum und Kanban einen pragmatischen Rahmen.

Hybride Arbeitsweisen sind kein Kompromiss und kein Zeichen dafür, dass etwas „gescheitert“ ist. Sie sind eine bewusste Entscheidung, die Arbeitsweise regelmäßig an Realität und Ziele anzupassen. Agilität entsteht nicht durch das Befolgen eines Modells, sondern durch reflektiertes Arbeiten.

FAQ – Scrum, Kanban und hybride Arbeitsweisen

Kann man Scrum und Kanban gleichzeitig nutzen?

Ja. Häufig planen Teams Features in Sprints und steuern ungeplante Aufgaben über ein kontinuierliches Board mit WIP-Limits. Entscheidend ist, dass beide Boardbereiche für das gesamte Team sichtbar und transparent sind und klar ist, nach welchen Regeln priorisiert wird.

Wann sollte ein Team darüber nachdenken, kombinierte Elemente aus Scrum und Kanban einzuführen?

Wenn regelmäßig ungeplante Aufgaben Sprintziele verdrängen oder Planung und Realität sichtbar auseinanderlaufen, kann die Ursache auch darin liegen, dass mehrere Arbeitstypen parallel existieren. Das ist dann kein Versagen des Frameworks, sondern ein Signal, dass die Arbeitsweise angepasst werden sollte.

Was ist “Scrumban” genau?

Das Konzept von “Scrumban” beschreibt eine mögliche Kombination aus strukturierter Planung (Scrum) und kontinuierlicher Flusssteuerung (Kanban), ohne ein eigenes starres Regelwerk zu definieren. Der Begriff ist eher beschreibend als normativ – er sagt, was Teams tun, nicht wie sie es exakt tun sollen.

Macht dies Scrum überflüssig?

Nein. Die Struktur bleibt erhalten. Sie wird lediglich ergänzt, um besser zur tatsächlichen Arbeitsweise zu passen. Scrum mit Kanban ist kein Ausstieg aus Scrum, sondern eine Erweiterung.

Sollte man direkt mit der Kombination aus Scrum und Kanban starten?

In der Regel hilft es, zunächst ein Framework kennenzulernen und zu verstehen, wie und warum es funktioniert. Eine Kombination entsteht sinnvoll, sobald echte Arbeitsmuster sichtbar werden – und das Team eine fundierte Basis hat, von der aus es bewusst anpasst.

Wie messe ich, ob mein Ansatz funktioniert?

Achtet auf konkrete Signale: Werden Sprintziele häufiger erreicht? Sinkt die Cycle Time (Umsetzungsdauer) für ungeplante Aufgaben? Gibt es weniger Konflikte über Prioritäten? Werden Retrospektiven wieder produktiver? Das sind verlässlichere Indikatoren als das Gefühl, „agiler“ zu sein.

Der Beitrag Scrum mit Kanban in der Praxis: Iterative Planung und Flow erfolgreich verbinden erschien zuerst auf Blog Antje Lehmann Training + Consulting.

Diese Frage höre ich oft in meiner Arbeit als Scrum Master und Agile Coach. Und die schlechte Nachricht: Es gibt keine pauschale Antwort, die für alle Teams passt.

Die gute Nachricht: Es gibt klare Kriterien und konkrete Situationen, die bei der Entscheidung helfen. Wer die richtigen Fragen stellt und die Rahmenbedingungen seines Teams kennt, kann eine fundierte Wahl treffen.

Die Entscheidung: Keine Glaubensfrage, sondern eine Frage der Voraussetzungen

In der Theorie klingen beide Ansätze gut. Scrum verspricht einen Rahmen mit logischem Aufbau und klaren Verantwortlichkeiten. Kanban bietet einen flexiblen Ansatz mit (bei guter Anwendung) besserem, kontinuierlichen Fluss. Beide wecken Hoffnungen auf weniger Abstimmungsmeetings. In der Praxis zeigt sich: Die Entscheidung hängt von sehr konkreten Faktoren ab.

Bevor wir uns die einzelnen Szenarien ansehen, lohnt sich ein Blick auf die wichtigsten Entscheidungskriterien. Dazu könnt ihr euch als Team folgende Fragen stellen:

Wie stabil ist euer Team?
Scrum-Teams profitieren davon, wenn sie fest und idealerweise auch schon eingespielt sind, mit klaren Verantwortlichkeiten und längerfristiger Perspektive. Wenn das Team oft wechselt oder Ressourcen generell unsicher sind, kann Scrum schlechter funktionieren und eventuell Kanban der passendere Ansatz sein.

Wie planbar ist eure Arbeit?
Scrum funktioniert besser bei klaren, gut gepflegten Product Backlogs und einer Planbarkeit für zumindest den Zeitraum einer Iteration (eines Sprints). Kanban eignet sich hingegen gut bei kontinuierlichem, aber unvorhersehbarem Input — etwa, wenn euer Team viel mit Support, Betrieb, Bugs und ähnliche Aufgaben, die ungeplant hereinkommen, beschäftigt ist.

Wie viel Zeit habt ihr für Abstimmung?
Scrum bringt feste Events mit sich: Planning, Daily, Review, Retrospektive. Auch wenn diese den Abstimmungsbedarf bereits auf ein notwendiges Minimum reduzieren sollen – wer selbst dafür wenig Zeit hat oder stark verteilt arbeitet, kann von einem Kanban-Setup mit weniger eingeplanter Meetingzeit bereits profitieren – wenn auch vielleicht mit Einbußen, da natürlich Abstimmungsmöglichkeiten verloren gehen.

Was wollt ihr erreichen?
Mehr Fokus, bessere Vorhersagbarkeit für die Zeiträume von ein oder zwei Sprints, klare Verantwortlichkeiten, effektive Zielsetzung- und -erreichung, Lernzyklen in komplexen Umgebungen? Dann eher Scrum.
Mehr Flow, kürzere Durchlaufzeiten, flexible Steuerung, effizientere Zusammenarbeit? Dann können Euch zwar beide Ansätze helfen, aber Kanban kann je nach Beantwortung der anderen Fragen schon sehr viele Vorteile bringen.

Wann Scrum die richtige Wahl ist

Scrum entfaltet seine Stärken besonders in folgenden Szenarien:

1. Komplexe Produktentwicklung mit vielen Beteiligten
Wenn ein Team an einem komplexen Produkt oder Feature arbeitet und regelmäßige Planung und Feedback wichtig sind, bietet Scrum den idealen Rahmen. Die Sprint-Struktur hilft, komplexe Anforderungen in überschaubare Häppchen zu zerlegen und schrittweise Ergebnisse zu liefern.

Beispiel aus der Praxis: Ein Start-up entwickelt eine neue Finanz-App. Das Entwicklungsteam arbeitet in zweiwöchigen Sprints. Jeder Sprint endet mit einem Review, bei dem das Team neue Features direkt mit ersten Nutzern testet. Das Feedback fließt in den nächsten Sprint ein. So kann das Team schnell lernen und Anpassungen vornehmen, ohne monatelang in die falsche Richtung zu entwickeln.

2. Feste Taktung
Scrum bringt einen stabilen Arbeitsrhythmus ins Vorhaben des Teams. Mit regelmäßigen Sprints (z.B. immer 2 oder 3 Wochen lang – mehr als 4 sollten es laut Scrum Guide nicht sein) und Reviews stellen sich Teams so auf, dass sie kontinuierlich Neues liefern, und der Fortschritt lässt sich besonders nach den ersten Sprints immer besser einschätzen. Das ist auch dann wertvoll, wenn externe Stakeholder auf Zusagen angewiesen sind.

Beispiel aus der Praxis: Ein E-Commerce-Unternehmen bereitet sich auf die Weihnachtssaison vor. Das Team muss bis Ende Oktober neue Payment-Optionen und verbesserte Checkout-Prozesse live bringen. Mit Scrum kann das Team in 2-Wochen-Sprints arbeiten, am Ende jedes Sprints den Fortschritt zeigen und transparent machen, ob der Termin gehalten werden kann. Wenn nicht, können sie gemeinsam mit ihren Stakeholdern schnell sprechen und, wenn notwendig, gegensteuern.

3. Cross-funktionale Teams mit hoher Autonomie
Scrum funktioniert am besten mit Teams, die gemeinsam Verantwortung übernehmen, schnell auf Feedback reagieren können und ihre Arbeit weitgehend selbst organisieren. Die klaren Verantwortlichkeiten im Team (Product Owner, Scrum Master, Developers) schaffen Orientierung, ohne Mikromanagement zu betreiben. Gleichzeitig verteilen sie die vielen verschiedenen Perspektiven der Teamarbeit auf unterschiedliche Schultern, so dass sich alle auf ihren Aufgabenbereich konzentrieren können.

Beispiel aus der Praxis: Ein Softwarehaus entwickelt eine neue CRM-Lösung. Das Team besteht aus Frontend-Entwicklern, Backend-Entwicklern, UX-Designern und QA-Testern. Alle sitzen im selben Scrum-Team als “Developers” und arbeiten gemeinsam an User Storys aus dem Backlog. Durch die Scrum Daily Events jeden Morgen sieht jeder, woran die anderen gerade arbeiten, ob sie Unterstützung brauchen, und ob es Abhängigkeiten geben könnte.

4. Notwendigkeit für regelmäßige Lern- und Verbesserungszyklen
Wenn sich das Produkt dank Kundenfeedback zwar inhaltlich weiterentwickelt und nur langsam Form annimmt, das Team aber trotzdem eine klare Struktur für Releases braucht, ist Scrum ein gut geeigneter Rahmen. Ganz wichtig dabei: Die Retrospektive am Ende jedes Sprints, die dafür sorgt, dass das Team nicht nur am Produkt, sondern auch an der eigenen Arbeitsweise feilt.

So startet Ihr mit Scrum:

• Team sowie Sprintplanung aufsetzen und Sprintdauer festlegen (z.B. 2-Wochen-Zyklen mit klaren Zielen)
• Backlog mit ersten User Storys erstellen und priorisieren (digital z.B. mit Atlassian Jira, Azure DevOps oder anderen Tools – gerne auch auf Zetteln an einem Whiteboard)
• Daily Scrums für die Team-Synchronisation aufsetzen
• Sprint-Reviews (mit Stakeholdern) und Retrospektiven (mit dem Team) für kontinuierliche Verbesserungen etablieren
• Backlog kontinuierlich verfeinern

Beispiel für Scrum-Board in Atlassian Jira mit Sprintziel (Cloud)

Wann Kanban eine gute Wahl ist

Die Wahl zwischen den Ansätzen ist nicht immer klar vorzugeben. Die Kanban-Methode zeigt aber ihre Stärken besonders in teilweise anderen Situationen:

1. Kontinuierlicher, unvorhersehbarer Arbeitsfluss
Wenn Aufgaben kontinuierlich und unvorhersehbar hereinkommen — ohne dass sich feste Iterationen sinnvoll planen lassen — ist Kanban ein idealer Ansatz. Die Methode sorgt für klaren Überblick und konzentriert sich darauf, dass die Arbeit fließt und Engpässe erkannt und beseitigt werden.

Beispiel aus der Praxis: Ein IT-Support-Team bearbeitet täglich zwischen 20 und 100 Tickets — von einfachen Passwort-Resets bis zu komplexen Systemausfällen. Mit Kanban visualisiert das Team alle offenen Tickets auf einem Board. Sobald die Spalte „In Progress“ zu voll wird, ist sofort klar: Es gibt einen Engpass. Das Team kann dann gemeinsam entscheiden, ob Prioritäten verschoben oder zusätzliche Ressourcen aktiviert werden müssen. Sie können auch Spaltenbegrenzungen (“WIP-Limits”) einführen, um ein Überlaufen zu vermeiden.

Beispiel-WIP-Limit (Einstellung in einem Kanban-Board in Atlassian Jira)

2. Wechselnde Prioritäten und häufige Ad-hoc-Anfragen
Wenn Anforderungen sich ständig ändern, bietet Kanban die Flexibilität, Aufgaben schnell neu zu priorisieren, ohne den Arbeitsfluss zu sehr zu stören. Vielleicht auch, weil das Team eher im Produkt-Betriebsmodus als an der Neuentwicklung arbeitet.

Beispiel aus der Praxis: Ein Migrationsteam überführt über 1.000 Kundendatensätze aus Altsystemen in eine neue Plattform — parallel zum laufenden Betrieb. Täglich kommen neue Anforderungen von Kunden, die dringend bestimmte Daten benötigen. Mit Kanban kann das Team flexibel reagieren: Dringende Aufgaben wandern nach oben im Backlog, werden gezogen, sobald Kapazität frei wird, und das Team behält durch WIP-Limits den Überblick.

3. Fokus auf Durchsatz (engl. Throughput) und kürzere Zykluszeiten (Cycle Times)
Wenn es darum geht, möglichst schnell möglichst viele Aufgaben abzuarbeiten — und weniger darum, komplexe Features schrittweise zu entwickeln — kann Kanban gut glänzen. Die Metriken Cycle Time (wie lange braucht eine Aufgabe vom Start bis zum Abschluss?) und Throughput (wie viele Aufgaben schaffen wir pro Woche?) helfen, die Effizienz zu steigern. Scrum-Teams, die hiervon ebenfalls profitieren möchten, finden dazu übrigens hier wertvolle Tipps.

Beispiel aus der Praxis: Ein Wartungsteam ist verantwortlich für kleinere Updates und Bugfixes an einer etablierten Software. Mit Kanban trackt das Team seine Cycle Time und stellt fest: Bestimmte Arten von Tickets dauern systematisch länger. Das Team führt eine neue Regel ein: Komplexere Tickets werden vorher in kleinere Teilaufgaben zerlegt. Ergebnis: Die durchschnittliche Cycle Time sinkt um 30%.

4. Teams mit wenig Zeit für Meetings
Kanban schreibt per se weder Rollen noch feste Meetings / Events vor. Teams, die stark verteilt arbeiten oder wenig Zeit für Besprechungen haben, können mit einem schlanken Kanban-Setup trotzdem von mehr Transparenz in ihrer Arbeit profitieren.

So setzt ihr euren Kanban-Ansatz um:

• Überlegt euch, wer euer Team darstellt und denkt dabei auch an euren Wertstrom – wo braucht ihr mehr Transparenz und bessere Arbeitsorganisation?
• Nutzt ein physisches Board oder digitale Tools wie Trello, Jira oder Asana
• Visualisiert alle Aufgaben und Phasen und überlegt euch einen sinnvollen Prozess für den Arbeitsfluss (z.B. „To Do“, „In Progress“, „Review“, „Done“)
• Beobachtet Arbeitsstaus und reagiert darauf
• Bonus: Messt regelmäßig Cycle Time und Throughput, um Verbesserungspotenziale zu erkennen
• Bonus: Definiert klare Work-in-Progress-Limits für jede Spalte, um Fokus zu behalten – am besten ist es, wenn das Team dies nach einiger Zeit von sich aus einfordert, weil die Notwendigkeit gesehen wird. Kanban lebt von evolutionärer Verbesserung aus dem Team heraus
• Bonus: Trefft euch immer wieder zu Retrospektiven, in denen ihr eure Arbeitsweise und Verbesserungen gemeinsam beleuchtet

Entscheidungshilfe Scrum oder Kanban: Der Quick-Check

Hier eine kompakte Übersicht, die bei der Entscheidung helfen kann:

Scrum passt gut, wenn:

• Ihr an komplexen Produkten oder Features arbeitet
• Regelmäßige, iterative Planung und Feedback wichtig sind
• Ihr Sprints braucht, um Ergebnisse fokussierter zu liefern
• Ihr in einem cross-funktionalen Team arbeitet
• Regelmäßige Events (Dailys, Retrospektiven) für euch sinnvoll sind

Kanban passt gut, wenn:

• Ihr mit anderen Abteilungen mehr Austausch sucht
• Aufgaben kontinuierlich und ungeplant hereinkommen und Prioritäten sich häufig ändern
• Ihr flexibel auf Ad-hoc-Anfragen reagieren müsst
• Das Team wenig Zeit für Besprechungen hat
• Ihr an Support, Wartung, Betrieb oder Migration arbeitet

Und was ist mit Kombinationen?

In der Realität halten sich Teams selten strikt an nur ein Framework. Viele kombinieren Elemente aus Scrum und Kanban, etwa Sprints mit Kanban-Boards, oder feste Events mit flexiblem Flow. Doch das ist ein eigenes Thema, dem wir uns im nächsten Artikel widmen werden.

Wichtig: Nicht dogmatisch entscheiden

Die Wahl zwischen Scrum und Kanban ist kein Bekenntnis fürs Leben. Viele Teams starten zunächst mit einem Ansatz und passen ihre Arbeitsweise im Laufe der Zeit an.

Beispiele aus der Praxis:

• Teams starten mit Kanban, weil es niedrigschwelliger ist und wechseln später zu Scrum, weil sie doch vom zielorientierten Arbeiten in Sprints profitieren können
• Produktentwicklungs-Teams arbeiten mit Scrum, wechseln dann zu Kanban, wenn sie von einem Neuentwicklungs- eher in eine Art Betriebsmodus ihres Produkts übergehen
• Teams bleiben bei Scrum, wenden aber Kanban-Praktiken wie WIP-Limits oder Cycle Time-Messung an

Das Wichtigste: Testet, sprecht drüber, lernt. Seid bereit, eure Arbeitsweise anzupassen, wenn sich die Rahmenbedingungen ändern. Sucht euch erfahrene Begleitung.

Fazit

Die Entscheidung zwischen Scrum und Kanban ist keine Glaubensfrage, sondern eine Frage der Voraussetzungen und Ziele. Wer von der Taktung und Struktur profitieren kann, fährt mit Scrum sehr gut. Wer dagegen besonders viel Flexibilität benötigt und mit wechselnden Prioritäten bei ständigem Anforderungseingang auf einen guten Arbeitsfluss setzen möchte, ist mit Kanban gut bedient.

Am Ende geht es nicht darum, das „richtige“ Framework zu finden, sondern ein Arbeitsmodell zu entwickeln, das zum Team, zum Produkt und zu den Rahmenbedingungen passt und das sich mit den Anforderungen weiterentwickelt.

Scrum oder Kanban sind keine “Patentrezepte” für Agilität, sondern Werkzeuge, die ihre Wirkung nur im passenden Kontext entfalten. Entscheidend ist nicht, welchem Ansatz ihr folgt, sondern wie gut eure Arbeitsweise zu eurem Team, euren Zielen und euren Rahmenbedingungen passt. Wer strukturiert lernen, planen und liefern will, findet mit Scrum einen starken Rahmen. Wer mit hoher Dynamik, wechselnden Prioritäten und kontinuierlichem Arbeitsfluss umgehen muss und dabei hohe Transparenz möchte, ist mit Kanban oft gut beraten. Erfolgreiche Teams bleiben dabei neugierig, reflektieren regelmäßig und entwickeln ihr Vorgehen weiter – statt sich starr an ein Modell zu klammern.

FAQ: Scrum oder Kanban. Wann passt welches Framework?

Kann man Scrum und Kanban gleichzeitig nutzen?
Ja, und das ist sogar sehr verbreitet. Viele Teams arbeiten in Sprints und nutzen ein einfaches Kanban-Board zur Visualisierung der Arbeit im Sprint, in dem sie auch WIP-Limits einsetzen. Andere kombinieren Scrum für geplante Feature-Entwicklung mit Kanban für ungeplante Support-Aufgaben. Wichtig ist nur, dass alle im Team verstehen, wie zusammengearbeitet wird. 

Wie entscheide ich, wenn mein Team völlig neu ist?
Für neue Teams und/oder solche, die mit agilen Arbeitsweisen noch nicht sehr vertraut sind, kann Scrum mit seinen klaren Rollen und Events Orientierung geben. Allerdings sollte das Team nicht überfordert werden und verstehen, wie und warum es so arbeitet — dann ist es wichtig, dass das Team vom Scrum Master gut begleitet wird. Kanban kann eine Alternative sein, wenn das Team schon sehr selbstorganisiert arbeitet – oder auch, um dieses zunächst zu fördern. Hier kann auch zunächst mit dem Notwendigsten (Board, Arbeitsablauf) gestartet und dann nach und nach die Methode erweitert und verfeinert werden.

Was mache ich, wenn das Team sich nicht einigen kann?
Testet beide Ansätze für jeweils 4 Wochen und entscheidet dann gemeinsam. Dokumentiert dabei: Was lief gut? Was war schwierig? Was hat gefehlt? Diese Erfahrungswerte sind oft aussagekräftiger als theoretische Überlegungen.

Muss ich den Scrum Guide oder die Kanban-Prinzipien zu 100% umsetzen?
Gerade am Anfang ist es sinnvoll, sich an den Grundprinzipien zu orientieren und diese zunächst zu verstehen. Teams dürfen (und sollen) ihre Arbeitsweise anpassen, gerade bei Kanban ist diese Grundidee auch in die Methode eingebaut. Wer Dinge aus dem Scrum Guide weg lässt oder verändert, riskiert eine Verwässerung des Ansatzes, aber dennoch sollte jeder Start mit Scrum natürlich mit Bedacht und Umsicht vonstatten gehen. Wichtig ist nur: Reflektiert regelmäßig, ob eure Arbeitsweisen noch sinnvoll sind und wo es Verbesserungspotential gibt.

Wie erkenne ich, ob unser aktueller Ansatz noch passt?
Achtet auf Warnsignale: Fühlen sich Meetings und Austausche wie Zeitverschwendung an? Werden Sprintziele regelmäßig nicht geschafft oder sind sie kaum noch planbar aufgrund zu vieler Ad-Hoc-Themen? Staut sich die Arbeit an bestimmten Stellen? Gibt es häufige Konflikte über Prioritäten? Solche Anzeichen können bedeuten, dass die gewählte Arbeitsweise, aber oft auch die Ausgestaltung dieser, Optimierungsbedarf hat.

Was, wenn mein Unternehmen (oder bei externer Mitarbeit auch: Unternehmskunde) auf einen bestimmten Ansatz besteht?
Manche Unternehmen haben Standards (z.B. „alle agilen Teams bei uns arbeiten mit Scrum“). Das kann aber in manchen Situationen hinderlich sein. Versucht in diesem Fall, so viel Flexibilität wie möglich zu schaffen — zum Beispiel durch die Anpassung von Sprint-Längen oder durch die Kombination mit Kanban-Elementen.

Der Beitrag Wann passt welcher Ansatz? Das Scrum Framework oder Kanban als Methode richtig einsetzen erschien zuerst auf Blog Antje Lehmann Training + Consulting.

Beide Ansätze können die Team-Agilität fördern, beide steigern Transparenz und Zusammenarbeit, und beide sind längst bereits in IT wie auch in vielen anderen Bereichen im Einsatz. Trotzdem unterscheiden sie sich grundlegend, etwa in Grundideen, Struktur, Rhythmus und Flexibilität.

Wer die Unterschiede versteht, kann nicht nur die richtige Wahl für sein Team treffen, sondern auch typische Stolperfallen vermeiden.

Scrum: feste Verantwortlichkeiten und ein klarer Takt

Scrum entstand Anfang der 1990er-Jahre. Jeff Sutherland und Ken Schwaber entwickelten das Framework, inspiriert durch ein Harvard Business Review-Paper von Takeuchi und Nonaka („The New New Product Development Game“, 1986). Darin wurde Produktentwicklung als Teamsport beschrieben, bei dem interdisziplinäre Gruppen eng gemeinsam, wie bei einem Rugby-Scrum („Gedränge“), arbeiten.

Wer dem Scrum-Framework folgt, teilt Arbeit in kurze, feste Zyklen: sogenannte Sprints. Ein Sprint dauert meist ein bis maximal vier Wochen. Ziel ist es, am Ende jedes Sprints (manchmal auch Iteration oder Arbeitszyklus genannt) ein potenziell nutzbares Ergebnis zu liefern. Ein neuer Ansatz für viele: statt monatelang vor sich hin zu entwickeln, verpflichten sich Scrum-Teams, früh und häufig echte Ergebnisse zu liefern.

Charakteristisch für Scrum sind die klar definierten Verantwortlichkeiten im Team:

• Ein Product Owner im Scrum-Team vertritt die Interessen der Stakeholder und priorisiert die Arbeit.
  
• Ein Scrum Master im Scrum-Team achtet auf die Einhaltung des Frameworks und fördert die Zusammenarbeit und Optimierung dieser.
  
• Die Developerinnen und Developer planen ihre Sprints gemeinsam mit Product Owner und Scrum Master und setzen dann die Arbeit um.
  

Unterstützt wird dieses Zusammenspiel durch die regelmäßigen Events in Scrum: Planning, Daily, Review und Retrospektive. Sie geben dem Projekt einen festen Rhythmus, der wie ein “Herzschlag” wirkt (Aussage im Scrum Guide). Dadurch sind die Strukturen verlässlich, wiederkehrend und planbar. Durch die eingebaute Feedbackschleifen in jedem Zyklus hat das Team außerdem regelmäßige Gelegenheiten, immer besser in der Zusammenarbeit werden

Der große Vorteil: Scrum ist ideal, wenn Vorhanden besonders komplex sind und viel Austausch und Lernzyklen notwendig ist. Kurze Feedbackschleifen helfen, schnell zu reagieren und Anpassungen vorzunehmen. Wer tiefer einsteigen will, findet die Details im Scrum Guide.

Beispiel aus der Praxis: Ein Team entwickelt eine neue App. Mit Scrum können Features in zweiwöchigen Abständen direkt gemeinsam mit den Nutzern getestet und verbessert werden. Nutzerfeedback fließt dabei in den nächsten Sprint ein.

Kanban: der kontinuierliche Fluss

Kanban als Methode hat eine andere Geschichte und Eigenschaften als das Scrum-Framework. Die Wurzeln liegen weiter in der Vergangenheit. In den Jahrzehnten nach dem 2. Weltkrieg entwickelte Toyota ein Produktionssystem, das Materialflüsse über einfache Karten (Kanban = „Karte“ oder „Schild“ auf Japanisch) steuerte. Ziel war es, Überproduktion zu vermeiden und nur das zu produzieren, was gerade gebraucht wurde – ein frühes Pull-System.

In den 2000er-Jahren übertrugen Software-Teams diese Prinzipien auf Wissensarbeit. Einer der Pioniere war David J. Anderson, der Kanban als Methode für IT-Teams formulierte und populär machte.

Statt Arbeit in feste Zeitabschnitte zu pressen, setzt Kanban auf kontinuierlichen Fluss. Jede Aufgabe durchläuft verschiedene Phasen: häufig in etwa von „To Do“ über „In Progress“ (oder “In Process”) bis „Done“. Sichtbar wird das Ganze auf einem Kanban-Board, das heute meist digital geführt wird, etwa mit Tools wie Jira, Planner oder Trello.

Ein wichtiges Steuerungselement von Kanban-Teams sind die Work-in-Progress-Limits (WIP). Sie legen fest, wie viele Aufgaben gleichzeitig bearbeitet werden dürfen. So wird Überlastung vermieden und werden Engpässe sichtbar – und das Team konzentriert sich auf das Wesentliche.

Ein Vorteil von Kanban liegt in der Flexibilität der Methode. Neue Aufgaben können jederzeit hinzugefügt oder Prioritäten geändert werden, ohne dass ein kompletter Plan über den Haufen geworfen werden muss. Auch Support- oder Betriebsteams profitieren davon, wenn sie oft auf Ad-hoc-Anfragen reagieren müssen.

Beispiel aus der Praxis: Ein IT-Support-Team nutzt Kanban, um Tickets zu priorisieren. Sobald die Spalte „In Progress“ zu voll wird, ist klar: Es gibt einen Engpass, den das Team lösen muss.

Kanban und Scrum im Vergleich: Die Unterschiede im Überblick

Um die Unterschiede auf einen Blick sichtbar zu machen, lohnt sich ein direkter Vergleich:

Scrum bringt also vor allem iterative Lern- und Anpassungszyklen und damit eine gewisse Struktur, Kanban dagegen fokussiert sich mehr auf Flow und kapazitätsbasiertes Arbeiten.

Empfehlungen

Scrum kann die richtige Wahl, wenn ein Team ein komplexes Produkt entwickelt, etwa eine neue App oder ein größeres Feature. Hier braucht es klare Verantwortlichkeiten und einen festen Takt, um Orientierung zu geben. Die Sprint-Taktung hilft, sich auf kurzfristige Ziele zu konzentrieren, ohne das große Ganze aus dem Blick zu verlieren.

Kanban hingegen punktet besonders dann, wenn Aufgaben unregelmäßig und oft ungeplant hereinkommen. Support-Tickets, Wartungsaufgaben oder unvorhersehbare Betriebsanforderungen lassen sich in einem fließenden System viel leichter steuern. Das Kanban-Board schafft Transparenz, und die WIP-Limits verhindern, dass das Team sich verzettelt.

Fazit 

Die Entscheidung zwischen Scrum und Kanban ist keine Glaubensfrage, sondern auch eine Frage der Voraussetzungen. Wer gerade von der Taktung profitieren kann, fährt mit Scrum sehr gut. Wer dagegen besonders viel Flexibilität benötigt und mit wechselnden Prioritäten bei ständigem Anforderungseingang auf einen guten Arbeitsfluss setzen möchte, ist mit Kanban gut bedient.

In der Praxis zeigt sich: Viele Teams starten zunächst z.B. mit Scrum und nehmen sich später Elemente von Kanban hinzu – oder umgekehrt. Das ist ebenfalls legitim (solange sich alle Beteiligten im Klaren sind, wie zusammengearbeitet wird), um ein Arbeitsmodell zu finden, das zum Team, zum Produkt und zu den Rahmenbedingungen passt.

FAQ: Scrum oder Kanban?

Wann Scrum und wann Kanban?
Scrum eignet sich dann sehr gut, wenn ein Team von iterativen Abläufe und Lernzyklen profizieren kann, etwa bei komplexen Produktentwicklungen mit vielen Beteiligten. Kanban ist besonders sinnvoll, wenn Anforderungen häufig wechseln und Aufgaben flexibel gesteuert werden müssen, z. B. in Support- oder Betriebsteams.

Wann ist es schwierig, mit Kanban zu arbeiten?
Kanban kann an Grenzen stoßen, wenn die Arbeit eines Teams stark von anderen abhängt. Gerade ohne klaren Takt kann es passieren, dass die Koordination leidet. Lösungsansätze können darin liegen, die anderen Teams in das Kanban-System einzubinden.

Wann entscheidet man sich eventuell nicht für Scrum?
Scrum ist weniger geeignet, wenn neue Aufgaben unregelmäßig und kurzfristig auftreten, etwa im 24/7-Support. Auch sehr kleine Teams ohne klare Rollenverteilung profitieren oft nicht von den Scrum-Abläufen in ihrer Gänze. Unabhängig davon kommt es auch nicht selten es vor, dass Produktentwicklungs-Team dann zu Kanban wechseln, wenn sie von einem Neuentwickungs- eher in eine Art Betriebsmodus ihres Produkts übergehen.

Was gibt es darüber hinaus noch zu beachten?
Kanban bietet Flexibilität, aber weniger klare Verantwortlichkeiten und nicht unbedingt immer eine kurzzyklige Taktung. Das kann dazu führen, dass Themen wie Verantwortung, Priorisierung oder Feedback zu kurz kommen. Scrum bringt hierfür zwar ziemlich klare Vorschläge mit – allerdings kann dies ein größerer Umstellungsaufwand für alle sein. In der Folge wünschen sich viele Teams eine Anpassung der Arbeitsweise entgegen den Regeln im Scrum Guide und “verwässern” dadurch eventuell das Framework. Im besten Fall hat das Team eine gute Begleitung, so dass es zu seiner optimalen Arbeitsweise findet.

Der Beitrag Kanban oder Scrum? Zwei agile Ansätze im Vergleich erschien zuerst auf Blog Antje Lehmann Training + Consulting.

Die Folgen waren gravierend: Fachabteilungen kämpften mit Problemen, Support-Anfragen blieben unbeantwortet, und das Misstrauen gegenüber dem Projektmanagement wuchs. Frustrierte Teams suchten Alternativen, wodurch eine Art Schattensystem entstand. Langfristig verursachte das Projekt so mehr Kosten als Nutzen. Erst ein Jahr später konnte das Chaos durch eine externe Beratung behoben werden. Die Lektion für das Unternehmen: Ein sauberer Projektabschluss ist essenziell – er schließt nicht nur die Baustelle des Projekts an sich, sondern sichert eben auch den nachhaltigen Erfolg.

In diesem Artikel wollen wir unterschiedliche Ansätze für den formellen Abschluss von Projekten betrachten – denn wie nicht nur die Eingangsgeschichte, sondern die Realität tatsächlich immer wieder zeigt: Solche Abschlüsse sind wichtig, und das ganz unabhängig von der verwendeten Methode im Projekt. Sie ermöglichen uns, Erfolge zu feiern, aus Fehlern zu lernen und wertvolle Erkenntnisse für zukünftige Projekte zu sichern.

Klassischer Abschlussbericht

Ein wichtiges Werkzeug im klassischen Projektmanagement ist traditionell der Abschlussbericht am Ende des Projekts, in dem eine umfassende Bewertung der Zielerreichung, der Ergebnisse und der gemachten Erfahrungen dokumentiert wird. Dieser Bericht dient dazu, die Projekterfolge und -herausforderungen detailliert zu analysieren und als Grundlage für zukünftige Projekte zu nutzen. Der Abschlussbericht wird in der Regel an das Management des Projektteams und andere relevante Stakeholder weitergegeben, um die Projektleistung festzuhalten – und um wertvolle Lessons Learned zu dokumentieren, also alles, was im Laufe des Projekts dazugelernt wurde. Diese Lessons Learned helfen dabei, ähnliche Herausforderungen in zukünftigen Projekten besser zu meistern und das Wissen im Unternehmen zu teilen und zu erweitern. Natürlich spricht auch nichts dagegen, Lessons Learned bereits im Projektverlauf immer wieder zu sammeln und festzuhalen – 

Einige Merkmale des klassischen Abschlussberichts sind:

• Umfassende Analyse: Eine detaillierte Bewertung der Projektziele, der erreichten Ergebnisse sowie der Herausforderungen und Risiken sollte sich im Bericht finden.
• Formale Dokumentation: Der Abschlussbericht ist ein formales Dokument, das als Referenz für zukünftige Projekte dient und im Unternehmen archiviert wird.
• Fokus auf Lessons Learned: Lessons Learned werden systematisch erfasst, um zukünftige Projekte erfolgreicher zu gestalten.

Beispiel: Abschlussbericht für ein Softwareprojekt

Angenommen, wir haben eine neue Funktion für eine Software entwickelt und das Projekt erfolgreich abgeschlossen. Der Abschlussbericht würde die folgenden Informationen enthalten:

• Inhaltliche Zielerfüllung: Die neue Funktion wurde erfolgreich implementiert und erfüllt die definierten Anforderungen. Die Projektinhalte wurden somit wie vereinbart geliefert. Die Benutzerregistrierung und Profilverwaltung wurden implementiert, und die Funktion ist auf iOS und Android verfügbar wie gefordert und sinnvoll.
• Ergebnisse: Die Arbeitszeit mit der neuen Funktion konnte gegenüber der alten Funktionsweise um XX Minuten im Schnitt verkürzt werden
• Lessons Learned: Es wurde festgestellt, dass eine besonders frühe Einbindung der Benutzer in den Testprozess dazu beigetragen hat, die Benutzerfreundlichkeit zu verbessern. Künftige Projekte sollten diesen Ansatz beibehalten.

Vorteile des klassischen Abschlussberichts

• Formale Dokumentation: Bietet eine formale und umfassende Dokumentation des Projekts, die für das Management und andere Stakeholder nützlich ist.
• Wissenssicherung: Lessons Learned als Teil des Abschlussberichts ermöglichen eine langfristige Wissenssicherung und Verbesserung zukünftiger Projekte.
• Reflexion und Bewertung: Der Abschlussbericht bietet die Möglichkeit, das Projekt systematisch zu reflektieren und Erfolge sowie Herausforderungen zu bewerten.

Herausforderungen des klassischen Abschlussberichts

• Zeitaufwendig: Die Erstellung eines detaillierten Abschlussberichts kann viel Zeit in Anspruch nehmen, insbesondere bei großen und komplexen Projekten.
• Vergangenheitsorientiert: Der Fokus liegt auf der Dokumentation vergangener Ereignisse, was in dynamischen Umgebungen schnell überholt sein kann.
• Umsetzung der Lessons Learned: Es besteht das Risiko, dass Lessons Learned zwar dokumentiert, aber in zukünftigen Projekten nicht mehr beachtet werden.

Agile Ansätze: Retrospektiven

In agilen Projekten werden statt eines Lessons-Learned-Meetings zum Projektende regelmäßig Retrospektiven durchgeführt. Diese finden typischerweise am Ende jedes Sprints oder jeder Iteration während des Entwicklungsverlaufs statt und dienen der kontinuierlichen Verbesserung des Teams – sodass Gelerntes nicht nur zukünftigen Projektteams, sondern auch aktuell an den Themen Arbeitenden. Zusätzlich gibt es am Ende des Projekts eine abschließende Retrospektive, die eine zusammenfassende Bewertung des gesamten Projekts ermöglicht. 

In Retrospektiven reflektiert das Team gemeinsam über die seit der letzten Retro vergangene Zeit (Iteration), identifiziert Herausforderungen, diskutiert Verbesserungsmöglichkeiten und legt konkrete Maßnahmen fest, um die Zusammenarbeit und die Qualität der Arbeit zukünftig zu verbessern. Das Ziel ist es, kontinuierlich Anpassungen vorzunehmen und das Team in seiner Arbeitsweise effektiver zu machen.

Merkmale von Retrospektiven:

• Regelmäßige Reflexion: Retrospektiven finden regelmäßig während des gesamten Projektverlaufs statt, nicht nur am Ende eines Projekts.
• Fokus auf Teamverbesserung: Der Schwerpunkt liegt auf der Verbesserung der Zusammenarbeit und der Prozesse innerhalb des Teams.
• Praxisorientierte Maßnahmen: Es werden konkrete Maßnahmen beschlossen, die in der nächsten Iteration umgesetzt werden können.

Ein ausführlicher Artikel über Retrospektiven von mir findet sich hier.

Beispiel: Retrospektive für ein Softwareprojekt

Nehmen wir das gleiche Beispiel der Entwicklung einer neuen Softwarefunktion. Nach dem Abschluss eines Sprints führt das Team eine Retrospektive durch, um die vergangenen Wochen zu reflektieren:

• Was lief gut?: Die enge Zusammenarbeit zwischen Entwicklern und Testern hat die Qualität der Implementierung verbessert.
• Was lief weniger gut?: Die Kommunikation mit den externen Stakeholdern war teilweise unklar, was zu Missverständnissen führte.
• Verbesserungen: In der nächsten Iteration soll eine wöchentliche Abstimmung mit den externen Stakeholdern eingeführt werden, um die Kommunikation zu verbessern.

Vorteile von Retrospektiven

• Kontinuierliche Verbesserung: Durch regelmäßige Reflexion und Anpassung verbessert sich das Team stetig, was zu besseren Ergebnissen führt.
• Flexibilität: Retrospektiven ermöglichen es, flexibel auf Herausforderungen und Veränderungen zu reagieren und Verbesserungen sofort umzusetzen.
• Teamfokus: Die gemeinsame Reflexion stärkt den Teamzusammenhalt und fördert eine Kultur der offenen Kommunikation.

Herausforderungen von Retrospektiven

• Disziplin erforderlich: Die Durchführung regelmäßiger Retrospektiven erfordert Disziplin und die Bereitschaft des Teams, offen über Probleme zu sprechen.
• Zeitlicher Aufwand: Auch wenn Retrospektiven kürzer sind als ein umfassender Abschlussbericht, benötigen sie dennoch Zeit und Ressourcen.
• Umsetzung der Maßnahmen: Es kann herausfordernd sein, die in Retrospektiven beschlossenen Maßnahmen konsequent umzusetzen, insbesondere wenn der Arbeitsdruck hoch ist.

Fazit: Wann sollte ich welche Methode wählen?

Die Entscheidung zwischen klassischeren Projektabschluss und regelmäßigen Retrospektiven hängt stark von der Projektumgebung ab. Klassische Abschlussberichte eignen sich besonders für Projekte, bei denen eine formale Dokumentation der Ergebnisse und eine umfassende Bewertung für das Management oder andere Stakeholder erforderlich sind. Retrospektiven sind ideal für agile Teams, die Wert auf kontinuierliche Verbesserung, Flexibilität und Teamtransparenz legen. In einigen Fällen kann es sinnvoll sein, beide Methoden zu kombinieren – etwa indem während des Projekts Retrospektiven durchgeführt werden und am Ende ein formaler Abschlussbericht erstellt wird, um sowohl eine kontinuierliche Verbesserung als auch eine abschließende Dokumentation sicherzustellen.

Der Beitrag Klassisch vs. Agil: Lessons Learned, Abschlussbericht und Retrospektiven erschien zuerst auf Blog Antje Lehmann Training + Consulting.

Die Wahl des richtigen Ansatzes für das jeweilige Projekt hängt von verschiedenen Faktoren ab, darunter die Dynamik des Projekts und die Erwartungen der Stakeholder. Als Projektmanager, Scrum Master oder einer anderen agilen Teamrolle ist es wichtig, beide Methoden zu kennen und ihre jeweiligen Vor- und Nachteile zu verstehen.

Klassische Projektstatusberichte

Im klassischen Projektmanagement sind Statusberichte meist in regelmäßigen Abständen (oft wöchentlich oder monatlich) extra angefertigte, auf bestimmte Weise strukturierte Dokumente. Sie dienen dazu, den aktuellen Stand eines Projekts zu beschreiben, den Fortschritt auf wichtige Meilensteine hin zu überprüfen und aktuelle Risiken sowie Probleme aufzuzeigen.

Statusberichte richten sich dabei meistens an das Management und andere Stakeholder, die nicht direkt im Projektteam arbeiten. Sie bieten eine Übersicht über Zeit, Budget, Ressourcen und geplante nächste Schritte.

Die Erstellung von Statusberichten stellt also einen formalisierten Prozess dar. Der Schwerpunkt liegt dabei auf der Überwachung und Steuerung des Projekts sowie der Sicherstellung, dass Plantermine, Kostenrahmen und Anforderungen eingehalten werden. 

Beispiel: Projektstatusbericht für ein Softwareprojekt

Angenommen, wir entwickeln eine neue Funktion für eine Software und erstellen dazu einen klassischen Statusbericht. Ein solcher Bericht würde detailliert den aktuellen Stand des Projekts beschreiben, beispielsweise: ‚Das Projekt ist aktuell zu 60 % abgeschlossen, und der nächste Meilenstein – die Testphase – ist in zwei Wochen geplant.‘ Darüber hinaus würde der Bericht Informationen zum Budget enthalten, etwa: ‚Das Projekt liegt im Budgetrahmen, wobei bisher 70 % des Gesamtbudgets ausgegeben wurden.‘ Zudem würden Risiken klar benannt, wie etwa: ‚Es besteht ein potenzielles Risiko einer Verzögerung der Testphase aufgrund von Ressourcenengpässen.‘ Abschließend werden konkrete nächste Schritte beschrieben, zum Beispiel: ‚Abschluss der Implementierungsphase und Beginn der Testphase.‘ Ein klassischer Statusbericht enthält in der Regel detaillierte Informationen, um die aktuelle Projektsituation klar darzustellen und darüber Rechenschaft abzulegen sowie Unterstützungsmöglichkeiten durch die Stakeholder bei Problemen zu kommunizieren.

Vorteile klassischer Projektstatusberichte

• klare und strukturierte Übersicht über den Projektstand 
• Transparenz für alle Stakeholder, insbesondere für das Management
• formale Dokumentation des Projektfortschritts 
• Grundlage für Projektunterstützung und für spätere Analysen

Herausforderungen klassischer Projektstatusberichte

• Erstellung kann viel Zeit in Anspruch nehmen, insbesondere bei großen Projekten
• Projektstatusberichte konzentrieren sich oft auf die Vergangenheit und können bei sich schnell ändernden Projektsituationen unzureichend sein
• Anpassungen sind oft schwierig, da die Berichte häufig auf festen Zeitplänen basieren
• Der “Observer Effect”: Sobald ein Bericht regelmäßig erstellt wird, besteht die Gefahr des Gefühls der Kontrolle von außen – manchmal mit der Folge, dass sich ein Team mehr auf die „Inszenierung“ konzentriert als auf den tatsächlichen Fortschritt und vor allem kosmetische Maßnahmen zur Verbesserung durchführt. 

Dem gegenübergestellt setzen agile Teams lieber auf mehr Transparenz in der täglichen Umsetzung:

Agile Ansätze – Team-Dashboards, Inspect & Adapt und kontinuierliche Verbesserung

In agilen Teams werden Projektstatusberichte oft durch Team-Dashboards ersetzt, die in Echtzeit aktuelle Metriken und Kennzahlen über den Projektfortschritt darstellen. Diese Dashboards schlagen dabei gleich zwei Fliegen mit einer Klappe: Sie sind nicht nur ein Werkzeug zur Information von Stakeholdern, sondern unterstützen auch die kontinuierliche Verbesserung des Teams und des Prozesses.

Ein Team-Dashboard ist eine visuelle Darstellung der wichtigsten Kennzahlen eines Projekts. Dadurch haben alle Teammitglieder Zugang zu den relevanten Informationen und können besser auf gemeinsame Ziele hinarbeiten. Typische Elemente eines Dashboards sind zum Beispiel (bei Scrum-Teams) ein Produkt- oder Release-Burndown-Chart, das den verbleibenden Arbeitsaufwand im jeweiligen Zeitraum visualisiert oder (bei Kanban-Teams) die durchschnittliche Cycle Time, die zeigt, wie effizient das Team Aufgaben abschließt, sowie die Work in Process (WIP), also die Anzahl der aktuell in Arbeit befindlichen Aufgaben und Themen. Eine zu hohe Anzahl an WIP deutet darauf hin, dass das Team möglicherweise zu viele Dinge gleichzeitig bearbeitet und dadurch ineffizient wird. Deshalb ist es eine bevorzugte Praxis in Kanban, diese Arbeit durch sogenannte WIP-Limits zu begrenzen

Bei Scrum-Teams, die in Sprints arbeiten, kann die Team Velocity dargestellt werden, also die Geschwindigkeit, mit der das Team User Storys abschließt. In Kanban-Teams helfen kumulative Flussdiagramme dabei, Engpässe im Workflow zu identifizieren. Auch Metriken zu Fehlern und Qualität können Bestandteil eines Dashboards sein, um sicherzustellen, dass die Produktqualität nicht beeinträchtigt wird.

Um ein Team-Dashboard zu erstellen, ist es zunächst wichtig, die relevanten Metriken zu identifizieren, die den Fortschritt, die Qualität und die Effizienz des Teams widerspiegeln. Danach sollte ein passendes Tool ausgewählt werden, das die Erstellung und Pflege des Dashboards erleichtert. Beispiele hierfür sind Jira, Trello, Azure DevOps oder spezialisierte Reporting-Tools wie Tableau oder Power BI. Das Design des Dashboards sollte übersichtlich und einfach zu interpretieren sein, sodass alle Teammitglieder die Informationen leicht verstehen können. Eine regelmäßige Aktualisierung der Daten ist ebenfalls notwendig, um die Aussagekraft des Dashboards zu erhalten. Dashboards sollten in regelmäßigen Team-Meetings genutzt werden, um sicherzustellen, dass alle Mitglieder informiert sind und auf aktuelle Entwicklungen reagieren können.

Team-Dashboards sind großartig – wenn sie richtig eingesetzt werden. Doch Vorsicht: Der “Observer Effect” kann auch hier zuschlagen! Sobald ein Team weiß, dass bestimmte Metriken beobachtet werden, können sich Verhaltensweisen ändern, um „gut auszusehen“, anstatt den Prozess tatsächlich zu verbessern.

Stell Dir dazu vor, ein Kanban-Team möchte seine Cycle Time verbessern. Das Dashboard zeigt stolz eine stetig sinkende Zeit pro Ticket – bis das Team entdeckt, dass unliebsame Aufgaben plötzlich länger in der „Ideen“-Spalte hängen bleiben, weil niemand sie anfassen will. Oder noch besser: Ein Teammitglied schließt plötzlich viel mehr Aufgaben an einem Tag ab. Bis das Team bemerkt, dass sich die Zahl lediglich verbessert hat, weil ein Kollege seine Aufgaben in 20 Mini-Tickets zerlegt hat. 

Die Lektion? Dashboards sind keine Zielvorlagen und schon gar keine Kontrollmittel, sondern Werkzeuge zur Reflexion. Anstatt Metriken zu manipulieren, sollte das Team regelmäßig hinterfragen, was die Zahlen wirklich bedeuten – und ob sie helfen, den Prozess nachhaltig zu verbessern. So lebt es eine kontinuierliche Überprüfung und Anpassung (Inspect und Adapt).

Und wie sieht es aus, wenn mehrere agile Teams am gleichen Produkt entwickeln? Im Grunde nicht viel anders, bis auf die Tatsache, dass es zusätzlich zur Einzelteam-Betrachtungsebene noch die übergeordnete Ebene gibt. Das Scaled Agile Framework (SAFe) schlägt deshalb zum Beispiel vor, circa einmal im Quartal gleich ein sogenanntes „Inspect & Adapt“ (I&A)-Event für alle alle relevanten Stakeholder des Multiteams (dieses wird in SAFe auch als “Agile Release Train” – ART bezeichnet). Genauer gesagt findet es am Ende jedes Program Increment (PI)-Zyklus statt, der etwa drei Monate dauert. Das I&A dient dazu, den Fortschritt aller Teams im ART zu reflektieren und Verbesserungspotenziale zu identifizieren. Das Event dient der Überprüfung und Anpassen auf mehreren Ebenen und besteht deshalb aus drei Teilen: 

1. der PI System Demo,
2. einer quantitativen und qualitativen Messungsüberprüfung sowie 
3. einem Retrospektive- und Problemlösungs-Workshop. 

Das Ziel des I&A-Events ist es also, den ART zu verbessern, indem Probleme gelöst und Verbesserungsvorschläge sowohl für das Produkt als auch den Prozess für den nächsten PI-Zyklus identifiziert werden.

Vorteile von Team-Dashboards und von Inspect & Adapt

• jederzeit aktuelle Informationen, wodurch das Team schnell auf Probleme reagieren kann. 
• die Selbstorganisation des Teams wird unterstützt, sodass es eigenständig Entscheidungen treffen und den Fortschritt kontinuierlich anpassen kann.
• dank kontinuierlicher Überwachung des Fortschritts und fortwährender Überprüfung und Anpassung von Produkt und Prozessen werden Probleme frühzeitig erkannt und Verbesserungen sofort umgesetzt

Herausforderungen von Team-Dashboards und von Inspect & Adapt

• Die Pflege der Daten und die kontinuierliche Nutzung des Dashboards sowie die Durchführung von Events zur Überprüfung und Anpassung von Produkt und Prozessen erfordern viel Disziplin und Engagement des Teams.
• Für externe Stakeholder kann die Darstellung auf Dashboards außerdem schwer zu interpretieren sein – es kommt ihnen nun auch eine neue Rolle zu: Sie müssen sich die Informationen aktiver einholen, als wenn ihnen ein Statusbericht bequem in den Posteingang schwebt. Das ist für viele eine große Umstellung.
• Zudem stellen Dashboards oft eine abstrahierte Sicht dar, die nicht alle Details abbildet, was für das Management manchmal hinderlich sein kann. Gemeinsame Betrachtungen und Diskussionen sowie die Ableitung der geeigneten Maßnahmen sind somit essenziell, damit das Miteinander von Team und Stakeholdern funktioniert. Effektive Kommunikation ist hier der Schlüssel.

Fazit: Wann sollte ich welche Methode wählen?

Die Wahl zwischen klassischen Projektstatusberichten und agilen Team-Dashboards hängt von den Anforderungen und der Kultur des Projekts ab. Klassische Projektstatusberichte sind ideal für Projekte, bei denen eine hohe formale Dokumentation und eine klare, vergangenheitsorientierte Übersicht für das Management benötigt werden. Team-Dashboards und Events wie ein I&A in SAFe oder ähnliches hingegen eignen sich besser für dynamische Projekte, bei denen Echtzeitinformationen, Teamtransparenz und kontinuierliche Anpassungen im Vordergrund stehen.

Nicht immer muss es entweder – oder sein: Ein hybrider Ansatz könnte zum Beispiel darin bestehen, klassische Projektstatusberichte mit Live-Daten aus einem Dashboard zu kombinieren, um sowohl formale Anforderungen zu erfüllen als auch Echtzeittransparenz zu schaffen. Auch die regelmäßige Einbindung von Stakeholdern in agile Reviews oder interaktive Dashboard-Demos kann Brücken zwischen den beiden Welten schlagen und die Kommunikation verbessern.

Der Beitrag Klassisch vs. Agil: Projektstatusberichte und Team-Dashboards erschien zuerst auf Blog Antje Lehmann Training + Consulting.

Klassische Teamführung: Der hierarchische Ansatz

In traditionellen, klassischen Projekten sind Projektmanager:innen oft die Personen, welche die Entscheidungen treffen und diese an das Team verkünden. Diese Art der Führung basiert auf klaren Hierarchien und Rollenverteilungen. Projektmanager:innen kontrollieren die Ressourcen, stellen den Zeitplan auf und verfolgen die Ziele. Das Team führt seine Aufgaben meist nach Anweisung aus, wobei die Kommunikation in der Regel vertikal verläuft, also von oben nach unten.

Die klassische Führung hat ihre Vorteile, insbesondere in Projekten, bei denen Planbarkeit und Kontrolle oberste Priorität haben. Nicht selten wird es von Teammitgliedern auch erwartet oder erhofft.

Ein Beispiel aus der Praxis: Angenommen, Du leitest ein Infrastrukturprojekt, wie den Bau einer neuen Fabrikhalle. Hier sind klare Strukturen, feste Pläne und genaue Vorgaben für die Ausführung der Arbeiten unverzichtbar. Das klassische Führungsmodell hilft Dir, den Überblick über das Projekt zu behalten, Risiken zu managen und sicherzustellen, dass das Team seinen Aufgabenbereich genau kennt.

Vorteile der klassischen Teamführung

• Klarheit und Kontrolle: Durch klare Hierarchien sind die Verantwortlichkeiten und Entscheidungsprozesse eindeutig definiert.
• Effizienz in stabilen Projekten: In gut strukturierten, langfristigen Projekten ist diese Führung oft effizienter, da sie wenig Raum für Unsicherheiten lässt.
• Risikomanagement: Der Fokus auf Kontrolle hilft, Risiken frühzeitig zu identifizieren und entsprechend gegenzusteuern.

Herausforderungen der klassischen Teamführung

• Begrenzte Flexibilität: Der hierarchische Ansatz ist oft starr, was in dynamischen Umgebungen ein Problem darstellen kann.
• Weniger Eigenverantwortung: Das Team hat oft wenig Autonomie, was zu einer geringeren Motivation und Kreativität führen kann.

Agile Teamführung: Servant Leadership

Das Konzept der so genannten “Servant Leadership” finden wir vor allem in agilen Umgebungen. Scrum Master oder agile Coaches sind keine “Chefs” im klassischen Sinne, sondern agieren als Unterstützer und im wahrsten Sinne des Begriffs als “Diener” des Teams. Sie beseitigen Hindernisse, die das Team in seiner Arbeit behindern könnten, und sie fördern eine Kultur der Selbstorganisation und Eigenverantwortung. Dabei gilt: Trotz allem enthält auch Servant Leadership als Führungsstil noch das Wort “Leadership” – es ist also nicht damit gemeint, dass man sich einfach ganz zurückzieht aus jeglicher Art von Führungsrolle, indem man alles dem Team überlässt. Vielmehr ist ständiges Fingerspitzengefühl gefragt bei der Entscheidung, in welcher Situation man als Servant Leader wie viel Kontrolle übernimmt oder loslässt. 

Servant Leadership zeichnet sich also durch eine flache Hierarchie aus, bei der sich alles um das Team dreht. Die Führungsperson sorgt dafür, dass das Team die notwendigen Werkzeuge, Informationen und Ressourcen hat, um erfolgreich zu sein, greift aber nur nach Notwendigkeit in den eigentlichen Arbeitsprozess ein.

Ein Beispiel aus der Praxis: Stell Dir vor, Du arbeitest mit einem Scrum-Team in einem ein Softwareentwicklungsprojekt. Als Scrum Master – eine im Scrum Guide als Servant Leader gestaltete Rolle –  bist Du dafür verantwortlich, dass das Team effektiv arbeiten kann, Hindernisse beseitigt werden und das Team die Möglichkeit hat, seine Arbeit selbst zu organisieren. Du förderst die Eigenverantwortung, unterstützt bei Problemen und ermöglichst es dem Team, in ihrem iterativen Vorgehen immer bessere Ergebnisse zu liefern. Du triffst aber auch immer dann Entscheidungen mit und für das Team, wenn die aktuelle Situation dies erfordert.

Vorteile von Servant Leadership

• Förderung von Selbstmanagement: Das Team übernimmt mehr Verantwortung und entwickelt Eigeninitiative, was die Motivation und Kreativität steigert.
• Flexibilität: Agiles Arbeiten und Servant Leadership ermöglichen es Teams, sich schnell an Veränderungen anzupassen.
• Teamförderung: Durch die Unterstützung des Teams wird die Zusammenarbeit verbessert und das Teamklima gestärkt.

Herausforderungen von Servant Leadership

• Mehr Verantwortung für das Team: Teams, die noch nicht an eine hohe Eigenverantwortung gewöhnt sind, benötigen Zeit, um sich an diese Arbeitsweise zu gewöhnen.
• Schwierigkeiten bei klaren Entscheidungen: In Situationen, in denen schnelle Entscheidungen erforderlich sind, kann der Servant Leadership-Ansatz manchmal viel Zeit in Anspruch nehmen.

Fazit: Klassische Teamführung oder Servant Leadership?

Die Entscheidung zwischen klassischer Teamführung und Servant Leadership hängt stark von der Art des Projekts, der Unternehmenskultur und den individuellen Teamanforderungen ab. Für stabile, gut strukturierte Projekte, bei denen Kontrolle und Risikomanagement entscheidend sind, kann der klassische Führungsansatz die beste Wahl sein. Auch bei großen Projekten mit vielen Beteiligten und Interessenvertretern ist mehr Kontrolle manchmal einfach vonnöten. Wenn Du jedoch in einem dynamischen Umfeld arbeitest, in dem eine hohe Lerngeschwindigkeit und somit Flexibilität und Eigenverantwortung im Vordergrund stehen sollten, bietet sich der Servant-Leadership-Ansatz vielleicht mehr an.

Letztlich liegt es an Dir als Projektleiter:in oder Teamverantwortliche:r, die richtige Methode für Deine spezifischen Bedürfnisse zu wählen – oder sogar beide Ansätze je nach Projektphase oder Situation und Kontext zu kombinieren.

Der Beitrag Klassisch vs. Agil: Teamführung und Servant Leadership erschien zuerst auf Blog Antje Lehmann Training + Consulting.

Die Wahl der passenden Methode für das jeweilige Projekt hängt von verschiedenen Faktoren ab, einschließlich der Art des Projekts und der Unternehmenskultur. Als Projektmanager:in oder Produktverantwortliche solltest Du idealerweise beide Ansätze kennen und verstehen, um die bestmögliche Entscheidung treffen zu können.

Klassische Anforderungsdokumentation

Im klassischen Projektmanagement wird eine Anforderungsdokumentation oft sehr detailliert und umfangreich erstellt. Ein typisches Anforderungsdokument (häufig etwa Lastenheft genannt) enthält alle wesentlichen Informationen über das Projekt, einschließlich funktionaler und nicht-funktionaler Anforderungen, Geschäftsregeln, Systemanforderungen und oft auch technische Spezifikationen.

Das Lastenheft wird vom Auftraggeber formuliert und dient im ersten Schritt bereits zur Einholung von Angeboten. Auch die Bezeichnung Leistungsverzeichnis ist im Deutschen geläufig. 

Der Auftragnehmer erstellt wiederum nach Erhalt des Lastenhefts ein Pflichtenheft. Dieses setzt die gewünschten Ergebnisse (Lasten) in Aufgaben (Pflichten) um. Wie ausführlich dieses Pflichtenheft ist, hängt vom jeweiligen Projekt ab. Es kann lediglich den Liefertermin und den Preis enthalten – oder bereits eine vollständige Projektplanung. 

Beide Dokumente werden bei Zustandekommen einer Zusammenarbeit Bestandteil des Vertrages. 

Merkmale der klassischen Anforderungsdokumentation

• Vollständigkeit und Detailtiefe: Das Dokument strebt danach, alle Anforderungen bis ins Detail zu erfassen, um Missverständnisse und Änderungen während des Projekts zu minimieren.
• Formaler Prozess: Die Erstellung des Anforderungsdokuments folgt einem formalen Prozess, der oft mehrere Iterationen von Überprüfung und Genehmigung durchläuft.
• Feste Basis: Einmal abgeschlossen, dient das Dokument als feste Grundlage für die weitere Planung und Umsetzung des Projekts.

Beispiel: Entwicklung einer neuen Funktion für eine mobile App

Angenommen, wir entwickeln eine neue Funktion für eine mobile App, die eine Benutzerregistrierung, das Erstellen eines Benutzerprofils und die Integration einer Push-Benachrichtigung umfasst. Ein klassisches Anforderungsdokument könnte folgendermaßen aussehen:

• Zielsetzung: Die neue Funktion soll die Benutzerregistrierung, das Erstellen von Benutzerprofilen und die Integration von Push-Benachrichtigungen ermöglichen, um die Benutzerinteraktion und -bindung zu verbessern.
• Funktionale Anforderungen:
  1. Benutzerregistrierung: Benutzer müssen sich registrieren können, um Zugang zur App zu erhalten. Die Registrierung erfordert die Eingabe von E-Mail, Passwort und Bestätigung.
  2. Benutzerprofil: Benutzer müssen ein Profil erstellen und verwalten können, einschließlich der Eingabe von Namen, Geburtsdatum und Profilbild.
  3. Push-Benachrichtigungen: Die App muss in der Lage sein, Push-Benachrichtigungen an Benutzer zu senden, um sie über wichtige Ereignisse zu informieren.
• Nicht-funktionale Anforderungen:
  1. Sicherheit: Die Registrierung und Profilerstellung müssen sicher und DSGVO-konform sein.
  2. Performance: Die App soll in der Lage sein, Benachrichtigungen innerhalb von 2 Sekunden nach dem Ereignis zu senden.
  3. Benutzerfreundlichkeit: Die Benutzeroberfläche muss intuitiv und leicht zu bedienen sein.
• Technische Anforderungen:
  1. Kompatibilität: Die Funktion muss auf iOS und Android laufen.
  2. Wartbarkeit: Der Code muss leicht wartbar und erweiterbar sein.

Vorteile der klassischen Anforderungsdokumentation

• Klarheit und Präzision: Durch die detaillierte Dokumentation werden Anforderungen klar definiert und Missverständnisse reduziert.
• Stabile Grundlage: Bietet eine stabile Grundlage für die Planung und Umsetzung, wodurch das Projekt weniger anfällig für Änderungen wird.
• Nachvollziehbarkeit: Jede Anforderung ist dokumentiert und kann bei Bedarf nachverfolgt werden.

Herausforderungen der klassischen Anforderungsdokumentation

• Zeitaufwändig: Die Erstellung eines umfassenden Anforderungsdokuments kann sehr zeitaufwändig sein.
• Rigidität: Änderungen sind oft schwierig und teuer, da sie den gesamten Plan beeinflussen können.
• Überkomplexität: Bei großen Projekten kann die Menge an Details überwältigend sein und die Übersichtlichkeit beeinträchtigen.

Agile Ansätze: User Storys

Bei den agilen Methoden werden Anforderungen oft in Form von sogenannten User Storys dokumentiert. Ursprünglich eine Idee aus dem agilen Framework “Extreme Programming” (XP), haben auch nach Scrum oder anderen agilen Ansätzen arbeitende Teams das Konzept von User Storys heute in ihren Alltag meist fest integriert. Doch was genau sind User Storys? Es handelt sich dabei zunächst einmal um kurze, einfache und eingängige Beschreibungen einer Funktionalität aus der Sicht des Endbenutzers oder Kunden, die in das Product Backlog des Teams aufgenommen werden können.

Merkmale von User Storys

• Einfach und prägnant: Jede User Story beschreibt eine Funktionalität in einer klaren und einfachen Sprache – meist tatsächlich wie eine Art sehr kurze Geschichte, in nur einem Satz zusammengefasst, s. Beispiele unten.
• Fokussierung auf Nutzer:innen: User Storys sollten den Mehrwert für Endnutzer:innen in den Vordergrund stellen.
• Flexible und iterative Entwicklung: Storys können in der agilen Arbeit mit einem Backlog jederzeit hinzugefügt, geändert oder entfernt werden, um sich ändernden Bedürfnissen, Erkenntnissen oder Gegebenheiten gerecht zu werden.

Beispiel: Entwicklung einer neuen Funktion für eine mobile App

Nehmen wir das gleiche Beispiel wie oben, um den Vergleich zu verdeutlichen. User Storys könnten dann so aussehen:

1. User Story 1: Benutzerregistrierung
   • Beschreibung: Als Benutzer:in möchte ich mich registrieren können, um auf die App zugreifen zu können.
2. User Story 2: Benutzerprofil erstellen
   • Beschreibung: Als Benutzer:in möchte ich ein Profil erstellen können, um meine Informationen zu speichern und zu verwalten.
3. User Story 3: Push-Benachrichtigung integrieren
   • Beschreibung: Als Benutzer:in möchte ich Push-Benachrichtigungen erhalten, um über wichtige Ereignisse informiert zu werden.

Vorteile von User Storys

• Flexibilität: User Storys ermöglichen eine flexible Anpassung von Anforderungen während des Projekts.
• Nutzerorientierung: Der Fokus auf die Perspektive von Endnutzer:innen stellt sicher, dass die entwickelten Funktionen tatsächlich einen Mehrwert bieten.
• Team-Beteiligung: Die Erstellung und Priorisierung von User Storys erfolgt im Team, was die Akzeptanz und das Verständnis fördert.

Herausforderungen der User Stories

• Abstraktheit: User Storys können für Stakeholder schwer verständlich und nachvollziehbar sein, da sie weniger detailliert sind. Sie sollten immer als Ausgangsbasis für weitere Detaildiskussionen gesehen werden, nie als dokumentiertes Ergebnis dieser. Jede:r im Team sollte darüber ein Bewusstsein haben.
• Erfahrung: Die Qualität und Genauigkeit der User Storys hängt stark von der Erfahrung des Teams ab.
• Kontinuierliche Pflege: User Storys müssen kontinuierlich gepflegt und angepasst werden, was zusätzlichen Aufwand erfordert.

Fazit: Wann sollte ich nun welche Methode wählen?

Die Entscheidung zwischen eher klassischer Anforderungsdokumentation und dem Einsatz eines Backlogs mit User Storys (und ggfs. anderen Einträgen) darin hängt unter anderem von der Art eines Vorhabens, der Unternehmenskultur und den spezifischen Anforderungen ab. Klassische Anforderungsdokumentation eignet sich besser für vorherplanbarere Projekte mit klar definierten Zielen und Anforderungen, während User Storys ideal für dynamische, sich schnell ändernde Projekte sind, bei denen Flexibilität und Nutzerorientierung im Vordergrund stehen.

Der Beitrag Klassisch vs. Agil: Anforderungsdokumentation erschien zuerst auf Blog Antje Lehmann Training + Consulting.

Welche dieser Ansätze am besten zu Deinem Projekt, Deiner Produktentwicklung und generell zu Eurem Team passt, ist von vielen Faktoren abhängig. Als Projektmanager:in oder Produktverantwortliche:r solltest Du jedoch verschiedene Ansätze und Methoden kennen.

Klassische Aufwandsschätzung: 3-Punkt-Schätzung

Die 3-Punkt-Schätzung ist eine Methode des klassischen Projektmanagements, die darauf abzielt, Unsicherheiten bei der Schätzung von Projektaufwänden zu reduzieren. Diese Methode verwendet drei verschiedene Schätzwerte, um eine realistischere und genauere Schätzung zu erstellen:

1. Optimistische Schätzung (O): Die Schätzung, die den besten Fall darstellt.

2. Pessimistische Schätzung (P): Die Schätzung, die den schlechtesten Fall darstellt.

3. Wahrscheinlichste Schätzung (W): Die Schätzung, die am wahrscheinlichsten ist.

Die 3-Punkt-Schätzung wird durch die Formel berechnet:

Diese Methode liefert einen gewichteten Mittelwert und berücksichtigt dabei sowohl die beste als auch die schlechteste Situation.

Hier ein Beispiel: 

Für unser Projekt, eine neue Webseite zu erstellen, haben wir bereits die verschiedenen Arbeitspakete definiert und wollen nun herausfinden, was der Gesamtaufwand für das Projekt sein könnte. 

Einer der ersten Schritte wäre die Aufgabe, die Anforderungen für die neue Seite zu sammeln und zu analysieren.

Die beispielhafte Berechnung der 3-Punkt-Schätzung für den Schritt „Anforderungen sammeln und analysieren“ sieht also so aus:

1. Optimistische Schätzung (O): 5 Tage
2. Wahrscheinlichste Schätzung (W): 8 Tage
3. Pessimistische Schätzung (P): 12 Tage

Wir schätzen den den Aufwand also auf ca. 8 Tage. 

Diese Berechnung führen wir für jedes Arbeitspaket aus und kommen so dann auf einen geschätzten Gesamtaufwand für das Projekt. 

Vorteile der 3-Punkt-Schätzung

– Reduzierung von Unsicherheiten: Durch die Berücksichtigung von optimistischen und pessimistischen Szenarien wird eine realistischere Schätzung erreicht.

– Detaillierte Analyse: Diese Methode zwingt das Team, verschiedene Szenarien zu betrachten und Risiken besser zu verstehen.

– Verlässliche Planung: Die gewichtete Schätzung führt zu einer besseren Planungsgenauigkeit und Ressourcenallokation.

Herausforderungen der 3-Punkt-Schätzung

– Zeitaufwendig: Die Erstellung von drei verschiedenen Schätzungen kann zeitintensiv sein.

– Subjektiv: Die Genauigkeit der Schätzung hängt stark von der Erfahrung und dem Wissen derjenigen ab, die die Schätzungen vornehmen.

– Potentiell komplex: Für große und komplexe Projekte kann die Anwendung dieser Methode schwierig sein.

Agile Aufwandsschätzung: Relative Größenordnung mithilfe Story Points

Im agilen Projektmanagement, insbesondere in Scrum, werden Aufwandsschätzungen häufig mit Story Points durchgeführt. Story Points sind eine abstrakte Maßeinheit, die den relativen Aufwand zur Umsetzung einer User Story widerspiegeln.

Charakteristika der Story Points

– Relative Schätzung: Story Points messen den relativen Aufwand im Vergleich zu anderen User Stories und berücksichtigen dabei Komplexität, Risiken und Unsicherheiten.

– Team-basierte Schätzung: Die Schätzung erfolgt durch das gesamte Team, oft mittels Planning Poker, um eine gemeinsame Einschätzung zu erreichen.

– Unabhängig von Zeit: Story Points sind keine Zeiteinheiten, sondern eine Maßzahl für den relativen Aufwand.

Auch hier ein konkretes Beispiel:

Beispiel: Entwicklung einer neuen Funktion für eine mobile App

Angenommen, ein Entwicklungsteam arbeitet an einer neuen Funktion für eine mobile App, die eine Benutzerregistrierung, das Erstellen eines Benutzerprofils und die Integration einer Push-Benachrichtigung umfasst. Das Team verwendet Story Points, um den relativen Aufwand für jede User Story zu schätzen.

Schritt 1: User Stories definieren

1. User Story 1: Benutzerregistrierung:
   • Als Benutzer möchte ich mich registrieren können, um auf die App zugreifen zu können.
2. User Story 2: Benutzerprofil erstellen:
   • Als Benutzer möchte ich ein Profil erstellen können, um meine Informationen zu speichern und zu verwalten.
3. User Story 3: Push-Benachrichtigung integrieren:
   • Als Benutzer möchte ich Push-Benachrichtigungen erhalten, um über wichtige Ereignisse informiert zu werden.

Schritt 2: Story Points zuweisen

Das Team diskutiert jede User Story und verwendet eine Methode wie Planning Poker, um den relativen Aufwand in Story Points zu schätzen. Dabei berücksichtigen sie Komplexität, Risiken und Unsicherheiten.

1. User Story 1: Benutzerregistrierung
   • Diskussion: Das Team bewertet die Registrierung als relativ einfach, da ähnliche Funktionen bereits vorhanden sind.
   • Schätzung: 3 Story Points
2. User Story 2: Benutzerprofil erstellen
   • Diskussion: Diese Aufgabe erfordert mehr Aufwand, da das Profil mehrere Felder und Validierungen umfasst.
   • Schätzung: 5 Story Points
3. User Story 3: Push-Benachrichtigung integrieren
   • Diskussion: Diese Aufgabe ist am komplexesten, da sie eine Integration mit einem externen Push-Dienst und umfangreiche Tests erfordert.
   • Schätzung: 8 Story Points

Schritt 3: Sprint-Planung

Das Team plant einen Sprint von zwei Wochen Dauer. Basierend auf der Velocity (Durschnitts-Durchsatz) des Teams aus früheren Sprints wissen sie, dass sie normalerweise etwa 20 Story Points in einem Sprint abschließen können.

Sprint-Backlog erstellen:

• User Story 1: Benutzerregistrierung – 3 Story Points
• User Story 2: Benutzerprofil erstellen – 5 Story Points
• User Story 3: Push-Benachrichtigung integrieren – 8 Story Points

Gesamtsumme der Story Points im Sprint-Backlog: 3 + 5 + 8 = 16 Story Points

Das Team entscheidet, dass sie diese User Stories im kommenden Sprint bearbeiten werden, da der geschätzte Aufwand innerhalb ihrer Kapazität liegt.

Vorteile von Aufwandsschätzung mit Story Points

– Flexibilität: Story Points ermöglichen es Teams, flexibel auf Veränderungen zu reagieren, ohne genaue Zeitvorgaben machen zu müssen.

– Team-Beteiligung: Durch die gemeinsame Schätzung wird das gesamte Team in den Schätzprozess einbezogen, was die Genauigkeit erhöht.

– Kontinuierliche Verbesserung: Durch regelmäßige Überprüfung und Anpassung der Schätzungen kann das Team seine Genauigkeit und Effizienz kontinuierlich verbessern.

Herausforderungen der Story Points

– Abstraktheit: Die Abstraktheit der Story Points kann für Stakeholder schwer verständlich sein.

– Erfahrung: Die Genauigkeit der Schätzungen hängt stark von der Erfahrung des Teams ab.

– Anfangsaufwand: Zu Beginn kann es schwierig sein, eine einheitliche Skala und ein gemeinsames Verständnis für Story Points zu entwickeln.

Fazit: Wann sollte ich nun welche Methode wählen?

Die Entscheidung zwischen der klassischen 3-Punkt-Schätzung und dem agilen Ansatz der Story Points hängt von der Art des Projekts, der Unternehmenskultur und den spezifischen Anforderungen ab. Die 3-Punkt-Schätzung eignet sich besser für Projekte, bei denen eine hohe Genauigkeit und Vorhersehbarkeit wichtig sind, während Story Points für dynamische, sich schnell ändernde Projekte ideal sind, bei denen Flexibilität und Team-Beteiligung im Vordergrund stehen. 

Es ist prinzipiell auch immer möglich, beide Ansätze in unterschiedlichen Situationen und Kontexten anzuwenden – so kann man etwa für eine Schätzung von Gesamtprojektkosten und -dauern auf die 3-Punkt-Schätzung zurückgreifen, für konkrete Arbeitsaufgaben mit dem Team aber Story Points verwenden.

Der Beitrag Klassisch vs. Agil: Aufwandsschätzung erschien zuerst auf Blog Antje Lehmann Training + Consulting.

Klassische Teambuilding-Maßnahmen und Konfliktlösungsmethoden

Im klassischen Projektmanagement werden Teambuilding-Maßnahmen und Konfliktlösungsmethoden häufig strukturiert und formalisiert angegangen. In klassischen Projektteams spielt der Projektmanager eine zentrale Rolle. Er gibt klare Anweisungen und leitet das Team durch die verschiedenen Phasen des Projekts. 

Die Teambildungs-Stadien nach Tuckman sind hier ein bewährtes Modell:

1. Forming: Das Team bildet sich, und die Mitglieder lernen sich kennen.

2. Storming: Erste Konflikte und Meinungsverschiedenheiten treten auf.

3. Norming: Das Team findet zu gemeinsamen Normen und Arbeitsweisen.

4. Performing: Das Team arbeitet effektiv und effizient zusammen.

Je nach Stadium erfordert das Team unterschiedliche Führungsstile. In der Forming-Phase sind klare Anweisungen und Strukturen notwendig, während in der Performing-Phase eher ein begleitender und unterstützender Führungsstil gefragt ist.

Teambuilding-Maßnahmen

Klassische Teambuilding-Maßnahmen zielen darauf ab, das Vertrauen und die Zusammenarbeit im Team zu stärken. Typische Methoden umfassen:

• – Teamworkshops: Regelmäßige Workshops fördern das Verständnis der Teammitglieder füreinander und schaffen ein gemeinsames Verständnis für die Projektziele.
• – Gemeinsame Aktivitäten: Aktivitäten wie Firmenausflüge oder Team-Building-Spiele stärken den Teamgeist und das Zusammengehörigkeitsgefühl.
• – Schulung und Weiterbildung: Durch gezielte Schulungen können Teammitglieder ihre Fähigkeiten ausbauen und lernen, effektiver zusammenzuarbeiten.

Konfliktlösungsmethoden

Auch in klassischen Teams sind Konflikte unvermeidlich. Die Rolle des Projektmanagers besteht hier oft darin, als Mediator zu fungieren und Lösungen aktiv herbeizuführen.

Im klassischen Projektmanagement werden Konflikte häufig hierarchisch und durch formalisierte Prozesse gelöst:

• Mediation durch Führungskräfte: Führungskräfte oder Projektmanager übernehmen oft die Rolle des Mediators und suchen nach einer für alle Parteien akzeptablen Lösung.
• Eskalationsprozesse: Konflikte, die auf einer Ebene nicht gelöst werden können, werden an höhere Managementebenen eskaliert.
• Formale Verfahren: Schriftliche Dokumentation und festgelegte Verfahren helfen, Konflikte systematisch zu analysieren und zu lösen.

Vorteile

• Struktur und Klarheit: Formalisierte Prozesse bieten klare Anweisungen zur Konfliktlösung.
• Professionelle Mediation: Führungskräfte sind oft speziell geschult, um Konflikte effektiv zu moderieren.

Grenzen

• Bürokratie: Formale Prozesse können zeitaufwändig und starr sein.
• Abhängigkeit von Führungskräften: Die Lösung von Konflikten hängt stark von der Kompetenz der Führungskräfte ab.

Agile Teambuilding-Maßnahmen und Konfliktlösungsmethoden

Agile Teams zeichnen sich durch eine hohe Selbstorganisation aus. Dies bedeutet, dass die Teammitglieder eigenverantwortlich arbeiten und Entscheidungen gemeinsam treffen. Der Scrum Master spielt hierbei eine entscheidende Rolle. Diese Person unterstützt das Team, fördert die Kommunikation und hilft dabei, Hindernisse zu überwinden. Es ist es wichtig, dass diese Person das Team dabei unterstützt, seine volle Leistungsfähigkeit zu entfalten, indem er Techniken wie Retrospektiven, Daily Stand-ups und Team-Building-Aktivitäten nutzt.

Beispiele für kontinuierliche und iterative Teambuilding-Maßnahmen:

• Daily Stand-ups: Tägliche kurze Meetings fördern die Kommunikation und den Zusammenhalt im Team.
• Retrospektiven: Regelmäßige Rückblicke ermöglichen es dem Team, kontinuierlich an der Verbesserung der Zusammenarbeit zu arbeiten.
• Pair Programming und Mob Programming: Diese Praktiken fördern das gemeinsame Arbeiten an Aufgaben und stärken das Teamgefühl.

Konfliktlösungsmethoden

Ein wesentlicher Bestandteil agiler Teams ist die Fähigkeit, Konflikte selbstständig zu lösen. Das Modell der 5 Konfliktstufen bietet hierbei einen Rahmen, um Konflikte zu erkennen und entsprechend zu handeln:

1. Latente Konflikte: Unausgesprochene Spannungen, die noch nicht offen zu Tage treten.

2. Angezeigte Konflikte: Erste Zeichen eines Konflikts werden sichtbar.

3. Fühlbare Konflikte: Der Konflikt wird intensiver und beeinflusst die Arbeit.

4. Manifeste Konflikte: Der Konflikt eskaliert und bedarf einer Lösung.

5. Konfliktlösungen: Maßnahmen zur nachhaltigen Lösung des Konflikts werden ergriffen.

Agile Teams sollten befähigt werden, Konflikte frühzeitig zu erkennen und selbst Lösungen zu erarbeiten. Hierbei helfen regelmäßige Meetings und eine offene Kommunikationskultur.

Vorteile

• Flexibilität: Agile Methoden ermöglichen eine schnelle Anpassung und Lösung von Konflikten.
• Empowerment: Teams sind eigenverantwortlich und können Konflikte direkt lösen.

Grenzen

• Selbstdisziplin erforderlich: Agile Teams benötigen ein hohes Maß an Selbstdisziplin und Eigenverantwortung.
• Abhängigkeit vom Scrum Master: Der Erfolg der Konfliktlösung kann stark vom Scrum Master abhängen.

Gemeinsamkeiten und Unterschiede

Unabhängig von den verwendeten Methoden ist das Ziel, ein effektives und harmonisches Team zu schaffen. Der Hauptunterschied liegt in der Flexibilität und Selbstorganisation der Teams. Während klassische Methoden strukturierte und formalisierte Ansätze bieten, setzen agile Methoden auf kontinuierliche Anpassung und Eigenverantwortung.

Fazit

Die Wahl zwischen klassischen und agilen Teambuilding-Maßnahmen und Konfliktlösungsmethoden hängt von verschiedenen Faktoren ab, wie der Art des Projekts, der Teamzusammensetzung und der Unternehmenskultur. Klassische Methoden bieten Struktur und Klarheit, während agile Methoden Flexibilität und Selbstorganisation fördern. Die beste Lösung liegt oft in einer Kombination beider Ansätze, angepasst an die spezifischen Bedürfnisse des Teams und des Projekts.

Der Beitrag Klassisch vs. Agil: Teambuilding-Maßnahmen und Konfliktlösungsmethoden erschien zuerst auf Blog Antje Lehmann Training + Consulting.

In diesem Artikel werden wir einen Vergleich zwischen der klassischen Terminplanung und dem agilen Ansatz des iterativen Vorgehens – im Rahmenwerk namens “Scrum” auch bekannt als Arbeit in Sprints – vornehmen. 

Welche dieser Ansätze am besten zu Deinem Projekt passt, ist von vielen Faktoren abhängig. Als Projektmanager:in oder Produktverantwortliche:r solltest Du jedoch verschiedene Ansätze und Methoden kennen.

Klassische Terminplanung

Im klassischen Projektmanagement ist der Terminplan ein zentrales Element. Dieser Plan legt genau fest, wann und in welcher Reihenfolge die einzelnen Projektaufgaben ausgeführt werden sollen. Er ist besonders wichtig, um sicherzustellen, dass alle Projektziele termingerecht erreicht werden und Ressourcen (also etwa Arbeitsmittel, Materialien, Zeit, aber auch die Arbeitskraft von Personen) effizient zugewiesen werden können.

Das zeichnet die klassische Terminplanung aus:

1. Festgelegte Meilensteine: Jeder wichtige Abschnitt des Projekts wird durch klar definierte Meilensteine markiert, die erreicht werden müssen.
2. Detaillierte Deadlines: Der Terminplan umfasst Start- und Enddaten für jede Aufgabe und ordnet ihnen spezifische Teammitgliedern zu.
3. Vorhersehbarkeit und Struktur: Der Plan bietet eine solide Struktur und Vorhersehbarkeit. 

Vorteile der klassischen Terminplanung

• Klarheit und Ordnung: Ein detaillierter Terminplan bietet eine klare Struktur und festgelegte Fristen, die helfen, das Projekt auf Kurs zu halten.
• Vorhersagbarkeit: Projekte, die stark von festen Budgets und Zeitplänen abhängen, profitieren von der Vorhersehbarkeit, die ein detaillierter Terminplan bietet.
• Effiziente Ressourcennutzung: Durch genaue Zeitpläne können Ressourcen effektiv geplant und zugewiesen werden, wodurch Überbuchungen und Leerlaufzeiten vermieden werden.

Herausforderungen der klassischen Terminplanung

• Inflexibilität: Änderungen in den Projektanforderungen können schwer zu integrieren sein, ohne den gesamten Plan zu stören. Dies kann besonders in dynamischen Projekten zu Verzögerungen und Mehraufwand führen.
• Übermäßiger Fokus auf Termine: Die starre Einhaltung des Zeitplans kann dazu führen, dass die Qualität der Arbeit oder das Endergebnis zugunsten der Einhaltung von Fristen kompromittiert wird.
• Widerstand gegen Änderungen: Ein detaillierter Plan kann das Team davon abhalten, auf neue Chancen oder notwendige Anpassungen flexibel zu reagieren, was letztlich die Innovation einschränken kann.

Agile Methodik: Iteratives Vorgehen / Arbeit in Sprints

Im Gegensatz zur klassischen Terminplanung ermöglicht die agile Methode ein flexibleres und dynamischeres Vorgehen. Arbeiten in Sprints, eine Kernkomponente der Vorgehensweise von Scrum-Teams, unterteilt das Vorhaben hierfür in kleinere, überschaubare Iterationen, die jeweils einen festgelegten und möglichst immer gleichen Zeitraum umfassen (meist 1-3 oder maximal 4 Wochen).

Charakteristika des iterativen Vorgehens:

1. Kurze Feedback-Zyklen: Jeder Sprint endet mit einer Überprüfung des Erreichten und einem Feedback der Stakeholder, das unmittelbar in den nächsten Sprint einfließen kann.
2. Anpassungsfähigkeit: Änderungen im Projektumfang oder in den Anforderungen können schnell integriert werden, was eine hohe Flexibilität gewährleistet.
3. Kontinuierliche Verbesserung: Durch regelmäßige Retrospektiven zu jedem Sprintende strebt das Team danach, seine Arbeitsweise ständig zu verbessern und effizienter zu gestalten.

Vorteile der agilen Arbeit in Sprints

• Flexibilität: Veränderte Kundenwünsche können schneller umgesetzt werden. Außerdem ist eine schnelle Anpassung an neue Marktbedingungen möglich.
• Erhöhte Transparenz: Durch regelmäßige Updates und Demos fühlen sich die Stakeholder integriert und das Vorhaben hat eine höhere Transparenz.
• Stärkere Teamdynamik: Die enge Zusammenarbeit und Selbstverwaltung fördern ein starkes Teamgefühl und eine hohe Motivation der Beteiligten.

Herausforderungen des iterativen Vorgehens

• Weniger Vorhersehbarkeit: Die Flexibilität kann zu einer gewissen Unsicherheit besonders auf Stakeholder-Seite hinsichtlich des Endprodukts führen.
• Kontinuierliche Stakeholder-Einbindung: Diese Herangehensweise erfordert ein hohes Maß an Engagement und regelmäßige Kommunikation mit allen Beteiligten. Stakeholder müssen folglich bereit sein, sich häufig aktiv mit ihrem Feedback einzubringen.
• Risiko der Zielverschiebung: Agile Ansätze brauchen eine klare Vision – ohne diese kann der Fokus vom eigentlichen Projektziel abweichen.

Fazit: Wann sollte ich nun welche Methode wählen?

Die Entscheidung zwischen klassischer Terminplanung und agilem iterativem Vorgehen hängt stark von der Projektart, der Unternehmenskultur und den spezifischen Anforderungen ab. Traditionelle Methoden eignen sich besser für Projekte, bei denen Stabilität und vorhersehbare Ergebnisse sowohl möglich als auch wichtig sind, während agile Methoden für dynamische Projekte in sich schnell ändernden, komplexen Umgebungen, wo schnelles Hinzulernen essenziell ist, gemacht sind.

Der Beitrag Klassisch vs. Agil: Terminplanung vs. Iteratives Vorgehen erschien zuerst auf Blog Antje Lehmann Training + Consulting.