Agilität ist nach wie vor in aller Munde. Auch große Unternehmen mit konservativen Strukturen haben diesen Trend aufgenommen und wollen "mitspielen". Dass sich das Partizipieren nicht einfach durch die Aussage "wir sind agil" bewerkstelligen lässt, möchten ich in diesem Beitrag anhand eines Erfahrungsberichtes zeigen. Neben den aufgetretenen Herausforderungen stelle ich auch die umgesetzten Erkenntnisse dar, dessen Berücksichtigung ein solches Projekt mit wesentlich höherer Wahrscheinlichkeit als erfolgreich bewerten lässt.

Wie kam es dazu?
Viele Hierarchieebenen, klassisch strikte Vorgaben von oben und eine Bandbreite an einzuhaltenden Prozessen. Kommt Ihnen das bekannt vor? Vielleicht können Sie sich dann vorstellen, wie überrascht ich war, als die Vorgabe kam, dass das Projekt mit agilen Methoden gesteuert werden soll. Auf der einen Seite freute ich mich, da ich wusste, über welchen Budgetrahmen das Projekt verfügte und es somit kein kleines agiles Vorhaben werden wird. Auf der anderen Seite fragte ich mich, ob eruiert wurde, ob "Agil" für das Projektziel überhaupt das zu bevorzugende Vorgehensmodell ist. Im Laufe der zwei Jahre kristallisierte sich immer mehr heraus, dass man sich diese Frage nicht gestellt hatte. Viel mehr gab es verschiedenste Erwartungshaltungen, die es natürlich zu erfüllen galt. Von "agil ist günstiger und schneller" bis "bei agil kann ich jederzeit alles ändern" war alles dabei. Auch war man sich nicht bewusst, dass man auch außerhalb des Projektes von einem anderen Vorgehensmodell betroffen sein wird. Dazu später noch mehr.

Alex-Artikel-bearbeitet-01

Wie war das Projekt strukturiert?
Das Projektziel war auf grober Ebene klar definiert: "Ablösung und Zusammenlegung von Alt-EDV-Systemen zur langfristigen Kostenreduktion, durch die Einführung einer Produktlösung". Bis hierhin war es noch ausreichend unkonkret, so dass man wirklich viel hätte agil angehen können. Es kam ein wenig anders.
In einem Vorprojekt war schon über die neue Tool-Landschaft entschieden worden, konkret welches Produkt die bisherigen Eigenentwicklungen ablösen sollte. Der Bedarf an Ressourcen und Knowhow war dafür noch recht wage, man wusste nur, dass es etwas Größeres werden wird.
Da aufgrund des anvisierten Personalbedarfs klar war, dass man die Mannschaft aufteilen musste, orientierte man sich an der bisherigen Struktur im Unternehmen. Ein Team für die technische Basis, zwei Teams für die unterschiedlich fachlichen Teilbereiche.

Zu Beginn war man noch der Ansicht, dass alle Teams für das gleiche Zielsystem entwickeln werden. Das neue Produkt, welches den technischen Rahmen vorgab, musste schließlich nur individuell erweitert und mit Inhalt gefüllt werden. Jedes Team sollte in einer Art von SCRUM gesteuert werden, sprich es gab einen Product Owner (PO), einen Agile Master (AM) und das Umsetzungsteam. Wie die Teams das konkret leben sollten, war nicht vorgegeben und hing sehr stark vom AM ab.
Über den 3 Teams – und hier wurde es schon nicht mehr so "scrummig" – gab es eine klassische Projektsteuerung und darüber noch ein steering board. An sich gab es die Idee, die Projektsteuerung als eine Art Scrum of Scrum (SoS) zu sehen, allerdings wurde hier sehr schnell klar, dass dies nicht der passende Name ist, so wie dort die Steuerung erfolgte.

Der Projektrahmen war folgendermaßen abgesteckt:

  • Zeitrahmen absolut fix (Monat des Umschalttermins stand fest)
  • Budget kann eventuell mal diskutiert werden
  • Scope ist doch recht klar. Nämlich alles was das alte System konnte und ein paar kleinere Erweiterungen.

Ansonsten ist zur Struktur noch zu erwähnen, dass in einem der Umsetzungsteams, Entwickler hinzugezogen wurden, die eine grundlegende Ablehnung gegenüber der agilen Welt hatten, geschweige denn ausreichendes Wissen über dort definierte Methoden und Werkzeuge.

