Agile Ideen in der Praxis

Einstieg in Scrum und Kanban – Teil 2

Agile Ideen in der Praxis

Wenn sich Kunde und Auftraggeber einig sind und auf einen agilen Prozess einlassen, stellen sich automatisch einige Fragen: Wie funktioniert das System nun im realen Projekt? Wie lässt sich diese Umsetzung kalkulieren? Und wie wird das im Vertrag festgehalten?

Im ersten Teil ging es um die grundlegenden Ziele und Methoden agiler Entwicklung. Dazu kommen nun verschiedene Positionen im Team, Werkzeuge sowie feste Elemente in agilen Prozessen:

Product Owner, Scrum Master und das Team

Im Scrum Prozess obliegt es dem sogenannten »Product Owner«, die Kundenbedürfnisse zu repräsentieren und die Einträge im Backlog nach diesen zu priorisieren. Der »Scrum Master« trägt die Verantwortung für die Einhaltung der Scrum-Regeln, Moderation von Meetings und Lösung von Problemen, die Fortschritte des Teams behindern (»Blocker«). Eine detaillierte Beschreibung der Rollen und ihrer Aufgaben sprengt den Rahmen dieses Artikels. Bei Verwendung der Methoden zur persönlichen Organisation oder zur Strukturierung der Aufgaben in kleinen Teams ist es ohnehin eher fraglich, inwiefern die »reine Lehre« von Scrum angewendet werden kann oder sollte.

Empfehlenswerte Werkzeuge

Meiner persönlichen Erfahrung nach ist es nicht sinnvoll, spezielle Softwarelösungen für agile Prozesse einzusetzen. Sie beschränken in der Regel die Möglichkeit, den Prozess an die eigenen Bedürfnisse anzupassen. Eine Mischung der folgenden Werkzeugen halte ich für sinnvoller:

Ein Board, um Karteikarten mit Epics / User Stories zu befestigen. Für eine Übersicht über das Product Backlog und wichtige Meilesteine / Termine, eher vergleichbar mit einer Roadmap.
Das vollständige Product Backlog in digitaler Form, zum Beispiel als Tabelle (etwa Excel, Open Office, google docs) oder in einem einfachen Ticketsystem (zum Beispiel redmine).
Das Sprint Backlog: entweder als eigenständiges Text-Dokument oder als Zuweisung einer Zielversion in Redmine. Es ist darüber hinaus sehr sinnvoll, in Form von Karteikarten auf einem weiteren Board für alle Beteiligten eine Visualisierung vorzunehmen, in Sprint Backlog – in Bearbeitung – Fertig.
Ein Kanban Board für jedes Mitglied im Team, das mindestens einmal am Tag aktualisiert wird.

Daily Standup Meeting

Ein fester Bestandteil im Scrum-Prozess ist das sogenannte »Daily Standup Meeting«. Zu einer festgelegten Zeit (möglichst zu Anfang des Arbeitstages) trifft sich das Projektteam. Jedes Teammitglied gibt dabei einen kurzen Statusbericht ab:

Was habe ich gestern getan?
Was werde ich heute tun?
Benötige ich Unterstützung? Was blockiert mein Fortkommen?

Ziel ist es, den Wissensstand aller Beteiligten abzugleichen, Probleme frühzeitig zu identifizieren und transparent zu kommunizieren, wer gerade an welcher Aufgabe arbeitet. Die wichtigsten Aspekte des Daily Standup:

Findet wirklich im Stehen statt, um möglichst dynamisch und kurz zu bleiben.
Ist sehr kurz (weniger als eine Minute pro Person).
Dient nicht als Diskussionsforum.
Benötigt Moderation (zumeist durch den Scrum-Master).
Als Vorbereitung auf den Daily Standup sollte sich jedes Teammitglied Gedanken über die an diesem Tag anstehenden Aufgaben gemacht haben. Als einfache und sehr effektiv Methode hat sich dabei bewährt, die Aufgaben schriftlich nach Priorität auf einem Blatt Papier festzuhalten. Selbstverständlich bildet ein gepflegtes Kanban Board genau diese Funktion ab. Es ist jedoch nicht immer praktikabel, alle Boards zum Standup Meeting mitzubringen.

Retrospektiven und Kaizen

Ein weiteres zentrales Element agiler Prozesse sind regelmäßige Überprüfungen des Prozesses selbst. Im Scrum Prozess ist hierfür in jedem Sprint ein »Retrospective Meeting« vorgesehen, um den Prozess zu reflektieren. Jedes Teammitglied bereitet dafür vorab Antworten auf die folgenden drei Fragen vor:

Was ist gut gelaufen / wovon sollten wir »mehr« tun?
Was ist schlecht gelaufen / was sollten wir »weniger« tun?
Wie können wir konkret eine Verbesserung einführen?

Generell finden sich zum Thema kontinuierliche Verbesserungsprozesse oder Kaizen zahlreiche erprobte Ansätze, die sich auf die Arbeit des Teams und die Arbeitsumgebung anwenden lassen. Wichtig ist, für diese Art der Prozessverbesserung genügend Zeit einzuplanen und die Umsetzung von Verbesserungen auch konsequent zu verfolgen. Ansonsten droht die Gefahr, dass Retrospektiven zu reinen Pflichtveranstaltungen ohne Wert für die Beteiligten verkommen und früher oder später als Zeitverschwendung betrachtet werden.

