Projektmanagement im Wandel

Die Scrum-Revolution

Die Scrum-Revolution

Projektmanagement im Wandel

Die Scrum-Revolution


Es ist kein Geheimnis: Viele Projekte, die nach der Wasserfallmethode und mit traditionellen Projektmanagement-Tools gemanagt werden, scheitern. Und zwar große wie kleine. Es wird viel geplant, dokumentiert und koordiniert, doch die Zielsetzungen werden häufig nicht erreicht. Warum ist das so?

Die Scrum-Revolution

Ist die traditionelle Form des Projektmanagements überholt und nicht länger geeignet, den heutigen Anforderungen in Bezug auf Kosten, Produktivität und Ergebnisorientierung gerecht zu werden? Jein, denn grundsätzlich kommt es auf das Projekt und die Organisation an. Fest steht aber, es gibt inzwischen Alternativen zum klassischen Ansatz, zum Beispiel die agile Projektmanagement-Methode Scrum.

Scrum und das Prinzip der Selbstorganisation
Scrum (auf Deutsch: Gedränge, als ein Spielzug aus dem Rugby) ist ein Framework für das Projektmanagement nach agilen Prinzipien und hat seinen Ursprung in der Softwareentwicklung. Seit seiner Entstehung in den frühen 1990er Jahren hat sich Scrum von einem Vorgehen aus der Softwareentwicklung hin zu einer allgemeinen Projektmanagement-Methode entwickelt. Eine wichtige Grundlage ist die Selbstorganisation der Teammitglieder, die in aufeinander aufbauenden (inkrementellen) und sich wiederholenden (iterativen) Arbeitszyklen das Produkt entwickeln. Einen Projektleiter im traditionellen Sinne gibt es nicht.

Scrum-2

Vom Paradigmenwechsel im Projektmanagement

Die Idee des agilen Projektmanagements ist alles andere neu. Schon vor über dreißig Jahren und im Zusammenhang mit der Lean-Management-Welle Ende der 1980er Jahre bestand ein reges Interesse an der agilen Methodik. Erste konkrete Konzepte entstanden Anfang der 1990er Jahre. Im Vordergrund stand damals der Wunsch, Produkte ergebnisorientierter zu entwickeln. Weniger Verwaltungs- und Planungsaufwand sowie die verbesserte Kommunikation und Kooperation zwischen den Mitarbeitern des Produktentwicklungsteams untereinander, aber auch dem Kunden gegenüber standen im Fokus. Der Ruf nach mehr Eigenständigkeit für den Einzelnen, optimierter Teamarbeit sowie einfachen Verhaltensrichtlinien und klaren Bewertungsmaßstäben wurde laut. Die Leitgedanken des Qualitätsmanagements und der bedarfsorientierten Produktionslogistik dienten in diesem Zusammenhang zur ersten Orientierung. So manche Konzepte und Techniken des agilen Projektmanagements haben in dieser Bewegung ihren Ursprung. Aber was macht agiles Projektmanagement und damit Scrum genau anders?

Im klassischen Projektmanagement werden in einer Planungs- und Spezifikationsphase vorab der Umfang der in Auftrag gegebenen Lösung festgelegt und der Realisationszeitraum und die Kosten möglichst exakt geschätzt („Plan Driven Development“). Oft wird im Projektverlauf dann festgestellt, dass sowohl Zeit als auch Budget zu knapp veranschlagt waren. Das belastet alle Projektbeteiligten und führt zu wirtschaftliche Einbußen.

Scrum-1

Der agile Ansatz arbeitet genau anders herum. Hier werden beim Projektstart Zeit und Budget fixiert. Erst im nächsten Schritt werden mit dem Kunden die Anforderungen besprochen, die sich innerhalb dieses definierten Rahmens umsetzen lassen („Vision Driven Development“). Neu ist außerdem, dass der Kunde den Projektverlauf jederzeit – auch nach dem Projektstart – beeinflussen kann.

