IT Strategie – Schwer agil

Es ist im Leben wie im Beruf – wer nicht aufpasst, wird unbeweglich. Und war früher (*hust*) noch Stabilität das Maß aller Dinge, haben uns die Dinosaurier, das Leben und die Märkte zwischenzeitlich gelehrt, dass zu wenig Bewegungsfähigkeit evolutionär ein Nachteil sein kann. Die Lösung? Agilität.

Der heilige Gral

Gelobt sei, was agil macht. Und so gibt es heute unzählige gut gemeinte Ratschläge, was man denn so alles agil machen sollte: Projekte umsetzen, Organisation aufbauen, Menschen führen, Mitarbeiter coachen und natürlich denken, kommunizieren, planen und ganz allgemein – leben. Doch was hat es mit agil eigentlich auf sich?

Grob gesagt meint agil, dass flexibel auf Veränderungen reagiert werden kann. Wenn wir also beim Projektmanagement bleiben, müssen wir

1. ohne vorgefertigten, starren Plan in das Projekt gehen
2. auch während des Projekts offen und beweglich für Veränderungen bleiben

Punkt 1. ist der Grundstein des agilen Vorgehens – verschwende keine Zeit mit Planung, denn am Anfang ist sowieso alles nichts. Anforderungen ändern sich, das Wissen nimmt im Projektverlauf zu, also fang lieber – methodisch strukturiert – an und sieh, was dabei herauskommt. Nicht minder wichtig ist Punkt 2. Denn einmal getroffene Festlegungen und Vereinbarungen müssen auch während des Projektverlaufs anpassbar bleiben. Dies meint agil auch im eigentlichen Sinn: beweglich bleiben.

Ein Projekt nach Wasserfall-Methodik geht hingegen von der Annahme aus, dass Frontloading uns teures Fehlerbeheben am Ende spart (Rule of Ten). Hier nimmt man sich daher ganz am Anfang des Projekts viel Zeit, um Wünsche und Anforderungen in ein Prozesskonzept zu gießen. Dieses wird dann zur Grundlage des Projektumfangs, und (mit kleineren Änderungen – Stichwort Change Management) 1:1 im technischen Konzept und später im System umgesetzt.

„Halt!“ rufen da die Projekt-Erneuerer, „In der Realität zeigt sich, dass zahlreiche Projekte in der Erreichung ihrer Ziele scheitern. Und das nicht zuletzt, weil sich Zielsetzungen verändert haben und das Projekt darauf nicht reagieren konnte.“ Damit haben Sie sicher nicht unrecht, denn häufig sind Projekte tatsächlich zu weit vom Kunden entfernt, und zu wenig sensibel gegenüber neuen Erkenntnissen, um auf Veränderungen angemessen reagieren zu können. Am Ende bekommt der Kunde dann oft etwas, aber es ist nicht (mehr) das was er braucht.

Also hat man zuerst Mitte der 90er agile Methoden ersonnen, die diesem Missstand begegnen sollen. Im Jahr 2001 entstand schließlich ein agiles Manifest.

Wie bitte?

Zur Umsetzung dieses agilen Gedankens gibt es verschiedene Ideen, von denen ich hier einige ganz kurz vorstellen will.

Scrum

Wenn heute jemand agil ruft, ruft mindestens ein weiterer „Scrum“. Scrum wurde 1995 erstmals veröffentlicht. Die Entwicklungsarbeit erfolgt bei Scrum in sogenannten Sprints, also kurzen (1-4 Wochen) Entwicklungszyklen an deren Ende ein anwendertaugliches (funktionsfertiges, getestetes) Ergebnis stehen muss.

Es gibt im engeren Sinne keinen Projektleiter, und gemäß agiler Denkweise auch keinen Business Blueprint. Letzterem kommt noch das Product Backlog am Nächsten. Dieser wird agil-typisch nicht mit funktionalen Lastenheft-Anforderungen sondern mit User Stories gefüllt. User Stories sind umgangssprachlich formulierte, kurze Beschreibungen der Projektanforderungen (Bsp. Kai Simons „Als Vertragshändler möchte ich alle Gebrauchtwagen auflisten können, um diese meinen Kunden anzubieten.“). Das Entwicklungsteam leitet dann ab, welche Tasks nötig sind um diese Story in einem Sprint in Software abzubilden. Anhand der Story geschieht später auch die Abnahme der Funktionalität.

Scrum hat um diese Grundelemente herum ein klares und einfaches Regelwerk geschaffen, nach dem Projekte abgewickelt werden können, bestehend aus:

• Rollen: Product Owner (Anforderer, erfolgsverantwortlich), Scrum Master (Governance), Entwicklungsteam (Generalisten, selbstorganisiert, 3-9 Personen)
• Artefakte: Product Backlog (Produktanforderungskatalog), Sprint Backlog (Umsetzungsplanung je Sprint), Product Increment (fertige Backlog-Einträge)
• Aktivitäten
  • Sprint Planning .. max. 2h je Sprintwoche, Planung des nächsten Sprints
  • Daily Scrum .. tägliche Kommunikation des Fortschritts und möglicher Probleme
  • Sprint Review / Retrospektive .. Nachbesprechung des Sprints
  • Product Backlog Refinement .. Auf- und Überarbeiten des Product Backlogs

