Hybrides Vorgehensmodell

Agile und klassische Methoden im Projekt passend kombinieren

Agil ist im Trend und immer mehr Unternehmen, die ihre Projekte bisher nach klassischen Prinzipien durchführten, denken über den Einsatz agiler Methoden nach. Doch selbst wenn die Organisation bereits beide Philosophien unterstützt, gilt für ein Projekt meist die klare Vorgabe: agil oder klassisch. Es gibt aber noch einen anderen Ansatz, mit diesen "unterschiedlichen Welten" umzugehen: Und zwar die beiden Philosophien innerhalb eines Projekts zu kombinieren. Wie dies in der Praxis aussehen und gelingen kann, zeigen Dr. Michael Kirchhof und Prof. Dr. Bodo Kraft in diesem Beitrag.
Hybrides Vorgehensmodell

Agile und klassische Methoden im Projekt passend kombinieren

Agil ist im Trend und immer mehr Unternehmen, die ihre Projekte bisher nach klassischen Prinzipien durchführten, denken über den Einsatz agiler Methoden nach. Doch selbst wenn die Organisation bereits beide Philosophien unterstützt, gilt für ein Projekt meist die klare Vorgabe: agil oder klassisch. Es gibt aber noch einen anderen Ansatz, mit diesen "unterschiedlichen Welten" umzugehen: Und zwar die beiden Philosophien innerhalb eines Projekts zu kombinieren. Wie dies in der Praxis aussehen und gelingen kann, zeigen Dr. Michael Kirchhof und Prof. Dr. Bodo Kraft in diesem Beitrag.

Agile Entwicklungs- und Projektmanagement-Methoden sind immer stärker im Kommen. Viele Unternehmen, die bereits klassische Entwicklungsmodelle wie z.B. den Rational Unified Process (RUP) oder PRINCE2 nutzen, denken mittlerweile auch über den Einsatz agiler Methoden nach. Die Gründe dafür sind vielfältig: Einerseits wünschen die Unternehmen schnellere und flexiblere Steuerungsmechanismen. Andererseits schreckt viele Projektbeteiligte der Aufwand für die zu erstellende Dokumentation ab sowie die aufwändige und kleinteilige Planung aller benötigten Aufgaben und Rollen.

Üblicherweise werden Projekte ausschließlich agil oder klassisch aufgesetzt und durchgeführt. Selbst in einer Organisation, die schon beide Philosophien unterstützt, besteht in der Praxis meist nur die Möglichkeit, das Projekt entweder nach agilen oder klassischen Prinzipien durchzuführen. Es gibt aber noch einen weiteren Ansatz, mit diesen "unterschiedlichen Welten" umzugehen: Und zwar die beiden Philosophien innerhalb eines Projekts zu kombinieren.

Wie dies in der Praxis aussehen und gelingen kann, stellen wir in diesem Beitrag vor. Zunächst beleuchten wir, für welche Anteile eines IT-Projekts sich agile Methoden besonders gut eignen und für welche Anteile eher der Einsatz traditioneller Vorgehensweisen sinnvoll ist. Danach zeigen wir anhand eines Praxisbeispiels, wie die Kombination von agilen und klassischen Methoden innerhalb eines Projekts funktionieren kann. Abschließend werden einige Erfolgsfaktoren und Lessons Learned vorgestellt.

Vorüberlegungen

Agile Methoden eignen sich gut, um Projekte effizienter zu steuern und flexibler auf Anforderungen der Stakeholder zu reagieren. So erfordert z.B. eine Produktneuentwicklung mit vielen Unklarheiten auf der Seite des Auftraggebers geradezu ein agiles Vorgehen. Aber auch klassische Methoden haben weiterhin ihre Berechtigung und ermöglichen – ein sorgfältiges Tailoring vorausgesetzt – effiziente Projekte. So bieten sich z.B. traditionelle Steuerungsmechanismen für kritische Migrationsprojekte an, bei denen der Kundenauftrag in Bezug auf Termin und Umfang genau und endgültig abgegrenzt ist und zudem ein hohes Maß an formaler Dokumentation erforderlich wird.

Doch warum sollte es nur ein "Entweder/Oder" geben? Warum nicht die Stärken beider Ansätze innerhalb eines Projekts nutzen? Dies würde dazu führen, nicht mehr zu entscheiden, ob ein Projekt im Ganzen agil oder klassisch durchzuführen ist. Vielmehr liegt die Herausforderung darin, für die jeweiligen Teilprojekte den jeweils passenden Ansatz zu identifizieren. Unserer Erfahrung nach ist es insbesondere bei großen Projekten (mit mehreren Teilprojekten und über 2.000 Personentagen) vielversprechend, die Methodik innerhalb der Projektstruktur zu variieren – also einzelne Teilprojekte und Arbeitspakete unterschiedlich entsprechend ihrer Bedürfnisse zu steuern. Wir begründen das insbesondere damit, dass in diesen Projekten die jeweiligen Anteile in der Einzelbetrachtung signifikante Aufwände darstellen. Die Anwendung unpassender Vorgehensweisen führt zu Effizienzverlusten, die durch die Vorteile einer einheitlichen Gesamt-Projekt-Vorgehensweise nicht kompensiert werden. Die Investition für die Einführung des Hybriden Vorgehensmodells lohnt sich somit in jedem Fall.

