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.

Virtuelle Zusammenarbeit ist keine Ausnahme mehr, sondern für viele Projektteams zur Normalität geworden. Doch trotz der zahlreichen Vorteile bringt diese Arbeitsweise auch ihre Herausforderungen mit sich. Kommunikationsprobleme, Schwierigkeiten bei der Abstimmung, das Gefühl von Isolation sowie kulturelle Missverständnisse gehören zu den größten Stolpersteinen in der Remote-Arbeit. In diesem Artikel möchte ich fünf bewährte Tipps aus meiner langjährigen Erfahrung mit virtuellen Teams teilen, um diese Herausforderungen effektiv zu meistern und die Zusammenarbeit zu verbessern.

Tipp 1: Die richtigen Kollaborationstools wählen

Laut der Studie „State of Remote Work“ gehören Kommunikationsprobleme und Schwierigkeiten bei der Zusammenarbeit zu den größten Herausforderungen virtueller Teams. Durch die sorgfältige Auswahl der passenden Kollaborationstools können technische Hürden in der Kommunikation vermieden werden. Dabei gibt es keine universelle Lösung für alle Teams und Projekte. 

Folgende Kriterien sollten bei der Auswahl berücksichtigt werden:​

• Die Tools müssen benutzerfreundlich sein, damit alle Teammitglieder schnell damit zurechtkommen.​
• Sie sollten eine effiziente Abstimmung und kontinuierliche Fortschrittsverfolgung ermöglichen.​
• Echtzeit-Interaktionen und rasche Entscheidungsfindungen müssen unterstützt werden.​
• Die Tools sollten den aktuellen Datenschutz- und IT-Richtlinien entsprechen.​
• Sie sollten leicht integrierbar und flexibel einsetzbar sein.​
• Für internationale Teams sollten sie auch die Zusammenarbeit über verschiedene Zeitzonen hinweg erleichtern.​

Aus eigener Erfahrung haben sich Tools wie Miro, Mural oder Conceptboard für kreative Prozesse und Ideenfindung bewährt. Für Aufgabenmanagement und Projektorganisation eignen sich Trello oder Jira, während Zoom oder Microsoft Teams die Kommunikation erleichtern.​

Tipp 2: Zeitmanagement und bewusste Kommunikation fördern

In der Remote-Arbeit verschwimmen häufig die Grenzen zwischen beruflicher Tätigkeit und privatem Leben. Klare Strukturen und ein bewusstes Zeitmanagement können helfen, Überlastung zu vermeiden. Führungskräfte können dabei aktiv unterstützen, indem sie regelmäßige Zeitfenster für Meetings festlegen und diese effektiv gestalten. So entsteht ein regelmäßiger Austausch, der den Informationsfluss fördert.​

Auch das Planen von klar definierten Fokuszeiten hilft den Mitarbeitenden, Ablenkungen zu vermeiden und produktiver zu arbeiten. Bewährte Hilfsmittel sind hierbei die Pomodoro-Technik oder Tools wie Focus@Will, die fokussiertes Arbeiten fördern.​

Bewusst geplante Pausen, die zur Regeneration genutzt werden sollten, helfen, die Konzentrationsfähigkeit und Arbeitsleistung zu erhalten. Virtuelle Kaffeepausen bieten gleichzeitig einen Raum für den informellen Austausch. So wird auch remote die Teambeziehung auf persönlicher Ebene gestärkt.​

Tipp 3: Digitale Nähe schaffen

Gerade in Remote-Teams kann das Gefühl entstehen, voneinander isoliert zu sein. Um dies zu verhindern, sind kreative Ansätze gefragt, die digitale Nähe ermöglichen. Zwei bewährte Techniken sind das sogenannte „Fishbowl Window“ und die Rolle eines „Remote-Teambotschafters“.​

Das Fishbowl Window bezeichnet eine dauerhaft offene Videokonferenz während definierter Arbeitszeiten. Dadurch wird spontane Kommunikation ermöglicht, ähnlich wie im physischen Büro. Wichtig ist hierbei eine klare Kommunikation über den Umgang mit der Kamera, um das Gefühl ständiger Beobachtung zu vermeiden.​

Ein Remote-Teambotschafter wiederum sorgt gezielt dafür, dass alle Mitarbeitenden über wichtige Entwicklungen informiert sind und sich integriert fühlen. Er organisiert sowohl formelle Meetings als auch informelle Treffen und trägt aktiv dazu bei, dass das Gemeinschaftsgefühl trotz räumlicher Distanz erhalten bleibt.​

Tipp 4: Persönliche Treffen gezielt einsetzen

Obwohl Remote-Arbeit durch Flexibilität überzeugt, ist der persönliche Kontakt nach wie vor unersetzlich, wenn es um die Stärkung von Vertrauen und Teamzusammenhalt geht. Persönliche Treffen sollten daher gezielt eingeplant werden, besonders bei der Einarbeitung neuer Teammitglieder oder regelmäßig als Team-Event.​

Das Onboarding neuer Mitarbeitender profitiert enorm von einer persönlichen Begegnung zu Beginn der Zusammenarbeit, da es hilft, Unsicherheiten abzubauen und Vertrauen aufzubauen. Regelmäßige Treffen, etwa zu Projektbeginn oder in regelmäßigen Abständen, festigen das Teamgefühl und ermöglichen eine andere Qualität des Informationsaustauschs als rein digitale Meetings.​

Tipp 5: Kulturelle Sensitivität entwickeln und fördern

Internationale Remote-Teams vereinen Menschen verschiedener kultureller Hintergründe, was zu kreativen Ideen, aber auch zu Missverständnissen führen kann. Deshalb ist kulturelle Sensitivität essenziell. Es gilt, das Bewusstsein für mögliche interkulturelle Unterschiede bei Kommunikation und Verhalten zu stärken.​

Gesten, Mimik und Formulierungen können in verschiedenen Kulturen völlig unterschiedlich interpretiert werden. Daher sollte eine offene und respektvolle Kommunikation gefördert werden, in der kulturelle Unterschiede besprochen werden können, ohne dass sich jemand angegriffen fühlt.​

Gemeinsame Events oder das bewusste Feiern kultureller Besonderheiten stärken zusätzlich das Zusammengehörigkeitsgefühl. Hilfreich ist es auch, gemeinsame Werte und Verhaltensregeln in einem Team-Charter festzuhalten.​

Fazit: Remote-Arbeit funktioniert, wenn die Rahmenbedingungen stimmen

Remote-Teams bringen eigene Herausforderungen mit sich – von Kommunikationshürden bis hin zu kulturellen Unterschieden. Doch mit den richtigen Strategien, passenden Tools und einem bewussten Fokus auf Teamkultur und Struktur lässt sich auch auf Distanz ein starkes Miteinander schaffen.

Virtuelle Teams können genauso effektiv, kreativ und verbunden arbeiten wie Teams im Büro – wenn die Rahmenbedingungen aktiv gestaltet werden. Persönliche Treffen, transparente Kommunikation und gegenseitiges Verständnis sind dabei keine „Nice-to-haves“, sondern die Basis für ein erfolgreiches Team.

