Agile Software-Entwicklung braucht auch ein agiles Projektmanagement

Zwischen Projektmanagement und Projektkultur

Reine Anpassung etablierter Projektmanagement-Standards reicht nicht aus

Dieser grundlegende kulturelle Unterschied zwischen beiden Systemen ist den Unternehmen durchaus bekannt. Inzwischen setzen sich deshalb Standardisierungsarbeitsgruppen im Bereich Projektmanagement damit auseinander, die gegensätzlichen Ansätze miteinander zu vereinbaren. Es gibt Versuche, agile Ansätze mit den bestehenden Standards zu verzahnen, bis hin zur Zertifizierung als "PMI Agile Certified Practitioner". Diese Umarmung der agilen Ansätze durch die Standardisierungsorganisationen hat allerdings eine ironische Note: Das agile Manifest von 2001 war als Kampfansage an die etablierten Projektmanagementstandards gedacht, die sich eben nicht mit dem Wunsch nach Planbarkeit und Kontrolle vereinbaren ließen. Die Betrachtung des klassischen Zieldreiecks aus Inhalt, Kosten und Zeit verdeutlicht das: Dreht der klassisch vorgeprägte Projektmanager bei vorgegebenem Inhalt an den Stellschrauben Kosten und Zeit, ist es bei agilen Ansätzen eher anders herum: Kosten und Zeit sind fix, der Inhalt bleibt aber variabel. Das kann nicht zusammengehen. Besonders riskant sind Lösungsversuche, bei denen im Projekt agil vorgegangen wird, der Projektleiter aber zum Management beziehungsweise dem Kunden hin klassisches Projektmanagement exerziert. Das führt jedes Mal zur Zerreißprobe, wenn das Projektteam agil und eigenverantwortlich Inhalte verändert oder verschiebt, der Projektmanager aber dafür einen Change Request in einen Change-Management-Prozess geben muss, bei dem eine Entscheidung länger dauert als die nächste Projektiteration.

Der Übergang auf ein agiles Projektmanagement wird sich daher nicht einfach als evolutionäre Weiterentwicklung etablierter Projektmanagementstandards darstellen lassen. Ebenso wenig reicht es, Anpassungen nur auf die Vorgehensmethodik in IT-Entwicklungsprojekten zu beschränken. Veränderungen in der übergreifenden Projektkultur und Unternehmenskommunikation sind ebenso wichtig.

Vorgehensmodelle der Software-Entwicklung

Betrachtet man die Entwicklung der Vorgehensmodelle für Softwareentwicklung im Rückblick, so kann man drei verschiedene Modellklassen unterscheiden: die sequentiellen Modelle ("Wasserfall"-Modelle), die iterativ-inkrementellen Modelle, deren Vater das Spiralmodell von Barry Boehm ist, und die agilen Modelle. Jede Klasse hat einen spezifischen Blick auf die Softwareentwicklung und adressiert jeweils eine ganz bestimmte Herausforderung in den Projekten.

Wasserfallmodell

Beim Wasserfallmodell geht es um die Frage "Was muss ich tun, um Software zu erzeugen?" Im Fokus liegt das "Management of Engineering". Die Tätigkeiten des Software Engineering, wie Analyse, Spezifikation, Planung, Design, Entwicklung, Test und Dokumentation, werden beschrieben und relativ zueinander angeordnet, und zwar sequenziell. Der große Beitrag dieser Modelle ist es, den Prozess der Softwareentwicklung als einen arbeitsteiligen Ingenieursprozess zu verstehen und dessen Bestandteile und Beziehungen sowie die Mechanismen für ihre Steuerung zu definieren.

Iterativ-inkrementellen Modelle

Bei iterativ-inkrementellen Modellen (II-Modelle) steht das Risikomanagement im Vordergrund: "Management of Risk" Treibende Kraft ist die Beobachtung aus der Praxis, dass ein reiner Engineering-Ansatz bei großen Projekten häufig nicht ausreicht, um die Risiken zu überschauen und die erforderlichen Maßnahmen zu steuern. Der Lösungsansatz besteht darin, eine große Aufgabe in viele kleine zu zerlegen und diese nacheinander zu lösen. Dabei fließen Erkenntnisse aus früheren Iterationen in die weitere Planung späterer ein. Nicht nur die Entwicklungsaufgabe selbst, sondern auch die Design- und Planungsprozesse unterliegen daher einem permanenten Lernprozess und sind in die dafür erforderlichen Rückkopplungsschleifen eingebunden. Die Lösung der II-Modelle für das Risikoproblem lautet daher: permanentes individuelles und organisationales Lernen.

Agiles Vorgehen

