… oder “Sh*t happens, finde Dich damit ab”

„Agile“ ist ein häufiges Buzzword in technischen Kreisen. Man könnte sagen, wir befinden uns in einer „Zeit nach Agile“ und dass es für die Softwareentwicklung unerlässlich ist.
Doch ebenso oft wird beklagt, dass Unternehmensleitungen dazu neigen, Agile für eine Wunderpille zu halten, mit denen die Teams schneller mehr mit weniger schaffen. Nicht für etwas, das sie an sich selbst ändern müssen.
Ist Agilität eine höhere Sphäre, die nur Ausnahmefirmen wie Spotify erreichen können, oder schafft das jedes Unternehmen?

Also, was ist dieses “Agile” eigentlich?

Man darf nicht vergessen, dass Scrum und Agile zwei verschiedene Dinge sind. Man kann durchaus Scrum einsetzen, ohne agil zu sein, und umgekehrt. Mit seinem Ausbruch „Ich hasse Agile“ meint David Cancel, CEO von Drift möglicherweise „Ich hasse es, wenn Leute glauben, mit Scrum seien sie agil!“ Oder anders gesagt: Der Agile-Baukasten aus Schulungen, Beratern, Zeremonien und Artefakten macht Unternehmen nicht automatisch agil, wendig und flexibel.

Ein Analyst von Deloitte verdeutlichte 2016 unbeabsichtigt diesen Begriffswirrwarr mit seiner berüchtigten „U-Bahn-Karte“. Das Diagramm zeigte einige der verschiedenen Tools und Praktiken aus der Welt von Agile.

Uff. Es ist nicht schwer zu erkennen, warum viele glauben, Agile sei in der Sackgasse.
Agile ist etwas, das man IST, nicht etwas, das man tun muss. Kein Tool macht einen agil.

Ein paar Beispiele aus meinem persönlichen Alltag…

Ich arbeitete einmal für einen CEO, der einfach nicht akzeptieren konnte, dass ich meinen Standpunkt oft in Meetings plötzlich änderte. Er wollte einfach „den Plan“ durchziehen und mit Stil ans Ziel kommen, und dieses Ziel war immer zu hoch gesetzt. Und natürlich war er im “früheren Leben” Projektmanager”, der schon bei der Ewähnung von “agilen Methoden” zusammenzuckte.

Mit starren Vorgaben leben zu müssen ist für hingegen “Agilisten” eine Tortur.

Als Student hastete ich einmal kurz vor dem Wochenende zu meinem Zug nach Hause nach Durham. Ich rannte auf den Bahnsteig, wo mein 17:25-Uhr-Zug bereits auf Bahnsteig 2 wartet. Dachte ich. Entsprechend entsetzt war ich, als der Zug in die falsche Richtung losfuhr und der Schaffner bestätigte, dass wir erst wieder in Edinburgh halten würden – 2 Stunden später. Aus meiner halbstündigen Heimfahrt war eine 4-Stunden‑Tour nach Schottland geworden.

Meist saß ich allein im Wagen, und wegen der Dunkelheit draußen sah ich nicht einmal die Landschaft. Auf der ungeplanten Fahrt hatte ich nichts zu lesen als die Broschüre der Bahn, die ausgerechnet für einen Tagesausflug ins historische Durham warb. Ganz ähnlich fühlt es sich an, in einem projektbestimmten Unternehmen Blogs über Agile zu lesen.
Ein anderes Mal – ich arbeitete als Berater – sprang ich in mein Auto und brauste von Newcastle auf der Autobahn zu einem Termin nach Süden. Plötzlich zuckte ich zusammen: Wo wollte ich eigentlich hin? Ich hielt an, überprüfte meinen Kalender auf dem Laptop (damals gab es noch keine Smartphones) und stellte fest, dass der Termin tatsächlich im Norden lag. Dieses Mal dauerte der ungeplante Umweg zum Glück nur 90 Minuten.

Sie erkennen die Analogie?
Der Zug entspricht Wasserfall, das Auto Agile. In beiden Fällen fuhr ich zunächst falsch. Aber im Zug musste ich bis zum bitteren Ende durchhalten.

Ich fragte den Schaffner, ob der Zug anhalten könne um mich rauszulassen, aber er lachte mich nur ungläubig an wie ein PRINCE2-Projektmanager, wenn man ihn um eine Neuausrichtung des Projekts bittet.

Der Zug war durch nichts zu stoppen, ebenso wie die Abläufe in gewissen Programmen.
Agile ist für mich die einzig mögliche Strategie, denn (a) kann niemand die Zukunft vorhersagen und (b) sollte man einen schlechten Plan nicht befolgen, sondern ändern.