Kurz gesagt: Gute Remote-Teamarbeit funktioniert – und zwar richtig gut, wenn man sie professionell angeht.

Der Beitrag 5 Tipps für Remote-Teams erschien zuerst auf Blog Antje Lehmann Training + Consulting.

Ähnlich passiert es oft bei Menschen, die sich auf eine Scrum-Zertifizierung vorbereiten. Sie kennen agile Techniken und haben praktische Erfahrung, doch der zentrale Leitfaden, der Scrum Guide, wird häufig übersehen. Diese Tipps zur Scrum Prüfung können bei der Vorbereitung helfen:

Tipp 1 für die Scrum Prüfung: Den Scrum Guide intensiv studieren

Der Scrum Guide bildet das Fundament jeder Zertifizierung und ist der Dreh- und Angelpunkt, egal ob als Scrum Master, Product Owner oder Developer. Die aktuellste Version ist entscheidend, denn sie bildet die Basis für die Prüfung. Während der Vorbereitung sollte klar sein, dass die Sprintplanung beispielsweise in drei Themen unterteilt ist oder dass der Begriff „Development-Team“ in älteren Versionen verwendet wurde, während in neueren nur noch die Rede von “Developers im Scrum-Team” ist. Weitere Neuerungen in der 2020er-Version sind hier gut zusammengefasst.

Tipps zum Umgang mit dem Scrum Guide:

• Notizen machen: Es kann helfen, neue Erkenntnisse oder korrigierte Missverständnisse schriftlich festzuhalten.
• Versionsvergleich: Prinzipien bleiben konstant, doch Details können sich ändern. Daher ist es ratsam, immer einen Blick auf die Scrum Guide Revision History zu halten.
• Austausch suchen: Durch Diskussionen mit Kolleg:innen und in passenden Netzwerken lässt sich ein tieferes Verständnis für den Guide entwickeln.

Je intensiver die Inhalte verinnerlicht werden, desto sicherer gelingt nicht nur die Prüfung, sondern am Ende natürlich auch der Alltag in der Praxis.

Tipp 2 für die Scrum Prüfung: Offizielle Open Assessments nutzen

Wie früher in der Schulzeit können Übungsfragen den Unterschied machen. Beispieltests, etwa auf scrum.org unter “Certification”, bieten eine effektive Möglichkeit, Wissen zu testen und gezielt Feedback zu erhalten.

So lassen sich Übungsfragen effektiv nutzen:

• Vertrauenswürdige Quellen nutzen: Die Scrum Open Assessments sind speziell darauf ausgelegt, Kenntnisse zu prüfen. Drittanbieter-Fragen hingegen sind oft unzuverlässig oder veraltet.
• Analyse: Mit dem erhaltenen Feedback können gezielt Wissenslücken geschlossen werden.
• Wiederholung: Mehrfache Tests führen zu mehr Sicherheit.

Mit den richtigen Ressourcen lässt sich das nötige Selbstvertrauen für die Prüfung aufbauen.

Tipp 3 für die Scrum Prüfung: Begriffe und Konzepte verinnerlichen

Scrum-Zertifizierungen testen nicht nur Faktenwissen, sondern auch das Verständnis für grundlegende Prinzipien und deren Anwendung in der Praxis. Begriffe wie „Facilitation“, „Servant Leadership“ oder „Transparency“ sollten in- und auswendig bekannt sein. Helfen kann dabei auch unser Glossar.

Praktische Lernstrategien:

• Flashkarten: Begriffe und Definitionen können auf Karten notiert und wie Vokabeln gelernt werden.
• Anwendungsübungen: Prinzipien wie „Servant Leadership“ lassen sich in Szenarien durchdenken, etwa wie sie in einem Teamkonflikt angewendet werden könnten.
• Sprache: Da Prüfungen auf Englisch abgehalten werden, kann es hilfreich sein, die eigenen Sprachkenntnisse aufzufrischen und die Schlüsselwörter speziell auf englisch zu lernen. Plugins wie Google Translate können in Scrum-Prüfungen häufig genutzt werden und sind eine Unterstützung, sollten aber keine ausschließliche Stütze sein.

Es reicht also nicht, Begriffe nur zu kennen – sie sollten auch anwendbar sein.

Tipp 4 für die Scrum Prüfung: Die geeignete Prüfungsumgebung schaffen

Ein gut vorbereiteter Prüfungsraum ist genauso wichtig wie das eigene Wissen. Technische Probleme oder Ablenkungen können entscheidend sein.

Checkliste für die optimale Umgebung:

• Ruhe: Eine ungestörte Umgebung ist essenziell. Familie oder Mitbewohner:innen sollten vorab informiert werden.
• Technik: Eine stabile Internetverbindung ist besonders wichtig. Tools wie Google Translate können wie bereits hilfreich sein, sollten aber bei einem geplanten Einsatz vorab getestet werden.
• Zeit: Genügend Puffer vor und nach der Prüfung schafft Raum für Konzentration.  Der Effekt auf die Nerven sollte nicht unterschätzt werden, ist dann aber durchaus gut durchzustehen.

Eine gut vorbereitete Umgebung erleichtert es, sich voll und ganz auf die Prüfung zu konzentrieren.

Tipp 5 für die Scrum Prüfung: Eine kluge Prüfungsstrategie

Viele berichten, dass die Zeit während der Prüfung wie im Flug vergeht – und damit eigentlich zu schnell. Mit einer durchdachten Strategie lässt sich die Kontrolle bewahren.

Bewährte Taktik:

• Schnellstart: Zunächst sollten alle Fragen beantwortet werden, bei denen Sicherheit besteht.
• Markieren: Unklare Fragen können markiert werden, um sie später gezielt zu bearbeiten.
• Priorisierung: Markierte Fragen werden nach dem ersten Durchgang bearbeitet.

Diese Herangehensweise hilft, Panik zu vermeiden und effizient zu arbeiten.

Mit diesen fünf Tipps zur Scrum Prüfung lässt sich die Scrum-Zertifizierung sicherer angehen. Sie bieten nicht nur einen Fahrplan für die Prüfung, sondern auch wertvolle Werkzeuge, um die agile Praxis nachhaltig zu verbessern.

Für weitere Unterstützung und Tipps zur Scrum Prüfung biete ich gerne meine Hilfe an.

Der Beitrag Fünf Tipps, um die Scrum-Prüfung zu bestehen erschien zuerst auf Blog Antje Lehmann Training + Consulting.

Das war in Zeiten, als die Technik noch nicht so ausgereift war wie heute: keine Webcams, Online-Meetings waren ähnlich wie Telefonate – nur eben über den PC. Trotzdem haben wir es geschafft, Projekte erfolgreich umzusetzen. Was war der Schlüssel dazu? Wir mussten lernen, wie man remote zusammenarbeitet. Und auch heute noch steht und fällt der Erfolg mit den richtigen Strategien.

Kann Remote-Projektarbeit langfristig erfolgreich sein?

