Agiles Projektmanagement: Methoden, Rituale und praktische Anwendung

Agiles Projektmanagement basiert auf konkreten Rollen und Ritualen, nicht auf einer vagen Philosophie. Hier erfahren Sie mehr über Scrum, Kanban und wie Sie die richtige Methode auswählen – auch in einem Dreierteam.

Agilität: Was sie ist und was sie nicht ist

Agilität wird oft fälschlicherweise mit dem Satz „Mal sehen, wie es läuft“ zusammengefasst. Dies ist das verbreitetste und schädlichste Missverständnis. Ein agiles Projekt ist kein Projekt ohne Planung. Es ist ein Projekt, dessen Planung kontinuierlich und iterativ ist und in jedem Zyklus angepasst wird, anstatt für mehrere Monate im Voraus festgelegt zu sein.

Selbst in einem iterativen Rahmen erfordert eine vertragliche Frist die vorherige Prüfung der Machbarkeit: a Retro-Zeitplan Das verbleibende Tool vergleicht den angekündigten Umfang mit der tatsächlich verfügbaren Zeit.

Der grundlegende Unterschied zu einem traditionellen Ansatz liegt im Umgang mit Unsicherheit. Anstatt von Anfang an alles zu wissen und Abweichungen stillschweigend hinzunehmen, akzeptiert ein agiles Team, dass sich die Bedürfnisse ändern, organisiert seine Arbeit in kurzen Zyklen und passt seine Prioritäten mit jeder Iteration an. Das ist keine Improvisation, sondern ein disziplinierter Ansatz.

Agilität ist weit mehr als nur Softwareentwicklung. Kommunikationsagenturen, Beratungsunternehmen, Kreativstudios und Vertriebsteams nutzen sie, um ihre Kundenprojekte reaktionsschneller und transparenter zu managen.

Das Agile Manifest und seine vier Werte

Im Jahr 2001 verfassten siebzehn amerikanische Entwickler das Agile Manifest, einen kurzen Text, der die philosophische Grundlage aller agilen Methoden bildet. Dieses Manifest schreibt weder Werkzeuge noch Rollen oder Rituale vor. Es formuliert vier Werte, die jeweils zwei Prioritäten gegenüberstellen, nicht um die zweite abzulehnen, sondern um zu bekräftigen, dass die erste wichtiger ist.

Diese vier Werte erklären, warum ein agiles Team eine funktionierende Demo einem 50-seitigen Bericht vorzieht und warum es jeden Morgen ein 15-minütiges Meeting abhält anstatt eines Lenkungsausschuss monatlich. Dies sind keine Launen der Organisation, sondern bewusste Entscheidungen, um die Zeit zwischen Entscheidung und Wertschöpfung zu verkürzen.

Agile vs. V-Modell: eine Vergleichstabelle

Bevor man sich für eine Methodik entscheidet, ist es hilfreich, die konkreten Unterschiede zwischen einem agilen Ansatz und einem traditionellen Ansatz wie dem V-Modell oder dem Wasserfallmodell zu verstehen. Diese beiden Ansätze unterscheiden sich nicht in ihrer Strenge, sondern darin, wie sie mit Unsicherheit und Veränderungen umgehen.

Das V-Modell bleibt relevant für Projekte, deren Umfang von Anfang an präzise und festgelegt ist, wie zum Beispiel ein Datenmigration oder einer Baustelle. Sobald sich die Anforderungen voraussichtlich ändern, der Kunde seine Erwartungen anhand der ersten Ergebnisse feststellt oder der Markt eine Kursänderung erfordert, ist ein agiler Ansatz angemessener.

Scrum im Detail: Rollen, Ereignisse und Artefakte

Scrum ist das am weitesten verbreitete agile Framework in Entwicklungs-, Produkt- und Serviceteams. Es strukturiert die Arbeit in kurze Zyklen, sogenannte Sprints, die typischerweise zwischen einer und vier Wochen dauern. Am Ende jedes Sprints liefert das Team ein funktionales und umsetzbares Inkrement.

Die drei Scrum-Rollen