Exkurs: Projektarbeit – der Vertrag

Agile Verträge bergen zahlreiche Fallstricke. Dieser Artikel soll, kann und darf keine Rechtsberatung darstellen.

In der Praxis kann oftmals eine klassische Vorgehensweise als »einfacher« verkauft werden. Diese Erfahrung schlägt sich dann auch im Angebot nieder – ein möglicher Rahmen ist also ein (Wasserfall-)Werkvertrag, der dann explizit definiert, dass dieses Projekt in Stufen umgesetzt wird und agile Elemente aufgreift. Mögliche Stufen:

Planung
- Gemeinsame Definition der Projektziele
- »content first« Ansatz
- Entwicklung einer visuellen Formensprache (»Design«)
Umsetzungsphase (Scrum Prozess)
- Umsetzung einer ersten Version
- Hinzufügen von Funktionen in kurzen Zyklen
- Verifizierung der Umsetzung
Einführung
- Schulung
- Finalisierung von Inhalten
- Auslieferung

Agile Kalkulation

Erwartungsgemäß »fixe« Kosten wie Konzeption, Design, Installation von Softwarekomponenten, Schulung und Auslieferung können aufgrund einer Anforderungsanalyse und Erfahrungenswerten aus der Vergangenheit gut kalkuliert werden. Für den agilen Teil könnte jetzt ein »fixes« Zeitkontingent angeboten werden. Wobei dies wirklich als Budget betrachtet werden sollte, da in enger Abstimmung mit dem Kunden dann während der Umsetzung der Umfang und die Verwendung angepasst werden. Ziel ist es, das Projekt gemeinsam mit dem Kunden vertrauensvoll und transparent zu realisieren. Dies ist möglich, wenn der Kunde jederzeit klar erkennen kann, wofür sein Geld verwendet wird, welchen Gegenwert er erhält, und an welchem Punkt der Entwicklung sich das Projekt befindet.

Wieso sollte sich ein Auftraggeber auf eine agile Vorgehensweise einlassen?

Priorisierung der Projektziele durch den Kunden anhand des Wertes (sowohl aus Unternehmens- als auch Nutzersicht).
»Nutzbare« Version der Software ab der ersten Iteration. Hierdurch sinkt das Risiko von kostspieligen Fehlentwicklungen.
Eine Neupriorisierung ist als Teil des Prozesses jederzeit möglich.

Weitere Ideen in der Zusammenfassung

Ziel agiler Vorgehensmodelle ist es, wertige Ergebnisse zu produzieren. Hierfür kommen unter anderem auch folgenden Ideen zum tragen:

Das Pull-Prinzip: Ein Mitarbeiter arbeitet nur an Aufgaben, für die er und die nachfolgenden Prozessschritte genügend Ressourcen haben.
Pareto-Prinzip (80/20): 80% der Ergebnisse benötigen 20% der Zeit – und die restlichen 20% der Ergebnisse 80% der Zeit. In Zusammenhang mit einer Betrachtung des Wertes einer Funktionalität kann die konsequente Anwendung dieser Idee bereits während der Projektplanung dazu führen, dass Überschreitungen des Zeit- und Budgetrahmens erkannt und dann vermieden werden können.
Qualität ist Bestandteil des Prozesses – zum Beispiel in Form von Test Driven Design (TDD).
Minimierung von Risiken durch kleine Schritte: Funktionalitäten sollten möglichst innerhalb eines Sprints realisiert werden, Arbeitspakete innerhalb eines Tages.
Überflüssige und nutzlose Features durch das KISS-Prinzip (Keep it simple stupid!) vermeiden: »so einfach wie möglich halten«.
Nur umsetzen, was jetzt wirklich benötigt wird: Yagni Prinzip oder auch Just-In-Time-Implementierung.
Features, die lange im Backlog liegen, sind in der Regel überflüssig (Stichwort: Backlog Grooming).
Das Konzept »Technische Schulden« beachten: Je länger die Lösung aufgeschoben wird, desto höher die Kosten der Lösung.

Als letzer Aspekt kann noch der Wissensaufbau und Transfer betrachtet werden. Beispiele hierfür sind:

Synchrones & asynchrones Pair-Programming.
Systematischer Erwerb von theoretisches Wissens zum Beispiel durch Weiterbildung, Besuch von Konferenzen, regelmäßige interne Vorträge.
Vermeidung von Insel-Know-How.

Grenzen agiler Methoden

Meine persönliche Meinung ist: Agile Vorgehensmodelle sind nicht automatisch besser. Unzählige Beispiele aus der in der Praxis zeigen, dass Produktivität und Zufriedenheit aller Beteiligten sinken kann, wenn der agile Prozess nicht konsequent befolgt und gelebt wird.

Es lohnt sich in jedem Fall, sich intensiver mit dem Thema auseinanderzusetzen und zumindest einzelne Elemente zu verwenden, selbst wenn eine Umsetzung kompletter Prozesse nicht ratsam erscheint, zum Beispiel weil auf Kundenseite noch keine Bereitschaft besteht, sich darauf einzulassen. Bereits die Verwendung einzelner Elemente wie Daily Standup Meetings, Planung mit User Stories, Planungsboards nach Kanban oder regelmäßige Retrospektiven können einen großen positiven Einfluss auf die persönliche Zufriedenheit für alle Beteiligten haben. Und nicht zuletzt den Projekterfolg.