Ein klares „Ja, aber“ – denn ohne die richtigen Strategien geht es nicht! Der entscheidende Faktor ist, die besonderen Anforderungen an Remote-Arbeit zu verstehen und entsprechende Strategien zu entwickeln. Dann kann ein Remote-Team ebenso erfolgreich sein, wie jedes andere Team.

Die Vorteile von Remote-Projektarbeit

Remote-Projektarbeit bietet zahlreiche Vorteile, die sowohl den Arbeitsalltag erleichtern, als auch die Produktivität von Projekten steigern können:

1. Flexibilität: Mitarbeitende können zu den Zeiten arbeiten, in denen sie am produktivsten sind, sofern dies mit den Abläufen des Teams harmoniert. Besonders für Eltern oder Personen mit besonderen Verpflichtungen stellt diese Flexibilität einen erheblichen Vorteil dar. Es wird möglich, berufliche und private Anforderungen besser zu vereinen.
   
2. Globale Talente: Die Möglichkeit, Fachkräfte weltweit ins Team zu holen, erweitert den Zugang zu Talenten erheblich. Gleichzeitig kann eine solche kulturelle Vielfalt die Kreativität und die Innovationskraft innerhalb des Teams steigern.
   
3. Kostenvorteile: Die Reduzierung des Bedarfs an teuren Büroflächen senkt die Fixkosten. Die dadurch eingesparten Mittel können in andere Projekte, moderne Tools oder Weiterbildungen investiert werden, was langfristig allen Beteiligten zugutekommt.

Allerdings gibt es auch Aspekte, die sowohl positiv als auch negativ wirken können:

• Unterbrechungen: Das Wegfallen spontaner Besuche von Kolleg:innen kann die Konzentration erhöhen. Gleichzeitig entstehen im Homeoffice neue Störfaktoren wie private Nachrichten, klingelnde Postbot:innen oder Haushaltsgeräte. Eine klare Trennung von Arbeits- und Privatbereich ist daher essenziell.

Darüber hinaus können sich soziale Herausforderungen ergeben. Das Gefühl von Isolation oder ein fehlendes Zugehörigkeitsgefühl zum Team sind Punkte, die aktiv angegangen werden sollten.

Die größten Herausforderungen von Remote-Projektarbeit und ihre Lösungen

Damit Remote-Projektarbeit langfristig erfolgreich bleibt, gilt es, typische Herausforderungen zu bewältigen:

1. Teamkommunikation

Die Kommunikation in virtuellen Teams kann durch das Fehlen spontaner Gespräche oder informeller Austauschmomente beeinträchtigt werden. Besonders die sogenannte osmotische Kommunikation – der beiläufige Austausch von Informationen im Großraumbüro – entfällt komplett.

Tipp: Kombiniere asynchrone Tools wie MS Teams oder Slack mit „Großraumbüro-Simulationen“: gemeinsame Arbeitsmeetings, in denen alle arbeiten und sich nur melden, wenn sie Fragen haben. Das reduziert Isolation und fördert die Zusammenarbeit. Teambuilding passiert nicht von alleine – doch in Remote Teams erfordert es mehr Engagement, um ein Team wirklich zusammenzubringen.

2. Selbstdisziplin

Die eigenverantwortliche Strukturierung der Arbeit ist eine der größten Herausforderungen, insbesondere ohne direkte Überwachung.

Tipp:  Feste Fokuszeiten und verbindliche Blocker im Kalender können helfen, Ablenkungen zu minimieren und eine klare Arbeitsroutine zu etablieren.

3. Technische Infrastruktur

Instabile Internetverbindungen oder mangelnde Technikkenntnisse können die Zusammenarbeit stören.

Tipp: Investitionen in hochwertige Hardware sowie gezielte Schulungen für Mitarbeitende stellen sicher, dass alle Teammitglieder uneingeschränkt an Projekten teilnehmen können.

Weitere Erfolgsfaktoren für Remote-Projektarbeit

Damit Remote-Arbeit effektiv gelingt, sind also bestimmte Erfolgsfaktoren entscheidend. Zu den weiteren wichtigen Faktoren gehört ein gemeinsames Verständnis von Zielen, Rollen und Verantwortlichkeiten im Team. Missverständnisse können gerade bei virtueller Zusammenarbeit schwerer erkannt werden und deshalb leicht zu Projektverzögerungen führen. Ein klar definierter Kommunikationsplan hilft dabei, alle Beteiligten auf dem gleichen Stand zu halten und den Austausch effizient zu gestalten.

Darüber hinaus spielt Vertrauen eine zentrale Rolle: Mitarbeitende, die das Gefühl haben, dass ihnen zugetraut wird, ihre Arbeit eigenständig zu organisieren, sind oft motivierter und produktiver. Führungskräfte sollten daher einen Fokus auf ergebnisorientiertes Arbeiten legen, anstatt reine Anwesenheit oder Aktivität zu bewerten.

Führungskräfte sind in virtuellen Teams besonders gefordert, eine unterstützende und inspirierende Rolle einzunehmen. Ohne die direkte Präsenz im Büro fehlt oft die Möglichkeit für spontanes Feedback oder informelle Gespräche. Umso wichtiger ist es, regelmäßige Einzelgespräche und Team-Check-ins zu etablieren, in denen nicht nur operative Themen, sondern auch persönliche Anliegen Raum finden.

Eine klare Vision und transparente Kommunikation helfen, Orientierung und Sicherheit zu bieten. Gleichzeitig sollten Führungskräfte auf eine offene Feedbackkultur setzen und den Austausch fördern – auch über digitale Kanäle. Virtuelles Teambuilding, wie gemeinsame Online-Spiele oder Kaffeepausen, kann ebenfalls dazu beitragen, die Beziehungsebene im Team zu stärken.

Die richtige Auswahl und Nutzung von Tools ist ein weiterer entscheidender Erfolgsfaktor für Remote-Projektarbeit. Dabei gilt: Weniger ist oft mehr. Zu viele verschiedene Tools können zu Verwirrung führen und die Zusammenarbeit erschweren. Stattdessen sollte das Team auf eine zentrale Plattform setzen, die alle wesentlichen Funktionen wie Kommunikation, Aufgabenmanagement und Dokumentenablage vereint.

Neben der Technik spielen auch Methoden wie das elektronische Aufgaben-Board, Tools mit Cloud-Bearbeitungsmöglichkeiten oder virtuelle Daily Stand-ups eine wichtige Rolle. Diese können helfen, den Fortschritt transparent zu machen und die Zusammenarbeit zu koordinieren. Wichtig ist, dass alle Teammitglieder so geschult werden, dass sie die Tools und Methoden effektiv einsetzen können – so werden Frustrationen vermieden und die Effizienz gesteigert.

Blick in die Zukunft: Remote ist gekommen, um zu bleiben