Scrum basiert auf einem kleinen, multidisziplinären und selbstorganisierten Team, das um drei unterschiedliche Rollen strukturiert ist.

• Der Produktverantwortliche Diese Person ist für die Produktvision verantwortlich. Sie pflegt und priorisiert das Produkt-Backlog, wägt Nutzen und Aufwand gegeneinander ab und stellt sicher, dass das Team stets an den Aufgaben arbeitet, die dem Kunden den größten Mehrwert bieten. Sie trifft die alleinige Entscheidung darüber, was in welches Backlog aufgenommen wird und in welcher Reihenfolge.
• Der Scrum Master Sie sind die Hüter des Rahmens. Sie fördern die Einhaltung von Ritualen, schützen das Team vor externen Störungen, beseitigen Hindernisse, die die Projektabwicklung behindern, und unterstützen das Team bei der kontinuierlichen Verbesserung seiner Arbeitsweisen. Sie sind keine Projektmanager: Sie haben keine hierarchische Autorität über das Team.
• Das Entwicklungsteam Es vereint die Menschen, die die Arbeit tatsächlich ausführen. Es ist multidisziplinär, selbstorganisiert und trägt gemeinsam die Verantwortung für die Qualität seiner Ergebnisse. Die ideale Größe liegt zwischen drei und neun Personen.

Die vier Disziplinen des Sprints

• Sprintplanung Das Sprint-Meeting beginnt. Das Team wählt die Elemente aus dem Product Backlog aus, deren Umsetzung es sich vornimmt, definiert das Sprintziel und unterteilt die Arbeit in konkrete Aufgaben. Die Dauer des Meetings ist proportional zur Sprintlänge: Zwei Stunden pro Sprintwoche sind eine gängige Faustregel.
• Das tägliche Scrum Es handelt sich um ein tägliches Meeting von maximal 15 Minuten. Jedes Teammitglied berichtet über die Aufgaben des Vortages, die heutigen Ziele und eventuelle Hindernisse. Ziel ist nicht die Berichterstattung an Vorgesetzte, sondern die Abstimmung im Team und die schnelle Identifizierung potenzieller Gefahren, die das Erreichen des Sprintziels beeinträchtigen könnten.
• Der Sprint-Review Jeder Sprint schließt mit einer Präsentation der entwickelten Funktionen vor den Stakeholdern ab. Dies ist eine Feedback-Runde, keine Verkaufspräsentation. Das gesammelte Feedback fließt direkt in den Backlog für den nächsten Sprint ein.
• Die Retrospektive Dies ist das Ritual der kontinuierlichen Verbesserung. Das Team reflektiert seine Arbeitsmethoden: Was lief gut, was verursachte Probleme und vor allem, welche konkreten Maßnahmen es im nächsten Sprint umsetzen will. Eine gute Retrospektive führt zu zwei oder drei konkreten Maßnahmen, für die jeweils eine verantwortliche Person benannt wird.

Die drei Scrum-Artefakte

• Der Produkt-Backlog Es handelt sich um die dynamische, priorisierte Liste aller Funktionen, die das Produkt bieten oder entwickeln soll. Sie wird vom Product Owner gepflegt und kontinuierlich auf Basis von Kundenfeedback und Teamentscheidungen weiterentwickelt.
• Der Sprint-Backlog ist die Teilmenge des Produkt-Backlogs, deren Auslieferung sich das Team für den aktuellen Sprint vorgenommen hat. Sie gehört dem Entwicklungsteam.
• Die Erhöhung Das konkrete und potenziell umsetzbare Ergebnis, das am Ende jedes Sprints erzielt wird, muss der Definition of Done entsprechen – einer Reihe von Kriterien, auf die sich das Team geeinigt hat, um eine Aufgabe als wirklich abgeschlossen zu betrachten.

Kanban im Detail: Board, WIP-Limit und Pull-Flow

