Wie Saboteure agile Projekte abschießen

Der Projektleiter fühlt sich degradiert, die Fachabteilung lehnt das Projekt ab, die Entwickler haben keine Lust auf Agilität: agile Entwicklungsprojekte können viele Gegner haben. Avision zeigt auf, wie sie vorgehen, um ein Projekt zu kippen. [...]

„Das kleine Handbuch für den Projektsaboteur“ ist inzwischen eine Art Klassiker. Kein Wunder, demonstriert es doch anschaulich, wie Projekte von ihren Gegnern manipuliert werden – und gibt Unternehmen damit eine Art Gebrauchsanweisung an die Hand, um sich davor zu schützen. Dabei bezieht sich das Buch allerdings ausschließlich auf das klassische Projektmanagement. Doch was hier gilt, gilt auch für agile Softwareprojekte: Oft gibt es Akteure, denen das Projekt ein Dorn im Auge ist und die deshalb höchst daran interessiert sind, dass es gegen die Wand fährt.

Das kann das Management der Fach- oder IT-Abteilung sein, dem vom Top-Management oder dem Betriebsrat des Unternehmens ein Projekt aufs Auge gedrückt wurde, dass sie eigentlich gar nicht umsetzen möchten. Oder der bisherige Projektleiter hat durch den Umstieg auf agile Methoden die neue Rolle des Product Owner erhalten, fühlt sich dadurch degradiert und fürchtet einen Machtverlust. Aber auch Entwickler können agile Methoden per se oder das konkrete Projekt als solches ablehnen.

Handelt es sich bei dem Projekt um die Modernisierung einer Legacy-Software, wächst der Kreis der Verdächtigen weiter an. Personen, die mit der Anwendung seit Jahren oder vielleicht sogar Jahrzehnten arbeiten, haben dadurch im Lauf der Zeit oft Exklusivwissen angehäuft und sich einen Expertenstatus im Unternehmen aufgebaut; und darauf will nicht unbedingt jeder einfach wieder verzichten.

Avision, Spezialist für Software Revivals, zeigt auf, wie diese Akteure vorgehen, um ein agiles Projekt abzuschießen:

Management

Ein sicherer Weg für das Management einer Fach- oder IT-Abteilung ist, zusätzlich zum Product Owner und Scrum Master einen Projektleiter zu installieren, obwohl diese Rolle gar nicht mehr vorgesehen ist. Um ganz sicher zu gehen, wählen sie dafür ein möglichst dominantes Alphatier aus und grenzen seine Aufgaben gegenüber Product Owner und Scrum Master so unscharf wie möglich ab. Dadurch ist Unordnung vorprogrammiert – und damit auch das Ende eines erfolgreichen agilen Projekts, bevor es überhaupt richtig angefangen hat.

Product Owner

Will er das Projekt sabotieren, hat es für ihn oberste Priorität, dass die Entwicklungssprints keine zufriedenstellenden Ergebnisse liefern. Das kann er unter anderem so erreichen: sich bewusst vor wichtigen Entscheidungen drücken; gestartete Sprints nicht laufen lassen, sondern sich einmischen und kurzfristige Änderungen verlangen; oder ständig auf immer detailliertere Dokumentationen bestehen. Die Tatsache, dass Scrum dem Product Owner keine Anwesenheitspflicht für Meetings auferlegt, lässt sich prima dafür missbrauchen, einige Zeit abzutauchen; nur um dann hinterher zu sagen: „So hab’ ich mir das aber nicht vorgestellt.“

Entwickler

Einer der effektivsten Hebel für die Entwickler, ein agiles Projekt zu kippen, ist die Schätzung der Story Points, die pro Sprint umgesetzt werden, da sich daraus die Geschwindigkeit eines Sprints ergibt. Werden diese Story Points vor dem ersten Sprint bewusst hoch angesetzt und in den folgenden Sprints immer niedriger, sieht es so aus, als ob die Geschwindigkeit kontinuierlich abnimmt; und beim Management muss zwangsläufig der Eindruck entstehen, dass das Projekt in Schieflage gerät.

Fachabteilung

Für das Backlog, das die zu erledigenden Aufgaben enthält, ist zwar nominell der Product Owner zuständig. Über ihn hat die Fachabteilung aber die Möglichkeit, dort absichtlich immer mehr fachliche Anforderungen einfließen zu lassen. Dasselbe gilt übrigens auch für die Entwickler und ihre technischen Anforderungen. So oder so wächst die Zahl der Backlog-Items dann kontinuierlich an, statt zurückzugehen. Damit lässt sich dem Management signalisieren, dass das Projekt komplett aus dem Ruder läuft und gegen die Wand fahren wird.

„Diese Tricks erheben natürlich keinen Anspruch auf Vollständigkeit. Will jemand ein agiles Projekt scheitern lassen, kann er dafür viele Ansatzpunkte finden“, sagt Nadine Riederer, CEO bei Avision. „Um mögliche Motive für eine Projektsabotage abzuschwächen, sollten Unternehmen sämtliche Beteiligte von Anfang an einbinden und ihnen Perspektiven aufzeigen. Ist erkennbar, dass jemand ein Projekt partout nicht unterstützen möchte, hilft alles nichts: er muss dann davon ferngehalten werden. Nur wer eine Rolle in einem Projekt innehat, kann es auch sabotieren.“