Mehr Motivation und Produktivität dank Scrum

In einem Scrum-Projekt sollen einfache und für alle gut nachvollziehbare Regeln gelten, die helfen sollen, das Projektziel möglichst effizient zu erreichen. Scrum vertraut auf die Fähigkeiten eines erfahrenen Teams und versucht, die strukturellen und organisatorischen Voraussetzungen dafür zu schaffen, dieses Team möglichst ungestört arbeiten zu lassen. Die Methode stützt sich auf die Annahme, dass das Team das Projekt zum Erfolg führen wird. Vorausgesetzt, es verfügt über die notwendige Entscheidungsfreiheit, der Projektfortschritt ist für alle transparent, man tauscht tagesaktuell Informationen zum Projekt aus und stimmt sich entsprechend ab.

Unverzichtbar beim agilen Projektmanagement: Das Team ist interdisziplinär zusammengesetzt und darf sich selbst organisieren. Die neue Entscheidungsfreiheit, die potenzielle Fehlentscheidungen einbezieht und nicht bestraft, ermöglicht es jedem Einzelnen, seine Arbeit als wertvoll wahrzunehmen. Das motiviert und führt zu besseren Ergebnissen und Lösungen.

Warum steigert Scrum die Produktivität?

Durch Scrum werden dysfunktionale Strukturen und Abläufe aufgedeckt und aufgelöst.

Wenn interdisziplinäre Teams gemeinsam an der Produktentwicklung arbeiten, wird dabei wie von selbst Know-how geteilt. Notwendige Abstimmungen erfolgen direkt. Die Kommunikation ist hierdurch zielgerichteter und effizienter. Scrum-Teams kommen ohne personal- und kostenintensive Verwaltungs- oder Kontrollinstanzen aus. Es gibt klare Verantwortlichkeiten. Konflikte und Probleme werden früh erkannt und besprochen. Dysfunktionale Strukturen und Abläufe werden aufgedeckt und aufgelöst. Es fällt schnell auf, wenn etwas nicht zum anvisierten Ergebnis führt. Fehler können somit kurzfristig korrigiert werden. Das spart Kosten.

Vom agilen Projekt zur agilen Organisation

Das Verständnis von Scrum als einer Methode des agilen Projektmanagements hat sich über die letzten Jahre hinweg tiefgreifend verändert. Anders als etwa eXtreme Programming (XP) oder das Feature Driven Development (FDD) handelt es sich bei Scrum um ein reines Framework. Es macht keine spezifischen Vorgaben, wie Produkte zu entwickeln sind. Stattdessen legt es den Grundstein für zielgerichtete Kommunikation und optimierte Zusammenarbeit zwischen den Teammitgliedern sowie zwischen Team und Kunde. Ein wesentliches Merkmal von Scrum ist, dass es Antworten gibt auf die Frage, wie ineffizient und suboptimal arbeitende Teams, Abteilungen, Organisationseinheiten und sogar ganze Unternehmen straff und agil geführt werden können. Meist wird Scrum zu Testzwecken zunächst auf Team- oder Projektebene eingesetzt. Viele belassen es dabei. Andere Unternehmen sind mutiger. Sie gestalten auf der Basis von Scrum sukzessive ihre gesamte Organisation um. Unternehmensweites Umdenken bildet hierfür die Voraussetzung.

Agilität lässt sich nicht top-down verordnen, fängt aber oben an

Managementansätze wie Scrum stellen Mitarbeiter in Unternehmen nicht selten vor große Probleme, denn an den Schnittstellen zur restlichen, traditionell geführten Organisation kommt es oft zu Konflikten. Als besonders problematisch zu bewerten ist, wenn das Top-Management im Unternehmen nicht hinter dem Paradigmenwechsel steht, auf dem Scrum aufsetzt. Das Management muss davon überzeugt sein, dass die Projektteams eigenverantwortlich Lösungen erarbeiten und letztlich das Produkt beziehungsweise Ergebnis herauskommt, das der Kunde und/oder der Product Owner erwartet. Ein solcher Vertrauensvorschuss und so viel Eigenständigkeit passen nicht mit jeder Unternehmenskultur oder Führungspersönlichkeit zusammen. Mit der Einstellung, alles bleibt wie eh und je, nur „die da unten“ sind von jetzt an agil, lässt sich jedoch wenig bewegen.

