Agiles Projektmanagement

Schon vor einiger Zeit habe ich in einem Beitrag darauf hingewiesen, welch ungeheure Geldsummen in Projekten vernichtet werden. Die Fehler passieren sowohl auf der strategischen als auch auf der operativen Ebene. Untersuchungen zeigen zum Beispiel, dass auch heute noch fast jedes fünfte Softwareprojekt komplett scheitert. Und das, obwohl man bereits vor knapp zwanzig Jahren damit begonnen hat, Methoden zu entwickeln, die über den klassischen Projektmanagementansatz hinausgehen.

Nachdem gescheiterte Projekte ja auch im Kunst- und Kulturbereich nichts Außergewöhnliches sind, hat mich das Thema natürlich interessiert und so ist in einem ersten Schritt vor einigen Wochen für die IT-Zeitschrift Monitor ein Beitrag über agiles Projektmanagement im Bereich der Softwareentwicklung entstanden.

Die Idee des agilen Projektmanagements hat mich von Anfang an fasziniert und so war es naheliegend, herauszufinden, ob sich dieser oder ähnliche Ansätze auch außerhalb des IT-Bereichs finden lassen bzw. ob sie sich auf den Kunst- und Kulturbereich übertragen lassen.

Neue Ansätze in der Softwareentwicklung

Was bedeutet agiles Projektmanagement nun? Dabei handelt es sich um eine Methode, die, ich erwähnte es schon, vor allem im Bereich der Softwareentwicklung angewendet wird. “Die agile Softwareentwicklung“, so heißt es bei Wikipedia, “entstand als Gegenbewegung gegenüber (anderen) oft als schwergewichtig und bürokratisch angesehenen Softwareentwicklungsprozessen […].” Dahinter verbirgt sich eine Reduktion der Vorgehensweisen und Regeln des klassischen Projektmanagements auf einige wenige Regeln und Praktiken.

Während man bei der klassischen Methode bis zum Ende des Softwareentwicklungsprozesses auf nutzbare Ergebnisse warten musste, setzt die agile Softwareentwicklung auf möglichst schnelle Ergebnisse. Die meisten Web2.0-Anwendungen werden nach diesem Prinzip entwickelt. Wir alle kennen die Beta-Versionen, die noch nicht voll ausgereift sind, aber bereits (halbwegs) funktionieren. Damit gibt es nicht am Ende des Entwicklungsprozesses ein böses Erwachen, sondern die Programme werden bereits sehr frühzeitig einem Praxistext unterworfen.

Den Vorteil habe ich in meinem Monitor-Beitrag so beschrieben:

“Das schnelle und möglichst frühzeitige Reagieren auf Änderungen soll Kostenexplosionen verhindern. Klar ist, dass Änderungen Geld kosten. Je später sie durchgeführt werden, desto höher werden die Kosten. Das klassische Projektmanagement versucht, das Vorhaben so gründlich zu planen, dass Änderungen später nicht mehr nötig sind. Der Prozess, der aus der Definition der Anforderungen, Analyse, Implementierung und Test besteht, wird nur einmal durchlaufen. Der Kunde merkt also im schlimmsten Fall erst bei der Abnahme, dass das Produkt seinen Vorstellungen nicht oder nur teilweise entspricht. Änderungswünsche werden, so das möglich ist, im Rahmen eines Change-Request-Verfahrens abgewickelt. Da in dieser späten Phase häufig weder Zeit noch Geld zur Verfügung stehen, verschiebt man die Änderungen auf das Folgeprojekt, was weitere Kosten verursacht.”