Auf der Skala zwischen klassisch und agil setzt Scrum die agilen Gedanken sehr konsequent um. Die Sprints sind die Atome im Scrum-Prozess, ein Mal geplant, können sie nur noch umgesetzt oder abgebrochen, aber nicht mehr angepasst werden.

Extreme Programming (XP)

Etwas lockerer nimmt man es da beim Extreme Programming. XP ist ungefähr zur gleichen Zeit entstanden wie Scrum, und beide teilen den agilen Grundgedanken. Das Projektergebnis wird inkrementell erstellt, in enger Abstimmung mit dem Kunden. XP bedient sich hier einiger von Scrum verschiedener Begriffe, ist aber nichtsdestotrotz sehr nah am bekannteren Bruder. Organisatorisch ist es jedoch etwas flacher aufgebaut:

• Produktbesitzer gibt es auch hier
  • teilweise ist dieser auch der Projektmanager
  • und der Kunde
  • und im Extremfall auch noch der Benutzer
• Entwickler

Damit entfällt die Rolle des Wachenden über die Methodik-Governance (wie es bei Scrum der Scrum Master ist). Auch sind Meetings in Namen, Struktur und Häufigkeit nicht festgelegt. Ein tägliches Standup-Meeting wird empfohlen. Außerdem sollen die (auch hier existierenden) User Stories möglichst in einer Iteration umgesetzt werden können, ansonsten empfiehlt sich der Split. Darüber hinaus hält man sich mit methodischen Vorgaben aber weitestgehend zurück, und propagiert stattdessen lieber Werte, Prinzipien und Praktiken.

Beispielhaft seien hier die Grundwerte benannt:

• Kommunikation
• Respekt
• Mut
• Einfachheit
• Feedback

XP fokussiert etwas stärker auf die Nutzenanalyse, jede Funktion wird nach YAGNI auf Ihren spezifischen Mehrwert geprüft. Dazu werden Modelle der Steifheit / Flexibilität eingeführt, je mehr Features, desto steifer ist mein Produkt. Da Steifheit den Aufwand in Erstellung und Pflege erhöht, ist diese immer dann zu vermeiden, wo es im Kundennutzen keine deutlichen Abstriche bedeuten würde.

Insgesamt gesehen ist XP nicht ganz so stringent agil wie Scrum, da es den Projektschaffenden bei der konkreten Ausgestaltung etwas mehr Freiheit lässt.

Kanban

Auch Kanban ist ein Vertreter der agilen Projektmethodik, welcher sehr lose mit der Signalkartentechnik aus der Fertigung verbunden ist. Kanban setzt sich als zentrales Ziel, die Anzahl paralleler Arbeiten zu begrenzen. Das schafft kürzere Durchlaufzeiten und lässt uns Probleme im Projekt schneller erkennen.

Dazu existieren einige Praktiken, die von David Anderson niedergeschrieben wurden:

• Visualisiere den Fluss der Arbeit
• Begrenze die Menge angefangener Arbeit
• Miss und steuere den Fluss
• Mache die Regeln für den Prozess explizit
• Fördere Leadership auf allen Ebenen
• Modelle für Chancen kollaborativer Verbesserungen

Klingt auch eher nach genereller Handlungsempfehlung, und genau so lebt es sich auch. Auch hier gibt es viele Gemeinsamkeiten mit Scrum (schlankes Vorgehen, Transparenz, viele kleine Inkremente, iterativer Releaseplan) aber die Unterschiede zu Scrum sind noch größer als bei XP:

• auch hier ist wie bei XP keine Dauer für die Iteration vorgeschrieben
• es dürfen auch Experten-Teams gebildet werden, Mischung ist nicht Pflicht
• Anforderungen dürfen auch über mehrere Iterationen entwickelt werden
• Kanban-Iterationen sind grundsätzlich offen (jederzeit Raum für Input, im Gegensatz zu Sprints)
• keine Rollenbeschreibungen
• keine Priorisierung zwingend

Kanban sieht es also mit den methodischen Vorgaben hinsichtlich Agilität noch am lockersten. Damit ist es auch am universellsten einsetzbar, denn Agilität löst zwar einige bekannte Projektprobleme, bringt aber neue Herausforderungen mit sich.

Warum nicht einfach alles agil?

Jede eingesetzte Methodik hat ihren spezifischen Anwendungsfall. Die Kernkompetenz eines strengen agilen Vorgehens ist der unbedingte Fokus auf das Werk und die Kundenakzeptanz.

