Welches Projektvorgehen passt zu meinem IT-Projekt? (inkl. Selbsttest)

Wenn man sich in der IT-Branche ein wenig umhört, kommt man nicht daran vorbei: Agilität ist in aller Munde. Es soll viel besser sein, sein Projektvorgehen agil zu gestalten, als mit einem Wasserfall. Stimmt das? Scheitern agile Projekte nicht? Die Antwort ist ein klares Jein.

Wasserfallprojekte kennt jeder. Das Projekt startet, man spezifiziert die Anforderungen, es wird entwickelt, um dann am Ende zu sehen, dass das, was man geliefert bekommt, nicht unbedingt dem entspricht, dass man sich vorgestellt hat. Trotzdem werden Softwareprojekte immer wieder als Wasserfall abgewickelt. Man kann sich jetzt fragen, warum das so ist. Wasserfallprojekte geben eine Sicherheit, die aber höchstens eine gefühlte Sicherheit ist. Man unterliegt der Illusion, dass man von Beginn an weiß, was man bekommt und wieviel man dafür bezahlt.

Agile Projekte vermitteln dem Unerfahrenen hingegen Unsicherheit. Man glaubt nicht zu wissen, was man am Ende hat. Man weiß auch nicht so recht, was es kosten wird. Die Realität zeigt uns aber, dass man das beim Wasserfall eigentlich auch nicht weiß. Der Scope verändert sich in jedem Wasserfallprojekt – Reizwort Change Request. Bei agilen Projekten werden nicht zu Beginn gleich alle Anforderungen definiert, sondern im Laufe des Projekts sukzessive ergänzt. Das bedeutet aber auch nicht, dass agile Projekte ziellos sind. Das Gegenteil ist der Fall: Agile Projekte folgen zu jeder Zeit immer der zu Projektstart definierten Produktvision. Man weiß also in welche Richtung man will und wo man am Ende stehen möchte.

Agil arbeiten ist eine Änderung des Mindsets und nicht bloß die Einführung eines neuen Prozesses. Im Rückschluss bedeutet das aber, dass eine Umstellung auf agile Arbeitsmethoden einen Change Prozess im Unternehmen auslöst, den nicht jedes Unternehmen bereit ist einzugehen. Agil zu werden ist für eine Organisation anstrengend. Umso schlimmer, wenn das Projekt dann trotzdem fehlschlägt.

Durch unsere Projekterfahrung kennen wir die Schwachstellen des Wasserfalls. Um diese weitgehend zu minimieren haben wir einen hybriden Projektansatz entwickelt. In den Grundzügen folgt dieser dem Wasserfall-Modell. Jedoch haben wir an verschiedenen Stellen Methoden aus der agilen Welt ausgeborgt, um die gefährlichsten Schwachstellen zu kompensieren. Mit dieser Kombination beider Welten stellen wir sicher, dass wir nicht nur das Richtige machen, sondern es auch richtig machen.

Schwerpunkt des hybriden Ansatzes ist, so früh wie möglich vom Kunden Feedback zu den umgesetzten Funktionen zu bekommen. Dies erreichen wir durch kürzere Releasezyklen während der Implementierungsphase des Projekts. Unsere Kunden können so – im Gegensatz zu einem klassischen Wasserfallmodell – sehr früh sehen, was sie bekommen und dies bereits auch testen. Dadurch steigt im weiteren Verlauf des Projekts auch die Kompetenz des Kunden im neuen System, womit die Formulierung der Anforderungen auch an Qualität gewinnt. Wir als Umsetzungspartner bekommen wiederum schnell Feedback zur Qualität unserer Entwicklungen. Aber wir sehen auch, ob wir unseren Kunden richtig verstanden haben.

Der hybride Ansatz erhöht auch die Kommunikation der Projektpartner, was sich positiv auf den Projektverlauf und die Zusammenarbeit auswirkt. Viele Projekte scheitern an zu wenig oder falscher Kommunikation. Diese Schwachstellen können wir mit dem hybriden Ansatz kompensieren.

Es gibt kein Projektvorgehen als Allheilmittel. Vielmehr geht es darum, das passende Vorgehen zu finden und sich nicht davor zu scheuen neue Wege zu gehen, wenn die Alten nicht zum Erfolg geführt haben.