Die agile Softwareentwicklung durchläuft diese Phasen ( Definition der Anforderungen, Analyse, Implementierung und Test) nicht nur einmal, sondern mehrmals. Auf diese Weise erhält der Kunde bereits nach dem ersten Durchlauf das bereits erwähnte lauffähige Teil-Produkt, das er testen kann. Nicht erst am Ende des Entwicklungsprozesses, sondern nach jeder dieser „Iterationen“ sind Anpassungen möglich. Dokumentiert werden diese Änderungen im so genannten „Backlog“, einer permanent aktuellen und priorisierten Liste von Anforderungen, welche die umfassende Dokumentation aus dem klassischen Projektmanagement ersetzt.

Umgesetzt wird ein solches Projekt über unterschiedliche agile Prozesse, zum Beispiel Scrum, eine der zurzeit beliebtesten Methoden. Auch hier ist die Vorgehensweise eine iterativ-inkrementelle, für die ein Product Owner als Kundenvertreter, der die fachlichen Anforderungen verwaltet und diese priorisiert, der ScrumMaster als der Prozessverantwortliche und das Entwicklerteam benötigt werden.

Die Vorgehensweise habe ich so beschrieben:

“Umgesetzt werden die im Backlog formulierten Anforderungen im Rahmen von so genannten Sprints, die typischerweise zwei oder vier Wochen dauern. Am Beginn eines jeden Sprints findet das Sprint Planning Meeting statt, in dem die Arbeit für den Sprint geplant wird. In Angriff genommen werden immer die jeweils am höchsten priorisierten Anforderungen aus dem Backlog. Das Team legt sich fest, die geplante Funktionalität bis zum Sprint-Ende abzuliefern und wird im Gegenzug dafür während der Dauer des Sprints gegen Änderungen von außen geschützt.

An jedem Tag des Sprints wird ein maximal 15-minütiges Daily Scrum Meeting abgehalten, das dazu dient, die Team-Mitglieder zu synchronisieren und zu erkennen, welche Probleme dem Team im Weg stehen. Während des Sprints werden alle notwendigen Aufgaben vorgenommen, so dass ein voll funktionierendes, potenziell auslieferbares Inkrement an Funktionalität entsteht.

Am Ende dieser Phase steht ein Sprint Review Meeting (…). Hier werden die Arbeitsergebnisse vom Product Owner als Repräsentant des Kunden begutachtet. Die Sprint Retrospektive dient der prozessualen Betrachtung des Sprints und erlaubt Verbesserungsvorschläge für die weitere Arbeit. Vor Beginn des nächsten Sprints kann der Product Owner mittels erneuter Priorisierung des Backlogs auf allfällige Änderungen reagieren und das Ziel für die weitere Arbeit vorgeben.”

Agiles Projektmanagement für die Stadt New York

Soweit zur Softwareentwicklung. Wie sieht es aber außerhalb des IT-Bereichs aus? Michele Sliger hat im “theagileblog” ein sehr anschauliches Beispiel gefunden. In einem Beitrag erzählt sie von einem Vortrag, den der frühere Bürgermeister von New York, Rudy Giuliani, gehalten hat. In dem, was er über Leadership erzählte, erkannte sie den agilen Ansatz.

Giuliani, so schreibt Sliger, identifizierte nach seiner Wahl zum Bürgermeister in einem ersten Schritt die wichtigsten Aufgaben, da er nicht über die Zeit verfügte, alle Probleme zu lösen. Er erstellte ein Backlog, in dem er alle anstehenden Probleme auflistete und sie entsprechend ihrer Wichtigkeit ordnete. Ganz oben stand für ihn die Verringerung der Zahl der Verbrechen in der Stadt.

Seine Strategie basierte auf der “broken windows theory“, die auf einem Aufsatz von James Q. Wilson and George L. Kelling basiert. Dort heißt es, so Sliger: “by focusing on fixing small things like vandalism, further neighborhood damage is discouraged and major crime is prevented from developing.”

Giuliani übernahm diesen Ansatz und konzentrierte sich auf drei Problemfelder:

• Schwarzfahren in der U-Bahn
• Trunkenheit in der Öffentlichkeit
• Vandalismus

