zurück zum Artikel

Wählen Unternehmen für Softwareprojekte ein agiles Entwicklungsvorgehen, steuern das Projekt aber mit einem klassischen Projektmanagement, prallen zwei Welten aufeinander. Um Veränderungen als positive Kraft zu integrieren, bedarf es für agile Softwareentwicklung auch eines agilen Projektmanagements.

Wählen Unternehmen für Softwareprojekte ein agiles Entwicklungsvorgehen, steuern das Projekt aber mittels eines klassischen Projektmanagements, prallen zwei Welten aufeinander. Denn traditionelle Ansätze des Projektmanagements gehen generell von der Vorstellung der nahezu vollständigen Planbarkeit zu Projektanfang aus. Veränderungen werden als Störungen vom geplanten Ablauf interpretiert und behandelt. In agilen Methoden werden Veränderungen dagegen nicht nur als gegeben hingenommen, sondern sogar als positive, treibende Kräfte betrachtet. Eine agile Softwareentwicklung braucht somit auch eines agilen Projektmanagements.

Agile Softwareentwicklung hat in den letzten zehn Jahren eine überwältigende Aufmerksamkeit erlangt. Viele IT-Projektteams reagieren mit ihr auf die wachsende Dynamik von Wirtschaftsprozessen durch einen globalisierten Wettbewerb.

Agile Softwareentwicklung reagiert auf diese steigende Dynamik. Die Besonderheit des agilen Vorgehens: Nicht alles ist bis ins letzte Detail vorgeplant, sondern es gibt einen offenen Lernprozess. Veränderungen sind nicht nur erlaubt, sie sind der Normalfall, was die Projektrealität in der Regel widerspiegelt. Agile Methoden eignen sich um so mehr, je stärker sich die Inhalte eines Projekts am Frontend orientieren, also die Schnittstelle zum Enduser betreffen.

Die wachsende Dynamik bei der IT-Entwicklung fordert den Projektmanagern allerdings eine neue Flexibilität ab. Denn es ist völlig normal, dass sich die Anforderungen an ein großes betriebliches Informationssystem während einer zwei- oder dreijährigen Entwicklungszeit deutlich ändern. Häufig zeigt sich nach der Einführung solcher Systeme, dass Funktionen, die für viel Geld entwickelt worden sind, an den Bedürfnissen der Anwender vorbeigehen oder nur wenig genutzt werden.

Die Managementkultur in Unternehmen muss sich wandeln

Es ist viel zu oft Gang und Gebe, dass agile Verfahren auf klassische Projektmanagementmethoden wie PMI oder Prince2 [1] stoßen, die auf einer starreren Planung und einem klaren Prozessdenken basieren. Hier besteht enormes Konfliktpotenzial. Denn viele Verantwortliche verkennen, dass die Umsetzung agiler Ansätze nicht nur aus dem Lernen und Anwenden handwerklicher Tools und Techniken besteht. Agilität erfordert gravierende Anpassungen in der Kultur der Organisation, um wirklich zu funktionieren. Die Managementkultur des Unternehmens muss auf die Anforderungen von Agilität eingerichtet sein. Die Projektmanager müssen sich wirklich – nicht nur formal – darauf einlassen. Dazu gehört beispielsweise, dass die Menschen mit ihren individuellen Ideen und Methoden einen größeren Stellenwert als das Befolgen von Abläufen besitzen ("People over Process", wie im agilen Manifest [2] gefordert). Die damit verbundene Freisetzung von Zeit und kreativer Kraft wird jedoch nicht gelingen, wenn die tatsächlichen Entscheidungen dann doch nach strengen Vorgaben des Projektmanagementhandbuches fallen und kreative Querdenker kaum Chancen haben, sich durchzusetzen, sondern eher ihre Karriere gefährden.

Flexibilität zwischen Auftraggeber und Projektteam ist Voraussetzung

