Es müssen nicht immer 100 % sein. Wie agile Tools auch in klassischen Projekten verwendet werden können.

Man hört es immer wieder: „Projekte können nicht komplett agil durchführt werden! Es gibt immer nicht agile Teile. Das Beste ist, man macht hybride Projekte.“ Ab wann ist ein Projekt ein hybrides? Gibt es überhaupt hybride Projekte?

Was heißt hybrid?

Ganz ehrlich, ich persönlich finde den Begriff hybrid nicht besonders gut. Es ist einfach nicht klar definiert, was es bedeutet. Aktuell ist der Konsens, dass ein hybrides Projekt Methoden und Tools aus beiden Welten nutzt. Also, ist ein agiles Projekt vielleicht doch ein Hybrid, wenn eine Risikoliste erstellt wird? Ist es dann überhaupt noch agiles Vorgehen? Ist ein klassisches Projekt ein Hybrides, wenn man Daily Standup etabliert? Tja, was jetzt?
Ich mag den Begriff einfach nicht. Was ich hingegen gerne mache, sind Tools und Methoden aus beiden Welten zu mischen.
 

Ich bin derzeit Projekt Manager in einem großen internationalen ERP-Projekt. COSMO CONSULT ist Subunternehmen und daher nur für einen bestimmten Teil des Projekts verantwortlich. Das Projekt wird nach der Wasserfallmethode durchgeführt. Die erste Phase des Projekts – Analyse und Design – ist abgeschlossen und die Entwicklungsphase startet gerade. 

In der ersten Phase kamen agile Methoden zum Einsatz. Es gab regelmäßig – wenn auch nicht täglich – ein Daily Standup, damit alle Beteiligten sich synchronisieren konnten. Das hat hervorragend funktioniert und war jedenfalls effizienter als klassische Statusmeetings. Zu den Standups kamen und kommen alle zusammen. Generalunternehmer und Subunternehmer. So erhält jeder einen Überblick über die Aktivitäten im Projekt, Probleme werden durch die Projektmanager schnell gesehen und sie können entsprechend effizient reagieren. Das Projekt ist aber durch die Durchführung von Daily Standups definitiv kein agiles Projekt geworden.

Die Entwicklungsphase wurde in Iterationen aufgeteilt, an deren Ende ein Release des Systems erfolgt. Das ist ebenfalls eine agile Methode. Was unser Team betrifft, wenden wir weiterhin unsere agile Projektmethodik an. Wir folgen so weit wie möglich den agilen Werten. Das Projekt wird dennoch nach dem Wasserfallmodell durchgeführt. Auch dadurch ist das Projekt defintiv kein agiles Projekt. Ist es ein hybrides Projekt? Lassen wir die Frage so stehen. Antworten wird es wahrscheinlich keine befriedigenden geben.
Wie auch immer man es nennen möchte, was geschehen ist, war ein Reduzieren von Risiken, die das Wasserfallmodell mit sich bringt - und um das geht es in der Regel. Risiken des einen Modells, durch Tools und Methoden des anderen Modells zu mitigieren. Auf das kommt es an, nicht auf den Begriff.

Der geneigte Leser wird sich jetzt wahrscheinlich folgendes Denken: „Alle?“ Auf jeden Fall. Jedes agile Tool ist sinnvoll in klassischen Projekten einsetzbar und das eigentlich komplett unbedenklich. Im besten Fall wird das klassische Projekt zu einem Agilen. Im schlimmsten Fall, profitiert es von den agilen Tools. Zum Beispiel sind regelmäßige Retrospektiven tausend mal effizienter und effektiver als eine Lessons Learned Session am Ende des Projekts.

Auch ein Sprint (Iteration) Planning Meeting ist sinnvoll. Auch wenn der Scope schon vorgegeben ist, ist diese Planung realistischer. Ebenso das Unterteilen von Anforderungsdokumenten in User Stories macht die Umsetzung der Anforderungen effizienter und besser. Der Einsatz von klassischen Methoden in agilen Projekten hingegen, sollte vorsichtig erfolgen. Tools wie Risikolisten sind sicher sinnvoll. Ein detaillierter Zeitplan widerum ist nicht nur unnötig, sondern schadet einem agilen Projekt. 

Eines möchte ich an dieser Stelle ganz klar darstellen, weil ich schon die Kritiker höre, die sagen, agile Projekte brauchen Projektmanagement. Ja, das brauchen sie und das haben sie auch, es ist nur anders geartet. In weiten Teilen ist es auch genauer, aber was agile Projekte nicht brauchen, ist klassisches Projektmangement. Das passt nicht zusammen.