Der Bürgermeister ließ nun jeden Tag in jedem Bezirk die Zahl der Verbrechen erheben. Anfangs geschah dies nur, um zu sehen, ob durch die Maßnahmen die Zahl der Verbrechen auch wirklich abnahm. Aber die Erhebung hatte einen Nebeneffekt, wie Sliger in ihrem Beitrag schreibt:

“…but then they began to notice patterns. By checking every day, they were able to shift the police force around to areas and times where they were most needed. They were constantly inspecting and adapting based on the metrics they were gathering.”

Auf diese Weise gelang es Giuliani, die Zahl der Verbrechen bis zum Ende seiner Amtszeit um 70 Prozent zu verringern. Sein Verständnis von Leadership baut, so Sliger, auf zwei Säulen auf:

• have a vision
• execute and accomplish

Die Vision reicht Giuliani zufolge nicht. “Without number two, you’re just a philosopher – not a leader”, wird er zitiert. Erfolg habe nur, wer an diesen glaube, ohne aber unrealistischen Träumen nachzuhängen. Sliger schreibt weiter:

“Resolving those challenges called for input from everyone, and resulted in what he termed “blue sky sessions” – where anyone could suggest any solution they wanted, no matter how crazy it sounded. Giuliani affirmed that there has to be a level of trust for this to work, and that it is the leader’s responsibility to establish this trusting and collaborative environment.”

Hinter all diesen Maßnahmen erkennt Sliger den agilen Ansatz, für den folgende Faktoren von Bedeutung sind:

• “working in an timebox,
• using a prioritized backlog,
• defining and measuring success,
• inspecting and adapting,
• effective leadership,
• collaboration in an environment of trust.”

Und der Kunst-und Kulturbereich?

Im nächsten und letzten Schritt habe ich mir die Frage gestellt, ob sich dieser Ansatz auch auf unsere Arbeit im Kunst- und Kulturbereich übertragen lässt. Ich denke schon. Und wenn wir uns diese kurze Liste anschauen, dann erkennen wir auch recht schnell, wo die Probleme liegen.

Zeit ist manchmal ein recht dehnbarer Begriff. Meine Erfahrung ist, dass wir zwar recht schnell sind, wenn es um das Erstellen von Zeitplänen geht. In der Umsetzung schaut die Sache dann aber anders aus.

Und wie sieht es mit der Prioritätenliste aus? Für mich geht es hier um Strategien, um Methoden, mit deren Hilfe sich Strategien entwickeln lassen. Es geht aber auch um Flexibilität, um die Reihung der Projekte wieder zu ändern. Was heute gilt, muss morgen schon nicht mehr richtig sein. Das heißt aber nicht, unvorbereitet darauf zu warten, was die Zukunft bringt. Die strategische Ebene fehlt mir häufig im Kunst- und Kulturbereich. Wenn wir ihr mehr Platz einräumen, dann werden wir wahrscheinlich mit mancher Situation besser umgehen können.

Und ein letzter Aspekt scheint mir wichtig, die Erfolgskontrolle. Woran messen wir den Erfolg? Ich will hier gar nicht vom künstlerischen Erfolg sprechen, sondern von den Vorhaben, die wir in den Bereichen Projektmanagement, Marketing oder Kommunikation angehen. Gibt es wirklich Diskussionen darüber, ob etwas gut oder schlecht gelaufen ist? Und wenn es in die Hose gegangen ist, was waren die Gründe dafür? Was können wir beim nächsten Mal besser machen?

Die von Michele Sliger aufgelisteten Punkte scheinen auf den ersten Blick banal zu sein. Aber sie bergen jede Menge Sprengstoff. Sie setzen vor allem voraus, dass man seine Hausaufgaben macht, dass man über die entsprechenden Tools verfügt. Agiles Projektmanagement bedeutet nicht, dass wir die alten Instrumente vergessen können. Ganz im Gegenteil: sie waren noch nie so wichtig wie heute.