Scrum © Fotolia/aa_amie

Projekte leiten mit Scrum

Scrum ist eine Methode des Projektmanagements, die ihre Wurzeln in der agilen Softwareentwicklung hat. Jedoch ist ihre Anwendung längst nicht mehr auf die IT beschränkt. Vielmehr ist sie auch in vielen anderen Bereichen hervorragend dazu geeignet, Projektarbeit produktiv zu organisieren.

Was heißt eigentlich Scrum?

Wer sich mit der Planung und Durchführung von Projekten beschäftigt, stößt früher oder später auch auf Scrum. Auf Deutsch bedeutet dieser englische Begriff “Gedränge”. Er stammt ursprünglich aus dem Rugby und bezeichnet dort einen dichten Haufen Spieler, der sich um den Ball schart. Von dort hat er seinen Weg in das agile Projektmanagement gefunden. Dort bezieht er sich auf die Tatsache, dass sich ein solches Projektteam täglich trifft, um Arbeitsergebnisse vorzustellen sowie offene Fragen und das weitere Vorgehen zu besprechen.

Sichern Sie sich das kostenlose
Projektmanagement-Handbuch!

Zur Geschichte von Scrum

Die Geschichte von Scrum beginnt Anfang der 1990er Jahren. Wichtige Grundlagen dafür wurden durch die japanischen Managementwissenschaftler Ikujiro Monica und Hirotaka Takeuchi – zwei Pionieren des modernen Wissensmanagements – und dem Managementexperten Jeff Sutherland geschaffen.

Sutherland definierte seinerzeit im Rahmen eines Projektes für das Unternehmen Guinness Peat Aviation die Rolle von Projektleitern neu: Um die Produktivität des Teams zu steigern, wurden die hierarchischen Unterschiede zwischen Projektleitern und Teammitgliedern weitgehend eingeebnet, den Projektleitern kam in dieser Konstellation vor allem die Funktion von Moderatoren und weniger von Managern zu. Nonaka und Takeuchi vertraten bereits 1986 in einem Artikel in der “Harvard Business Review” die Ansicht, dass interdisziplinäre Teams in der Produktentwicklung den größten Kundennutzen bringen.

Dieser Ansatz wurde durch die agile Softwareentwicklung übernommen. Den ersten Konferenzvortrag in diesem Kontext hielt der US-amerikanische Programmierer Ken Schwaber im Jahr 1995. Zuvor war er bereits an Jeff Sutherlands Projekt beteiligt. Sechs Jahre später, im Jahr 2001, gehörten Schwaber und Sutherland zu den insgesamt 16 Unterzeichnern des “Manifesto for Agile Software Development”. Im Jahr 2003 veröffentlichte Ken Schwaber sein Buch “Agile Project Management with Scrum”, in dem er das Konzept nicht nur auf IT-Entwicklungsteams, sondern auf sämtliche Projektteams in Unternehmen ausweitet. Heute ist Scrum eine etablierte Methode zur Projektorganisation, die weltweit angewendet wird.

Ansatz und Ziele der Methode

Scrum verfolgt einen empirischen, inkrementellen und iterativen Ansatz. Mit anderen Worten: Es orientiert sich an realen Prozess- und Kollaborationsverläufen, zerlegt eine Projektaufgabe in ihre Einzelschritte und nutzt dafür das Prinzip der permanenten Wiederholung. Zu seinen Grundideen gehört, dass viele Projekte so komplex sind, dass die Projektbeteiligten anfangs und auch in späteren Etappen nicht in der Lage sind, sämtliche Anforderungen und Lösungsansätze zu überblicken. Diese lassen sich jedoch anhand von Zwischenergebnissen bestimmen, die gleichzeitig ermöglichen, einen “fehlerhaften” Projektverlauf fortlaufend zu korrigieren.