Mit welchen konkreten Herausforderungen waren wir konfrontiert?

Der persönliche Kampf einzelner
Im Gegensatz zu den eben erwähnten Kolleginnen und Kollegen, war den meisten in den Umsetzungsteams klar, was agiles Vorgehen im Grunde bedeutet. Sowohl von Prozessen, Begrifflichkeiten als auch und vor allem, welche Vor- und Nachteile dieses mit sich bringt. Nichts desto trotz reichten schon diese kleinen Störfeuer der Agil-Verweigerer aus, dass im Grunde genommen Kleinigkeiten zu enormen Problemen geführt haben.

Vorschläge, die Sprintlänge auf sechs Monate oder mehr zu erweitern, waren keine Seltenheit. Das "Daily Standup" wurde eher als sektenartiger Gebetskreis bezeichnet, in dem der Agile-Gott (AM) jeden auffordert sein Gebet vorzutragen. Und nicht zu vergessen, dass man, vor allem persönlich und bereits schon nach ein paar Wochen, seine Entwicklungsergebnisse vorzeigen muss (Review) wurde als überaus lästig und nicht sogar stressig empfunden. Somit verwunderte es auch niemanden, dass die bunten Kärtchen (Stories oder Tasks) nicht dem aktuellen Bearbeitungsstand entsprechend im Board gepflegt wurden.

Insofern fand man sich immer wieder in Prozess- und Methoden-Diskussionen wieder. In jedem Meeting gingen immer wieder ein paar Minuten auf die immer gleichen Themen drauf. Im Laufe der Zeit unterstützen alle anderen Team-Mitglieder den AM in seiner Überzeugungsarbeit bis dann doch die Stimmung irgendwann zu kippen begann.

Alex-Artikel-bearbeitet-02

Der variable Fix-Scope
Wie eingangs erwähnt, befasste sich das Projekt mit der Ablösung einer selbstentwickelten und in die Jahre gekommenen Anwendungslandschaft, durch die Einführung eines Standard-Produktes. Ein Teil des Teams kannte die alte Anwendung und wusste somit um den bisherigen Funktionsumfang. Ein anderer Teil war als Produkt-Spezialist involviert wodurch dieser der einzige Wissensträger war, wie aufwändig etwas in dem Produkt umzusetzen ist. Der dritte und letzte Teil des Teams kannte weder noch und sollte für das Produkt vom Spezialisten aufgegleist werden. Für das Umsetzungsteam war der eigentliche Scope nicht wirklich ersichtlich, da einerseits die einzelnen Blöcke erst nach und nach durch die Groomings (Refinements) wanderten und andererseits grundsätzlich nicht klar war, was man nun wirklich an Funktionalität aus der alten Welt übernehmen möchte.

Im Gegensatz zu den Stakeholdern war das Umsetzungsteam der Meinung, dass man agil sei und somit der Teil ausgeliefert wird, der dann zum Tag X fertig sein wird. Für die Stakeholder und zu diesem Zeitpunkt auch noch der Product Owner (PO) war der Scope genau jener, welcher zu Beginn des Projektes einmal definiert worden war.

Im Laufe des Projektes kamen immer mehr Stories in den Status "Ready for Grooming", sodass sich das Umsetzungsteam langsam die Frage stellte, ob dies wirklich alles noch für das Minimum Viable Product (MVP) notwendig ist. Erst als die kritischen Stimmen immer mehr und lauter wurden, drang dies bis zum PO durch, dessen Hauptaufgabe sich dann darauf beschränkte den fixen Scope zu variabilisieren. Ab diesem Zeitpunkt ging es nur noch darum den Scope auf das wirkliche Mindestmaß zu reduzieren. Für das Team gab es viel fachlichen Spielraum, für den PO ordentlich viel technische Reduzierungsmöglichkeiten.

Alex-Artikel-bearbeitet-03