Warum gibt es Wasserfall also immer noch, trotz seines schlechten Rufs bei der Software-Entwicklung?

Loslassen fühlt sich nicht richtig an

Menschen erkennen Muster instinktiv. Das nutzen wir, um aufgrund unserer Erfahrungen auf die Zukunft zu schließen. Das hat den leidigen Nebeneffekt, dass wir emotional wissen wollen, was die Zukunft bringt, und dass wir Prognosen für Gewissheit halten. Wir fühlen uns sicher, wenn wir tun, was wir kennen. Es kann lange dauern, bis wir hart auf dem Boden der Realität aufschlagen.

Bei der Planung eines Wasserfallprojekts machen sich alle vor, dass das Release „rechtzeitig“ und „im Budget“ auf den Markt kommen wird. Der Chef gibt den Stichtag vor, und die Delivery-Teams sagen auf der Grundlage ihrer Prognosen zu. Die Entwicklungsabteilung beschwert sich, die Dauer sei unmöglich vorherzusagen, also schlägt man eine kleine Marge auf die aus der Luft gegriffenen Zahlen auf. Alle sind zufrieden, denn es gibt einen Plan.

Über kurz oder lang werden die Stakeholder jedoch nervös. Da es noch keine fertige Software gibt, beginnen sie den Fortschritt anzuzweifeln. Sie fragen nach und erhalten die lapidare Antwort: „Es gibt noch nichts zu sehen, wir bauen noch an der Plattform.“

Ohne sichtbare Fortschritte liegen bei einem Wasserfallprojekt schnell die Nerven blank. Die Angst wächst. Man fragt nach, ob die Deadline noch zu halten ist, und drängt auf ein konkretes Ergebnis. Das Delivery-Team schimpft über „Scope Creep“, „sich ständig verändernde Anforderungen“ und die Forderung nach einem „Hochglanzprodukt“. Das Gefühl, die Kontrolle zu verlieren, erzeugt eine negative Stimmung.

Gleichzeitig bekommt das Team das Gefühl, die Außenstehenden hätten keine Ahnung von der Komplexität der Arbeit. Die Deadline wird verlängert, die Nerven liegen blank, auf das Team wird immer mehr Druck ausgeübt und einige werfen das Handtuch. Das kennen wir alle nur zu gut. Bei einer solchen Projektleitung ist das Chaos vorprogrammiert!

Es ist unmöglich vorherzusagen, wie sich ein Software-Projekt entwickelt, weil man überhaupt nie die Kontrolle hatte. Das ist der Hauptgrund für das Agile-Konzept des „Überprüfen und Anpassens“ (Inspect and Adapt).

Es ermutigt das Delivery-Team, Fortschritte frühzeitig und häufig zu überprüfen, um nicht längere Zeit auf einem Irrweg zu bleiben. Vielleicht kennen Sie das folgende Vergleichsmodell der Risiken bei Agile und Wasserfall bereits.

Die Idee ist, dass das Risiko bei einem Wasserfallprojekt bis zum Ende hoch bleibt. In Agile hingegen wird das Risiko ab in einem frühen Stadium durch laufende Überprüfung und Anpassung ständig verringert.

Risiken in Wasserfall-Projekten und agilen Projekten

 

Das ist jedoch ein sehr optimistisches Bild von Wasserfall. In der Praxis hat dies nur zu oft ein elegantes Versagen in Zeitlupe zur Folge, das auf vorgefassten falschen Meinungen (aka „Anforderungen“) basiert.

Eine strikte Änderungskontrolle deckt den Projektmanager und lässt ihn sogar gut aussehen. Das Ziel ist nicht Mehrwert für den Kunden zu schaffen, sondern einen Plan zu befolgen. Abgehakte Listen, protokollierte Meetings, Entschuldigungen. Nur zu oft endet alles in einem Desaster, und nachdem so lange das Falsche gebaut wurde, ist kein Geld mehr da, um es zu korrigieren. Der Pioniervorteil ist verloren.

Die Deadline-Illusion

Es grenzt an Gotteslästerung in der agilen Welt, aber Deadlines sind im Geschäftsleben nun einmal unumgänglich.

Produktentwicklung kostet Geld, das nicht unbegrenzt vorhanden ist. Zeit ist Geld, und die Stakeholder wollen dafür schnell etwas sehen. Leider ist es eine Tatsache, dass die Deadlines von Software-Projekten fast immer überzogen werden. Mögliche Gründe hierfür sind:

• Die Kunden wollen Ergebnisse immer spätestens bis gestern. Die Konkurrenz droht zuzusagen, also wächst der Druck, eine schnelle Lösung zu versprechen.
• Technische Teams überschätzen oft ihre Fähigkeiten und räumen keine Puffer für Fehler, verlorene Zeit und Unvorhergesehenes ein.
• Sobald etwas Greifbares entsteht, wiegt sich das Team in Sicherheit und glaubt, noch viel Zeit zu haben. Man greift erst ein, wenn die Dinge offensichtlich falsch laufen, aber dann ist es zu spät.

Den Zwängen entfliehen

Wie bricht man also aus Gewohnheiten aus?

Erlauben Sie mir noch eine persönliche Anekdote: Mitte Zwanzig war ich starker Raucher und weigerte mich jahrelang, aufzuhören. Ich konnte mir keine Zukunft als Langweiler und Spaßverderber vorstellen und hatte feste Vorstellungen, wie mein Leben verlaufen würde. Als ich endlich beschloss aufzuhören, war es entsetzlich. Ich fühlte mich, als würde ich sterben. Für den Raucher/Rebell in mir bedeutete es das Ende, und ich konnte mir kein Leben nach dem Tod dieses Selbstbilds vorstellen. Es war eine traumatische Erfahrung, aber ich habe überlebt (offensichtlich), und dieses Versions-Upgrade hat mich ein paar Lektionen fürs Leben gelehrt.

Lektion 1: Es zählt nur was als nächstes passiert
Es war hart, die selbsterfüllende Prophezeiung zu durchbrechen, ich würde immer rauchen. Ich hatte mir mental ein Leben vorgezeichnet, das ich für unvermeidlich hielt.

Leider hat die menschliche Intuition, obwohl sie uns meist gute Dienste leistet, gewisse Systemfehler wie die „Sunk Cost Fallacy“. Wir setzen einen eingeschlagenen Irrweg fort, weil bereits Kosten angefallen sind. Wir glauben, dass wir Pech hatten, aber dass sich das Glück bald wenden werde. Falsch! Geld, das man auf ein Produkt verschwendet hat, ist Sache der Vergangenheit. Jetzt ist der Zeitpunkt, um die Weichen für zukünftigen Erfolg zu stellen.

Viele Produkte sind wie Airbnb das Ergebnis vieler Faktoren, und unterwegs wurden viele Fehler gemacht und mutige Entscheidungen getroffen. Die Analogie ist vielleicht gewagt, aber im Privat- und Geschäftsleben ist nichts vorherbestimmt.

Lektion 2: Wenn man beständig auf etwas hinarbeitet, kommt man wahrscheinlich irgendwann ans Ziel
Nach etwa einem Jahr als Nichtraucher erkannte ich, dass ich nicht mehr ständig an eine Zigarette dachte und auch keine mehr wollte. Das war nur möglich, weil ich am 17. März 2001 um 13:35 Uhr beschlossen hatte, Nichtraucher zu werden. Ein klares Ziel mit einem unklaren Zeitrahmen.

Auch meine Autofahrt hatte ein Ziel (trotz des Umwegs nach Süden). Ohne ein festes Ziel hätte ich endlos über die englischen Autobahnen fahren können – immer unterwegs, ohne je anzukommen. Um nach Lewis Carroll zu sprechen: „Wenn du nicht weißt, wohin du gehst, wird dich jede Straße ans Ziel bringen.“

Agile ist nicht Zufall. Vielmehr ist es aufmerksamer Pragmatismus, der einem hilft, auf dem richtigen Weg zu bleiben. Der Kurs wird ständig korrigiert, aber man hat das Ziel immer fest im Blick.
Anhänger des klassischen Projektmanagement würden sagen, dass man dies auch durch Änderungssteuerung erreichen kann. Doch hierbei werden Änderungen immer als Ausnahmen betrachtet.

Agile kann man sich dagegen als ständige Änderungssteuerung vorstellen. „Änderung“ ist aber eigentlich nicht das richtige Wort, viel mehr geht es um die Akzeptanz von Unsicherheiten.

Ich höre in meinem Beruf immer wieder Delivery-Teams, die sich über geänderte Anforderungen und „Scope Creep“ beklagen. Meistens hatte der Kunde die Anforderungen aber gar nicht geändert. Vielmehr waren ihm im Laufe der Zeit und nach näherer Betrachtung die Auswirkungen seiner vagen Wünsche immer klarer geworden.

Lektion 3: Angst führt zu Ärger
Nach den Worten des großen Business-Philosophen Meister Yoda: „Angst erzeugt Negativität, Negativität führt zu Trägheit, Trägheit verschlechtert die Quartalsergebnisse.“