Das generelle Ziel dieser Methode besteht darin, hochwertige Produkte mit optimalem zeitlichen und finanziellen Aufwand zu entwickeln, denen eine vorab formulierte Vision zugrunde liegt. Die Anforderungen an das Produkt werden nicht abstrakt, sondern aus der Sicht des Anwenders formuliert. Am Ende jedes Projektabschnitts – dem sogenannten Sprint – wird ein fertiges Teilprodukt (incremental product) geliefert und auch dem Anwender/Kunden präsentiert.

Letztlich werden damit unabhängig vom konkreten Anwendungsbereich die Werte des “Manifesto for Agile Software Developement” in die Praxis umgesetzt. Zentrale Punkte sind hier insbesondere der Vorrang von Menschen und Interaktionen vor Werkzeugen und Produkten, funktionierende Produkte, aktive Kollaboration mit dem jeweiligen Kunden und funktionierende Produkte.

Die Scrum-Akteure

Innerhalb dieses Projektkonzepts sind keine Manager und Chefs, sondern drei völlig anders definierte Hauptakteure mit unterschiedlichen Rollen vorgesehen:

  • Der Product Owner (Produkteigner) vertritt die Anwender des Produkts sowie andere Stakeholder, die in dessen Entwicklung und/oder Anwendung außerhalb des eigentlichen Entwicklungsprozesses involviert sind. Zu den Stakeholdern zählen neben den unmittelbaren Produktanwendern beispielsweise interne oder externe Kunden/die Auftraggeber für das Produkt sowie das Management des Unternehmens. Der Product Owner verantwortet die Produkteigenschaften und dessen wirtschaftlichen Erfolg.
  • Der Scrum Master agiert als Moderator und Dienstleister für das Projektteam. Zu seinen Aufgaben gehört es, die erforderlichen Ressourcen zu beschaffen und Hindernisse aus dem Weg zu räumen. Er vertritt das Team nach außen und verfügt über vertiefte Methodenkompetenz, mit der er die Teammitglieder unterstützt. Bei Konflikten greift er regulierend ein. Jedoch besitzt er keine Weisungsbefugnisse gegenüber den Teammitgliedern und übt auch keine disziplinarischen Kontrollfunktionen aus.
  • Das Projektteam besteht aus Vertretern aller Fachbereiche, die für die Projektdurchführung nötig sind. Die Teammitglieder verfügen über unterschiedliche Kompetenzen, agieren jedoch hierarchiefrei und gleichberechtigt. Ein solches Team ist selbstorganisierend, es entwickelt und liefert das Produkt in der vom Product Owner vorgegebenen Reihenfolge und Qualität. Optimal ist, wenn das Projektteam aus fünf bis zehn Mitgliedern besteht, größere Teams müssen ihre Tätigkeit in einem komplexeren und gegebenenfalls teamübergreifenden Kontext organisieren, was auf der gleichen Grundlage erfolgen kann.

Der Scrum-Prozess

