Wasserfall, Agilität, Hybrid – völlig egal

Die 10 Gebote der Vorgehensmodelle

In Unternehmen werden Projekte in drei Varianten organisiert. Traditionelles Vorgehen (Wasserfall), agiles Vorgehen oder eine Mischform, ich nenne sie hier hybrid. Alle Modelle haben so ihre typischen Probleme. Alle Modelle haben aber auch ihre Daseinsberechtigung. Es gibt kein „Schlecht“, sondern ein «besser geeignet» oder «weniger geeignet», je nach Situation, in der sich die Organisation befindet. Es misslingen sowohl traditionell als auch agil oder hybrid geführte Projekte. Wichtig ist, dass man unabhängig vom eingesetzten Modell einige Geboten beherzigt.

Variante Wasserfall

Der Wasserfall und seine typischen, festgelegten Strukturen und Vorgehensweisen sind in allen Bereichen eines Unternehmens fest verankert. Da sind die typischen organisatorischen Strukturen, wie die Aufteilung in Fach-Abteilungen, und typische Rollen wie Projektleiter oder Testmanager sowie die klassische Vorgehensweise in aufeinander aufbauenden Phasen, die erst beendet sein müssen, bevor die nächste startet. Vorausgedacht, fest geplant und budgetiert.

Variante Agilität

Dann das agile Vorgehen, ob Scrum, KANBAN oder etwas Anderes, ist unwesentlich. Viele Prinzipien hier sind denen des Wasserfalls entgegengesetzt, kurze Zyklen, sich erst nach und nach schärfende Vorgaben, mehr Entscheidungsbefugnisse beim Team und neue Rollen. Um nur ein paar der wichtigsten Unterschiede zu nennen.

Vom Wasserfall zur Agilität ist ein oft harter Weg, in den meisten Unternehmen wurde er (noch) nicht bis zu Ende gegangen. Denn wie weit soll mit der Erneuerung gegangen werden? Wie weit die Organisation umstellen, z.B. einem Projektleiter mitteilen, dass seine Rolle nicht mehr benötigt wird. Die Mitglieder einer Abteilung in agile Teams aufteilen, was passiert mit dem Abteilungsleiter. Keine im Vorfeld durchgeplanten Projekte mehr, Interaktion und dynamische Wertschöpfung statt Formalismus.

Vielleicht befindet man sich auch in einer digitalen Transformation, Aufbrechen alter Kompetenzsilos, hin zu schlagkräftigen Teams über alte Fachgrenzen hinweg. Oder die Organisation wird aktuell an die DevOps-Prozesse angepasst. Auch hier finden Umstrukturierungen statt.

Variante Hybrid

Aus welchem Grund auch immer, in den Projekten befinde ich mich als Consultant meistens in einem Zustand, in dem eine Umstrukturierung bisher nur teilweise vorgenommen wurde. Meistens nur in der IT-Abteilung, wo Entwickler-Teams zu agilen Teams umgeformt werden. Die Vorgaben wie Zeitrahmen und Milestones bleiben aber wie bisher detailliert vorgeplant und vorgegeben. Wir haben es in diesen Fällen mit einem hybriden Modell zu tun, einem Zustand, in dem traditionelles Vorgehen und agile Ansätze gleichzeitig existieren. «Hybrid» ist allerdings kein definiertes Modell.

Wie auch bei Wasserfall und Agilität, sieht es bezüglich hybriden Modellen in jedem Unternehmen anders aus, je nach Ausgangssituation und Anpassungen. Man muss sich ausserdem bewusst sein, dass sich in einem Hybrid-Umfeld zum einen neue Risiken auftun, zum anderen bekannte Risiken ein höheres Gewicht bekommen.

Die 10 Gebote

Er wurde viel organisiert, viel neu gemacht, aber egal welches Modell im Unternehmen angewandt wird, traditionell, agile oder hybrid, immer noch geraten Projekte in Schieflage. Hauptgrund: wesentliche Punkte werden immer wieder vergessen oder vernachlässigt. Vielleicht sind sie die Bäume, die man wegen des Waldes nicht sieht. Ich nenne sie die 10 Gebote:

1. Klare unzweideutige Rollen, Verantwortlichkeiten und Prozesse definieren.
   Es kommt des Öfteren vor, dass man von Einem zum anderen geschickt wird, weil eine klare Zuständigkeit fehlt. Es gibt oft keinen «Head of» zu einem Thema, keine Übersicht, keinen Verantwortlichen. Und, genauso wichtig, es muss für jede Rolle einen Stellvertreter geben. Dieser Stellvertreter muss auch willens und vor allem fähig sein, Entscheidungen zu fällen. Allzu oft ist er nur pro forma ernannt.
   
2. Verhindern von sich überschneidenden Rollen.
   Meistens existieren die Rollen Projektleiter und Product Owner nebeneinander, ohne dass ihre jeweiligen Aufgaben aufeinander abgestimmt sind. Stattdessen haben sie sich von den Aufgaben her überschneidende Rollen. Wenn das nicht verhindert werden kann oder keine klare Rollen- und Aufgabeverteilung erstellt werden kann, ist es ein unabdingbares Muss, dass beide sich austauschen. Mindestens jede Woche und immer, wenn strategische Entscheidungen anstehen. Das gilt übrigens auch, wenn alles prima läuft, oder es zumindest so aussieht.
3. Klare Definition des Go-Live erstellen.
   Wasserfall vs. Agilität bedeutet ein grosses Release vs. mehrere minor Releases bzw. continuous Delivery. Agilität ist nicht für Big-Bang-Releases konzipiert. Marketing und Vertrieb hingegen setzen aber noch immer gern auf grössere stabile Releases. Ungeachtet dessen, welches Vorgehensmodell verwendet wird, es gibt fast immer Unvereinbarkeiten zwischen Marketing bzw. Vertrieb und der IT. Im agilen und hybriden Modell wäre es eine Möglichkeit, die sprintweise Auslieferungen in die Produktion als minor Release in die Wasserfall-Release-Strategie zu integrieren. Im traditionellen Modell sollte man die Grösse des Go-Live zwischen IT und Marketing bzw. Vertrieb genau abstimmen.
4. Coaching einholen.
   Sollte die Firma, das Team, der Projektleiter, der Scrum Master oder der Product Owner keine Erfahrung mit dem hybriden Modell oder die agilen Vorgehensweise haben, sollte man sich coachen lassen. Aber auch im traditionellen Vorgehen sind (Test)Prozesse, Rollen, Definitionen und das Zusammenspiel zwischen Anforderungsdefinition, Entwicklung und Test nicht immer optimal organisiert. Probleme entstehen vor allem dann, wenn man auf eine neutrale Sicht verzichtet oder Unwissenheit mit Aktionismus kaschiert. Nebenbei könnte diese neutrale Person auch als Schlichter in allfälligen Ansichtsdiskrepanzen auftreten.
5. Kompromisse eingehen.
   Beinharte Vertreter der reinen Lehre führen sehr oft Projekte in Schwierigkeiten. Beispielsweise soll der eine nicht auf sturer Definition der Vorgaben beharren, der andere nicht die bedingungslose Unabhängigkeit des Teams verteidigen.
6. Erfolg messen.
   Eine grosse Frage ist die nach dem Erfolg von Sprint, Release und Projekt. Wie wollen wir diese objektiv messen? Öfters ist der Grund für Unstimmigkeiten der Leitsatz aus dem agilen Manifest «Individuen und Interaktionen statt Prozesse und Werkzeuge». Das bedeutet, dass im Wasserfall genau vorgegeben werden «WAS wird umgesetzt» und «WIE wird es umgesetzt». Im agilen dagegen immer nur ein bisschen „WAS“ und so gut wie kein «WIE».
   Im Wasserfall wird das Team dann an der Erreichung der vorgegebenen Ziele gemessen. Dies ist grundsätzlich eine objektive Messung, vernachlässigt aber die Zufriedenheit des Kunden. Im agilen wird das Team an der Kundenzufriedenheit gemessen, was eher eine subjektive Messung ist.Im hybriden Modell haben wir aber einen Zielkonflikt zwischen Erreichen-der-Vorgaben und Erreichte-Kundenzufriedenheit. Ein möglicher Lösungsansatz wäre, zu Beginn weiterhin genaue Vorgaben des «WAS wird umgesetzt», der Erfolg wird aber nicht erst am Projektende gemessen, sondern im Rhythmus der Sprints, genauer: bei den Demos. Hier wird dann entschieden, ob das Vorgehen der agilen Teams und/oder die Zielvorgaben angepasst werden müssen, je nach Zufriedenheit und aktuellen Bedürfnissen des Kunden.