Lesen Sie auch: Agile im Konzern: Kann das funktionieren?

Agiles Projektmanagement verlangt nach einem neuen Blickwinkel, aus dem die Projektorganisation eines Unternehmens betrachtet und bewertet wird. Ohne eine entsprechende Unternehmenskultur, die zuversichtlich die Eigeninitiative und das Verantwortungsbewusstsein eines jeden Einzelnen fördert, und ohne Mitarbeiter, die neben der reinen Fachkompetenz auch über soziale und methodische Fähigkeiten verfügen, lässt sich eine solche Veränderung nicht realisieren. Gelingen kann der Paradigmenwechsel hingegen, wenn sich Führungsebene und Mitarbeiter unter Scrum-Vorzeichen neu miteinander vernetzen, um so einen Rahmen zu schaffen, in dem step-by-step Vertrauen, eigenverantwortliches Handeln und Interdisziplinarität aufgebaut werden können.

Scrum modifizieren? Für den Anfang keine gute Idee!

Hat ein Unternehmen sich entschieden, Scrum zu implementieren, muss es zunächst der Versuchung widerstehen, das Framework von vorneherein an die Prozesse oder das Rollenverständnis im Unternehmen anpassen zu wollen und es um wichtige Elemente zu beschneiden. Typische Beispiele für unternehmensspezifische Modifikationen, so genannte ScrumButs, sind:

Wir setzen Scrum ein, aber wir …

  • … bündeln die Daily Scrums in einem wöchentlichen Meeting.
  • … benötigen keinen Scrum Master. Das Team regelt das alleine.
  • … verzichten auf die umfangreiche Aufwandsschätzung für einzelne Aufgaben.
  • … verlängern einen Arbeitszyklus, bis wir das Ziel erreicht haben.
  • … kommen ohne Review aus.

Empfehlenswert ist ein derartiges Vorgehen nicht. ScrumButs zeigen in der Regel, dass die Bedeutung des jeweiligen wegrationalisierten Elementes noch nicht erfasst wurde. So ist zum Beispiel die Arbeit mit fest definierten Zeitabschnitten (auch: Timeboxes) in Scrum unverzichtbar. Schafft man die Arbeit innerhalb einer Iteration jedoch nicht, sollte die Lösung nicht darin bestehen, einfach den Zeitraum zu verlängern. Vielmehr sollte man versuchen, das Projekt in kleinere Teilaufgaben zu untergliedern. Ein unvollständiges beziehungsweise schlechtes Gesamtverständnis von Scrum kann zudem schnell dazu führen, die Methode als ungeeignet zu verteufeln und für den Projektmisserfolg verantwortlich zu machen. Von zentraler Bedeutung ist es deshalb, Scrum in einem ersten Schritt genau und sauber einzuführen.

Scrum implementieren – Mögliche Stolpersteine

Scrum erfordert ein unternehmensweites Umdenken.

Bei der Implementierung von Scrum können auf verschiedenen Ebenen Konflikte und Probleme auftauchen, denn Scrum erfordert ein unternehmensweites Umdenken. Nicht allen Mitarbeitern ist das möglicherweise so ad hoc und von heute auf morgen möglich. Andere kommen schlicht mit der Scrum-Philosophie nicht zurecht. Denn die neue Transparenz macht die Leistung jedes einzelnen sehr schnell und einfach bewertbar. Die Gründe für Verzögerungen im Arbeitsablauf in den täglich angesetzten Kurzbesprechungen treten damit schnell zu Tage. Wenn ein Teammitglied seine Aufgabe nicht erledigt, kommen die Kollegen nicht voran. Ein solcher Vorfall wird offen und direkt angesprochen. Nicht jedem liegt diese Form der unmittelbaren Kritik.