Kanban ist eine visuelle Methode, die ursprünglich aus der japanischen Fertigungsindustrie stammt und von Serviceteams zur Steuerung eines kontinuierlichen Arbeitsablaufs eingesetzt wird. Im Gegensatz zu Scrum schreibt Kanban keine spezifischen Rollen, Sprints oder obligatorischen Meetings vor. Es basiert auf drei grundlegenden Praktiken: Phasen, Formate und Moderation. Vollständiger Leitfaden zur agilen Retrospektive entfaltet die Sitzung Schritt für Schritt.

Das Kanban-Board

Le Kanban-Board Es visualisiert den Fortschritt jeder Aufgabe in Spalten. Die Minimalkonfiguration umfasst drei Spalten: „Zu erledigen“, „In Bearbeitung“ und „Erledigt“. Fortgeschrittenere Teams fügen Zwischenspalten hinzu, die ihren tatsächlichen Workflow widerspiegeln: „Validierung ausstehend“, „Test“ und „Bereitstellung“. Jede Aufgabe wird durch eine Karte dargestellt, die von Spalte zu Spalte wandert, bis sie abgeschlossen ist.

Limit für unfertige Arbeiten (WIP)

Die wichtigste Regel von Kanban ist die Begrenzung der laufenden Arbeiten (Work In Progress, WIP). Jede Spalte des Boards hat eine maximale Anzahl an Aufgaben, die gleichzeitig bearbeitet werden dürfen. Sobald eine Spalte voll ist, kann das Team keine neue Aufgabe hinzufügen, sondern muss die bereits laufenden Aufgaben abschließen. Diese zunächst kontraintuitive Beschränkung optimiert den Workflow und verkürzt die Durchlaufzeiten. Sie zwingt das Team, Aufgaben abzuschließen, bevor es neue beginnt, anstatt mehrere Projekte parallel zu bearbeiten.

Saugstrom

Kanban basiert auf einem Pull-Prinzip: Neue Aufgaben werden erst dann ins System aufgenommen, wenn Kapazität frei ist. Dies ist das Gegenteil eines Push-Systems, bei dem die Arbeit dem Team nach einem vordefinierten Zeitplan zugewiesen wird. Das Pull-Prinzip stellt sicher, dass das Team nie überlastet wird und jede Aufgabe die nötige Aufmerksamkeit erhält, um effektiv erledigt zu werden.

Die wichtigsten Kennzahlen im Kanban-System sind die Zykluszeit (die Zeit zwischen Beginn und Abschluss einer Aufgabe) und der Durchsatz (die Anzahl der pro Zeiteinheit abgeschlossenen Aufgaben). Diese Kennzahlen helfen, Engpässe zu identifizieren und den Arbeitsablauf kontinuierlich zu verbessern.

Scrum, Kanban oder Hybrid: Das Entscheidungsboard

Die Wahl zwischen Scrum und Kanban ist keine Frage von Trends oder persönlicher Vorliebe, sondern eine Frage des Kontexts. Hier sind die Kriterien, die diese Entscheidung leiten.

Der hybride Ansatz, oft auch Scrumban genannt, behält die Strukturierungsrituale von Scrum (Sprintplanung, Retrospektive) bei und übernimmt gleichzeitig die Work-in-Progress-Grenzen (WIP) und das visuelle Board von Kanban. Er eignet sich besonders gut für Teams, die sowohl ein Produkt über einen längeren Zeitraum entwickeln als auch täglich unerwartete Anfragen bewältigen müssen.

Schätzung in agilen Projekten: Komplexitätspunkte und Geschwindigkeit

Die Aufwandsschätzung ist eines der Themen, das am häufigsten zu Missverständnissen zwischen agilen Teams und ihren Kunden führt. In agilen Projekten schätzen wir nicht in Stunden, sondern in Komplexitätspunkten, auch Story Points genannt.

Was ist ein Punkt der Komplexität?

Ein Story Point ist eine relative Maßeinheit. Er repräsentiert keine Dauer, sondern den Gesamtaufwand einer Aufgabe unter Berücksichtigung ihrer technischen Komplexität, des Unsicherheitsgrades und des damit verbundenen Arbeitsumfangs. Eine mit 8 Punkten bewertete Aufgabe gilt als etwa doppelt so komplex wie eine mit 4 Punkten bewertete Aufgabe, ohne dass dies einer genauen Stundenzahl entspricht.