7. Aufbau einer Testkultur.
   Um eine konsequent hohe Qualität zu gewährleisten, darf ein Qualitätsanspruch nicht temporär an ein Projekt gebunden sein, sondern muss im Unternehmen ständig gelebt werden. Testen darf nicht als notwendiges Übel betrachtet werden, sondern als einer der Grundpfeiler des Qualitätsanspruchs. Dazu gehören:

   - Ein etablierter Testprozess

   - Den Ruf des Testing verbessern

   - Einbeziehen der Tester in die Anforderungs- oder User Story Definition («Power of Three» oder das «Tres Amigos» Konzept)

   - Schaffen notwendiger Test-Strukturen, damit nicht ständig gefragt werden muss: «wer macht das eigentlich»

   - Ausbildung

8. Eine klare Dokumentationstruktur.
   Der Aufbau einer projekt- und personen-unabhängigen, fachlich-logisch aufgebauten Dokumentationsstruktur ist zwingend. Jeder sollte leicht auf relevante Dokumente zugreifen können, die Suche sollte intuitiv zum Ziel führen. Stichwort Confluence, wo schon recht schnell ein unübersichtlicher Wirrwarr von Dokumenten und Projekten entsteht
9. Konsequent Lessons Learned durchführen.
   Eine kontinuierliche Qualitätsverbesserung kann nur entstehen, wenn Lessons Learned konsequent und richtig durchgeführt werden. Und dies unabhängig vom verwendeten Vorgehensmodell. Aus Lessons Learned sollten Tasks entstehen, die umgesetzt werden müssen. Periodisch sollte die Effektivität der Umsetzung kontrolliert und wenn notwendig angepasst werden. Nur so ist man in der Lage, eine nachhaltige kontinuierliche Verbesserung zu initiieren.
   
10. Initiieren einer Fehlerkultur.
    Ein abschliessender Punkt liegt mir sehr am Herzen, ein Dauerthema. Die «Suche des Schuldigen». Da droht ein möglicher menschlicher Fehler, und die erste Reaktion? «Das liegt nicht an mir, sondern ...» Warum haben Menschen Angst vor Fehlern? Fehler dürfen gemacht werden, ja sie müssen gemacht werden. Warum? Weil man dann lernen kann, wie es besser geht. Und das ist der Punkt, macht Fehler, aber lernt daraus. Daher ist es sehr wichtig, ein Klima des Problemlösens zu haben und nicht ein Klima des verkrampften Fehlervermeidens.
    

Das perfekte Vorgehensmodell

Leider, diese 10 Gebote zu beherzigen heisst nicht zu garantieren, dass keine Probleme auftauchen oder dass das perfekt abgestimmte Vorgehensmodell entsteht. Es minimiert nur das Risiko, dass Probleme auftauchen.

Man könnte sich jetzt die Frage stellen, wie dann das perfekte Vorgehensmodell aussieht.

Ganz einfach, eine IT-Welt, in der der Fokus wieder auf dem Produkt liegt und nicht mehr auf dem Sieg im Kampf um das Vorgehensmodell. Jedes Modell hat seine Stärken und Schwächen. Das Modell muss zum Produkt passen, nicht zu einer Person oder modischen Strömungen. Eine Welt, in der die wesentlichen und eigentlich selbstverständlichen Grundregeln eingehalten werden. In der das berücksichtigt wird, was seit gefühlter Ewigkeit immer wieder in den „Lessons learned“ auftaucht.

Selten, eigentlich nirgends sonst, ist die Einhaltung von 10 Geboten so einfach. Und wird derart belohnt ...

Wenn Sie Fragen zu Vorgehensmodellen oder momentan Probleme mit dem in ihrer Organisation implementierten Vorgehensmodell haben, dann nehmen Sie doch bitte Kontakt mit uns auf. Wir helfen Ihnen gerne weiter oder stehen Ihnen als neutrale Person zur Verfügung.