Agile Methoden im traditionellen Projektmanagement-Umfeld einsetzen

Agile Vorgehensweisen sind in der Softwareentwicklung weit verbreitet. Doch die Restriktionen des traditionellen Unternehmensumfelds schränken den Einsatz dieser Methoden häufig ein. Lassen sich agile Vorgehensweisen in einem solchen Umfeld überhaupt einsetzen? Welchen Nutzen können Unternehmen davon haben? Und was bedeutet das für die traditionelle Rolle des Projektmanagers? Thomas Müller und Benedict Gross beschreiben in ihrem Beitrag, wie sich beide Konzepte in Einklang bringen lassen.

Agile Methoden im traditionellen Projektmanagement-Umfeld einsetzen

Agile Vorgehensweisen sind in der Softwareentwicklung weit verbreitet. Doch die Restriktionen des traditionellen Unternehmensumfelds schränken den Einsatz dieser Methoden häufig ein. Lassen sich agile Vorgehensweisen in einem solchen Umfeld überhaupt einsetzen? Welchen Nutzen können Unternehmen davon haben? Und was bedeutet das für die traditionelle Rolle des Projektmanagers? Thomas Müller und Benedict Gross beschreiben in ihrem Beitrag, wie sich beide Konzepte in Einklang bringen lassen.

Projekte kämpfen heutzutage mit Innovations- und Marktdruck. Das Projektergebnis kann anfangs oft nur abstrakt beschrieben werden. Technische Rahmenbedingungen und Kundenwünsche verändern sich im Projektverlauf. Und die Engpass-Ressource sind gute Mitarbeiter mit hohen und seltenen Qualifikationen. Wo diese Faktoren zusammenkommen, werden seit einigen Jahren agile Vorgehensweisen angewandt, hauptsächlich Scrum und Extreme Programming (XP).

Diese Methoden kommen aus der Softwareentwicklung und werden bisher größtenteils auch genau dort eingesetzt. Jedoch ist der Trend erkennbar, dass agile Ansätze über die IT-Abteilungen auch ihren Weg zur Anwendung in anderen Unternehmensbereichen finden – und sogar in Branchen Einzug halten, die als besonders auf Sicherheit bedacht und starr bekannt sind, wie z.B. Banken, Versicherungen, Medizintechnik oder Rüstungsunternehmen. Gerade weil agile Ansätze immer weiter verbreitet werden, können sich auch hartgesottene Profis im traditionellen Projektmanagement diesen Ideen nicht mehr verschließen.

Aber was macht den agilen Ansatz aus Sicht des traditionellen Projektmanagements so reizvoll? Und wie lassen sich agile Vorgehensweisen auch in traditionellen Projektmanagement-Umgebungen einsetzen? Was bedeutet das für die Rolle des klassischen Projektmanagers? Diesen Fragen widmet sich der vorliegende Beitrag, der Projektverantwortlichen und Organisationsgestaltern Anregungen geben soll, wie sich agile Methoden auch in ein traditionelles PM-Umfeld integrieren lassen und beide Konzepte von dieser Kombination profitieren können.

Kurze Übersicht: Was sind agile Vorgehensweisen?

Die heute als agil bezeichneten Vorgehensweisen (Scrum, Extreme Programming, die Chrystal-Familie und einige andere) haben alle eine eigene Entwicklungsgeschichte. Ihre Wurzeln liegen in den 90er Jahren. Im Februar 2001 kamen die führenden Denker dieser Methoden zusammen und verabschiedeten ein gemeinsames Credo, das sog. "Agile Manifest" (www.agilemanifesto.org). Seitdem werden diese Methoden unter dem Sammelbegriff "Agile Vorgehensweisen" zusammengefasst und sind hauptsächlich für die Softwareentwicklung beschrieben. Dabei lässt das Agile Manifest in seiner Formulierung keinen Zweifel, dass es von Softwareentwicklern für Teams in der Softwareentwicklung verfasst wurde.

Eine Umdeutung als generellen Ansatz für das Projektmanagement erfahren die agilen Methoden erst in den letzten Jahren. Dieser schließen sich die Urheber der Vorgehensweisen sowie Berater und Buchautoren bereitwillig an. Am ergiebigsten aus Sicht des Projektmanagements ist wohl "Scrum", da es hauptsächlich einen einfachen Planungs- und Steuerungsprozess für das Management eines Entwicklungsprojekts beschreibt. Die anderen agilen Ansätze gehen hingegen sehr spezifisch auf Methoden der Softwareentwicklung ein. Aus diesem Grund scheint Scrum auch die weiteste Verbreitung zu erfahren.

Die agilen Vorgehensweisen heben sich vom klassischen Projektmanagement zunächst in der Betonung ihrer vier "agilen Werte" ab, die im Agilen Manifest als Glaubenssatz beschrieben sind:

"Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

  • Individuen und Interaktionen mehr als Prozesse und Werkzeuge
  • Funktionierende Software mehr als umfassende Dokumentation
  • Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlungen
  • Reagieren auf Veränderung mehr als das Befolgen eines Plans

Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein." (Quelle: www.agilemanifesto.org)