Ebenfalls problematisch: Einzelne Teammitglieder versuchen sich als Teamanführer zu etablieren. Da der Scrum Master nicht autorisiert ist, die Selbstorganisation des Teams zu beeinflussen, gibt es in einem solchen Fall kaum Korrekturmöglichkeiten.

Nicht selten hadern auch die Projektleiter mit Scrum. Sie fühlen sich degradiert. Während sie beim traditionellen Projektmanagement eine zentrale Führungsrolle besetzen, fungieren sie im Rahmen von Scrum lediglich als eine Art Facilitator. Dies kann dazu führen, dass sich der ein oder andere frisch ernannte Scrum Master wie ein Projektleiter verhält und die Teamleitung für sich in Anspruch zu nehmen versucht. Bei Scrum hat jedoch das Team die Entscheidungsgewalt.

Lesen Sie auch: 6 Agile-Tools im Vergleich: Agilo for Scrum – ZenHub – Active Collab – ScrumDo – JIRA – Pivotal Tracker

Auch die organisatorischen Rahmenbedingungen spielen eine Rolle für den Erfolg oder Misserfolg von Scrum. Wenn beispielsweise das Projektteam räumlich getrennt ist, Spezialisten nur zeitlich begrenzt zur Verfügung stehen oder die Anforderungen an das Endprodukt ungenau und unzureichend beschrieben und dokumentiert sind, kann dies die Realisation eines Projektes mit Scrum maßgeblich behindern. Außerdem sind agile Methoden nicht per se für jedes Projekt geeignet. In Projekten, die kein klar spezifiziertes Ergebnis zum Ziel haben, wie es etwa beim Veränderungsmanagement, der Organisations- und Personalentwicklung vorkommen kann, eignet sich Scrum daher manchmal nur für die Bearbeitung von Teilaufgaben.

Fazit

Wer Scrum einführen will, muss mehr tun, als sich mit der reinen Theorie zu befassen. Zwar sind die Kerngedanken und Leitideen von Scrum einfach nachzuvollziehen, der Transfer in die tägliche Praxis erfordert jedoch eine gewisse Bereitschaft zur Konsequenz. Ist man hierzu in der Lage, dann ebnet Scrum jedoch den Weg hinaus aus der klassischen Projektmanagement-Denkweise und legt den Grundstein für mehr Produktivität und verbesserte Kommunikation. Der Paradigmenwechsel erfordert ein Umdenken. Innerhalb der Fachabteilungen, innerhalb der Gesamtorganisation und auf Kundenseite. Um Agilität fest in der Organisationskultur zu verankern, benötigen Unternehmen einen langen Atem, den Willen zur stetigen Prozessverbesserung und die Bereitschaft, aus Fehlern zu lernen.

Ebenfalls essentiell: Alle Mitarbeiter müssen einbezogen werden. Dies ist eine der wichtigsten Voraussetzungen, um das Prinzip der Agilität im Unternehmen mit Leben zu füllen und zum festen Bestandteil der Unternehmenskultur werden zu lassen.

 GLOSSAR