Remote-Arbeit wird auch langfristig eine zentrale Rolle spielen. Laut einer Studie des Fraunhofer-Instituts für Arbeitswirtschaft und Organisation (IAO) haben 89 % der befragten Unternehmen angegeben, dass mindestens die Hälfte ihrer Mitarbeitenden im Homeoffice arbeiten kann. Zudem haben 80 % der Unternehmen die Remote-Arbeit für Bereiche eingeführt, die vor der Pandemie nicht als geeignet galten. Diese Zahlen verdeutlichen, dass Remote- und Hybridmodelle nicht nur eine vorübergehende Lösung sind, sondern sich als fester Bestandteil der Arbeitswelt etabliert haben.

Auch hybride Arbeitsmodelle gewinnen zunehmend an Bedeutung. Sie verbinden die Flexibilität der Remote-Arbeit mit den sozialen Vorteilen der Büropräsenz. Studien zeigen, dass solche Modelle von vielen Unternehmen bevorzugt werden, um sowohl die Produktivität zu steigern als auch die Bindung der Mitarbeitenden an das Unternehmen zu stärken 

Doch um langfristig erfolgreich zu sein, benötigen Teams klare Regeln, passende Tools und eine Kultur des gegenseitigen Vertrauens. Die Investition in hybride Strukturen kann dabei helfen, die Vorteile beider Welten optimal zu nutzen und gleichzeitig Herausforderungen wie Isolation und technische Hürden zu minimieren.

Fazit: Erfolgreich remote arbeiten – mit Strategie und Teamgeist

Remote-Projektarbeit kann langfristig erfolgreich sein, wenn Teams ihre Kommunikation, Disziplin und Technik im Griff haben. Mit den richtigen Strategien wird das Homeoffice zur echten Alternative – nicht nur kurzfristig, sondern auch auf lange Sicht.

Der Beitrag Remote, aber richtig: Wie Projektarbeit auch auf Distanz funktioniert erschien zuerst auf Blog Antje Lehmann Training + Consulting.

Dieses Projektmanagement Glossar liefert eine schnelle Übersicht über die wichtigsten Begriffe aus den Themenbereichen Agilität, Skalierungs-Frameworks und Projektmanagement, wie sie auch hier im Blog verwendet werden.

A

Agile Coach: Sorgt für das richtige Verständnis agiler Praktiken, ist erfahren darin, Teammitglieder effektiver zu machen und Prozesse für die Organisation zu verbessern. Ein Agile Coach ist Moderator:in und Facilitator:in – ähnlich wie die Rolle Scrum Master im Scrum-Framework.

Agile Release Train (ART): Im Skalierungs-Rahmenwerk SAFe® ein dauerhaftes Team aus mehreren agilen Teams, das zusammen mit seinen Stakeholdern innerhalb eines zusammenhängenden Themenbereichs inkrementell eine oder mehrere Lösungen entwickelt, bereitstellt und betreibt.

Agile Triangle: Das klassische Dreieck der drei Einschränkungen (fester Umfang, berechnetes Projektbudget und Zeit) wird sozusagen „auf den Kopf gestellt“, wodurch der Umfang gelieferter Ergebnisse flexibel und verhandelbar wird. Stattdessen werden feste Zeitvorgaben, basierend auf Iterationsrhythmen und möglicherweise einer Deadline, gesetzt.

B

Burn-down Chart: Ein Diagramm, das den Arbeitsaufwand zeigt, der voraussichtlich in der Abarbeitung eines Backlogs verbleibt. Die Zeit wird auf der horizontalen Achse und die verbleibende Arbeit auf der vertikalen Achse angezeigt.

Burn-up Chart: Ein Diagramm, das den Umfang der abgeschlossenen Arbeit anzeigt. Die Zeit wird auf der horizontalen Achse und die abgeschlossene Arbeit auf der vertikalen Achse angezeigt.

C

CCC für User Storys: User Storys sollten kurz genug sein, um auf eine auf eine Karte (Card) zu passen. Sie sollten außerdem als Grundlage für eine Konversation dienen, und sie sollten transparent machen, wann eine Bestätigung (Confirmation) vorliegt, dass sie abgeschlossen sind (also Details, Akzeptanzkriterien enthalten).

Chief Product Owner (CPO): Rolle, die in Jeff Sutherlands Skalierungs-Rahmenwerk ‚Scrum at Scale‘ die Gesamtstrategie und -vision beibehält. Alle anderen agilen Praktiken und Muster des CPO folgen denen von Product Ownern in Scrum.

Communities of Practice (CoPs): Menschen mit gemeinsamen Interessen an einer bestimmten technischen oder geschäftlichen Domäne, die sich zu diesen Themen in Gruppen organisieren. Sie arbeiten in diesen Themengruppen regelmäßig zusammen, um Informationen auszutauschen, ihre Kompetenzen zu verbessern und aktiv an der Weiterentwicklung und dem Austausch ihres Domänenwissens zu arbeiten.

Continuous Integration: Softwareentwicklungs-Prinzip, aus dem Framework ‚Extreme Programming‘: Sobald die Arbeit an einer Aufgabe abgeschlossen ist, wird das Ergebnis früh und häufig in das Gesamtsystem integriert. Nach jeder solchen Integration müssen Tests im System erfolgreich durchlaufen.

Control Limits: Werkzeug aus dem Bereich der Statistik und Qualitätskontrolle, das auch im Projektmanagement Anwendung findet. Sie werden genutzt, um Variabilität in Prozessen zu analysieren und sicherzustellen, dass diese innerhalb eines akzeptablen Bereichs bleibt. Sie können in eigenen Kontrolldiagrammen dargestellt oder in anderen Diagrammen eingezogen werden, so etwa auch in einem Burn-down Chart oder in Fehlermessungen, um z.B. Abweichungen von gewünschten Bearbeitungszeiten oder von der gewünschten Anzahl Fehler im Produkt früh zu erkennen.

Cross-functional team: Ein funktionsübergreifendes Team besteht aus Individuen mit unterschiedlichen fachlichen Spezialisierungen. Es wird funktionalen Teams vorgezogen, da Silos reduziert und die Selbstorganisation gefördert werden.

Crystal Family of Methods: Ein Framework, das die Kritikalität eines Projekts und die Teamgröße mithilfe einer farbcodierten Matrix bewertet, um die passende Vorgehensweise auszuwählen. Crystal Clear ist für kleine, agil arbeitende Teams geeignet.

Cumulative Flow Diagram (CFD): Ein Kanban-Diagramm, das den Feature-Backlog, die laufenden Arbeiten und die abgeschlossenen Features im Laufe der Zeit kumulativ darstellt. Es wird verwendet, um Engpässe zu erkennen und zu beseitigen.

Cycle Time (CT): Lean-Metrik: die durchschnittliche Zeit, die benötigt wird, um Arbeit vom Beginn der Bearbeitung einer Anforderung bis zur Veröffentlichung abzuschließen. Je kürzer, desto besser, solange die Qualitätsstandards eingehalten werden. Begrenzung der Work in Progress oder Erhöhung des Durchsatzes können die Cycle Time reduzieren.

D

