Windows Developer | Agil richtig starten

Viele Projektteams wünschen sich die Einführung agiler Methoden, verspricht doch die agile Projektwelt gleichberechtigte und sinnhafte Projekte. Gleichzeitig treibt die Teams eine latente Unsicherheit: „Das wäre so schön. Aber bei uns funktioniert das nicht.“ Mit der Einführung agiler Methoden wird nicht von heute auf morgen alles einfacher oder besser. Der Umstieg lohnt sich dennoch. Mittelfristig steigt durch die Einführung agiler Methoden die Mitarbeiterzufriedenheit und Produktqualität. Damit der Umstieg gelingt, sollte dieser einfach gestaltet sein.

Die agile Bewegung geht davon aus, dass Software-Projekte in einer chaotisch-komplexen Welt stattfinden. Während sich eine komplexe Fragestellung in einen kompliziertem Plan abbilden und bewältigen lässt (was klassische Projektmethoden voraussetzen), ist eine chaotische Grundfrage nicht durch einen Plan beantwortbar. Die agile Antwort ist ein offenes und lernendes Vorgehen im Projekt.

Entsprechend unterschiedlich setzen agile und klassische Projektmethoden ihren Fokus in den Methodenbausteinen.

In klassischen Projekten ist die Abfolge von Projektschritten an schriftliche Artefakte gekoppelt. Dabei ist die Frage, „wie“ das Dokument erstellt wird, nicht die wichtige Frage. Es ist wichtig, dass schriftlich dokumentiert wird. Eine große Aufgabe wird in viele Teilaufgaben zerlegt, deren Übergabe von einem Teilschritt in den nächsten schriftlich dokumentiert wird.

Die agilen Projektmethoden setzen im Gegensatz dazu stark auf Kommunikation. „Business people and developers must work together daily throughout the project.“ und „The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.“ sind zwei der zwölf Prinzipien [2] hinter dem agilen Manifest, die diesen Kommunikationsanspruch formulieren.

Entstanden ist dieser Kommunikationsanspruch aus der Erfahrung heraus, dass in schriftlichen Dokumentationen wichtige Informationen nicht enthalten sind.

Die Projektparteien lernen Zielsetzung und Ansprüche der jeweiligen Disziplinen direkt kennen – und können diese auch bewusst bedienen. So wird dem Auftraggeber vielleicht zum ersten Mal bewusst, wie viel Geschäftslogik er eigentlich noch nie in schriftlichen Dokumenten hinterlegt hat, die implizit aber von Entwicklern erfasst und umgesetzt werden müssen. Der Entwickler hat umgekehrt das A-Ha-Erlebnis, warum eine bestimmte visuelle Darstellung für die Erreichung der Geschäftsziele besonders wichtig ist. Der gemeinsame, direkte Austausch ermöglicht Fragen und Antworten, deren Detailtiefe in reinen Schritstücken nur schwer zu vermitteln und zu erfassen ist.

Das Schlüsselmoment agiler Projekte zeigt sich darin,

1. offen für Änderungen zu sein: „Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.“ [2],

2. die eigene Projektmethodik ständig zu hinterfragen und zu optimieren: „At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.“ [2] und

3. auf fachliche Ziele zu fokussieren: „Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.“ [2]

Dieses Schlüsselmoment verändert die bisherige Projektwelt gravierend:

1. Der Auftraggeber wird täglich in die Projektarbeit involviert.

2. Die Entwicklungsteam verlangt eine Diskussion um den Projektgegenstand auf Augenhöhe.

3. Alle Projekt-Beteiligten kennen die fachlichen Ziele des Projekts und können ihren Anteil an der Zielerreichung benennen.

Zur Erreichung dieser Punkte ist zu kommunizieren. Dieser Kommunikationswunsch kann eine Herausforderung sein, die nicht für jeden der Projekt-Beteiligten zu schaffen ist:

1. Das klassische schriftliche Formulieren von Anforderungen macht es zum Einen möglich, Sachfragen zu „verstecken“. Zum Anderen hat nicht jeder Auftraggeber die Zeit, ein Projekt in dieser Form zu begleiten.

2. Die tägliche Auseinandersetzung mit dem erreichten Stand ist für viele Beteiligte schwer aushaltbar.