Begriff Bedeutung
Product Owner Der Product Owner nimmt die Auftraggeberrolle wahr und wird im Allgemeinen vom Fachbereich gestellt. Er beschreibt und priorisiert die Anforderungen an das Produkt und ist hierdurch maßgeblich für den Projekterfolg verantwortlich. Er hält regelmäßig Rücksprache mit den Stakeholdern und steht dem Team bei Fragen für Auskünfte zur Verfügung.
Scrum Master Er ist vor allem Moderator, Coach und Dienstleister für das Projektteam. Er sorgt dafür, dass Hindernisse und Störfaktoren im Umfeld des Teams beseitigt werden. Er beschafft die notwendigen Ressourcen und ist Ansprechpartner für Außenstehende. Er hilft dem Team bei methodischen Problemen und stellt sicher, dass die Scrum-Regeln eingehalten werden. Der Scrum Master arbeitet eng mit dem Product Owner zusammen.
Entwicklungsteam Ein Scrum-Team sollte zwischen fünf bis zehn Mitglieder umfassen, die alle Aufgaben selbst organisieren. Innerhalb des Teams gibt es keine Hierarchie. Im Hinblick auf die Rechte und Pflichten unterscheiden sich die Teammitglieder nicht, lediglich in Bezug auf die Kompetenzen und die dazugehörigen Zuständigkeiten. Alle relevanten Fachbereiche sollten bei der Teamzusammenstellung einbezogen werden.
Product Backlog Der Product Owner erstellt anhand von Nutzenbeschreibungen eine priorisierte Liste mit Produktanforderungen, das Product Backlog. Das Dokument wird laufend und von allen Projektbeteiligten gepflegt. Änderungswünsche oder neue Produktanforderungen werden direkt im Product Backlog vermerkt und dokumentiert. Wichtig ist in diesem Kontext, dass das Team Änderungswünsche und neue Anforderungen nicht als Störung bewertet, sondern vielmehr als Korrektiv, das hilft, ein zielgerichtetes Ergebnis zu produzieren.
Sprint: Planung und Durchführung Ein Sprint ist als ein möglichst störungsfreier Arbeits- beziehungsweise Entwicklungszyklus von zwei bis vier Wochen definiert. In einer ersten Besprechung werden die Rahmenbedingungen abgesteckt: Wo und wann finden die täglichen Teammeetings statt? Wie soll der allgemeine Aufbau des Produkts und/oder das Projektergebnis aussehen? Welche Meilensteine sind definiert? In welche Teilaufgaben lässt sich das Projekt untergliedern? Welche Konventionen und Schnittstellen sind einzuhalten? Eine einzelne zu erledigende Aufgabe wird Scrum Task genannt. Alle Tasks sind im sogenannten Sprint-Backlog aufgeführt, quasi die To-Do-Liste für das Entwicklerteam. Aus jedem Arbeitszyklus kann das Team im Sprint Review sogenannte „Lessons Learned“ ableiten und für die weiteren Zyklen nutzen. Das Produkt gewinnt mit jeder Iteration an Umfang und Qualität. Der Projektfortschritt bleibt für den Kunden auf diese Weise stets transparent.
Daily Scrum Meeting Nachdem ein Sprint begonnen hat, treffen sich das Team und der ScrumMaster täglich zum Daily Scrum Meeting. Das informelle Planungsmeeting dauert maximal 15 Minuten. Es wird oft im Stehen abgehalten, um es kurz zu halten. In dem Meeting hat jedes Teammitglied die Aufgabe, drei Fragen zu beantworten: 1) Was habe ich gestern getan, um das Sprintziel zu erreichen? 2) Was werde ich heute tun, um es zu erreichen? 3) Gibt es ein Problem, welches mich davon abhält, meine Aufgabe zu realisieren?
Sprint Review/Retrospektive Die Sprint-Retrospektive ermöglicht dem Team, systematisch zu lernen. Hier wird analysiert, welche Arbeitsprozesse verbessert werden müssen, damit das Team effektiver arbeiten kann. Die Resultate aus der Retrospektive werden im sogenannten Impediment Backlog festgehalten und lassen sich so als konkrete Verbesserungsvorschläge in die nächste Sprintplanung einbeziehen.

Aufmacherbild: Close up of rugby players arm / Urheberrecht: Paolo Bona

Sebastian Helfmann ist Teamleiter des Entwicklungsteams der ADACOR Hosting im Network Operation Center (NOC) am Standort des Unternehmens in Offenbach am Main. Als zertifizierter Professional Scrum Master ist es zudem seine Aufgabe, dem Scrum Team der ADCAOR moderierend zur Seite zu stehen, um die Lösungs- und Entscheidungsfindung anzuregen und zu unterstützen.