Produkt- und Projektmanager müssen zwei Welten vereinen: Auf der einen Seite stehen die sich ständig ändernden Anforderungen der Kunden, auf der anderen die internen Prozesse. Agilität ist in diesem Rahmen Synonym für Effizienz und wird durch SCRUM Realität.
Donnerstagmorgen, Projektmeeting – der Projektmanager informiert das Team über eine Anpassung, die der Kunde kurzfristig geäußert hat, kommuniziert sie direkt dem Team und plant mit diesem die Umsetzung des neuen Anspruchs. Fünfzehn effiziente Minuten mit dem Team, um noch am selben Tag die neuen Wünsche des Kunden in die Umsetzung zu führen.
SCRUM heißt die Methode, die sowohl Flexibilität als auch Verbindlichkeit vereint. Sie hat Unternehmen wie der Scout24 Gruppe eine Effizienzsteigerung von 200 Prozent in einem Jahr eingebracht. Der Grundgedanke ist simpel: durch flache Hierarchien, Transparenz und offene, regelmäßige Kommunikation Fehlentwicklungen vermeiden und das Tagesgeschäft an den sich ständig ändernden Bedürfnissen des Marktes und der Kunden ausrichten.
SCRUM entfaltet seine Stärken dort, wo eine Planung nicht zu einem wirtschaftlichen Ergebnis führt, weil sie wenig sinnvoll oder schlicht nicht möglich ist. Ein Beispiel dafür bietet die Softwareentwicklung:
Klassische Methoden haben in den 1990er-Jahren dazu geführt, dass Ziel und Ergebnis weit voneinander abwichen, da das Ziel bis zum Datum der Fertigstellung längst überholt war. Diese Umstände haben zur Entwicklung von agilen Methoden wie SCRUM geführt. Entsprechend ist SCRUM für Situationen geeignet, in denen Entwicklungsprozesse gestaltet oder auf sich ständig ändernde Rahmenbedingungen reagiert werden muss.
Allerdings ist SCRUM kein Allheilmittel. Besonders in Situationen, wo der Ablauf klar ist, endet SCRUM in einem Mehraufwand. Sind die Abläufe klar, bauen aufeinander auf und erfordern Unbeweglichkeit, um zu funktionieren, ist die Verwendung von SCRUM nicht sinnvoll. Natürlich können auch diese Abläufe verbessert werden, jedoch ändert dies nichts am angestrebten Ziel.
Während einer Entwicklung fallen dem Team oft Fehler auf, die sich dem Kunden oder Projektmanager erst beim Test des Produktes erschließen. Um dieses böse Erwachen zu vermeiden, braucht es eine offene Fehlerkultur, gepaart mit einer gewissen Autonomie des Entwicklerteams. Denn so können Fehler von vornherein angesprochen und Lösungen gefunden werden.
SCRUM soll genau dies ermöglichen: Die Methode schafft Raum für Kreativität und Agilität und hält diesen durch eine für alle Akteure transparente Kommunikation zusammen. Diese Kommunikation folgt einer gewissen Struktur, die klassische Hierarchien auflöst und dynamische Rollen installiert. Voraussetzung dafür ist eine entsprechende Denkweise im Team.
|
Konflikte bei der Einführung von SCRUM Es ist wichtig, Rollenkonflikte zu vermeiden. Die Selbstorganisation aller Mitarbeiter impliziert die Infragestellung von Hierarchien. Mitglieder, die nicht bereit sind, ihre bisherige Stellung im Entwicklungsteam aufzugeben, können Konflikte verursachen. Es ist wichtig, dass sich möglichst jeder an allen Aufgaben beteiligt, statt sich ausschließlich als Entwickler, Architekt oder Tester zu sehen. Hier ist der SCRUM Master, welcher im folgenden Kapitel genauer erläutert wird, in der Pflicht der Aufklärung und Mediation. |
Hierarchien können bremsen. Anstelle der direkten Lösung eines Problems rückt oft ein Prozess: Den Ansprechpartner identifizieren, einen Termin vereinbaren, die Freigabe zur Lösung des Problems einholen – all dies frisst Zeit und Ressourcen. SCRUM löst dieses Problem, indem dynamische Rollen anstelle von Positionen und Hierarchien definiert werden.
Folgende Rollen werden bei SCRUM definiert:
| SCRUM-Rolle | Wer sie besetzt |
| Stakeholder | Management, Kunden, Nutzer |
| Product Owner | Produkt- / Projektmanager |
| Entwicklerteam | Mitarbeiter |
| SCRUM Master | SCRUM Coach |
Stakeholder stoßen Prozesse extern an. Dieser Gruppe sind Kunden, das Management, sowie Nutzer zuzuordnen. Stakeholder stehen im ständigen Austausch mit dem Product Owner, nicht jedoch mit dem Entwicklerteam.
Der Product Owner ist am ehesten mit einem Projekt- und Produktmanager gleichzusetzen. Er bildet die Schnittstelle zwischen den Stakeholdern (Kunden, Management, Anwendern) und dem Entwicklungsteam. In der Kommunikation mit den Stakeholdern führt der Product Owner das Product-Backlog, dass die Anforderungen an das Produkt, also das „Was“ festschreibt, nicht jedoch das „Wie.“
Im Product Backlog werden User-Storys formuliert, deren Eigenschaften mit dem Akronym INVEST zusammengefasst werden können:
| Independent | User Storys sollten nicht voneinander abhängen. |
| Negotiable | User Storys sollten keine Umsetzungsdetails festlegen. |
| Valuable | Ihre Umsetzung erhöht den Produkt-Gebrauchswert für den Endkunden. |
| Estimable | Der Aufwand für die Umsetzung muss abschätzbar sein. |
| Small | Der Aufwand für die Umsetzung sollte überschaubar (Tage / Wochen) sein. |
| Testable | Erfolgreiche Umsetzung sollte mit objektiven Kriterien überprüfbar sein. |
Die Umsetzung der Entwicklung, des „Was“, erfolgt in Zyklen, die Sprints genannt werden. Ein Sprint ist meist auf vier Wochen angelegt. Seine Ziele werden beim sogenannten Sprint Planning gemäß der Priorisierung, die aus dem Product Backlog hervorgeht, festgelegt.
Am Ende eines jeden Sprints soll ein einsatzbereites Ergebnis vorgelegt werden. Die Sammlung aller in diesem umgesetzten und getesteten Aspekte werden als Product Increment bezeichnet.
Das Entwicklungsteam ist für die technischen Ausprägungen und die Umsetzung, also das „Wie“ verantwortlich und organisiert sich selbst. Dazu nutzt es unter anderem den Daily SCRUM, ein täglich stattfindendes Meeting, das der Planung der Tagesaufgaben dient und eine Dauer von fünfzehn Minuten nicht übersteigen soll.
Die Ergebnisse des Daily SCRUM werden – wie auch alle anderen Aktivitäten des Entwicklungsteams – im Sprint Backlog festgehalten. Dieses umfasst alle Aufgaben mitsamt Bearbeitungsstand, die während des Sprint Planning aus dem Product Backlog ausgewählt wurden. Für das Sprint Backlog wird meist ein Taskboard verwendet. Dieses gewährleistet Transparenz und ermöglicht die Hinterlegung von für den Task relevanten Informationen.
Der SCRUM Master ist mit einem Methoden Coach genauer gesagt Change Manager vergleichbar. Er ist für die Implementierung von SCRUM in die Prozesse des Unternehmens verantwortlich und unterstützt alle Beteiligten, bei der Einhaltung der SCRUM Regeln. Ihm obliegt die Verbesserung der Bedingungen, sodass den Anforderungen jederzeit bestmöglich entsprochen werden kann.
Dazu dient unter anderem die SCRUM Retroperspektive: Am Ende eines jeden Sprints trifft sich das gesamte SCRUM Team unter Ausschluss der Stakeholder, um seine Arbeitsweise ehrlich zu reflektieren. Je SCRUM Woche sind maximal 45 Minuten dazu angedacht, unangenehme Wahrheiten auszusprechen und Lösungen zur Optimierung des Workflows zu finden. Die Ergebnisse fließen in das Sprint Backlog mit ein.
SCRUM Master und Product Owner werden immer nur mit einer Person besetzt. Nur die Gruppen Entwicklungsteam und Stakeholder sind für mehrere Personen offen. Ein SCRUM Team soll die Größe von sieben bis neun Personen nicht überschreiten. Geschieht dies doch, so sollen mehrere SCRUM Teams gegründet werden.
Das am Ende eines Sprints entstandene Product Increment soll im Rahmen des SCRUM Review mit den Stakeholdern begutachtet werden. Es dauert maximal eine Stunde je Sprint Woche. Dabei werden unter anderem die im Product Backlog formulierten User-Storys evaluiert. User-Storys laufen meist nach folgendem Muster ab:
„Als NUTZER will ich FUNKTION oder EIGENSCHAFT, damit NUTZEN.“
Dieses Event ist nicht mit einer Abnahme gleichzusetzen. Stattdessen handelt es sich beim SCRUM Review um eine Feedbackrunde mit dem Ziel der Aktualisierung des Product Backlog. Danach folgt das Sprint Planning, in dem eine Abnahme angesetzt werden kann, sofern bereits sinnvoll. Auch die bis dahin noch nötigen Schritte werden erneut gemäß der Priorisierung für das Entwicklungsteam formuliert. Der Prozess wird nun wiederholt, der nächste Sprint beginnt.
Die Idee, Arbeitsschritte in möglichst kleinteilige Prozesse zu zerlegen und autark abzuarbeiten, stammt primär aus der Softwareentwicklung. Entsprechend sind die meisten Werkzeuge zur Implementierung und Nutzung von SCRUM auf Softwareentwicklungsprozesse angelegt. SCRUM kann jedoch für diverse Entwicklungsprozesse – unabhängig vom IT-Sektor – verwendet werden.
Da Scrum im Gegensatz zu Kanban, ebenfalls ein Mitglied der agilen Methoden-Familie, im Aufbau komplex ist und für den reibungslosen Ablauf mehrere Kompetenzträger erfordert, ist es ratsam, sich gründlich zu informieren. Daher finden Sie unten Literaturempfehlungen, Anbieter für Weiterbildungen und für Scrum-Software. Letztere bieten auf ihrer Website Tutorials und Guides, die hilfreich sind, um in das Themenfeld SCRUM einzusteigen.
Einer der wichtigsten Autoren rund um SCRUM ist Ken Schwaber. Mit seiner SCRUM Alliance zertifiziert er SCRUM Master seit 2001 für jeweils 2 Jahre. Bereits über 1,2 Millionen Personen nahmen dieses Angebot einer Trainerbegleitung bereits in Anspruch.
Dieser Anbieter stammt ebenfalls von Ken Schwaber. Sie unterscheidet sich von SCRUM Alliance primär dadurch, dass sie dauerhafte SCRUM Zertifizierungen durch ein Selbststudium ermöglicht. Über 400.000 Personen haben dies bereits getan.
SCRUM Inc. Wurde von Jeff Sutherland initiiert. Neben Ken Schwaber ist er einer der führenden Autoren rund um SCRUM. SCRUM Inc. Bietet ebenfalls eine Trainerbegleitung, vergleichbar mit SCRUM Alliance, an.
Agilo for Trac ist eine freie, webbasierte Projektmanagementsoftware, die die agile Software-Entwicklungsmethode SCRUM unterstützt. Agilo basiert auf Trac, einem Fallbearbeitungssystem, und ist in der Programmiersprache Python geschrieben.
Redmine ist eine freie, webbasierte Projektmanagement-Software. Sie kann für Benutzer- und Projektverwaltung, Diskussionsforen, Wikis, zur Ticketverwaltung oder Dokumentenablage genutzt werden.
OpenProject ist ein netzgestütztes Projektkollaborationssystem für die team- und standortübergreifende Zusammenarbeit in Projekten.
Jira ist eine Webanwendung zur Fehlerverwaltung, Problembehandlung und operativem Projektmanagement, die von Atlassian entwickelt wurde. Jira wird auch in nicht-technischen Bereichen für das Aufgabenmanagement, primär aber in der Softwareentwicklung eingesetzt.
Der Azure DevOps Server, vormals Team Foundation Server, von Microsoft ist eine Plattform für kollaborative Softwareprojekte. Über ihn können Projekte geplant, erstellt und verwaltet werden. Er kann dabei bis zu 2000 Entwickler und 500 Projekte verwalten.
Melde Dich an, bleibe informiert.
Diese Posts zu Agiles Projektmanagement
Telefon: +49 (2332) 9169-01
Telefax: +49 (2332) 9169-11
E-Mail: info@bloola.com
© 2020 bloola