Der erste Schritt ist die Entwicklung einer gemeinsamen Vision für das Produkt. Auf dieser Grundlage werden die Projektanforderungen und die einzelnen Arbeitspakete definiert:

  • Die Produktanforderungen werden auf sogenannten Story Cards notiert. Dabei geht es nicht um einen abstrakten Eigenschaftenkatalog, sondern um Produktaspekte und Funktionalitäten, die aus der Perspektive der unmittelbaren Anwender des Produktes von Bedeutung sind.
  • Auf Basis der Story Cards wird ein Product Backlog erstellt, das sämtliche Funktionen, Produkteigenschaften und Produktmerkmale zusammenfasst. Anfangs ist diese Zusammenstellung noch recht ungenau, sie konkretisiert sich jedoch während des Projektverlaufs.
  • Prioritäten im Hinblick auf die Produktentwicklung werden ebenfalls aus der Anwender-Perspektive definiert: Welche Funktionen sind für den Anwender essentiell? Welche Aspekte sind nachgelagert oder zum gegenwärtigen Zeitpunkt nicht realisierbar? Durch diese Art der Priorisierung werden gleichzeitig Grundlagen für spätere Produktüberarbeitungen oder -Erweiterungen geschaffen.
  • Die Sprint-Planung bezieht sich auf die Aufteilung der Projektarbeit in einzelne Etappen. Ein Sprint ist jeweils ein konkreter Arbeitsabschnitt, der in der Regel zwei bis vier Wochen dauert. Zeitverlängerungen nicht vorgesehen. Falls ein Sprint-Ziel aufgrund von zeitlichen Problemen oder anderen Schwierigkeiten nicht erreicht wird, kann er aufgrund der Entscheidung des Product Owners abgebrochen werden. Im Rahmen der Sprint-Planung werden Teilziele, Meilensteine und die Rahmenbedingungen für die einzelnen Produktentwicklungsphasen definiert.
  • Die Aufgabenverteilung innerhalb des Projektteams erfolgt über sogenannte Tickets, die im Sprint-Backlog gesammelt werden. Die Teammitglieder wählen ihre Aufgaben/Tickets eigenverantwortlich aus, die Grundlage dafür bildet eine entsprechende Selbstverpflichtung. Alle Tickets werden auf einer Tafel – dem Task oder Kanban Board – festgehalten, so dass alle Mitarbeiter wissen, welche Aufgaben noch zu erledigen sind. Bei der Ticketverteilung wird das Kanban-Prinzip angewendet: Die Freigabe der Tickets richtet sich nach den Kapazitäten des Projektteams – durch einen Ticket-Stau werden also auch Engpässe im Projektverlauf direkt an der Tafel sichtbar.
  • Product Owner, Scrum Master und alle Teammitglieder treffen sich täglich zu einer 15-minütigen Besprechung, dem sogenannten Daily Scrum. Zu diesem Termin berichten sie über den Fortschritt ihrer Arbeit und über ihre Planung bis zum nächsten Treffen. Falls dabei Hindernisse und Schwierigkeiten zur Sprache kommen, liegt es in der Verantwortung des Scrum Masters, für deren Beseitigung zu sorgen. Der Fortschritt des Projekts bzw. des aktuellen Sprints wird während des Meetings im Sprint-Burndown-Chart festgehalten.
  • Jeder Sprint endet mit einem Sprint Review Meeting, in dem das Team dem Product Owner die Ergebnisse des aktuellen Zyklus präsentiert, der sie offiziell akzeptieren muss. Gesonderte Reviews können der Überprüfung der Kollaborationsprozesse im Projektteam sowie der Optimierung künftiger Projekte dienen.
  • Das Projekt wird abgeschlossen, wenn das Produkt endgültig an den Product Owner geliefert werden kann.

Scrum-Produkte und neue Paradigmen

Ein Scrum-Produkt kann aus nahezu beliebigen Leistungen bestehen. Neben physischen Produkten sind hier beispielsweise auch die Entwicklung einer Marketing-Kampagne, die Zusammenarbeit an einem wissenschaftlichen Projekt und viele andere Projektszenarien zu nennen. Selbstverständlich lassen sich entsprechende Projekte heute auch auf digitalem Wege steuern.

Allerdings erfordert die Anwendung dieser Methode der Projektorganisation in den Unternehmen einen Paradigmenwechsel, der sowohl das Management als auch die Mitarbeiter einschließt. Schließlich stellt sie Hierarchien in Frage bzw. setzt sie völlig außer Kraft. Zudem steht und fällt ihr Erfolg mit der Lernbereitschaft des Projektteams. Diese müssen bereit und in der Lage dazu sein, ihre Arbeitsergebnisse ständig zu überprüfen, ihre Kollaboration und das Produkt zu überdenken, Anpassungen vorzunehmen und interdisziplinäre Arbeit zu akzeptieren.

Fotoquelle Titelbild © Fotolia/aa_amie

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.