Wer dabei in den Schatten geschoben wird, ist der Sponsor im klassischen Projektsinne. Wenn ich ein vergleichsweise großes Vorhaben (6 bis 8-stellige Budgets) auf den Weg bringen will, sitze ich oft zuerst jemandem gegenüber, der auf dem Geld sitzt. Und dieser legt (zu Recht) Wert auf Termin- und Kostentreue, denn in der überwältigen Mehrzahl der Organisationen wird Geld nur zweckgebunden und zielgerichtet in die Hand genommen. Da braucht es vor Budgetgenehmigung eine (möglichst) valide Planung von Inhalt, Kosten und Zeit, und im Projektverlauf auch Konzepte, Verträge, Teilabnahmen und mehr. Unmöglich, dem Sponsor einen validen Termin- und Kostenplan vorzulegen, wenn die Eigenschaften des Projektergebnisses erst im Lauf erarbeitet werden und jederzeit Änderungen unterliegen können. Monitoring ist im Agilen sicher zentral, aber ganzheitliche Planung wird wirklich schwer. Darüber hinaus ist es mindestens ebenso schwer, anhand einer Leistungsspezifikation die Erfüllung festzustellen (Wann sind wir eigentlich fertig?).

Das macht inbesondere dann Probleme, wenn externe Partner im Spiel sind. Projekte dieser Größenordnung werden fast immer mithilfe externer Ressourcen angegangen, weil das Unternehmen die Herausforderungen mit eigenen Kapazitäten know-how- oder lastseitig nicht stemmen kann oder will. Wenn diese jedoch nicht über Jahre ohne klare Zielvorgabe auf T&M arbeiten sollen, muss es irgendeine Art von Pflichtenheft geben, dass sie bepreisen und auf das man sie anschließend auch „verpflichten“ kann. Das jedoch würde auch in seiner schwächsten Form (z.B. CPIF-Verträge – Cost Plus Incentive Fee) dem agilen Vorgehen widersprechen, denn zu Beginn existiert keinerlei Leistungsspezifikation des Gesamtvorhabens.

Auch der Mensch spielt eine Rolle. Im strengeren Scrum-Vorgehen darf ein Entwicklungsteam aus Gründen der Liefersicherheit nur aus Generalisten bestehen, die sich gegenseitig vertreten können. Fruchtbarer Austausch mit dem Kunden ist zentraler Kern des agilen Vorgehens. Nicht zuletzt sind auch die Anforderungen an die eigene Arbeitsplanung sehr hoch, denn es gibt de facto niemanden außerhalb des Entwicklungsteams der die eigentliche Arbeit organisiert. Die Menge generalistischer, hoch-kommunikativer, selbstoptimierter Entwickler da draußen ist jedoch stark begrenzt.

Zu guter Letzt ist auch der Kunde selbst in der Pflicht. Haben wir in klassischen Projekten mit vergleichsweise seltenen und langfristig geplanten Abstimmungs- und Testzeiträumen schon Schwierigkeiten fachlich versierte Kundenansprechpartner aus dem Tagesgeschäft zu bekommen, nimmt das im agilen Umfeld noch einmal eine ganz andere Dimension an. Denn der Kunde ist hier viel mehr und dauerhafter im Boot, sein Feedback soll ja ständig ins Produkt einfließen. Eine große organisatorische Herausforderung, die durch ständig wiederholte Iteration an Entwicklung, Test, Abstimmung, Neuplanung in Projekt und Linie beträchtliche Ressourcen verschlingen kann.

Das bringt mich zu dem Schluss, dass die Führung größerer Projekte schwieriger ist, je agiler sie geführt werden. Vorgehensmodelle wie SAFe und LeSS versuchen den typischen Herausforderungen großer Vorhaben durch eine gut strukturiertes Portfoliomanagement zu begegnen, die Kerneigenschaften des agilen Vorgehens bleiben jedoch bestehen, und damit auch seine Kernanwendungsgebiete.

Für Projekte in der genannten Größenordnung scheint es sinnvoller, die Vorteile aus beiden Welten zu kombinieren. Es macht für diese Art von Projekten durchaus Sinn ganz klassisch Anforderungen zu sammeln, Konzepte zu schreiben und Meilensteine aufzuplanen. Jedoch sollten die gemachten Annahmen über Umfang, Zeit und Kosten nicht als heilige Pflicht angesehen werden, der alles – inklusive des Produkts und der Kundenzufriedenheit – untergeordnet wird. Das Projekt und der Kunde können von agilen Ansätzen profitieren, indem z.B. Prototyping, enge Kommunikation mit dem Kunden, Ergebnisorientierung und die Vermeidung von „Steifheit“ (siehe auch: technische Schuld) umgesetzt werden.

Der Projekterfolg liegt hier nicht im dogmatischen Befolgen des einen oder anderen Vorgehens, sondern in der Kombination der für den Anwendungsfall optimal passenden Ansätze. Nur so können wir den steigenden Anforderungen an das Projekt begegnen, ohne gleich das Kind mit dem Bade auszuschütten.

In diesem Sinne, stay agile,