Scrum als Projektkonzept, Teil 2
Projekte nach klassischem Schema führen oft nicht zum gewünschten Erfolg. Deshalb wurden im Laufe der Zeit immer wieder neue Ansätze und Konzepte entwickelt. Hierzu gehört auch Scrum. Scrum ist eine Variante des agilen Projektmanagements und lebt im Wesentlichen von der Flexibilität.
Im ersten Teil unseres Beitrags zum Thema “Scrum als Projektkonzept” ging es um die Idee hinter Scrum, die Rollen und den Ablauf eines Scrum-Projekts.
Hier geht es nun mit Teil II weiter:
Inhalt
Die Regeln bei Scrum
Der Kerngedanke bei Scrum ist, dass das Projektteam nicht an starre Vorgaben gebunden ist, sondern frei agieren und flexibel reagieren kann. Das Projektteam soll sich selbst organisieren können, um die gemeinsamen Ziele zu erreichen. Dennoch kommt auch Scrum nicht ganz ohne Regeln aus.
Diese beschränken sich jedoch auf die wichtigsten Punkte und sind sehr einfach gehalten:
· Aufteilung: Das Projekt und die Aufgabe werden in einzelne Elemente zerlegt, die gut überprüft werden können. Bei diesen Elementen kann es sich um Arbeitspakete oder um Aspekte des Produkts, das im Rahmen des Projekts entwickelt werden soll, handeln.
· Transparenz: Alle Mitglieder des Projektteams kommen täglich zusammen, um in kurzen Meetings sowohl die Fortschritte als auch mögliche Hindernisse zu besprechen. Die bisherigen Ergebnisse werden für alle sichtbar dokumentiert. Dadurch ist jedes Projektmitglied stets auf dem aktuellen Stand.
· Kontrolle: Die Lösungen und Ergebnisse der einzelnen Arbeitspakete und Teilaufgaben werden regelmäßig abgeliefert und bewertet.
· Flexibilität: Die Projektziele werden nicht starr festgeschrieben. Stattdessen werden sie nach jeder Lieferung neu beurteilt, mit den ursprünglichen Ideen abgeglichen und bei Bedarf angepasst.
Die Kontrollmechanismen bei Scrum
Um zu gewährleisten, dass alle Projektmitarbeiter über den Verlauf, die Entwicklung und den aktuellen Stand des Projekts informiert sind, gibt es ein sogenanntes Taskboard oder Sprint-Taskboard. Auf dieser Tafel sind alle Teilaufgaben in Form von Tickets aufgeführt und dabei nach Bearbeitungsstand sortiert.
Dadurch sieht jeder Projektmitarbeiter auf einen Blick, welche Teilaufgaben noch erledigt werden müssen, welche Teilaufgaben gerade bearbeitet werden und welche Teilaufgaben schon fertig sind. Für die Bearbeitung werden aber immer nur so viele Tickets freigegeben, wie das Projektteam bewältigen kann. Kommt das Projekt an einer Stelle ins Stocken, stauen sich dort deshalb die Tickets. Das Projektteam kann daraufhin entsprechend gegensteuern.
Teilaufgaben, die eilig oder besonders wichtig sind, werden gekennzeichnet, beispielsweise durch eine andere Farbe. Diese Tickets können dann vorgezogen werden. Auf diese Weise steuert das Projektteam sowohl die Verteilung der Aufgaben als auch den Arbeitsfluss eigenständig.
Dient das Taskboard nicht nur als Übersicht, sondern wird damit auch der Projektablauf gesteuert, wird es als Kanbanboard bezeichnet.
Ein weiteres Kontrollinstrument bei Scrum nennt sich Burndown-Chart. Hierbei handelt es sich um eine Grafik oder ein Diagramm, das den Verbrauch der Ressourcen, meist Budget und Zeit, abbildet. Dazu werden der geplante Aufwand und der Ist-Zustand eingezeichnet.
Die täglichen Meetings tragen dazu bei, dass der Ressourcenverbrauch sehr aktuell dargestellt werden kann. Gleichzeitig können zeitnah Korrekturmaßnahmen eingeleitet werden, wenn sich zeigt, dass das geplante Budget wohl nicht eingehalten werden kann.
Die Anfänge von Scrum
Die ersten Erfahrungen mit dem agilen Projektmanagement liegen inzwischen über 30 Jahre zurück. Seinerzeit bestanden die Ziele darin, die Entwicklung von Produkten schneller und kundenorientierter zu gestalten. Dies sollte gelingen, indem Bürokratie und Planung reduziert und dafür die Zusammenarbeit zwischen den Mitgliedern des Projektteams intensiviert würde.
Außerdem sollten sich die Projektmitarbeiter nicht nur häufiger untereinander austauschen, sondern auch direkt mit den Kunden, den Anwendern und den Auftraggebern kommunizieren.
Hirotaka Takeuchi und Ikujiro Nonaka belegten in einem Fachbeitrag, dass kleine, interdisziplinäre Projektteams am effektivsten sind, wenn es gilt, möglichst schnell neue Produkte mit höchstem Kundennutzen zu entwickeln. Der Fachbeitrag erschien 1986 im Management-Magazin „Harvard Business Review“ und schon damals sprachen die Autoren von Scrum.
Der Wunsch, Bürokratie und starre Regeln abzubauen, ging einher mit dem Aufkommen des Lean Managements Ende der 1980er-, Anfang der 1990er-Jahre. Die Idee war, alle Tätigkeiten im Rahmen der Wertschöpfung aufeinander abzustimmen und überflüssige Aktivitäten gleichzeitig zu vermeiden.
Ressourcen sollten nicht unnötig verschwendet, sondern optimal ausgeschöpft werden. Im Deutschen wird für diesen Ansatz auch der Begriff Schlankes Management verwendet. Im Laufe der Zeit haben sich daraus schließlich verschiedene Methoden und Konzepte entwickelt, die als agiles Projektmanagement bezeichnet werden.
Die Grenzen von Scrum
Scrum stößt längst nicht überall auf Zustimmung. So gibt es durchaus Teammitglieder, die mit der sehr transparenten Art nicht zurechtkommen. Schließlich werden die Leistungen jedes Teammitglieds deutlich sichtbar und zum Inhalt der täglichen Besprechungen.
Hat ein Teammitglied sein Ticket nicht erledigt, können die anderen Teammitglieder nicht weitermachen und die Arbeitsabläufe verzögern sich. Dies wird offen kommuniziert, doch längst nicht jeder Mitarbeiter kann mit der direkten Kritik umgehen. In der Folge können sich Konflikte entwickeln, die die Kommunikation deutlich erschweren. Auch der Ausstieg eines Projektmitglieds ist nicht ausgeschlossen.
Eine andere Problematik kann sich dann ergeben, wenn einzelne Projektmitglieder zu dominant auftreten. Statt die gemeinsamen Projektziele zu verfolgen, versuchen sie, ihre Ansichten und Interessen durchzusetzen. Dies kann den Projekterfolgt deshalb gefährden, weil es kaum Korrekturmöglichkeiten gibt. Denn die Idee bei Scrum ist ja gerade, dass sich das Team selbst organisiert und der Scrum-Master lediglich als Moderator auftritt.
Auch für gestandene Projektleiter ist Scrum eine Herausforderung. Während sie im klassischen Projektmanagement die zentrale Rolle und die Führungsfunktion übernehmen, sind sie bei Scrum nur der Moderator. So mancher Projektleiter fühlt sich dadurch degradiert.
Zudem ist es bei Scrum nicht möglich, mit besonderen Einzelleistungen zu glänzen, um sich für den nächsten Karriereschritt zu empfehlen. Denn dies würde dem Teamgedanken und dem gemeinsamen Erreichen der Projektziele widersprechen. Aber auch die Geschäftsleitung muss sich darauf verlassen, dass das Projektteam am Ende tatsächlich die erwarteten Ziele erreicht. Dies wiederum setzt einen hohen Vertrauensvorschuss voraus, der sich nicht mit jeder Unternehmenskultur vereinbaren lässt.
Nicht zuletzt hängt es aber auch vom Projekt als solches und den Rahmenbedingungen ab, ob Scrum in Frage kommt. Scrum eignet sich hauptsächlich für Projekte, bei denen Produkte oder Dienstleistungen entwickelt oder neue Technologien eingeführt werden sollen. Bei Projekten, die im Bereich der Organisationsentwicklung, des Change Managements oder der Personalentwicklung angesiedelt sind, ist das Ergebnis meist zu unspezifisch, um vom Produkteigner abgenommen werden zu können.
Hier kommt Scrum deshalb bestenfalls für Teilaufgaben in Betracht. Daneben können die Rahmenbedingungen einen Strich durch die Rechnung machen. Sind die Projektmitglieder beispielsweise räumlich voneinander getrennt und tägliche Meetings folglich unmöglich oder kann der Produkteigner die Anforderungen nicht klar benennen, scheidet Scrum als Projektkonzept aus.
Mehr Tipps, Anleitungen und Ratgeber:
- Projekt Kommunikation und Vortrag: 3 Sprechübungen
- Projekt selbstbewusster Auftritt: 7 Tipps für ein besseres Durchsetzungsvermögen
- Erfolgreiches Projektmanagement mit dem 9-Punkte-Schema
- Wie sich Projektleiter die Unterstützung der Geschäftsleitung sichern
- Scrum als Projektkonzept Teil 1
Thema: Scrum als Projektkonzept, Teil 2
Übersicht:
Fachartikel
Verzeichnis
Über uns