Teams verwenden üblicherweise die Fibonacci-Skala (1, 2, 3, 5, 8, 13, 21) zur Punktevergabe. Die großen Abstände zwischen den Werten sind beabsichtigt: Sie spiegeln die Tatsache wider, dass die Dauer einer Aufgabe umso ungenauer eingeschätzt werden kann, je wichtiger sie ist. Die Planning-Poker-Technik ermöglicht es dem gesamten Team, gleichzeitig über die Aufwandsschätzung einer Aufgabe abzustimmen und dabei Unstimmigkeiten aufzuzeigen und zu diskutieren.

Geschwindigkeit: ein Planungsinstrument, kein Leistungsinstrument

Die Velocity ist die Summe der Komplexitätspunkte, die das Team am Ende eines Sprints erreicht hat. Durch die Berechnung des Durchschnittswerts über mehrere Sprints erhält das Team einen zuverlässigen Indikator für die Planung: Beträgt die durchschnittliche Velocity beispielsweise 30 Punkte und der verbleibende Backlog 150 Punkte, so lässt sich abschätzen, dass das Projekt etwa fünf Sprints in Anspruch nehmen wird.

Zwei wichtige Einschränkungen sind zu beachten. Erstens ist die Velocity teamspezifisch: Ein Vergleich der Velocity zweier Teams ist sinnlos, da ihre Schätzskalen unterschiedlich sind. Zweitens ist die Velocity ein Planungsindikator, kein Leistungsziel. Der Druck auf ein Team, seine Velocity zu erhöhen, führt in der Regel zu überhöhten Schätzungen, nicht zu einer schnelleren Lieferung.

Budget und Vertrag: Festpreis oder Zeit- und Materialaufwand für ein agiles Projekt?

Diese Frage ist der häufigste Grund für Verzögerungen bei kommerziellen Verhandlungen über agile Projekte. Der Kunde wünscht sich einen Festpreis. Das Team weiß, dass sich der Projektumfang weiterentwickeln wird. Wie lassen sich diese beiden Wünsche vereinbaren?

Warum das traditionelle Festpreismodell für agile Methoden ungeeignet ist

Ein Festpreisvertrag basiert auf einem präzise definierten und festen Leistungsumfang. In agilen Methoden ist der Leistungsumfang per Definition flexibel; das ist sogar eine ihrer Stärken. Die Verwendung eines Festpreises in einem agilen Projekt führt zu einem strukturellen Widerspruch: Das Team arbeitet in Sprints und passt die Prioritäten an, der Vertrag verlangt jedoch die Einhaltung der vor dem ersten Sprint festgelegten Spezifikationen. Die Folge: ständige Änderungen, Spannungen darüber, was „enthalten“ ist und was nicht, und mitunter Streitigkeiten.

Agiles Management und seine Alternativen

Das Zeit- und Materialmodell (oder Projektmanagementmodell) ist am ehesten mit Agilität vereinbar. Der Kunde zahlt die tatsächlich verbrachte Zeitzum vereinbarten Preis. Er behält die Kontrolle über die Prioritäten und kann das Projekt jederzeit neu ausrichten. Im Gegenzug trägt er das Budgetrisiko und muss aktiv an der Priorisierung des Auftragsbestands beteiligt sein.

Für Kunden, die Budgettransparenz benötigen, gibt es verschiedene Zwischenmodelle.

• Der Pauschalpreis pro Sprint Für jede Iteration wird ein Festpreis bei variablem Umfang festgelegt. Der Kunde weiß genau, was jeder Sprint kostet, kann aber die Prioritäten von Sprint zu Sprint anpassen.
• Der Budgetumschlag Es wird ein Gesamtlimit festgelegt, und der Kunde entscheidet fortlaufend, welche Funktionen auf Basis des verbleibenden Budgets entwickelt werden sollen.
• Das eingeschränkte agile Paket Es ist ein Höchstpreis festgelegt, der Umfang kann jedoch nach unten angepasst werden, falls sich bestimmte Funktionen als zu komplex erweisen. Ist eine Funktion zu teuer, wird sie durch zwei einfachere Funktionen von gleichem Wert ersetzt.