Es ist zu erwähnen, dass das gewählte Produkt um eine wesentliche Komponente erweitert werden musste, da es für eines der Teams eine unabdingbare Anforderung gab, die mit dem gewählten Produkt nicht erfüllt werden konnte. Eigentlich war es noch schlimmer, denn diese Anforderung zeigte, dass das Produkt für eines der fachlichen Themen nicht analysiert wurde und letztlich auch gänzlich ungeeignet war. Dies führte dazu, dass das Produkt, von einem der Teams kaum noch genutzt wurde, sondern Elemente um dieses herum gebaut wurden. All dies trug selbstverständlich nicht dazu bei, den anvisierten Scope in diesem Team, im vorgegebenen Zeitrahmen zu erreichen.

Die eigentliche Problematik zeigte sich erst gegen Ende des Projektes, als sich der Go-Live-Termin näherte. Es gab für das Team mit der Sonderlocke einen ganzen Berg an Stories, die bereits gegroomed und auch schon mit Storypoints geschätzt waren. Auch hier noch, war dieses Team der Meinung, dass nicht alle für den MVP fertiggestellt werden müssen. Es kam zum Eklat, als der PO verkündete, dass es ohne diese Stories nicht gehen würde. Die Verschiebung des Livegangs, zumindest für diesen Teamteil, um ganze 2 Monate, brachte ziemlich Aufruhr in das Unternehmen. Jeder der irgendetwas zu sagen hatte, sagte dies. Der PO musste seine Arbeit für diese Zeit ruhen lassen, das Team wurde auf Mikromanagementart überwacht und musste eine Sonderretro über sich ergehen lassen, die eher den Anschein erweckte, jemanden an den Pranger zu stellen, als daraus Änderungspotential zu erkennen, geschweige denn anzugehen. Der verschobene Termin wurde eingehalten und man war live.

Die übergreifende Programmsteuerung
In meiner Vorstellung einer agilen Projektstruktur mit mehreren Teams muss es auf jeden Fall übergeordnete Strukturen geben, die den Überblick behalten und steuernd eingreifen, aber bitte mit grundlegendem Verständnis von agilen Methoden und vor allem Werten.

Mein erster Kontakt mit der Programmsteuerung (PGS) war, als ich eine Excel-Liste erstellen sollte, welche alle Anforderungen/Stories enthält, die in diesem Projekt umgesetzt werden sollen. Wenn möglich sollte diese priorisiert und mit ersten Aufwandsindikationen versehen sein. Die Excel-Datei zu liefern, inklusiver Priorisierung, war kein Problem. Ein Export aus unserem eigentlichen Webtool wäre kinderleicht, doch als ich erwähnte, dass diese Liste nur eine Halbwertszeit von eventuell wenigen Tagen oder Wochen hätte und ich diesen Export nicht jeden Tag erstellen möchte, wurden die fragenden Augen immer größer. Wie sollen sie denn sonst den Fortschritt verfolgen, dass man bis zum Ende alles schaffen wird und dies dem steering board präsentieren.

Selbst nach endlosen Diskussionen um agiles Vorgehen bestand die PGS darauf, im mehrwöchentlichen Rhythmus Folien mit Gantt-Diagrammen der drei Teams einzufordern um deren Fortschritt zu besprechen. Wenn sich dann Balken nach hinten verschoben haben oder komplett verschwunden sind, war man sich wieder einmal einer Fragentrijade ausgesetzt.

So ganz ist mir die Aufgabenstellung der PSG nicht klar, aber eines bin ich mir bewusstgeworden: Leider werden übergreifende Positionen immer mit erfahrenen beziehungsweise langjährigen Mitarbeitern besetzt, die ihre Methoden und Vorgehensweisen fest eingefahren haben und nur bedingt damit zurechtkommen, etwas komplett Anderes zu machen.

Aber immerhin, einen Excel-Export hatte ich nie machen müssen.

Das Linienmanagement
Das Projekt hing natürlich nicht im leeren Raum, sondern war eingebettet in den Sichtweisen, Kontrollstrukturen und dem Verantwortungsgefühl der Linien(-Vorgesetzten). Eines der fünf Werte im agilen Manifest ist "Vertrauen": Gebe den Projektmitarbeitern entsprechendes Vertrauen, denn sie sind viel näher am Thema dran und können dies in der Regel dadurch auch besser beurteilen - so die Theorie.

In der Praxis gab es dieses Vertrauen auch, zumindest solange die Nachrichten positiv waren. Bei negativen Punkten wurde sofort eingegriffen und dem Team somit bescheinigt, dass sie es nicht alleine stemmen können. Wie bereits erwähnt, wurde der PO für zwei Monate auf das Abstellgleis gestellt um ihn dann wieder reinzuholen, da es keiner aus der Linie weitermachen wollte.