In Wahrheit hat man nichts wirklich unter Kontrolle, egal wie viel man plant. Angst ist unproduktiv.

Was kann im schlimmsten Fall passieren? Sie könnten Ihren Job verlieren? Wenn dies das Worst-Case-Szenario ist, fragen Sie sich einfach: „Wenn ich mich hier nicht wohl fühle, wegen des beschränkten Denkens, mangelndem Vertrauen und systemischer Angst, warum gehe ich dann nicht?“

Natürlich kann man nicht ständig die Arbeitsstelle wechseln. Wie kann man also der Deadline-Illusion und den Kontroll-Freaks entkommen?

Immer daran denken: Auch Stakeholder bekommen Angst. Die meisten verstehen Agile nicht und erwarten einen linearen Fortschritt, wie beim Bau eines Hauses. Aber die Schaffung eines neuen Produktes ist viel weniger vorhersagbar als der Bau eines Hauses, und man muss verstehen, wie sich die Zuversicht der Stakeholder im Laufe der Zeit wandelt.

Vertrauen der Stakeholder im Projektverlauf

Bei Wasserfall wird das Vertrauen zum Release-Zeitpunkt entweder wiederhergestellt oder vollständig zerstört, abhängig davon, ob das Produkt die Erwartungen erfüllt.

Bei Agile ist das Vertrauen vielleicht durch die ersten unvollständigen Produktphasen zunächst getrübt. Doch so lange das Delivery-Team Feedback annimmt, wächst das Vertrauen in dem Maße, in dem folgende Iterationen einem marktfähigen Produkt immer näher kommen.

Ein Plan ist kein Ziel, sondern Werkzeug – sogar ein recht flexibles

Baut man ein Unternehmen und benötigt man Software für ein neues Produkt, hat man sicher bereits bestimmte Vorstellungen. Außerdem braucht man die Zusage des Produktteams, dass es in einer angemessenen Zeit innerhalb des Budgets gebaut werden kann.

Wie setzt man also die drei Eckpfeiler Umfang/Ressourcen/Zeit fest?

Traditionell würde man zunächst einige Zeit lang die Anforderungen detailliert analysieren, das Ergebnis genau planen, Prognosen anstellen, eine Marge aufschlagen und einen Änderungsmanagementprozess hinzufügen. Müssen Zeitrahmen und Kosten relativ zuverlässig angegeben werden, erfordert dies oft einen viel längeren Zeitrahmen. Gleichzeitig steigt die Gefahr, dass die Lösung am Ende den Anforderungen nicht mehr gerecht wird, die im Projektverlauf neu hinzugekommen sind oder sich geändert haben.

Agile ist kein Allheilmittel. Planen Sie nicht über einen Sprint hinaus! Orientieren Sie sich immer wieder neu! Priorisieren Sie alles. Radikal! Es kommt, wie es kommt! Fanatiker werden jede Diskussion über Roadmaps, Planung oder Strategie niederschreien.

Natürlich ist das keine ernst zu nehmende Unternehmensstrategie (sollte man zumindest meinen). Unternehmen funktionieren, weil jemand eine Vision hatte und diese energisch und hartnäckig gegen alle Widerstände verfolgt hat. Der Gründer oder Unternehmensleiter versucht sein Glück und übernimmt die Verantwortung für seine Idee. Agile ist eine gute Möglichkeit für Richtungswechsel in Details oder Durchführung. Aber wenn die große Idee fehlschlägt, kann dies das Ende für das Unternehmen bedeuten.

Entspannen Sie sich, nichts ist unter Kontrolle.

Um mit einer Zen-ähnlichen Platitüde zu enden…

Hüten Sie sich davor zu glauben, Sie könnten die Zukunft eines Produkts planen.

Lernen Sie, die Realität des aktuellen Sprint zu akzeptieren. Schätzen Sie seinen wirtschaftlichem Nutzen.
Und trösten Sie sich damit, dass Ihre Karriere nicht mit dem Projekt steht und fällt. Schaffen Sie Nutzen, dann wird sich der Chef auch wieder beruhigen.

Der Autor
Aidan Dunphy ist Senior Consultant bei Product Focus.

Er war bereits Head of Product, Product Director und Chief Product Officer bei Technologieanbietern und digitalen Agenturen in verschiedenen Branchen.
Aidan Dunphy verfügt über umfassende Erfahrungen im gesamten Software-Lebenszyklus, einschließlich Startups, Scaleups und der Steuerung reifer Produktportfolios.

Share this page

Kommentar schreiben

Your email address will not be published. Required fields are marked *