Wie man einem Kunden, der einen Festpreis wünscht, ein agiles Projekt verkauft

Der Schlüssel liegt darin, das Gespräch vom Gesamtpreis auf den Preis pro Sprint zu verlagern. Anstatt ein komplettes Ergebnis zum Festpreis zu versprechen, bieten Sie dem Kunden die Finanzierung für eine erste Sprint-Serie (beispielsweise zwei oder drei) an, um ein erstes funktionales Inkrement zu erstellen. Am Ende dieser ersten Serie verfügt der Kunde über ein konkretes Ergebnis, eine messbare Velocity und eine deutlich zuverlässigere Einschätzung des restlichen Projekts. Dieser Ansatz reduziert das Risiko für beide Seiten und schafft schrittweise Vertrauen.

Agilität an ein kleines Team von drei oder vier Personen anpassen

Scrum wurde für Teams von fünf bis neun Personen entwickelt. Das heißt nicht, dass es für kleinere Teams ungeeignet ist, aber einige Anpassungen sind notwendig.

In einem Team von drei oder vier Personen können die Scrum-Rollen nicht immer von verschiedenen Personen übernommen werden. Häufig übernimmt ein Entwickler auch die Rolle des Scrum Masters oder der Product Owner ist gleichzeitig Mitglied des Entwicklungsteams. Das ist zwar nicht optimal, da es potenzielle Interessenkonflikte birgt, aber in kleinen Organisationen oft unvermeidbar. Wichtig ist, dass alle die Scrum-Rollen verstehen. Verantwortlichkeiten ist mit jeder Rolle verbunden und übernimmt sie bewusst.

Rituale lassen sich optimieren, ohne sie abzuschaffen. Ein zehnminütiges Daily Stand-up reicht in einem kleinen Team, in dem die Kommunikation unkompliziert ist. Eine einstündige Sprint-Planung kann einen halben Tag ersetzen, wenn das Backlog gut vorbereitet ist. Die Retrospektive sollte jedoch niemals vernachlässigt werden: Sie ist die einzige Zeit, die der Verbesserung der Teamdynamik gewidmet ist, und hier wird agile Reife entwickelt.

Kanban eignet sich oft besser für sehr kleine Teams, die gleichzeitig verschiedene Projekte und Kundenanfragen bearbeiten. Ein dreispaltiges Board, die Begrenzung auf zwei oder drei laufende Aufgaben pro Person und ein wöchentliches Meeting genügen, um den Workflow transparent und kontrolliert zu gestalten.

Die häufigsten Fehler im agilen Projektmanagement

Schlecht umgesetzte agile Methoden können schlimmer sein als ein gut durchgeführter traditioneller Ansatz. Hier sind die häufigsten Fehler, die bei Teams beobachtet werden, die gerade erst anfangen oder den Bezug zu ihren bewährten Vorgehensweisen verloren haben.

Rituale, ihrer Bedeutung entleert

Das tägliche Stand-up-Meeting verkommt zu einer Gesprächsrunde, in der jeder aufzählt, was er gestern getan hat und was er morgen vorhat, ohne dass Hindernisse angesprochen werden. Die Retrospektive produziert Haftnotizen, die zu keinem konkreten Handeln führen. Die Sprint-Review fällt aus Zeitmangel aus. Diese Rituale haben zwar eine bestimmte Funktion: Sie mechanisch auszuführen, ohne ihren Sinn zu verstehen, ist wie Form ohne Substanz zu wahren. Ein sinnvolles tägliches Stand-up-Meeting beantwortet eine einzige Frage: Was könnte das Team daran hindern, sein Sprintziel heute zu erreichen?

Ein nie priorisierter Auftragsbestand

