Agile Software-Entwicklung braucht auch ein agiles Projektmanagement

Inhaltsverzeichnis

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 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 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 (Project Management Institute, USA): Prozessorientierter Best-Practice-Ansatz. Inhalte sind im PMBoK beschrieben (Project Management Book of Knowledge).
• IPMA (International Project Management Association, in Deutschland GPM): Kompetenz-orientierter Ansatz. Inhalte sind in der ICB beschrieben (IPMA Competence Baseline).
• PRINCE2 (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.