3. Das Verstehen von fachlichen Zielen und der Abgleich der eigenen Arbeit mit diesen ist nicht einfach. Fordert dies doch – entsprechend begründet – den Verzicht der perfekten Lösung zu Gunsten einer Lösung, die inhaltlich und wirtschaftlich angemessen ist.

Dies sind Themen, die in agilen Projekten früh im Projektverlauf aufgedeckt werden. Dann ist es Zeit, eine adäquate und individualisierte Projektmethodik zu erfinden, die für beide Seiten passt.

Aber auch im Team verändert sich das Kommunikationsverhalten: an Stelle von Auseinandersetzungen im Ticketsystem („Ticketkrieg“) zwischen Auftraggebern und Entwicklern ist der direkte Austausch zwischen allen Beteiligten gefragt.

Dabei bedienen sich die meisten agilen Methoden eines Hilfsmittels: der Visualisierung des Projektverlaufs in einer Wandzeitung. Die Wandzeitung gibt Aufschluss über die Dinge, die zu tun sein werden, die getan werden und die abgeschlossen sind. Je nach Projektmethodik zeigt die Wandzeitung das komplette Projekt oder ein Teilprojekt.

Durch die Visualisierung und den täglichen Austausch über den Projektstand lassen sichProjektverzögerungen nicht verbergen. Ein weiteres Maß für den Projektfortschritt ist die agile Forderung: „Working software is the primary measure of progress.“ [2] Gefragt ist also immer das Team, welches den Rahmen und die Inhalte für eine jeweils lauffähige Software schafft.Viele Projektteams in klassischen Projekten leiden darunter, dass Projekte verspätet oder im Leistungsumfang stark reduziert ausgeliefert werden. Dass der eigene (Qualitäts-)Anspruch unterlaufen wird, tut weh.

Die firmeninterne Schuldzuweisung erfolgt häufig in Richtung der Software-Teams. Geht man den Ursachen auf den Grund, wird man eine Melange an Gründen finden. Unklare Anforderungen, wechselnde Leit- und Marketingideen fürs Projekt und nicht ausreichende Zulieferungen werden ihren Teil zum Ergebnis beigetragen haben. In einem klassisch geführten Unternehmen, erfolgt die Schuldzuweisung gerne auf den letzten Schritt. Das ist – aus Wasserfall-Sicht – in einem Software-Projekt die Implementierung.

In dieser Situation ist die Sehnsucht nach einem besseren Arbeitsumfeld groß. Und die agile Bewegung liefert eine Idee, wie es besser laufen könnte.

Neben der Analyse der bisherigen Projektparameter gibt es noch einen zweiten Grund, agile Projektmethoden anzustreben.

In vielen Unternehmen ist die Größe der Software-Projekte im Laufe der Zeit signifikant gewachsen. Kleine Projekte kann jeder organisieren. Auf Grund der kurzen Projektlaufzeit lassen sich potenzielle Störquellen leicht identifizieren, und das Team kann einigermaßen klar das Projektziel erreichen. Werden nun die Projekte größer, funktioniert die „So wie beim letzten Mal“-Projektmethode nicht mehr. De facto besitzen viele Software-Teams keine definierte, klare Projektmethodik. An Stelle dessen organisieren die Team-Mitglieder das Projekt – und das meist mehr schlecht als recht. Der fehlenden Projektkultur strahlt die agile Hoffnung entgegen.

Egal, mit welcher Motivation ein Software-Team in die agile Welt startet, die Verheißung agiler Projekte ist groß. Weil das damit verbundene Heilsversprechen so riesig ausfällt, fangen viele Projektteams von heute auf morgen mit einer agilen Projektmethode an. Sie wählen dabei den kompletten Ansatz: ab heute wird alles anders. Dabei wählen signifikant mehr Projektteams SCRUM als Start in die agile Projektmethodik als Kanban oder XP. Das mag an der größeren SCRUM-Trainerzahl bzw. an der Zertifizierungsmöglichkeit für SCRUM liegen.

Dabei sind in der Praxis zwei Phänomene zu beobachten, die sich in den folgenden Aussprüchen zeigen:

1. „Unser PO versteht SCRUM nicht“

2. „Das Projekt ist sehr eng. Deswegen machen wir gerade keine Retrospektiven.“