Daily Scrum: 15-minütiges Scrum-Event, das jeden Tag für die Developer:innen stattfindet. Das Daily Scrum findet an jedem Tag des Sprints statt. Dabei planen die Developer:innen die Arbeit für die nächsten 24 Stunden. Dies optimiert die Zusammenarbeit und Leistung im Team, indem die Arbeit seit dem letzten Daily Scrum überprüft und die noch bevorstehende Sprint-Arbeit prognostiziert wird. Das Daily Scrum findet jeden Tag zur gleichen Zeit und am gleichen Ort statt, um die Komplexität zu reduzieren.

Daily Standup: Ein Synchronisationsereignis in Kanban und ähnlich in Scrum (dort als Daily Scrum bezeichnet), bei dem sich die Developer:innen über den täglichen Fortschritt abstimmen und bei Bedarf neu planen.

DEEP Backlog: Ein guter Product Backlog ist Detailed Appropriately, Estimated, Emergent und Prioritized (im angemessenen Grad detailliert, geschätzt, neueste Erkenntnisse berücksichtigend und priorisiert). Mehr zu Deep Backlogs.

Definition of Done: Ein gemeinsames Verständnis von allgemeinen Erwartungen, die ein Entwicklungsergebnis erfüllen muss, um produktiv genutzt werden zu können. Es erhöht die Transparenz und hilft bei der Planung des benötigten Aufwands für Arbeit – eine längere DoD braucht auch mehr Zeit, um sie zu erfüllen. Wird von agilen Teams erstellt und verantwortet.

Defect Rate: Die Anzahl der bei und nach der Entwicklung gefundenen Fehler in einem Produkt sollte gemessen und verfolgt werden. Eine höhere Rate kann mehr Defekte oder eine bessere Erkennung bedeuten, daher ist es wichtig, auch die Defect Detection Rate zu überwachen (wie gut sind wir beim Erkennen von Fehlern, wie viele bleiben unerkannt?).

Design Thinking: Ein Ansatz, der vom Designunternehmen IDEO entwickelt wurde. Er fördert Kreativität bei der Entscheidungsfindung durch einen Prozess aus Erfahrung, Ideenfindung und Prototyping mit starker Einbindung der Nutzer.

Developer:in: Jedes Mitglied eines Scrum-Teams, das sich dazu verpflichtet, in jedem Sprint einen Aspekt eines nutzbaren Inkrements umzusetzen.

DevOps: ein Ansatz, der die Zusammenarbeit von Entwicklung (Development) und IT-Betrieb (Operations) fördert, um Software schneller, zuverlässiger und mit höherer Qualität bereitzustellen.

Dreyfus Skill Acquisition Model: Schritte, die eine Person beim Erlernen neuer Fähigkeiten durchläuft: Einsteiger, Anfänger, Kompetent, Erfahren, Experte. In einem agilen Team sollten zumindest einige Personen über die Fähigkeiten verfügen, die notwendig sind, um lieferbare Inkremente zu erstellen – und mindestens erfahren in diesen Fähigkeiten sein. Sie sollten ihr Wissen mit dem Team teilen.

Dynamic System Development Method (DSDM): Ansatz aus den frühen 1990er-Jahren, um IT-Projekte agiler durchzuführen, mit explorativen Projektphasen und iterativen Aspekten.

E

Earned Value Management (EVM): Eine klassische Methode zur Messung der Projektleistung, die Umfang, Zeit und Kosten integriert, um den Fortschritt zu überprüfen, Abweichungen vom Plan zu messen und Maßnahmen zu ergreifen. Häufig in Kombination mit einer Work Breakdown Structure (WBS) verwendet.

Entwicklungs-Standards: Ein gemeinsamer Satz von Umsetzungs- und Technologiestandards, die Entwickler anwenden, um lieferfähige Software-Inkremente zu erstellen.

Emergenz: Der Prozess des Entstehens oder des Bekanntwerdens neuer Tatsachen bzw. neuer Erkenntnisse, der unerwartet zu Tage tritt.

Empirismus: Die Philosophie, dass alles Wissen aus Erfahrung und Beobachtungen entsteht.

Escaped Defects: Defekte, die vom Kunden nach der Auslieferung gemeldet werden. Diese sollten verfolgt werden, um Möglichkeiten zur Prozessverbesserung zu identifizieren.

Evidence-Based Management (EvBM): Beinhaltet das Treffen von Entscheidungen auf Basis harter Fakten darüber, was tatsächlich funktioniert. Es umfasst eine Reihe von Metriken zur Messung des Produktwerts, z. B. Current Value, Time to Market und Ability to Innovate.

Executive Action Team (ETA): Nach dem S@S-Framework in großen Organisationen eine höhere Abstraktionsebene über der SoS-Ebene. Das ETA befasst sich mit Hindernissen, die vom Scrum of Scrums Master nicht gelöst werden können.

Executive Meta Scrum (EMS): Nach dem S@S-Framework ein Event, bei dem sich Chief Product Owner mit Führungskräften und wichtigen Stakeholdern treffen, um Prioritäten zu setzen, Budgets zu ändern oder Teams neu auszurichten.

Extreme Programming (XP): Agiles Framework, das ähnlich wie Scrum ein Projekt in kleinere Iterationen aufteilt; nutzt Release-Planung, User Storys und Velocity. 13 Kernpraktiken wie Refactoring und Pair Programming. Mehr zu Extreme Programming.

F

5 Whys: Eine Technik, bei der die Frage „Warum (ist das passiert)?“ fünfmal gestellt wird, um die Schichten von Symptomen abzutragen und die eigentliche Grundursache eines Problems zu finden. Entwickelt von Taiichi Ohno bei Toyota.

Feature: Eine Funktion oder eine Arbeitseinheit, die nach ihrer Fertigstellung den Endbenutzern einen Mehrwert bietet.

Feature Breakdown Structure (FBS): Eine Zerlegung des Arbeitsumfangs für ein Produkt in Features, Epics, Storys und Tasks (aus dem agilen Framework ‚Feature-Driven Development‘). Wird in agilen Ansätzen häufiger verwendet als eine klassische Work Breakdown Structure (dt. Projektstrukturplan), bei der Budgets und Zeitpläne auf Arbeitspakete verteilt werden und damit der Umfang fixiert wird.

Feature-Driven Development: Ein iterativer und inkrementeller Softwareentwicklungsprozess, der sich an funktionaler, für den Kunden wertvoller Funktionalität (Features) orientiert. Feature-Driven Development wird hauptsächlich in der agilen Softwareentwicklung eingesetzt. Es basiert auf dem Prinzip, nach Features zu planen, zu entwerfen und zu entwickeln, und organisiert Teams in funktionsübergreifende Feature-Teams (nicht in einzelne Komponenten-Teams).

Fishbone-Analyse: Ein Ansatz von Kaoru Ishikawa zur Problemlösung, bei dem ein Diagramm in Form einer Fischgräte gezeichnet wird, das das Problem und seine möglichen Ursachen darstellt, damit diese in ihrer Vielfalt genauer untersucht werden können.