Eigene Konzepte erforderlich

Entscheidet man sich dafür, die Teilprojekte mit verschiedenen Vorgehensmodellen durchzuführen, müssen diese Modelle um Konzepte erweitert werden, die es z.B. ermöglichen, die Arbeitsteilung zu strukturieren oder die Teilprojekte untereinander zu synchronisieren. Die meisten Vorgehensmodelle bieten hierzu wenig Hilfestellung, d.h. es bleibt den Unternehmen oder sogar den Projekten selbst überlassen, Wege zu finden, um diese Herausforderungen zu bewältigen. Zu betrachten ist hierbei nicht nur das Projektmanagement, sondern ebenso weitere Querschnitts-Disziplinen, wie z.B. das Anforderungsmanagement und die Qualitätssicherung.

So ist es bei einer Kombination agiler und klassischer Ansätze während der Projektinitialisierung wichtig, die Schnittstellen, insbesondere die Kommunikations- und Steuerungsmechanismen, festzulegen. Gerade bei großen Projekten mit mehreren Teilprojekten und großen Lenkungsausschüssen ist eine durchgängige Planung mit Fortschrittskontrolle sowie ein einheitliches Reporting und Stakeholdermanagement für den Projekterfolg elementar. Nicht zuletzt erfordern auch Compliances, z.B. CMMI, eine integrierte Sichtweise auf das Gesamtprojekt.

Ein Praxisbeispiel

Nachfolgend möchten wir den Einsatz unterschiedlicher Vorgehensmodelle innerhalb eines Projekts an einem Praxisbeispiel verdeutlichen. Das Beispiel ist an vielen Stellen vereinfacht, um auf die hier relevanten Aspekte eingehen zu können. Vor allem soll das Beispiel zeigen, wie auf Teilprojektebene die eher volatilen (geeignet für agile Methoden) und die stabilen (geeignet für traditionelle Methoden) Anforderungen identifiziert und durch entsprechende Methoden umgesetzt werden können. Darüber hinaus möchten wir beleuchten, wie die Gesamtprojektsteuerung einen konsolidierten Blick auf das Projekt erhält und wie sich einheitliche Dokumentationsanforderungen erreichen lassen.

Das Beispielprojekt mit seinen Teilprojekten wird nach dem Vorgehensmodell des Rational Unified Process (RUP) abgewickelt. Dabei ordnen wir RUP den klassischen Vorgehensweisen zu. Dies ist allgemein umstritten (s. hierzu auch Ambler, 2002 und Cohn, 2009), da durch mehrere Inkremente und die fortlaufende Beteiligung des Auftraggebers bereits agile Grundideen realisiert werden. Dennoch beschreibt der RUP ein eher komplexes und detailliert festgelegtes…

Bewertungen und Kommentare

(nur angemeldete Benutzer)

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

Alle Kommentare

Christian
Kirchner
Bereits auf dem letzten PM-Forum ein sehr interessanter Beitrag und auch hier wieder gelungen. Gern mehr davon :)
Guest
Was ich nicht verstehe, wenn schon ein "Teil"-Projekt agil arbeitet, warum das bei den anderen nicht auch gemacht wurde, um das gesamte Projekt effizienter zu machen. die Adaption an die klassische Welt kann auch höher aufgehangen werden. Die Idee einen dedizierten Tester in das Scrum-Team mit reinzunehmen entspringt der klassischen Denke. In agilen Projekten müssen die "Entwickler" diese Aufgabe mit übernehmen, damit von ihnen (eigenverantwortlich) die Definition of Done erfüllt werden kann.
Guest
@Rainer: Das ist so nicht ganz Richtig. Es ist ein interdisziplinäres Team zu bilden, welches in der Lage ist alle Projektanforderungen zu erfüllen. Es sollten also Entwickler, Architekten und Tester typischerweise innerhalb des Teams bei Softwareprojekten vertreten sein. Nur wird eben von diesen verlangt, dass Sie auch über den eigenen Tellerrand schauen. Es ist eine weitverbreitete, aber dennoch fehlerhafte Annahme, dass jedes Teammitglied alle Qualifikationen mitbringen muss und somit auch, dass die Entwickler die Tester ersetzen. Nur die Summe der Qualifikationen des Teams muss stimmen. Ich berufe mich hierbei auf mehrere Quellen der einschlägigen Literatur wie zum Beispiel "Agile Softwareentwicklung" von Beck und Wolf.
Alle anzeigen