Die agilen Methoden greifen genau diesen Aspekt des Lernens auf, vertiefen und erweitern ihn. Ein iterativ-inkrementelles Vorgehen ist dann agil, wenn von Iteration zu Iteration nicht nur die Lösungsansätze und Prozesse des Projekts überprüft und optimiert werden, sondern auch seine Anforderungen und Randbedingungen. Diese werden nicht mehr als gegeben betrachtet, sondern in den Lernprozess einbezogen. Das erfordert zwingend den "Kunden" in das Projekt einzubeziehen, also die Person oder Organisation, die diese Inhalte definieren und verändern kann. Die agilen Methoden fokussieren radikal auf den Umgang mit Dynamik, sie erfordern das "Management of Change". Zu nennen sind hier zum Beispiel Scrum, Extreme Programming oder Crystal.

Vertrauen als Erfolgsfaktor

Agilität bedeutet Offenheit gegenüber Lernprozessen und das Ernstnehmen von Erkenntnissen des Projekts. Deshalb kann es auf Dauer nicht gut gehen, wenn innerhalb eines Projekts agil vorgegangen werden soll, die Agilität und Ihre Prinzipien jedoch an den Projektgrenzen – und damit genau an den Projektrahmenbedingungen Zeit, Kosten und Inhalt – endet. Agilität benötigt die Möglichkeit, auch an diesen Bestimmungsgrößen Änderungen vorzunehmen oder zumindest diese Änderungen zu verlangen, wenn die Projektmitglieder feststellen, dass die gegebene Projektdefinition nicht zum Erfolg führen kann. Wenn der Zieldefinitionsprozess im Unternehmen ausschließlich "top-down" funktioniert und sich Erkenntnisse aus den Projekten nicht zurückspiegeln lassen, wird das "Commitment" eines Teams zu einem Projektziel nur kurz anhalten.

Grundlage jedes agilen Vorgehens ist das Ernstnehmen der Projektmitglieder und das Vertrauen in ihre professionelle Kompetenz und ihr Commitment zum Projekt. "People over Process" bedeutet in der Konsequenz, dass Menschen nicht als "Prozessoren" betrachtet werden, die in vordefinierten Prozessen möglichst klar definierte, abgegrenzte Aufgaben erfüllen, sondern als kompetente Subjekte zielgerichteten Handels, die Prozesse als Hilfsmittel und Werkzeuge benutzen. Die Interpretation von Prozessen als Werkzeuge schließt ausdrücklich ein, dass das Team die Prozesse ändern kann, wenn es im Sinne der Zielerreichung erforderlich oder sinnvoll ist und es die volle Verantwortung für die Zielerreichung übernimmt. Ein Management, das dagegen nach dem Motto "Wasch mir den Pelz, aber mach' mich nicht nass!" die Vorteile agiler Methoden ernten will, ohne die Rahmenbedingungen in Form von Offenheit und Vertrauen zu gewährleisten, wird zwangsläufig scheitern.

Entwicklungsvorgehen bestimmt die Projektmanagementmethode

Zum Übergang zu einem agilen Projektmanagement gehört damit, die methodischen Grundannahmen in Frage zu stellen. Damit IT-Projekte nicht durch die falsche Wahl der Projektmanagement-Methode scheitern, sollten sich die Verantwortlichen bewusst entscheiden, ob sie agil oder klassisch entwickeln. Aspekte dieser Entscheidung sind beispielsweise, ob die Unternehmenskultur ein agiles Herangehen an Projekte zulässt. Weiterhin ist es wichtig zu wissen, inwieweit die Anforderungen an das Endergebnis schon vorab bekannt und klar spezifiziert sind. Darüber hinaus sollten sich die Verantwortlichen verdeutlichen, wie stark Rahmenbedingungen im Projektverlauf veränderbar sind, wie unternehmenskritisch das Projekt ist und wie stark Frontend-Funktionen vom Entwicklungsprojekt betroffen sind. Diese Überlegungen erlauben die bewusste Wahl eines Vorgehensmodells, dass zu den realen Bedingungen des Projekts passt und damit optimale Erfolgsaussichten besitzt. (rl)

Hans-Bernd Kittlaus
ist Gründer von InnoTivum Consulting (www.innotivum.de). Sein Fokus liegt auf dem Zusammenwirken von Geschäfts- und IT-Seite, besonders Software-Produkt-Management, Change Management, Business Process Management, CRM und BI. Er hat verschiedene Bücher und Artikel veröffentlicht, zuletzt "Software Product Management and Pricing" (Springer).

Hartmut Herde
ist Bereichsleiter bei der PPI AG Informationstechnologie und verantwortet die Entwicklung von Softwarelösungen mit dem Schwerpunkt auf Komponenten und Anwendungssystemen für das Risikomanagement. Seit 2003 setzt er agile Methoden in seinen Projekten ein.