Der erste Ausspruch könnte ein Signal sein, dass der Product Owner (PO) einem Methodenwechsel ohne Kenntnis der agilen Wertewelt zugestimmt hat. Wenn sich nicht alle Projekt-Beteiligte auf den Wechsel in die Agilität geeinigt haben, ist klar, dass die agil geprägten Anforderungen und Ansprüche nicht erfüllt werden. Diese Phänomen ist besonders in Teams zu beobachten, die bisher wenig eigene Projektkultur besaßen und durch die Einführung von SCRUM erstmals eine definierte Projektmethode nutzen.

Der zweite Ausspruch zeigt, dass das Team unter Zeitdruck in alte Reflexe verfällt – und die agilen Prinzipien verlässt, sobald das Projekt schwierig wird. Auf das Mittel der Retrospektive zu verzichten, wird den aktuellen druckvollen Projektstand erhalten. Einige Teams verzichten auch unter Druck auf das „Daily SCRUM“. Würde doch der tägliche Austausch offenlegen, dass das Team auf der Stelle tritt.

Gleichzeitig signalisiert das Team, dass es nicht in der Lage ist, alle mit der neuen Methode erforderlichen Prinzipien zu folgen und die schriftlichen Artefakte zu produzieren. SCRUM führt parallel neun Methoden und Artefakte ein [4]. Projektmethodik zu ändern, heißt Verhaltensweisen zu ändern. Der schrittweise Wechsel ist einfacher zu bewerkstelligen.

Vor der Zusammenstellung von Methodenbausteinen ist zu klären, wer genau Mitglied im Team ist. Die Diskussion über die Zusammenstellung sollte mit allen Beteiligten offen geführt werden. Dabei ist zu beachten, dass das Auflösen bisheriger Teamgrenzen entlang von Disziplinen für einzelne Mitarbeiter eine große Herausforderung, wenn nicht Zumutung, bedeutet. Viele Schwierigkeiten entstehen bei der Übernahme von Vorarbeiten, die vom Entwicklerteam als unzureichend wahrgenommen werden. Projekte über interdisziplinäre Teams zu gestalten, kann hier der Schlüssel der Erfolg sein.

Hier gilt es vorab für eine neue Herangehensweise zu werben. An dieser Stelle ist ein Bekenntnis für und die Hoffnung auf agile Werte zu formulieren: lernend, offen, beweglich, fokussiert auf die fachlichen Ziele des Projekts.

Und in diesem Sinne ist auch der agile Start zu vollführen: möglichst einfach! Um zu verstehen, was im Projekt passiert, sind zwei Methodenbausteine sinnvoll: die Wandzeitung und der tägliche Austausch über den Projektstand.

Die Wandzeitung wird in Schritte unterteilt, die dem Projekt entsprechen. Dabei ist die vorgeschlagene Weg kein zunächst keine Kanban-Board, welches weitere Artefakte, wie die maximale Anzahl von WIP (Work in Progress) pro Station, vorsieht – und weitere Handlungen daraus ableitet.

Um den Wechsel aus der klassischen in die agile Welt zu erleichtern, sollten sich die Schritte auf der Wandzeitung an den Wasserfall-Prozessschritten orientieren:

1. Anforderung

2. Konzept

3. Design

4. Software-Design

5. Implementierung

6. QA

7. Bereit zur Übergabe

Dabei ist darauf zu achten, dass die Prozessschritte nicht zu feine Unterteilungen aufweisen. Das wäre zu schwer zu pflegen. Das Team beginnt nun, alle Aufgaben, die aktuell bearbeitet werden, in der jeweilige Rubrik aufzuhängen.

In einem täglichen kurzen Arbeitstreffen von einer Viertelstunde (gerne im Stehen, das verkürzt die Dauer ganz natürlich) werden vor der Wandzeitung von jedem Beteiligten die folgenden Fragen geklärt:

1. Was habe ich gestern getan?

2. Was werde ich heute tun?

3. Bei welchem Thema habe ich Bauchschmerzen?

Wurden am Vortag Aufgaben im jeweiligen Prozessschritt erledigt, werden diese an der Wandzeitung weitergehängt. (Schnell kommen Teams dann auf die Idee die Prozesschritte in „in work“ und „done“) zu unterteilen – das wäre der entsprechenden Team-Retrospektive vorweggenommen.)