In diesen Grundsätzen sowie den "Zwölf Prinzipien Agiler Softwareentwicklung" (siehe hierzu auch das Agile Manifest) wird den Menschen in einem Projekt eine besonders hohe Bedeutung zugemessen. Man beachte aber, dass das Agile Manifest nicht die traditionellen PM-Tugenden wie Prozesse, Werkzeuge oder Plantreue schlecht macht, wie es gelegentlich dargestellt wird. Im Gegenteil: Sie werden ausdrücklich als Werte angeführt. Gleichzeitig werden ihnen jedoch Werte gegenübergestellt, die verdeutlichen sollen, worin die traditionellen PM-Tugenden auch ihre Schwächen haben. Einen Widerspruch stellen die Begriffspaare nicht dar! Man kann funktionierende Software produzieren, die umfassend dokumentiert ist oder einen umfangreichen Vertrag verhandeln und trotzdem gut mit dem Kunden zusammenarbeiten. Aus Sicht des traditionellen Projektmanagements kann das Agile Manifest deswegen auch als Aufruf zur Ausgewogenheit verstanden werden.

Alle agilen Vorgehensweisen sind stark darauf ausgerichtet, den Mitarbeitern des Projektteams ein angenehmes produktives Arbeitsumfeld zu bereiten und die Kommunikation untereinander zu fördern. Wenn man diese Ideen vor dem Hintergrund von Softwareprojekten sieht – tatsächlich trifft das aber heute auf die meisten anderen Projektarten ebenfalls zu –, dann leisten qualifizierte Mitarbeiter den größten Beitrag zum Erfolg, sind gleichzeitig die Ressource, die am schwersten zu beschaffen ist, und das von ihnen eingesetzte Wissen ist oft zu abstrakt für eine schriftliche Dokumentation. Insofern bedeutet die Fokussierung auf Individuen und Interaktionen letztendlich eine Form der Produktionsoptimierung, wie sie in der Industrie bezogen auf deren Produktionsmittel schon lange selbstverständlich ist.

Agil versus traditionell: gleicher Rahmen, verschiedene Ansätze

Bewertungen und Kommentare

(nur angemeldete Benutzer)

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung. Jetzt einloggen
Gesamt
Bewertungen 25
Kommentare 5

Alle Kommentare

Jochen
Dinter
Gerade im Hinblick auf die gegebenen Organisationsstrukturen in traditionell nicht-lean aufgestellten Unternehmen ist die Vorgehensweise mit Scruminseln äusserst praktikabel und sinnvoll. Mögliche kannibalisierte Alternativen dürften sich zwangsläufig nicht Scrum nennen und hätten auch auf die Vorteile von Scrum zu verzichten. Als Scrum-Master mit klassischer PMI-Ausbildung halte ich diesen Weg für den bestmöglichen Konsens, welchen ich auch aktuell in einem grossen Migrationsprojekt leben kann. Elementare Voraussetzungen für den Erfolg sind meines Erachtens eine programmübergreifende Release- und Iterationsplanung, sowie eine definierte und gelebte Rollenverteilung, die Projektmethodik und Scrum-Workflow gleichermassen abdeckt.
Michael
Laussegger
Guten Tag Herr Müller, Guten Tag Herr Gross! Ich sehe das etwas anders. Anstatt nach der goldenen Mitte zu suchen sollten wir nach Spuren suchen, die in Richtung Schlankheit und Agilität weisen. Dafür sind nicht immer gleich radikale Veränderungen nötig, aber die Richtung sollte Stimmen (vgl. Scrum vs. Kanban). Wir sollten innovative Keimzellen in der Organisation stärken. Dann sollten wir uns fragen welche Rahmenbedingungen wir schaffen können damit der Funke überspringen kann. Den Projektmanager als Torwächter, quasi als Verhinderer von Innovation hinzustellen gefällt mir nicht. Ich sehe den Projektmanager lieber als Ermöglicher. Beste Grüße Michael Laussegger (Die Projektur GmbH)
Michael
Ferchau
Nur allgemeine Aussagen, keine Hinweise wie man agile Verfahren mit traditionellen verbinden kann (wie z.B. bie APM), Verbindung mit kontreten Modellen wie PRINCE2 oder V-Modell fehlt.
Guest
Der Artikel war nicht hilfreich für mich. 7 Seiten lang habe ich gewartet, dass die allgemeine Einführung endet und es praktisch losgeht. Die folgenden 3 Seiten werden für die Nennung der Idee benötigt, in einem größeren Projekt einzelne Teilprojekte nach Scrum durchzuführen und den Rest mit klassischen Methoden zu managen. Ich vermisse jegliche Idee, Scrum-Elemente mit klassischem Vorgehen innerhalb eines (Teil-)Projektes zu verbinden oder auch beim Scrum-Ansatz eine Kostenplanung und -nachverfolgung zu integrieren.
Guest
Was mir bei der ganzen Betrachtung besonders fehlt ist das praktische Wissen im Umgang mit Scrum. Es gibt keine Team-Leiter in Scrum. Deshalb funktioniert die vorgeschlagene Brücke klassischer-PL-zu-Scrum-Teamleiter nicht. Der Scrum Master sorgt dafür, daß der Scrum-Prozeß richtig gelebt wird und die auftretenden Probleme (Impediments) so schnell wie möglich aus dem Weg geräumt werden. Er hat keinerlei Weisungsbefugnis dem Team gegenüber. Der Product Owner wäre ebenfalls als Team-Leiter ungeeignet. Warum? "Agil" heißt in erster Linie "selbstbestimmtes Team". Damit bricht der hierarchische Leiter-Ansatz des Artikels auch komplett zusammen. Interessant wäre gewesen, darüber zu lesen, wie eine Adaption einer "Scrum-Insel" mit der klassischen Umgebung aussehen muß, damit beide Welten co-existieren können. Man könnte z.B. Proxies einführen. Aber genau hier suche ich noch nach einer tragfähigen Lösung.
Alle anzeigen