Ein Backlog, der nicht regelmäßig überprüft und priorisiert wird, verkommt schnell zu einer unstrukturierten Wunschliste. Das Team weiß nicht mehr, was es zuerst angehen soll, dem Product Owner fehlt eine klare Vorstellung davon, was den größten Mehrwert bietet, und Sprints werden planlos statt anhand tatsächlicher Prioritäten geplant. Der Backlog sollte ein lebendiges Dokument sein, das mindestens einmal pro Sprint in einer Refinement-Session überprüft wird.

Das Fehlen einer Definition von endlich

Ohne eine gemeinsame und schriftliche Definition von „Fertig“ hat jedes Teammitglied seine eigene Interpretation von „Fertig“. Ein Feature könnte vom Entwickler als geliefert betrachtet werden, selbst wenn es nicht getestet, dokumentiert oder vom Product Owner validiert wurde. Die Definition von „Fertig“ ist eine gemeinsame Vereinbarung, die in jedem Sprint angezeigt und überprüft wird und sicherstellt, dass die gelieferten Ergebnisse tatsächlich nutzbar sind.

Verwechslung von Agilität mit mangelnder Strenge

Agilität erfordert mehr Disziplin als ein traditioneller Ansatz, aber nicht weniger. Rituale müssen eingehalten, das Backlog gepflegt und Sprint-Verpflichtungen erfüllt werden. Ein Team, das Retrospektiven auslässt, „um Zeit zu sparen“, oder den Inhalt eines laufenden Sprints ohne klaren Prozess ändert, praktiziert keine Agilität, sondern improvisiert.

Eine Tabellenkalkulation reicht nicht aus, um ein Kundenprojekt zu verwalten

Ein gut gepflegtes Kanban-Board und regelmäßige Sprints ermöglichen eine organisierte Projektabwicklung. In einem Dienstleistungsunternehmen reicht eine gute Projektabwicklung jedoch nicht aus: Profitabilität ist ebenso wichtig. Das agile Board gibt jedoch weder Aufschluss über den tatsächlichen Zeitaufwand für die einzelnen Aufgaben noch über die dem Kunden in Rechnung gestellten Kosten. Ein Team kann alle Sprints termingerecht abschließen und dennoch Verluste machen, einfach weil der Zeitaufwand die vereinbarte Zeit überschreitet.

Das ist der blinde Fleck vieler kleiner Agenturen und Kleinstunternehmen, die agile Methoden anwenden: Sie verbessern ihre interne Organisation, ohne ihr Projektmanagement mit ihrer finanziellen Realität zu verknüpfen. Das Projekt schreitet voran, der Kunde ist zufrieden, doch die Gewinnspanne schrumpft Sprint für Sprint, ohne dass es jemand bis zur Schlussrechnung bemerkt.

Djaboo verknüpft Projektaufgaben, Team-Zeiterfassung und Kundenabrechnung in einem zentralen Arbeitsbereich. So lässt sich der Projektfortschritt in Echtzeit mit dem Budget vergleichen: Wie viele Stunden wurden aufgewendet, wie viel wurde abgerechnet und wie hoch ist das verbleibende Budget für den Projektabschluss? Diese kontinuierliche finanzielle Transparenz ermöglicht es, rechtzeitig Entscheidungen zu treffen – sei es die Neuverhandlung des Projektumfangs, die Benachrichtigung des Kunden oder die Neuordnung der Prioritäten für den nächsten Sprint.

Häufig gestellte Fragen

Worin besteht der Unterschied zwischen Scrum und Agile?

Agilität ist eine Projektmanagementphilosophie, die auf vier Werten und zwölf Prinzipien des Agilen Manifests von 2001 basiert. Scrum ist ein konkretes Framework, das diese Prinzipien in die Praxis umsetzt – mit definierten Rollen, regelmäßigen Meetings und spezifischen Artefakten. Zu sagen, man arbeite agil, ohne das Framework zu nennen, ist, als würde man sagen, man treibe Sport, ohne die Sportart zu benennen. Scrum ist das am weitesten verbreitete agile Framework, aber es gibt auch andere: Kanban, SAFe, LeSS oder sogar hybride Ansätze wie Scrumban.

Wie lange dauert ein Sprint?