Ein gängiger Konfliktherd ist die einseitige Betrachtung von Agilität und Flexibilität. Die Projektauftraggeber, sei es der Kunde oder die eigene Fachabteilung, sind sich selten bewusst, dass in einem agilen Projekt nicht nur sie, sondern auch das Projektteam Änderungen initiieren kann. Stattdessen herrscht oft die Devise: "Ihr Entwickler seid mit agilen Methoden schneller und besser, und wir können jederzeit die Anforderungen ändern." Agile Softwareentwicklung funktioniert allerdings nur, wenn dieser einseitige Blick aufgelöst ist. Denn die Flexibilität, die die Auftraggeber für sich in Anspruch nehmen, gilt genauso für die Entwickler. Auch die IT-Seite kann im laufenden Projekt wesentliche Änderungen verlangen, wenn es den Projektzielen nützt. Das kann ebenfalls Konsequenzen auf der Projektmanagementseite haben – zum Beispiel bei der Reihenfolge von Projektschritten oder bei den Inhalten.

Weitere Hürden bestehen im Falle der Beauftragung von externen Entwicklungsdienstleistern. Hier tun sich vor allem Einkaufs- und Rechtsabteilungen schwer mit agilen Projekten. Eine Einkaufsabteilung wünscht Standardisierung, unter anderem, um Preise zu vergleichen. Und Rechtsabteilungen wollen beim Gestalten von Verträgen vorab genau wissen, welche Leistungen sie zu welchen Bedingungen erhalten. Die agilen Ideen der Ausarbeitung von Details "on demand" und die Berücksichtigung von Lernprozessen während des Projekts treffen hier selten auf Gegenliebe.

Wenn Gegensätze zu stark sind

Eine Vereinbarkeit heute üblicher Projektmanagementstandards mit agiler Softwareentwicklung scheitert zudem schon im Ansatz. Denn das klassische Projektmanagement hat sich kaum weiterentwickelt, ihre letzte Professionalisierung erlebte die Disziplin Ende der 1980er Jahre mit dem Entstehen von Standards für Methoden und Vorgehensweisen mit dazugehöriger Zertifizierung. Zu den wichtigen internationalen Standards zählen heute:

• PMI [3] (Project Management Institute, USA): Prozessorientierter Best-Practice-Ansatz. Inhalte sind im PMBoK beschrieben (Project Management Book of Knowledge).
• IPMA [4] (International Project Management Association, in Deutschland GPM): Kompetenz-orientierter Ansatz. Inhalte sind in der ICB beschrieben (IPMA Competence Baseline).
• PRINCE2 [5] (UK): Prozessorientierter Best-Practice-Ansatz mit starker Ergebnis-Fokussierung. Inhalte sind im Buch "Erfolgreiche Projekte managen mit PRINCE2" beschrieben.

All diese Standards gehen noch immer davon aus, dass sich zum Projektbeginn oder beim Start einer neuen Projektphase die wesentlichen inhaltlichen Ziele vereinbaren und dokumentieren lassen. Sie bilden die Basis für eine konsequente Vorausplanung. Anforderungen werden damit als weitgehend bekannt unterstellt. Change Requests sind möglich, hierbei handelt es sich allerdings um einen formalen Prozess zum Umgang mit Änderungen von Anforderungen. Das Ergebnis führt zu einem neuen geänderten Plan. Damit gibt es zu jedem Zeitpunkt einen vollständigen Plan, der den Beteiligten Stabilität und Kontrolle suggeriert. Eine Änderung stellt eine Störung des stabilen Zustands dar, der durch Change Requests und Change Management in einen neuen stabilen Zustand überführt wird. Der Plan und seine Umsetzung sind zentrale Elemente der Tätigkeit des Projektmanagers.

Agile Softwareentwicklung setzt dagegen auf klare Rahmenbedingungen, in der sich die Akteure frei bewegen können, und nicht auf Projekte, die strikt nach Vorschrift abgearbeitet werden. Auch für agile Projekte sind klare Pläne und ein konsequentes Projektcontrolling unverzichtbar. Der Plan besitzt hier jedoch einen anderen Stellenwert. Während er in klassischen Ansätzen die übergeordnete Leitlinie ist, stellt er in agilen Projekten ein Werkzeug zur Ziellerreichung dar, das selbst ebenfalls permanenter Veränderung unterliegt. Der Unterschied zu den etablierten Projektmanagement-Standards ist offensichtlich.

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.

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.

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. (rl [6])

URL dieses Artikels:
https://www.heise.de/-1598135

Links in diesem Artikel:
[1] http://de.wikipedia.org/wiki/PRINCE2
[2] http://agilemanifesto.org/iso/de/
[3] http://www.pmi.org/
[4] http://ipma.ch/
[5] http://www.prince2.com/
[6] mailto:rl@ix.de

Copyright © 2012 Heise Medien