Des Weiteren gab es für das Management aus der Linie nur das Review, in dem man sich informierte. Alle anderen Termine waren nicht existent und auch die völlig offene Dokumentation des gesamten Fortschritts, mit recht gut strukturierten Übersichten, wurde nicht genutzt. Ganz im Gegenteil, wenn gewisse (offene) Informationen – von denen man natürlich genau wusste, dass sie jetzt ganz dringend benötigt wurden – nicht in der gleichen Geschwindigkeit entsprechend kommuniziert wurden, befand man sich wieder in Erklärungsnot.

Somit mussten wieder einmal Folien gemalt werden, die diese Übersichten dann enthielten und es gab im mehrwöchigen Rhythmus ein entsprechendes Meeting in dem das Management gesondert informiert wurde.

Alex-Artikel-bearbeitet-04

Die Finanzierung
Einer der größten Problempunkte war das Thema Finanzierung. Schon sehr merkwürdig, wenn man bedenkt, dass im agilen Kontext die Budgetlage fixiert und somit wesentlich planbarer sein sollte. In unserem Projekt musste mehrfach nachfinanziert werden. Der mehr oder weniger starre Scope innerhalb des Zeitrahmens führte zu enormer Mehrarbeit, die offensichtlich nicht eingeplant war. Auch waren Kostenpunkte außerhalb des Teams nicht wirklich bedacht worden, die in einer Welt mit großen infrastrukturellen Abhängigkeiten nun mal nicht unwesentlich sein können.

Okay, diese Punkte hätte man zu Beginn besser überdenken können. Spannender war aber die aufkommende Problematik, dass Anfragen an das eigene Team oder auch von uns an andere Teams, immer im Kontext einer möglichen Finanzierung standen. Im klassischen Vorgehen waren einzelne Features beschätzt, dann finanziert und final beauftragt worden. Und nun? Das Team war eigentlich fix, somit auch die Kosten und man müsste sich letztlich nur mit dem PO über die Priorisierung der Themen einigen. Dies ist aber in den Köpfen nicht angekommen, sondern einzelne Features wurden immer noch individuell angefragt. Und wenn die Feature-Finanzierung geregelt war, entstand beim PO ein enormer Druck dieses Features vorzuziehen, schließlich bringt man auch das nötige Kleingeld mit. Auch anders herum habe ich es erlebt, nämlich, dass der PO ein Thema nicht anging, weil die gesonderte Finanzierung nicht geklärt war, obwohl die Kunden dieses Feature unbedingt brauchten.

Was hat sich zum positiven geändert und weshalb?
Mittlerweile werden im Team keine Diskussionen mehr über agile Prozesse und ihren Nutzen diskutiert. Dies liegt aber nicht daran, dass eine Vielzahl an Schulungen und Retrospektiven diesem Thema gewidmet wurden. Vielmehr kam die Ruhe ins Team, weil besagte Kollegen das Projekt verlassen haben. Für das Projekt, aber auch für die Mitarbeiter, war diese Entscheidung ein Befreiungsschlag. Wer diesen Wandel nicht mitgehen möchte beziehungsweise, wer es nicht kann, sollte dazu auch nicht gezwungen werden. Es gibt genügend Projektvorhaben, die nicht agil durchgeführt werden können und hoffentlich auch nicht werden, daher gibt es auch für jeden den besser passenden Deckel.

Was den variablen Fixscope betrifft, hat sich nach dem Livegang des MVP natürlich die Welt komplett gedreht. Es gibt nicht mehr den einen Termin, der mit einer fast unüberschaubaren Anzahl an Funktionen bedient werden soll. Jeder Sprint enthält sein Päckchen was im gleichen oder nächsten Sprint auch schon ausgeliefert wird. Letztlich befindet sich das Vorhaben auch nicht mehr in einer typischen Projektsituation, sondern in einer Betriebsphase.
Interessant ist der Forecast für das anstehende kommende Jahr, da hier die Erwartungen bereits wieder ordentlich geschürt werden. Unser Vorgehen und auch meine Empfehlung ist, so wage wie möglich zu bleiben. Mehr als grobe Schlagwörter und Ideen sollten nicht kommuniziert werden. Gerade im Betracht dessen, dass man im agilen Kontext so flexibel wie möglich bleiben möchte, sollte man sich nicht schon von Anfang an Fesseln anziehen.