Ein Sprint dauert zwischen einer und vier Wochen. Am häufigsten sind zwei Wochen, da dies ein gutes Gleichgewicht zwischen der Häufigkeit der Lieferungen und dem Zeitaufwand für die Entwicklung eines signifikanten Inkrements bietet. Einwöchige Sprints eignen sich für sehr erfahrene Teams oder Projekte mit hoher Unsicherheit. Vierwöchige Sprints sind für Projekte mit komplexen Funktionen, die mehr Entwicklungszeit erfordern, geeignet. Die Sprintdauer sollte nach der Festlegung während des gesamten Projekts beibehalten werden.

Kann der Inhalt eines Sprints während dessen Durchführung geändert werden?

In Scrum ist der Sprintinhalt nach Abschluss der Sprintplanung geschützt. Das Sprintziel darf sich während des Sprints nicht ändern, selbst wenn neue dringende Anforderungen auftreten. Diese neuen Anforderungen werden dem Product Backlog hinzugefügt und im folgenden Sprint bearbeitet. Sollte ein Notfall den Fortschritt tatsächlich blockieren, kann der Product Owner den Sprint abbrechen; dies ist jedoch eine Ausnahme. Dieser Sprintschutz ermöglicht es dem Team, sich auf ein Ziel zu spezialisieren und dieses einzuhalten. In Kanban hingegen können Prioritäten jederzeit neu geordnet werden, solange laufende Aufgaben nicht unterbrochen werden.

Wie überzeugt man einen Kunden von agilem Arbeiten?

Der Widerstand von Kunden gegen agile Methoden rührt fast immer von der Angst her, die Kontrolle über Budget und Projektumfang zu verlieren. Um diese Angst zu überwinden, ist es entscheidend zu zeigen, dass agiles Vorgehen dem Kunden mehr, nicht weniger Kontrolle gibt. Im agilen Projektmanagement erhält der Kunde am Ende jedes Sprints konkrete Ergebnisse, kann Prioritäten flexibel anpassen und zahlt nur für die tatsächlich erbrachten Leistungen. Der Schlüssel liegt darin, zunächst Sprints mit begrenztem Umfang anzubieten, die in einem konkreten Ergebnis münden. So kann der Kunde die Methodik kennenlernen, bevor er sich für ein komplettes Projekt entscheidet.

Welche Größe ist ideal für ein Scrum-Team?

Der Scrum Guide empfiehlt Teams von drei bis neun Personen. Bei weniger als drei Personen kann es zu einem Mangel an vielfältigen Kompetenzen und Engpässen kommen. Ab neun Personen wird die Koordination komplexer und die Rituale umständlicher. In kleinen Organisationen kann ein Team von drei oder vier Personen Scrum durchaus praktizieren, indem die Dauer der Rituale angepasst und bestimmte Rollen an dieselben Personen verteilt werden. Entscheidend ist, dass die Verantwortlichkeiten jeder Rolle klar definiert sind.

Benötigen Sie ein digitales Werkzeug, um Agilität zu trainieren?

Nein, nicht unbedingt am Anfang. Ein Whiteboard, Haftnotizen und ein Stift reichen völlig aus, um in einem kleinen Team mit Kanban oder Scrum zu starten. Der Vorteil eines physischen Boards liegt in seiner sofortigen Sichtbarkeit und Zugänglichkeit ohne Schulung. Digitale Tools werden erst dann nützlich, wenn das Team geografisch verteilt ist, das Arbeitsaufkommen steigt oder die Aufgabenverfolgung mit anderen Managementaspekten wie Zeiterfassung, Rechnungsstellung oder Kundenberichten verknüpft werden muss. In diesem Fall vermeidet ein Tool, das diese Informationen zentralisiert, die Verwaltung mehrerer voneinander unabhängiger Dashboards.

Auch zu lesen

• Abwesenheitsmanagement: Antragsverfahren, Validierung und Transparenz
• Teamplanung: Methodik, Werkzeuge und Abwägungen
• Support-Ticket: Lebenszyklus, Priorisierung und Indikatoren