… Dass Vorhaben scheitern, liegt meist an unzureichender Kommunikation als Folge mangelhaften Projektmanagements. Vor allem kleinere Unternehmen arbeiten oft einfach drauflos nach dem Motto »So wie beim letzten Mal«. Zwar orientiert man sich vage am klassischen Wasserfallmodell, doch letztlich hält sich das Team nicht an die vorgesehenen methodischen Schritte (siehe Grafik weiter unten). Greift man derart unreflektiert auf zuvor praktizierte Vorgehensweisen zurück, verschenkt man zudem die Möglichkeit, aus Fehlern und Irrwegen zu lernen. Diese werden sich beim nächsten Mal also ebenfalls wiederholen.
Wenn es dann im Team rumort und die Forderung nach agilen Arbeitsweisen laut wird, manifestiert sich darin hauptsächlich der Wunsch nach einer bewusst aufgesetzten Methode. Aber Vorsicht: Es droht die Gefahr, dass das agile Projektmanagement zu groß und zu gesprächsintensiv für die eigentlich einfache Aufgabe ist. Denn es ist keineswegs so, dass dieses klassischen Vorgehensweisen generell überlegen ist. Auch diese haben ihre Vorzüge. Es kommt darauf an, die richtige Methode für die jeweilige Aufgabe zu wählen.
Chris Bartsch, Kreativdirektor bei der Agentur Rocknrolladvertising (RNRA) in Hamburg, die sich mit ihren Entwicklungen häufig auf Neuland wagt, sagt:
»Wir bewerten jedes Projekt danach, wie hoch der Abstimmungsaufwand ist, wie dynamisch die Ziele und wie viele Stakeholder beteiligt sind, wie lange es dauert und ob die Anforderungen alle geklärt sind.«
Über eine entsprechende Matrix könne man dann schnell herausfinden, ob sich ein agiler Prozess lohne. Selbstverständlich fließen auch früherer Erfahrungen in die Entscheidung mit ein. »Dauert das Projekt über drei Monate und ist ziemlich komplex, muss der Kunde mit an Bord sein, weil noch nicht klar ist, was wirklich dabei herauskommen soll. Dann würden wir auf jeden Fall einen agilen Prozess vorziehen«, so Chris Bartsch. Es gibt aber auch Aufgaben, bei denen sich RNRA ganz bewusst für das klassische Wasserfallmodell entscheidet (siehe Seite 32 f., PAGE 10.2014).
Ein Modell, das die systematische Klassifizierung von Projekten erlaubt und dabei hilft, die richtige Projektmanagementmethode zu finden, hat der Wissenschaftler und Managementberater Dave Snowden mit seinem Cynefin-Framework entwickelt (siehe Seite 28 f., PAGE 10.2014). Je nachdem, ob eine Aufgabe eher in den offensichtlichen, komplizierten, komplexen oder chaotischen Habitat fällt, entscheidet die Projektleitung infolgedessen, ob eher eine agile oder klassische Vorgehensweise oder eine Kombination aus beidem zielführend ist.
Die Wasserfallmethode steht für das klassische Projektmanagement. Sie sieht einen linearen, in verschiedene Sequenzen gegliederten Ablauf vor. Dabei gehen die Ergebnisse einer Phase – wie bei einem Wasserfall – als verbindliche Vorgaben in die nächsttiefere ein. Dieses Vorgehen eignet sich, wenn sich alle Aufgaben im Projektverlauf in ihrer Abfolge erläutern lassen. Typischerweise werden bei gut modellierten Wasserfallprojekten die Teilprojekte jeweils von einer Disziplin bearbeitet. Um die Übergaben möglichst effizient zu gestalten, empfiehlt es sich, diese frühzeitig mit allen folgenden Gewerken festzulegen.
Bei klaren Aufgabestellungen ist eine direktive Führung, wie sie bei der Wasserfallmethode üblich ist, effizient und ausreichend. Die Projektleitung erarbeitet einen Plan, gliedert ihn in Teilaufgaben, die das Team dann Schritt für Schritt sauber umsetzt – begleitet von einem klaren Berichts- und Kontrollwesen.
»Wir nutzen Basecamp, um unsere To-do-Listen zu sortieren und den einzelnen Mitarbeitern die Aufgaben zuzuweisen«
sagt Frank Rausch vom Designstudio Raureif in Berlin. Bei anspruchsvolleren Wasserfallprojekten setzt man am besten auf eine Tandem-Führung: Zwei Personen können die Rahmenparameter schneller und umfassender erfassen und besser zu Entscheidungen kommen.
Bei gut überschaubaren Projekten ist die Wasserfallmethode auch heute noch sinnvoll. Wichtig ist dabei das bewusste methodische Vorgehen mit abschließenden moderierten Lessons-Learned-Meetings, bei denen sich das Team entweder auf ein Maßnahmenpaket einigt oder Verhaltensänderungen vereinbart. Um sich im nächsten Projekt nicht zu verzetteln, sollte man sich auf maximal zwei Änderungen beschränken und genaue Aufgaben und Erfüllungszeitpunkte definieren. Bei langen Projektlaufzeiten empfehlen sich zwei Sitzungen – eine in der Mitte und eine am Ende. Die Termine sollte man gleich zu Projektbeginn festlegen; zudem empfiehlt es sich, diese selbst zeitlich zu begrenzen.
Dass das klassische Projektmanagement mit seiner klaren Führungsstruktur heute schnell in die Kritik gerät, liegt auch daran, dass der Trend momentan in Richtung kooperativer Arbeitsformen geht, bei denen das Team ohne Hierarchien zusammenarbeitet und in regelmäßigen Abständen reflektiert, wie es effektiver werden kann. Direktiven werden leicht mit autoritärer Führung gleichgesetzt, auch wenn es eigentlich nur darum geht, die Person für die Projektleitung auszuwählen, die den Prozess am besten übersehen und die Einzelschritte modellieren kann. Gelingt dies, ist diese Art der Führung für alle Beteiligten eine Entlastung, denn jeder kann sich vollständig auf die eigene Disziplin und Kompetenz konzentrieren.
Im Laufe der letzten Jahre hat sich das agile Projektmanagement zu einer ernstzunehmenden Methode entwickelt, um interaktive Anwendungen gemäß der Spezifikation »in time and budget« zu produzieren. Im Unterschied zum klassischen Projektmanagement mit einem festen, klar definierten Ziel und einem geschätzten Termin und Budget arbeiten sich agile Teams – ausgehend von einem fixen Budget und einem fixen Termin – einem noch offenen Ziel entgegen, da es darum geht, wirklich neuartige Lösungen zu entwickeln. Agile Methoden wie Scrum oder Kanban zielen darauf ab, die Entwicklungsprozesse selbst äußerst flexibel und schlank zu gestalten (siehe Grafiken weiter unten). Zudem fördern sie die direkte Kommunikation im Team sowie zwischen diesem und dem Auftraggeber.
Zentral für die agile Entwicklung sind User Storys. In diesen beschreibt das Team markante Nutzungsszenarien und priorisiert diese. Diese User Storys geben keinen Lösungsweg vor, sondern definieren einen Zielzustand aus Anwender- oder Kundensicht. Die Umsetzungsform bleibt dem Team überlassen. Auf diese Weise vermeiden agile Projektmethoden lange Ausformulierungen von Anforderungen, die sich erstens aufgrund der Komplexität nicht vorhersehen lassen und die zweitens im weiteren Verlauf aufgrund des Auftauchens neuer Stör- und Einflussfaktoren umformuliert werden müssten.
Das agile Projektteam arbeitet in einem Raum und folgt definierten Rollen sowie einer institutionalisierten Meetingkultur zur Beurteilung des Projektstands und zur kontinuierlichen Optimierung. Die Scrum-Methode kennt drei Rollen mit unterschiedlichen Verantwortungen: den Product Owner, das Entwicklungsteam und den Scrum Master. Der Product Owner vertritt die Interessen des Kunden und ist für den wirtschaftlichen Erfolg des Produkts verantwortlich. Im Backlog hält er regelmäßig alle Projektschritte sowie die Anforderungen fest und nimmt aus dem Entwicklungsprozess heraus Ergänzungen vor oder verändert die Prioritäten. Der Scrum Master ist mehr Coach als Projektleiter (zu diesem Jobprofil lesen mehr hier). Er sorgt dafür, dass das Arbeitsumfeld für das Team stimmt, die Meetings eingehalten werden, und er erinnert den Product Owner daran, das Backlog zu aktualisieren.
Das Product Backlog ist eine Auflistung sämtlicher für das Produkt benötigten Anforderungen. Es ist dynamisch und wird ständig weiterentwickelt. Dabei kann es sich um eine einfache Excel-Datei handeln, eine Wandzeitung oder ein webbasiertes Projektmanagementtool wie JIRA oder Kanbanize. Edenspiekermann beispielsweise nutzt ScrumDo (www.scrumdo.com). Diese Werkzeuge haben den Vorteil, dass Mitarbeiter und Kunden auch von außen auf das Backlog zugreifen können.
Jeden Morgen gibt es ein sogenanntes Daily-Stand-up-Meeting, das den aktuellen Stand transparent macht. Außerdem steht am Ende jedes Sprints – das ist eine ein- bis vierwöchige Produktionsphase – ein Review-Meeting, bei dem das Entwicklungsteam dem Product Owner die fertiggestellten Features demonstriert, der diese direkt abnimmt. An die Review schließt sich die Sprint-Retrospektive an. Hierbei überprüft das Scrum-Team gemeinsam mit dem Scrum Master die praktizierte Arbeitsweise, um sie in Zukunft effizienter zu gestalten.
»Agiles Projektmanagement ermöglicht uns einen besseren Überblick und spart Zeit. Deshalb entwickeln wir bei Edenspiekermann seit drei Jahren jedes digitale Projekt agil«
erklärt Michael Börner, Account Director bei Edenspiekermann in Berlin. »Auftraggeber sind am Anfang schon tendenziell skeptisch, vor allem, wenn sie noch nie agil entwickelt haben, aber da der Product Owner immer vom Kunden gestellt wird, lernen auch sie mit der Zeit, diese Methode zu schätzen.«
Sich fest an eine einmal definierte Vorgehensweise zu klammern, würde den Prinzipien des agilen Arbeitens grundlegend widersprechen. Daher finden sich in der Praxis meist Abwandlungen agiler Projektmanagementmethoden. »Wir entwickeln agil, aber nicht dogmatisch nach Scrum oder einer anderen gängigen Methode – wir haben unsere eigene gefunden«, sagt Kristian Kerkhoff, einer der Geschäftsführer der Digitalagentur demodern in Köln. Ähnlich ist das bei der Berliner Kreativagentur Moccu: »Wir haben ein eigenes Vorgehen entwickelt, das unseren Projektgrößen entgegenkommt. Einerseits planen wir nach Wasserfallmanier, lassen aber in der Entwicklung selbst agile Arbeitsweisen zu, die zum Beispiel Änderungen während des Prozesses erlauben«, sagt Moccu-Geschäftsführer Thomas Walter. Dabei setzt Moccu das Projektmanagementtool Redmine (www.redmine.org) ein, mit dessen Hilfe Mitarbeiter sogenannte Tickets mit Aufgaben abarbeiten, die das Team ihnen zugeordnet hat.
Ein agiles Verfahren in Reinkultur ist also in den wenigsten Fällen anzutreffen. Wer den agilen Geist lebt, wird die zunächst gewählte Methode so lange anpassen, bis sie seinen Erfordernissen genügt. Über alle agilen Methoden hinweg Gültigkeit haben jedoch Bausteine wie die Wandzeitung zur Visualisierung des Prozesses, das Daily Stand-up zur Statuserhebung im Team und zum Erkennen von Problemen sowie Retrospektiven, um die Vorgehensweise zu optimieren und bei Bedarf auszubauen.
»Die Regeln des agilen Arbeitens zu lernen, braucht nicht viel Zeit«
meint Michael Börner. Schwieriger sei es schon, diese zu verfeinern und die jeweilige Aufgabenstellung anzupassen. Agile Methoden fördern sowohl auf der inhaltlichen als auch auf der prozessuralen Ebene das Erkennen und Lernen im Team. Für herausfordernde Aufgaben sind sie daher genau das Richtige – aber eben auch nicht immer.
(Autor: Judith Andresen/ae)
Ein gutes Wasserfallprojekt besteht aus einer festen Abfolge von Phasen (rechts) und enthält folgende methodischen Bausteine (bei einfachen Projekten entfällt die Stakeholder- und Risikoanalyse):
1 Auftragsklärung mit dem Auftraggeber
2 Erstellung eines Projektplans mit klaren Zielformulierungen (Gesamt- und Teilprojekte)
3 Stakeholder- und Risikoanalyse durch die Projektleitung
4 Projekt-Set-up mit ganzem Team: Klärung aller wesentlichen Fragen (Kunde, Auftragsziel, Methode unter Berücksichtigung der »Learned Lessons« aus dem letzten Projekt, Abnahmekriterien)
5 Vorstellung und Überprüfung sowie bei Bedarf Anpassung der Stakeholder- und Risikoanalyse mit allen Teammitgliedern
6 Durchführung des Projekts mit regelmäßiger Kontrolle der Ergebnisse, um Transparenz über den Arbeitsfortschritt und das Vorgehen zu erzielen
7 Übergabe und Abnahme durch den Auftraggeber
8 Lessons-Learned-Sitzung, um Fehler im nächsten Projekt zu vermeiden
Kanban ist eine Methode aus der Softwareentwicklung, mit der sich die Anzahl paralleler Arbeiten reduzieren lässt, um den Projektablauf zu beschleunigen und zugleich einen gleichmäßigen Flow zu erreichen. Alle Aufgaben liegen dabei in einem Pool, der bereits priorisierte Tasks enthält. Mittels eines Kanban-Boards, das zum Beispiel aus einem einfachen Whiteboard und Haftnotizen oder Karteikarten besteht, visualisiert das Team alle Tasks und deren Status. Jede Karte oder Notiz repräsentiert eine Aufgabe.
Diese Methode für ein agiles Projektmanagement besteht nur aus wenigen Regeln und eignet sich für umfangreiche Projekte, die damit in einem iterativen Prozess vorangetrieben werden. Der Ansatz beruht auf der Erfahrung, dass Entwicklungen heute in der Regel zu komplex sind, um einen alles erfassenden Plan erstellen zu können. Den langfristigen Plan (Product Backlog) verfeinert und optimiert das Team kontinuierlich und erstellt einen Detailplan (Sprint Backlog) nur für den jeweils nächsten Zyklus (Sprint). Damit lässt sich die Planung auf das Wesentliche reduzieren, was im Gegenzug eine hohe Planungsdisziplin ermöglicht.
Dieser Beitrag wurde als erstes in PAGE 10.2014 veröffentlicht.