Flow: bezeichnet in Lean und Kanban das ungehinderte, gleichmäßige Fließen von Arbeit durch einen Prozess. Ziel ist es, Reibungsverluste wie Engpässe, Wartezeiten oder unnötige Unterbrechungen zu minimieren, damit Arbeit möglichst schnell und effizient von der Idee bis zum Ergebnis durchläuft.. Ein Team sollte seinen Flow finden und schützen. In einem Kanban-System fließen Aufgaben (z. B. User Storys) durch Spalten wie „To Do,“ „In Progress“ und „Done.“ Wenn eine Spalte blockiert ist (z. B. zu viele Aufgaben „In Progress“), wird der Engpass analysiert und behoben, um den Flow wiederherzustellen.

Forecast (Vorhersagen von Funktionalitäten): Die Auswahl von Einträgen aus dem Product Backlog, die Entwickler für die Umsetzung in einem Sprint für machbar halten.

G

Guilds: Im Spotify-Modell eine Gruppe von Arbeitnehmern mit demselben Fachwissen und/oder den gleichen Interessen. Bezieht die gesamte Organisation mit ein.

I

Increment: Agiles Artefakt, das die vollständige und wertvolle Arbeit definiert, die von den Developer:innen während eines Sprints geleistet wird – insofern also die Arbeitsergebnisse enthält. Die Summe aller Inkremente bildet ein Produkt.

Internal Rate of Return (IRR): Interner Zinsfuß etwa eines Projekts – also was dieses spätestens nach Beendigung „abwirft“ bzw. wie rentabel es ist. Projekte mit einer höheren Internal Rate of Return (IRR) sind finanziell attraktiver.

INVEST criteria für User Storys: User storys sollten sein: Independent – unabhängig von anderen Storys im Backlog, Negotiable – flexibel und nicht als fixiertes Detail betrachtet werden, Valuable – einen klaren Mehrwert für den Nutzer bieten, Estimable – Einschätzbar in Aufwand und Umfang sein, Sized Appropriately oder Small – klein genug, um in kurzer Zeit umgesetzt zu werden, Testable – mittels klarer Akzeptanzkriterien in ihrer Erfüllung überprüfbar sein. Das Ziel dieser Kriterien ist es sicherzugehen, dass User Storys in einem Backlog immer leicht umsetzbar und für alle verständlich sind.

J

Just-in-time (JIT): Ein Lean-Ansatz, bei dem Materialien genau dann geliefert werden, wenn sie für die Produktion oder den Weiterverkauf benötigt werden. In der Wissensarbeit bedeutet Just-in-Time-Planung, dass Arbeit erst dann im Detail geplant wird, wenn sie bald durchgeführt werden soll. Höher priorisierte Backlog-Elemente erhalten dabei mehr Aufmerksamkeit und Detailgenauigkeit als weniger priorisierte.

K

Kaizen (jap): Kontinuierliche Verbesserung der Prozesse, die alle Beteiligten einbezieht.

Kanban (jap.): „Karte“ oder „sichtbarer Eintrag“ – bezieht sich auf ein System zur Steuerung des Arbeitsflusses in einer Fabrik oder einem Wissensarbeitsteam zu steuern, zu visualisieren und zu organisieren, und somit auf eine Methode. Kanban beginnt mit einem bestehenden Prozess und lässt diesen sich weiterentwickeln. Es basiert auf Selbstorganisation, Pull-Prinzipien und WIP-Limits (Work in Progress).

Kano Model: Ein von Noriaki Kano entwickeltes Modell, das hilft, Kundenpräferenzen zu verstehen. Das Kano-Modell berücksichtigt Eigenschaften eines Produkts oder einer Dienstleistung, die in Bereiche wie Grundfaktoren, Begeisterungsfaktoren und Leistungsfaktoren unterteilt werden. Es kann verwendet werden, um Backlog-Elemente zu klassifizieren und Begeisterungsmerkmale (Exciters/Delighters) in ein MVP (Minimum Viable Product) aufzunehmen.

Kohärenz: Die Qualität der Beziehung zwischen bestimmten Product Backlog-Elementen, die es wert sein kann, als Ganzes betrachtet zu werden.

L

Lean Manufacturing / Production: Ein Ansatz, der darauf abzielt, die höchstmögliche Produktivität und Gesamtqualität kosteneffizient zu erreichen, indem unnötige Schritte im Produktionsprozess eliminiert und kontinuierlich Verbesserungen angestrebt werden. Geprägt als Toyota Production System (Taiichi Ohno). Kontinuierliche Verbesserung und die Beseitigung von Verschwendung stehen im Mittelpunkt.

Little’s Law: Beschreibt eine mathematische Beziehung zwischen Durchsatzrate, Cycle Time und der Menge an Work in Progress (WIP).

M

Minimum Business Increment (MBI): Ein Konzept aus dem Toolkit Disciplined Agile von PMI: ein Increment, das auf einer bestehenden Struktur oder einem Produkt aufbaut und diesem neuen Mehrwert liefert.

Minimum Marketable Feature (MMF): Eine kleine, in sich geschlossene Funktion, die schnell entwickelt werden kann und dem Nutzer einen bedeutenden Mehrwert bietet.

Minimum Viable Product (MVP): Ein Konzept aus dem Lean Startup, das ein minimalistisches Produkt beschreibt, mit dem Unternehmer und Entwickler grundlegende Konzepte einer Idee testen und validieren sowie Kundenfeedback sammeln können.

Mockup: Das ursprüngliche Design oder die Idee, die entweder auf dem Bildschirm angezeigt oder in gedruckter Form präsentiert wird. Mockups ermöglichen es dem Kunden, zu sehen, wie das Endprodukt aussehen soll.

MoSCoW technique: Eine Priorisierungstechnik aus DSDM für User Storys im Backlog: Welche Features sind Must-haves, Should-haves, Could-haves, Won’t-haves this time?

N

Net Present Value (NPV): In der BWL die Summe der Barwerte der erwarteten zukünftigen Cashflows aus einer Investition, abzüglich der Kosten dieser Investition. Angewendet im Projektmanagement ist ein Projekt mit einem höheren Net Present Value (NPV) finanziell attraktiver.

Nexus: Ein Framework der Organisation Scrum.org, das agile Ansätze für größere Projekte skaliert. Mehrere Teams arbeiten dabei am selben Product Backlog, koordiniert durch das Nexus Integration Team, das die Anwendung von Nexus und Scrum koordniniert, coacht und überwacht. Dabei ist es für dieses Team wichtig, für transparente Verantwortlichkeit der Integration zwischen den Scrum-Teams zu sorgen.

P

Payback Period: Die Zeitspanne, die erforderlich ist, damit eine Investition ausreichend Cashflows generiert, um ihre Anfangskosten auszugleichen. Projekte mit einer kürzeren Amortisationszeit sind finanziell attraktiver.

Pair programming (Praktik aus XP): Bezieht zwei Programmierer:innen an einem einzigen Arbeitsplatz ein und bringt sie zusammen. Während einer den Code schreibt, beobachtet der andere aktiv, achtet auf mögliche Fehler und denkt gleichzeitig über den Gesamtansatz nach. Fördert Kreativität und Wissensaustausch.