Die übergreifende Programmsteuerung gibt es nach wie vor, aber aus Sicht der Teams scheint deren Einfluss gesunken zu sein. Die üblichen Jour Fixes gibt es immer noch, die üblichen Ganttcharts werden immer noch besprochen und wenn sich auf diesen etwas ändert, hat man eigentlich immer gute Gründe dafür. Somit verkommen diese Meetings zu kleinen Reporting-Treffen in denen man übergreifende Themen mal kurz ansprechen kann, um sie später dann mit den anderen Teams/POs konkret zu besprechen.

Das Linienmanagement scheint mittlerweile besser zu verstehen, was agiles Arbeiten bedeutet aber bei negativen Nachrichten, bin ich mir sicher, würden sie wieder eingreifen. Gut, dass es keine langlaufenden Terminvorgaben mehr gibt.

Beim Thema Geld hört bekanntlich die Freundschaft auf: Die Finanzierung scheint sich immerhin an der Teamgröße für das kommende Jahr zu orientieren, inklusive Puffer für externe Zulieferungsaufwände. Spannend wird es eher dahingehend, was das Team für dieses Geld liefern wird. Die ersten Schätzungen waren nicht vielversprechend. Das Team wird bei Schätzungen immer vorsichtiger, sodass sie immer weniger in Aussicht stellen, egal wie einfach und klein eine Anforderung klingen mag. Aber immerhin werden die Themen schon mal sehr vage vorgestellt, die der PO für das kommende Jahr sieht und dies bringt einiges an Übersicht und auch viel Umsetzungsspielraum mit sich.

Fazit
Grundsätzlich wurden in diesem Projekt viele Fehler gemacht, deren Ursprung schon mal darin lag, dass man sich keine Zeit genommen hat, um zu eruieren, ob das Projekt überhaupt für ein agiles Vorgehen geeignet ist. Eine kurze Analyse hätte schon gezeigt, dass zum Beispiel der technische Mindestbedarf nie im ersten Drittel des Projektes hätte erreicht werden können. Auch waren die inhaltlichen Vorgaben so konkret, dass man für ein agiles Vorgehen zu wenig Spielraum hatte. Die Entscheidung, ein Projekt mit agilen Methoden zu steuern, muss wirklich wohlüberlegt und bewusst erfolgen. Ein blindes folgen eines möglichen Hype-Themas könnte hier ziemlich teuer werden.

Entscheidend ist auch, dass wirklich "alle" Beteiligten, also auch jene außerhalb des Projektes, diese Entscheidung mittragen und sich über die Konsequenzen absolut im Klaren sind. Eine schriftliche Fixierung der Auswirkungen, Konsequenzen und Erwartungsmöglichkeiten für jeden einzelnen sollte mögliche Auswüchse enorm eindampfen.

Alex-Artikel-bearbeitet-05

Eine doch wesentliche Komponente, die ebenfalls nicht wirklich vorhanden war, ist der sogenannte Sprint 0. Dieser soll die Grundlagen des gesamten Projektes etablieren, etwaige Architekturfragen klären und den Fahrplan aufzeigen. Hier hilft es auch den wirklich minimalsten Scope aufzuzeigen, damit sich das Team darauf einstellen kann. Auf diesen Sprint sollte auf keinen Fall verzichtet werden, auch wenn dazu einige Wochen einzuplanen sind und die inhaltliche beziehungsweise funktionale Umsetzung dadurch noch warten muss. Dieser Sprint lässt die Wahrscheinlichkeit, ein erfolgreiches Projekt zu werden, enorm ansteigen.

Ob ein agiles Projekt in nicht agilen Strukturen erfolgreich sein wird, hängt meines Erachtens nach aber nur mittelbar damit zusammen, ob es durch ein agiles Unternehmensumfeld unterstützt wird oder von klassischen Strukturen umgeben ist. Vielmehr ist entscheidend, wie der PO und der AM das Umsetzungs-Team vor diesen Strukturen abschotten können. Umso mehr die umliegenden Strukturen das agile Vorgehen unterstützen umso entspannter sind diese beiden Rollen und umso erfolgreicher wird das Projekt am Ende sein.