Die Wandzeitung dient dazu, dass alle einen Überblick über die anstehenden Aufgaben und in Arbeit befindlichen Aufgaben haben. Reicht eine Wand nicht aus, um die Teamarbeit zu beschreiben, sind zwei Fragestellungen zulässig:

1. Haben wir zu viele Themen gleichzeitig in Arbeit? Sollten wir uns nicht stärker fokussieren auf wenige Arbeiten, die wir leichter abschließen können?

2. Ist unser Team zu groß? Ist es für uns sinnvoller, uns in mehrere Teil-Teams aufzuteilen, die jeweils voneinander unabhängige Teilgewerke (lose gekoppelt über die Geschäftsziele) erstellen?

Um das eigen Verhalten zu optimieren und die Teamarbeit zu verbessern, trifft sich das Team regelmäßig zu Retrospektiven. Diese finden regelmäßig statt. Der Turnus hängt von der Projektlaufzeit ab. In kurzen Projekten mag ein wöchentliches Treffen von einer Stunde, in längeren Projekten ein zwei- bis dreiwöchiger Abstand des einstündigen Treffens angemessen sein. Liefert das Projektteam in regelmäßigen Iterationen aus, ist die Retrospektive an diese zu koppeln.

Mittels Retrospektiven definieren für das Team effiziente Methodenbausteine zum Standard und sprechen neue Verfahrensweisen ab. Der Bereich, der änderbar ist, ist nicht begrenzt.

Das Team kann über Methodenbausteine, Kommunikationsformen und schriftliche Artefakte genauso beschließen wie über typische Teamregeln wie die Frage nach der Startzeit im Team oder der Etablierung eines regelmäßigen Team-Mittagessens.

Für den Start in Retrospektiven empfiehlt es sich, Verfahren zu ändern, die durch das Team realisierbar sind. Veränderungen „nach außen“ sind meist nur mit Vorarbeit (und mit unsicherem Ausgang) vermittelbar.

Stellen sich die Fragen „nach außen“ dringend, ist die Frage, ob die Zuteilung „außen“ korrekt ist, zu klären. Sollte derjenige Projekt-Beteiligte nicht besser Teil des Teams sein?

Wenn das Team über Methodenbausteine verhandelt, die die bisherigen „So wie beim letzten Mal“-Methodenbausteine ablösen sollen, lohnt sich der Blick in bekannte Projektmethoden. Was machen die agilen Projektmethoden wie SCRUM, Kanban oder XP, um ein bestimmtes Thema zu lösen? Und wie lösen es die klassischen Projektmethoden? Welche der erkannten Methodenbausteine passen zu uns? Welche setzen wir ab heute ein? Es ist dabei nicht entscheidend, ob alle eingesetzten Methodenbausteine einer Projektmethode entstammen. Wichtig ist nur, dass die gewählten Methodenbausteine für das Team passen – und insgesamt zum Projekterfolg führen.

Dabei kann sich eine Methode entwickeln, die sich stark an bereits etablierte und ausformulierte Methoden annähert. Es kann aber auch eine ganz eigene agile Methode entstehen.

Mit jeder Retrospektive wird das Team neue Verhaltensweisen aushandeln, welche die Projektarbeit bestimmen. Einige dieser Regeln und Verhaltensweisen gelten genau im Kontext des aktuellen Projekts, andere Regeln hingegen haben eher allgemeinen Charakter – für das Unternehmen und für kommende Projekte. Das Team wird diese Regeln in andere Bereiche und Projekte mitnehmen.

Auf diese Art wächst die Sammlung der Methodenbausteine. Diese Sammlung mausert sich so langsam zu einer firmeneigenen Projektkultur, welche auf den agilen Werten „lernend, offen, beweglich und fokussiert auf die fachlichen Ziele des Projekts“ basiert.

Wenn der Kanon groß genug geworden ist, wird es Zeit für einen guten Namen für die eigene Projektmethode und viel Kommunikation über diese (z.B. auf Konferenzen) - damit das eigene Verhalten andere Projektteams inspirieren kann. 

Dieser Artikel ist zuerst im Windows Developer, Ausgabe 04/2013, Software & Support Verlag erschienen.

• Nächster Artikel: PHP Magazin | Erfolgsfaktor Unternehmenskultur
• Vorheriger Artikel: Nachfüllbare FlipChart-Stifte