Persona: Fiktive Vertreter realer Nutzer oder Nutzertypen, die eingesetzt werden, um eine benutzerzentriertere Entwicklung zu ermöglichen. User Storys können für bestimmte Personas geschrieben werden.

PI Planning: Ein kadenzbasiertes Face-to-Face-Event und der Herzschlag des Agile Release Train (ART).

Planning Poker: Eine konsensbasierte Technik zur Schätzung, die hauptsächlich verwendet wird, um den Aufwand oder die relative Größe von Storys oder Aufgaben in der Softwareentwicklung zu ermitteln. Dabei stellt jemand die Story vor, und alle Schätzenden (z. B. Entwickler:innen) geben gleichzeitig ihre Schätzungen, wie Story Points, ab. Wenn es Abweichungen gibt, werden diese diskutiert, und der Vorgang wird wiederholt.

Program Increment (PI): Eine Timebox, in der ein Agile Release Train (ART) inkrementell Wert liefert.

Product Backlog: Ein Scrum-Artefakt, das aus einer sortierten Liste derjenigen Arbeiten besteht, die für eine Produktentwicklung, -pflege und -wartung ausgeführt werden müssen.

Product Backlog Refinement: Die Aktivität in einem Sprint, durch die der Product Owner und die Entwickler dem Product Backlog mehr Granularität hinzufügen.

Product Goal (Produkt-Ziel): Beschreibt einen zukünftigen Zustand des Produkts, der als Ziel für das Scrum-Team dienen kann.

Product Owner: Rolle in Scrum, die für die Maximierung des Wertes eines Produkts verantwortlich ist.

Prototype: Ein vollständiges funktionsfähiges Modell, das verwendet wird, um ein Designkonzept zu testen, tatsächliche Beobachtungen zu machen und erforderliche Anpassungen vorzunehmen.

R

Ready: Ein gemeinsames Verständnis zwischen dem Product Owner und den Entwicklern hinsichtlich des gewünschten Beschreibungsgrades von Product-Backlog-Einträgen.

Refactoring: Überarbeitung, Neuorganisation und Umstrukturierung eines Teils eines Systems, um dessen Qualität zu erhöhen.

Refinement: Siehe Product Backlog Refinement

Relative sizing / relative Schätzung: Die Schätzung der Größe einer Funktion oder User Story, basierend auf der Größe einer anderen. Ein Beispiel ist die Übung, eine Gruppe von User Storys von der schwierigsten bis zur einfachsten oder von der höchsten bis zur niedrigsten Komplexität zu ordnen, ohne eine absolute Schätzung vorzunehmen. Psychologisch fällt Menschen diese Art der Schätzung leichter als die absolute (es ist einfacher zu sagen „diese Aufgabe ist kleiner als jene“ im Gegensatz zu „für diese Aufgabe brauche ich 3 Tage“).

Release Train Engineer (RTE): In SAFe ein Coach für den Agile Release Train (ART) und somit eine Art Integrations-Scrum-Master.

Return on Investment (ROI): Der Prozentsatz der Gesamtkosten einer (Projekt-)Investition im Verhältnis zum erzielten Gewinn aus dieser Investition (den Nutzen, den das Projekt liefert). Ein Projekt mit einem höheren ROI ist finanziell attraktiver.

Retrospektive: Agile Teams überprüfen und passen regelmäßig ihre Prozesse, Tools und Teamdynamik an. Die Definition of Done kann in diesem Event aktualisiert werden. Mehr zu Retrospektiven hier.

Root-cause analysis (RCA): Ermittelt die zugrunde liegende Ursache von unerwünschten Ereignissen; wird nach einem Vorfall eingesetzt, um die Hauptursache aufzudecken. Grundregel: Verstehe immer die Ursache eines Problems, bevor du versuchst, es zu lösen.

S

Scaled Daily Scrum: Nach dem S@S-Rahmenwerk koordinieren im Scaled Daily Scrum Mitglieder der Scrum-of-Scrum Teams (Vertreter:innen der einzelnen agilen Teams) ihre tägliche Arbeit und Abhängigkeiten untereinander sowie aktuelle Hindernisse und Blocker.

Scrum: Ein gängiges Framework für die agile Entwicklung komplexer Produkte. Teams planen und erledigen ihre Arbeit in kurzen Iterationen, den sogenannten Sprints. Diese schaffen eine regelmäßige Taktung für die weiteren Events und dienen der Anwendung empirischer Prinzipien.

Scrum@Scale (S@S): Ein agiles Vorgehensmodell von Jeff Sutherland zur Skalierung von Scrum über mehrere Teams und Organisationsebenen.

Scrum Board: Ein physisches Board zur Visualisierung von Informationen für und durch das Scrum-Team.

Scrum Guide: Die Definition von Scrum, geschrieben und bereitgestellt von Ken Schwaber und Jeff Sutherland unter scrumguides.org.

Scrum Master: Rolle innerhalb eines Scrum-Teams, die für die Anleitung, das Coaching, das Training und die Unterstützung eines Scrum-Teams verantwortlich ist.

Scrum Team: Ein selbstmanagiertes Team, bestehend aus Scrum Master:in, Product Owner:in und Developer:innen.

Scrum-Werte: Diese lauten Commitment, Fokus, Offenheit, Respekt und Mut und sind für jedes Scrum Team verpflichtend als Werte-Ideal, nach dem immer gestrebt werden sollte.

Selbst-Management: Scrum-Teams sind funktionsübergreifend und selbstverwaltend.

Shu Ha Ri: Ein Fortschreiten eines Teams oder auch einzelner Mitglieder durch verschiedene Stufen: Shu = Befolgen oder Schützen, Akzeptieren der Regeln, Ha = Ablösen oder Abweichen, Abweichen von den Regeln, Ri = Verlassen oder Trennen, Eigene Regeln erstellen. Ein agiles Team benötigt mindestens einige Personen auf der Ri-Stufe.

Spikes: („Durchstich“:) Explorative Aufgaben, die in einer Iteration durchgeführt werden, um Unsicherheiten bezüglich einer Situation, eines Risikos, der zu verwendenden Technologie usw. zu verringern. Sie führen nicht direkt zu Features, tragen aber dazu bei, diese in Zukunft zu erstellen. Sollten bei Bedarf Teil des Product Backlogs sein, um Unsicherheiten zu reduzieren.

Spotify-Modell: Ein Modell, das kein klassisches Skalierungs-Framework darstellt, sondern eine Momentaufnahme aus dem skalierten agilen Unternehmensumfeld von Spotify.

Squads: Agile Teams als Basis des Spotify-Modells, vergleichbar mit einem Scrum Team.

Sprint: Scrum-Begriff für eine Iteration – ein zeitlich begrenztes Ereignis von bis zu vier Wochen, in dem Arbeit geplant, abgeschlossen und in einem Review mit Stakeholdern überprüft wird, um deren Feedback einzuholen. Der Sprint sollte mit einer Sprint-Retrospektive abgeschlossen werden, um teamintern Prozesse, Tools usw. zu analysieren und Verbesserungen für den nächsten Sprint zu finden.

