Werkzeuge – Agile Methoden

Agile Methoden des Projektmanagements – allen voran Scrum – sind zum De Facto-Standard in der modernen Software-Entwicklung geworden.
Bei Projekten in komplexen Umfeldern, bei denen die klassischen Projektplanungs-Methoden schlichtweg versagen, haben sich agile Methoden als erstaunlich zuverlässig und effektiv erwiesen.
Quasi als Nebeneffekt sind Scrum Teams häufig motiviert, kreativ und resilient gegenüber Auswirkungen organisatorischer Veränderungen im Unternehmen.

Hier finden Sie mehr Informationen, was ich im Rahmen der Einführung und Verbesserung agiler Methoden in ihrem Unternehmen für Sie tun kann.

Die klassischen Projektmanagement-Verfahren sind einfach erklärt: Zu Projektbeginn erfolgt eine detaillierte Planung des Projektablaufs, anhand der das Projekt vom Projektmanager gesteuert wird. Für Unvorhergesehenes werden Puffer eingeplant.
Das funktioniert sehr gut, wenn die Thematik gut verstanden, die Anforderungen fixiert und das Team erfahren ist.
Weniger gut klappt das bei Projekten in einem innovativen Kontext, der von den Teams erschlossen werden muss, bei Projekten, bei denen sich die Anforderungen während des Projektverlaufs stark ändern („Moving Target“) und bei Projekten mit jungen, unerfahrenen Teams.

Hier gibt es in Wirklichkeit nur eine Alternative: Grob die Richtung festlegen, engen Kontakt zu den Kunden herstellen, losmarschieren und kontinuierlich nachjustieren.
Um nichts anderes geht es bei den agilen Methoden.
Was auf den ersten Blick als ungeplant, überoptimistisch, gar choatisch erscheinen mag, ist der Ansatz, der sich in dynamischen Umfeldern als der nachhaltig erfolgreichste herausgestellt hat.
Mehr noch: Die Klarheit, Einfachheit und kontinuierliche Verbesserung des Prozesses (am Beispiel Scrum) garantiert eine Verläßlichkeit und Sicherheit, die von den stark Planungs-orientierten Methoden nicht erreicht werden kann.

Das Team

Die Gruppe der Produktentwickler, der Produktverantwortliche (Product Owner), und der Prozessverantwortliche (Scrum Master) bilden ein Team.
Der Product Owner bildet für das Team die Schnittstelle zu den Anforderungen des Kunden.
Die Aufgabe des Scrum Masters ist es, dafür zu sorgen dass alle Beteiligten die Regeln des Prozesses einhalten und eine Umgebung herzustellen, in der das Team ungestört und ohne Hemmnisse arbeiten kann.
Begleitet wird der Prozess vor allem in der Anfangsphase eines Teams von einem Scrum Coach, der in erster Linie dem Scrum Master und dem Product Owner zur Seite steht.

Direkte Kommunikation und persönlicher Kontakt der Teammitglieder sind wichtig, ebenso das Verständnis für die Bedürfnisse des Kunden bei allen Mitgliedern des Teams.

Schritt für Schritt

Die Features des Produkts werden durch den Product Owner kontinuierlich in einer strukturierten, verständlichen Form (User Stories) im Product Backlog abgelegt und entsprechend ihrer Bedeutung für den Kunden priorisiert.

Die Entwicklung erfolgt iterativ in gleich langen Intervallen (genannt Sprint, typischerweise 1-4 Wochen).
Jede Iteration beginnt mit der Sprintplanung. Der Aufwand für neue Backlog-Einträge wird vom Team grob geschätzt. Die Backlog-Einträge, die in diesem Sprint implementiert werden sollen, werden entsprechend der Priorisierung vom Team ausgewählt und bilden das Sprint Backlog.
Während des Sprints arbeitet das Team ungestört, konzentriert sich voll auf die Fertigstellung der ausgewählten Features. Das Sprint Backlog wird während des Sprints nicht verändert. Sofern Ad-Hoc-Themen (Fehlerbehebungen, Feuerwehr-Aktionen) in der Zuständigkeit des Teams liegen, wird dafür ein festgelegter Anteil der Arbeitskraft des Teams reserviert.
In einem kurzen täglichen Statusmeeting (Daily Scrum) informiert sich das Team gegenseitig über den Projektfortschritt und identifiziert Hemnisse.

Kontinuierliche Qualität

Das Team legt in einer Vereinbarung fest, wann ein Feature als wirklich fertig angesehen werden kann (Definition Of Done, kurz DoD). Mit der DoD werden klare Abnahme- und Qualitätskriterien definiert.
Fertiggestellte Features werden am Ende des Sprints präsentiert. Features, die nicht vollständig der DoD entsprechen, gelten als nicht abgenommen und landen wieder im Backlog.
Das Ergebnis jedes Sprints ist ein grundsätzlich auslieferfähiges Produkt mit den in der Sprintplanung festgelegten Features in der per DoD festgelegten Qualität.

Ergänzend führt das Team eine Retrospektive durch, in der festgestellt wird, was gut und was weniger gut lief und wie der Prozess verbessert werden kann. Der Scrum Master, der dafür Sorge trägt, dass das Team unbeeinträchtigt arbeiten kann, stellt sicher, dass entsprechende Maßnahmen in die Wege geleitet werden.

Mehr als nur eine Methode

Wichtig: Es wird keine Kontrollfunktion durch den Scrum Master ausgeübt. Das Team arbeitet selbstorganisierend. Der Scrum Master sorgt lediglich dafür, dass vom Team die Regeln des Prozesses eingehalten werden und dass das Team optimale Bedingungen für seine Arbeit vorfindet.
Das ist häufig der Knackpunkt:
Die Einführung von Scrum heißt für das Management vor allem, Kontrolle abzugeben – und statt dessen der Selbstorganisationfähigkeit der Teams, der Qualität des Prozesses und der Erfahrung der Scrum Coaches zu vertrauen.

Ein agiles Verfahren wie Scrum zu etablieren, heißt mehr als nur eine neue Methode des Projektmanagements einzuführen. In Wirklichkeit handelt es um einen Paradigmenwechsel.
Und das bringt immer auch Widerstände mit sich. Mitunter kann es da schon holprig werden. Ein guter Scrum Coach, der die Stolpersteine kennt und weiß, wie er die Beteiligten auf die agile Reise mitnimmt, erspart Zeit, Frust und Geld.
Und es gibt wirklich viel zu holen:

• Die Mitglieder des Teams übernehmen mit jedem Commitment zu Beginn des Sprints die volle Verantwortung für ihre Zusagen. Ausführende werden zu aktiven Partnern.
• In der Sprint Planung interagieren die Entwickler so lange mit dem Product Owner, bis sie den Inhalt des Sprint Backlogs gut genug verstanden haben, um ihn im Sinne des Kunden umzusetzen. „Über den Zaun geworfene“ Spezifikationen gibt es in dieser Form nicht mehr.
• Micro-Controlling kostet viel Aufwand. Das Management gewinnt wieder Zeit zur Rückkehr aus der reaktiven Überlastung in die aktive Gestaltung.
• „Ist die Katz aus dem Haus, tanzen die Mäuse“ gilt nicht für Teams, die eigenständig Verantwortung übernommen haben. Niemand verkündet im Daily Scrum gerne, dass er/sie seit dem letzten Daily nichts erreicht hat.