Agile Starthilfe für Konzern IT´s – Warum die agile Transformation im Unternehmen gar nicht so leicht ist

Studien zur Verbreitung agiler Methoden^[1] haben ergeben, dass sich agiles Projektmanagement in den Unternehmen immer mehr durchsetzt. Aus IT Abteilungen von Konzernen wird uns in letzter Zeit sogar berichtet, dass sie inzwischen alle IT-Projekte agil abwickeln müssen. Gleichzeitig tut sich die Konzern IT schwer, ihre Softwareprojekte flächendeckend auf agil umzustellen. Wir beobachten das mitunter daran, dass wir gerade jetzt vermehrt Anfragen nach „agilen Starterpaketen“ für Softwareprojekte erhalten. Warum ist das so?

Auf Anweisung agil – Warum eigentlich?

Zunächst stellt sich die Frage, warum der Konzern IT das agile Vorgehen auf einmal „verordnet“ wird. Sind mögliche Einsparungen bei den IT-Kosten der Treiber hinter dieser Anweisung? Wird eine frühere Time-to-Market für die Projektergebnisse erwartet? Oder ist es eher die höhere Erfolgsquote eines agilen Projektes, die zu dieser Neuausrichtung führt? Wie eine Studie der deutschen Gesellschaft für Projektmanagement (GPM) herausgefunden hat, schätzen agile Unternehmen die Erfolgsquote ihrer Projekte deutlich höher ein als Unternehmen, die mit klassischem Projektmanagement unterwegs sind. Vielleicht liegen die Gründe aber auch in höheren Anforderungen an die Innovationsfähigkeit der Fachbereiche und der IT, um Marktanteile langfristig zu sichern?

Tatsächlich sind agile Projekte „nicht billiger“. Die zu leistende Arbeit wird durch agile Ansätze nicht weniger. Sie wird besser verteilt und transparenter. Durch eine agile Starthilfe kann das gefördert werden. Die frühere Time-to-Market des Projektergebnisses ist schon eher ein Faktor. Dabei wird ein agiles Projekt auch „nicht schneller“, als ein anderes. Es ist die „bessere Qualität“ der Ergebnisse, die in höherem Maß mit den Kundenanforderungen übereinstimmen. Dieser Effekt vergrößert sich, je komplexer die Aufgabenstellung ist. Und damit kommen wir zur Steigerung der Innovationsfähigkeit. Agile Methoden eignen sich ganz besonders dann, wenn es darum geht, Neuland zu betreten. Risiken werden durch den iterativen Ansatz und den hohen Lerneffekt früher erkannt und Chancen können besser genutzt werden. Eine gute Spielwiese zum Ausprobieren innovativer Ideen.

Agiles Vorgehen in einem Projekt basiert auf Vertrauen, Kooperation und Selbstorganisation. Alle drei Faktoren sind notwendig, weil eines allen agilen Projekten gemeinsam ist: Der Scope lässt sich am Anfang des Projektes nie so exakt spezifizieren, dass er bis zum Ende des Projektes unumstößlich stabil bleibt. Das betrifft insbesondere die Art und Weise der Umsetzung. Software bietet so viele Möglichkeiten, schnell und günstig auf Veränderungen zu reagieren oder neue Chancen durch alternative Lösungswege zu nutzen, dass „der Appetit oftmals mit dem Essen kommt“.

Dagegen stehen die wirtschaftlichen Interessen von Einkäufer und Anbieter. Der Einkauf strebt nach voller Kostenkontrolle. Festpreisverträge scheinen das Mittel der Wahl. Damit wird allerdings das Risiko komplexer, agiler Projekte voll auf den Anbieter verlagert. Dagegen strebt der Anbieter volle Flexibilität an. Mit Time and Material Verträgen wird aber das Risiko voll auf den Auftraggeber verlagert. Deshalb sollte auch in der Vertragsgestaltung ein hohes Maß an Kooperation und Vertrauen eingebaut werden. Von Anfang an definierte Ausstiegspunkte für beide Seiten, oder Rahmenverträge mit einer Bandbereite und „releaseweiser“ Beauftragung sind gute Möglichkeiten für faire kooperative Verträge.

Viel zu oft wird aber bei der Verordnung agiler Vorgehensweisen der Einkauf nicht mit ins Boot geholt. Und so kommt es zu agilen Projekten im Festpreiskorsett. Der Bewegungsspielraum des Projektteams wird damit extrem eingeschränkt. Das einzige Erfolgsrezept in einer solchen Konstellation ist Erwartungsmanagement von Anfang an und das Ausnutzen kleinster Spielräume. Die Rollen des Scrum Masters und des Product Owners erfordern dafür starke Projektmanagement-Qualitäten.

Agile Starthilfe zur Vermeidung unglücklicher Product Owner

 
In zahlreichen agilen Projekten beobachten wir, dass die Fachbereiche über agile Projekte oft gar nicht so glücklich sind. Zwar schätzen sie die guten Ergebnisse und die Transparenz, aber sie sind es nicht gewohnt, so intensiv und kontinuierlich an den Projekten mitzuarbeiten. Wenn sie die Product Owner Rolle ausfüllen sollen, fehlt ihnen oft die Kenntnis darüber, wie sie User Stories schneiden sollen oder was es mit der Bewertung des Business Value auf sich hat. Neulich erreichte mich ein Hilferuf einer Geschäftspartnerin: „Wir haben kürzlich auf Scrum umgestellt. Die IT ist glücklich damit. Aber irgendwie kommen wir Product Owner noch nicht klar damit. Könnt ihr uns bitte helfen, unsere Produkte „zu ownen“?“ Aus dem Hilferuf wird deutlich, was passiert wenn sich die Umstellung auf agil auf die IT-Abteilung beschränkt. Die Product Owner fühlen sich abgehängt und können nicht mit den Anforderungen umgehen, die ein agiles Projekt an sie stellt. Gleichzeitig befürchtet die IT, dass die Product Owner ihnen ihre neugeformten Prozesse durcheinander bringen. Dann passiert das, was in einem agilen Projekt eigentlich nicht passieren darf: Es entstehen unsichtbare Mauern zwischen Fachbereich und IT. Das Projekt ist damit zum Scheitern verurteilt.

In einigen Konzernen wird mit „agilen Starthilfe Paketen“ für neue agile Projekte gegengesteuert. Neben einer Basisschulung enthalten solche Pakete die Begleitung durch einen Projektcoach beim Projekt Setup und in den ersten beiden Sprints. Eine gute Idee, um Fachbereich und IT gemeinsam den agilen Start zu ermöglichen.

Es gibt viele gute Gründe für Konzerne, ihre IT-Projekte auf eine agile Vorgehensweise wie Scrum umzustellen. Wenn sich die Einführung agiler Arbeitsweisen auf die IT-Abteilungen beschränkt, werden sie sich allerdings sehr schwer bei der Umsetzung tun. Ideale Voraussetzungen für eine erfolgreiche flächendeckende Einführung agiler Methoden sind gegeben wenn:

• der Einkauf in der Vertragsgestaltung mit dem IT-Dienstleister bereits agile Strukturen umsetzt
• die Fachabteilung befähigt wird, ihre Rolle des Product Owners auszuführen
• in agilen Projekten bereits bei der Initialisierung eine vertrauensvolle Kommunikation zwischen Team, Product Owner und Scrum Master aufgebaut wird.

Quellen:

^[1] https://www.gpm-ipma.de/fileadmin/user_upload/Know-How/studien/Studie_Agiles-PM_web.pdf