Sprint-Backlog: Scrum-Artefakt, das einen Überblick und Transparenz über die Entwicklungsarbeit zur Erreichung des Ziels eines Sprints bietet.

Sprint-Ziel: Ein kurzer Ausdruck des gemeinsam anvisierten Ziels für eines Sprint, wird bei jeder Sprintplanung vom Team gemeinsam festgelegt und danach täglich verfolgt.

Sprintplanung: Scrum-Event, um gemeinsam in einen neuen Sprint zu starten.

Sprint-Retrospektive: Scrum-Event, um einen Sprint gemeinsam zu beenden und Verbesserungen zu planen.

Sprint-Review: Scrum-Event, um die Entwicklungsarbeit eines Sprints abzuschließen.

Stakeholder: Personen, die an einem Produkt interessiert sind und deren Interessen durch das Produkt beeinflusst werden (sie haben einen „Anspruch“ darauf). Dazu können Kunden, Sponsoren, Endbenutzer, Manager und beteiligte Abteilungen, Geschäftsleute, juristische Personen, im Bauwesen auch Anwohner und viele andere gehören.

System Demo: Ein Event in SAFe, das am Ende eines Entwicklungs-(PI-)-Zyklus eine integrierte Sicht neuer Features für alle Interessierten und Beteiligten bietet.

T

Task: Eine Arbeitseinheit, die erledigt werden muss – die kleinste Arbeitseinheit, die idealerweise im Iterations-Backlog zu finden ist und während der Iterationsplanung (siehe Just-in-Time-Planung) geplant wird.

Technische Schulden: Der in der Regel unvorhersehbare Aufwand für die Wartung des Produkts.

Test-Driven Development: Eine Methode der Softwareentwicklung, ursprünglich aus XP – Testfälle werden vor der eigentlichen Entwicklung der Software erstellt und oft automatisiert. Schritte: Neuen Test schreiben, der zunächst fehlschlägt, Code schreiben, bis der Test erfolgreich durchläuft, Code bereinigen (Refactoring), wiederholen.

Theory of Constraints: Ein Managementansatz, beschrieben von Eliyahu M. Goldratt, der die Bedeutung des Umgangs mit Einschränkungen hervorhebt und darauf abzielt, Engpässe zu identifizieren und zu beseitigen.

Timebox: Ein Prinzip, dass Ereignisse zeitlich begrenzt (mit einer maximalen Dauer) sein sollten, um danach weiterzugehen, Prokrastination und Chaos zu begrenzen sowie Disziplin und Gewohnheit zu entwickeln, sich daran zu halten und das Beste aus ihnen herauszuholen. Alle Scrum-Events, einschließlich des Sprints, sind zeitlich begrenzt.

Trade-off Matrix: Eine von Jim Highsmith (im Buch „Agile Project Management“) vorgeschlagene Matrix, bei der Stakeholder entscheiden müssen, ob sie Fixierungen eher bei Zeit, Budget oder Umfang wünschen. Basierend darauf wird festgelegt, welche der drei als notwendig definiert werden und was flexibel bleibt. Eine Alternative zum Agile Triangle, häufig von DevOps-Teams eingesetzt.

Tribes: Eine Gruppe von Squads, die am gleichen Produkt oder miteinander in Verbindung stehenden Produkten arbeiten.

Tuckmans Modell der Teamentwicklung: Laut Bruce Tuckman durchlaufen Teams typischerweise diese Phasen: Forming (Formierung), Storming (Konfliktphase), Norming (Normierungsphase), Performing (Arbeitsphase), Adjourning (Auflösungsphase). Achtung: Ein Team fällt in die Forming-Phase zurück, wenn neue Mitglieder hinzukommen.

U

User Story: Eine kleine, prägnante Beschreibung einer Funktionalität oder Qualität, die erforderlich ist, um einem bestimmten Stakeholder Wert zu liefern. Häufig ein Eintrag im Product Backlog eines agilen Teams. Mehr zu User Stories.

V

Value Stream Mapping: Eine grafische Darstellung des Value Streams (Wertstroms), also der Wertschöpfung für Stakeholder durch einen Prozessfluss. Sie dient der Analyse, wo im Prozess Schritte Wert hinzufügen oder nicht. Wird verwendet, um Verschwendung zu identifizieren. Mehr dazu hier.

Velocity: In der agilen Entwicklung bezeichnet die Menge an Backlog-Elementen, die während einer Iteration in funktionsfähige Inkremente umgesetzt wird. Ein Team kann seine Velocity nachverfolgen und beschützen, um zu einem nachhaltigen Arbeitsrhythmus zu gelangen. Sie sollte in der Planung jeder Iteration berücksichtigt werden.

W

Walking Skeleton: Ein Produktentwicklungsansatz, bei dem eine vollständige Systemstruktur erstellt wird, jedoch mit nur minimaler Funktionalität.

Wideband Delphi Technique: Wideband-Delphi ist eine gruppenbasierte Schätztechnik, die verwendet wird, um den Arbeitsaufwand und die benötigte Zeit zur Fertigstellung eines Projekts zu bestimmen. Dabei geben die Teammitglieder anonym Schätzungen für jede Funktion ab, und die anfänglichen Schätzungen werden in einem Diagramm dargestellt. Anschließend diskutiert das Team die Faktoren, die ihre Schätzungen beeinflusst haben, und führt eine zweite Schätzrunde durch. Dieser Prozess wird so lange wiederholt, bis die Schätzungen der einzelnen Mitglieder nahe beieinander liegen und ein Konsens für die endgültige Schätzung erreicht werden kann.

Wireframe: Eine Abbildung oder eine Reihe von Abbildungen, die die funktionalen Elemente einer Website oder Seite darstellen, typischerweise zur Planung der Struktur und Funktionalität einer Website verwendet. Oft in Schwarz-Weiß und als einfache Skizze gehalten.

Work Breakdown Structure (WBS): Ein klassisches Projektmanagement-Tool, dt. Projektstrukturplan: eine hierarchische Zerlegung des gesamten Arbeitsumfangs, der vom Projektteam durchgeführt werden muss, um die Projektziele zu erreichen und die erforderlichen Ergebnisse zu liefern. Mehr zum Projektstrukturplan hier.

Work in Progress / Process (WIP): Ein Status, der bedeutet, dass Aktivitäten begonnen haben, aber noch nicht abgeschlossen sind. Er wird häufig als Status für Storys, Incidents, Probleme, Änderungen, Backlog-Items, Aufgaben usw. verwendet. Work in Process (WIP) sollte begrenzt werden, um den Fokus zu bewahren und Engpässe zu vermeiden. In Scrum wird WIP bei jeder Sprint-Planung für den jeweiligen Sprint schon allein durch die Auswahl an geeigneten Backlog-Einträgen begrenzt.

Der Beitrag Projektmanagement und agile Rahmenwerke: Glossar 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.