Читать книгу Roadmap durch die VUCA-Welt - Dennis Willkomm - Страница 34

„Mit 85 % ist ScrumScrum die meistgenutzte agile Methode. Danach folgen Kanban, Lean und DevOps.“ Zu diesem Schluss kommt die Studie Status Quo Agile,1 die von der Hochschule Koblenz 2016/17 durchgeführt wurde.2 Scrum erfreut sich damit viele Jahre nach seiner ersten Erwähnung im „New new product development game“ sehr großer Beliebtheit.

Eine tragende Rolle bei der systematischen Umsetzung der von Takeuchi und Nonaka beschriebenen Praktiken nahmen Ken Schwaber und Jeff Sutherland ein. Jeff Sutherland griff die beschriebene Idee auf und nutzte die Erkenntnisse in ersten Projekten. Ken Schwaber veröffentlichte bereits 1995 auf der OOPSLA-Konferenz einen ersten Beitrag über Scrum. Beide Pioniere gehörten auch zu den Unterzeichnern des Agilen Manifests im Jahr 2001. Im gleichen Jahr veröffentliche Ken Schwaber auch das erste Buch zum Thema Scrum, gemeinsam mit Mike Beedle (Schwaber/Beedle 2002).

Schwaber und Sutherland taten sich zusammen und gestalteten gemeinsam den Scrumguide,Scrumguide der die Spielregeln von Scrum definiert, auf die sich alle Anwender des Frameworks berufen.3 Der Scrumguide wurde in viele Sprachen übersetzt und wird regelmäßig aktualisiert. Auch wenn Scrum sehr populär in der IT ist, wird im Scrumguide explizit darauf hingewiesen, dass Scrum in allen erdenklichen Bereichen verwendet werden kann. Von einer großen Liste strahlender Beispiele berichtet Jeff Sutherland in seinem Buch „Die Scrum Revolution“ (Sutherland 2015). Der Scrumguide beschreibt drei wichtige Rollen, die zur Ausführung von Scrum benötigt werden.

Der Product Owner (Eigentümer des Produkts) hat die Verantwortung für das Produkt. Dafür muss er sicherstellen, dass die Aufgaben erledigt werden, die am meisten Wert generieren. Dies gelingt ihm, indem er alle Arbeiten, die zu erledigen sind, um das Produkt herzustellen, in das Product Backlog einträgt und dort in eine eindeutige Reihenfolge bringt.

In der Regel gibt es eine Reihe von Leuten, die ein Interesse an dem Produkt haben. Dies können zum einen (potenzielle) Kunden sein, zum anderen aber die eigene Unternehmensführung oder auch andere Abteilungen im eigenen Unternehmen. Die Aufgabe des Product Owners besteht nun darin, die Interessen dieser Stakeholder einzusammeln und gegeneinander zu gewichten. Dafür muss er in engem Kontakt mit den Stakeholdern stehen.

Im Gegensatz zum Wasserfallmodell, wo das Produktmanagement und die Entwicklung zwei getrennte Abteilungen bilden, ist der Product Owner Teil eines Scrum Teams und daher auch mitverantwortlich für die gelungene Umsetzung der Anforderungen. Der Product Owner ist dafür verantwortlich, was getan wird. In Scrum ist es wichtig, dass es genau einen Product Owner für ein Produkt gibt. Dies soll verhindern, dass sich zum Beispiel ein Komitee nicht einigen kann und somit Entscheidungen sehr träge getroffen werden können. Zwar können verschiedene Personen sich die Aufgaben des PO aufteilen, am Ende muss es aber genau eine Person geben, deren Entscheidung im Zweifelsfall von allen akzeptiert wird.

Das Entwicklungsteam besteht aus den Experten, die das Produkt herstellen. Das Team zeichnet sich durch seine interdisziplinäre Aufstellung aus. Im Scrum-Umfeld wird diese Eigenschaft als „Crossfunktionalität“ (X-funktional abgekürzt) bezeichnet. Es sind Experten aus den unterschiedlichsten Bereichen der Wertschöpfungskette in einem Team vorzufinden, die dann gemeinsam als Team eine Gesamtverantwortung für ein Produkt oder eines Produktbestandteils übernehmen. Dabei bemüht man sich um die Ausprägung eines T-Profils bei den Teammitgliedern (siehe Exkurs).

Exkurs | T-ProfilT-Profil

In klassischen Arbeitsgruppen, die aus Experten der gleichen Fachrichtung bestehen, hat man es in aller Regel mit Spezialisten zu tun. Diese haben eine tiefgehende Expertise in einem bestimmten Fachgebiet. Damit ihre Expertise möglichst effizient genutzt werden kann, ist ihr Arbeitsumfeld so gestaltet, dass sie sich ausschließlich auf diesen Fachbereich konzentrieren können. Auch Mitarbeiterentwicklung findet in diese Spezialrichtung statt. Dies wird oft als I-Profil bezeichnet, weil es eine einzelne, sehr spezialisierte Fähigkeit repräsentiert.

Demgegenüber strebt man in interdisziplinären Teams das sogenannte T-Profil (T-Shape) an. Dies bedeutet, dass das Teammitglied immer noch ein Experte in einem bestimmten Fachgebiet ist, was den Stängel des T repräsentiert. Gleichzeitig bemüht sich das Teammitglied aber auch, Aufgaben aus angrenzenden Fachgebieten zu lernen und bei Bedarf zu übernehmen. Wenn man ein wenig rechts und links seiner eigenen Spezialfähigkeit schaut, dann ergibt sich so der Querbalken des T-Profils.

Erinnern wir uns zurück an die Engpasstheorie, dann sehen wir, dass dieses angestrebte T-Profil kein Selbstzweck ist, sondern sehr wichtig, um die Leistungsfähigkeit eines Teams zu erhöhen. Ein Teammitglied mit I-Profil könnte, wenn ein Engpass gefunden wird, der in einem angrenzenden Arbeitsschritt liegt, nicht unterstützen, da ihm entsprechende Fähigkeiten fehlen. In klassischen Organisationen, die auf Effizienz und Auslastung optimiert sind, würde ein solches Teammitglied sich weiter mit den eigenen Aufgaben beschäftigen. Dies wäre aber eine lokale Optimierung, die dazu führen würde, dass sich vor dem Engpass ein Berg von Arbeit anhäuft. Besitzt das Teammitglied aber ein T-Profil, kann es den Engpass entlasten und somit zur Gesamtleistung des Teams beitragen, selbst wenn einzelne Glieder der Wertschöpfungskette nicht optimal ausgelastet sind.

Oftmals wird das T-Profil so missverstanden, dass jeder im Team in der Lage sein sollte, jede Aufgabe zu übernehmen, die anfallen könnte. Wie Sie oben gesehen haben, ist dies nicht das Ziel (und auch sehr utopisch). Das T-Profil soll vielmehr sicherstellen, dass eventuelle Engpässe entlastet werden können und im Falle des Ausfalls eines oder mehrerer Teammitglieder die Arbeit nicht komplett eingestellt werden muss, nur weil der eine „wissende“ Fachexperte nicht greifbar ist.

Das Entwicklungsteam organisiert sich selbst, so wie es meint, die gesetzten Ziele erreichen zu können. Das Team trägt die Verantwortung, wie etwas getan wird.

In Scrum gibt es keine speziellen Rollen innerhalb des Teams. Es gibt also keine weitere Unterteilung zwischen Entwicklern, Testern, Analysten, Ingenieuren, Layoutern oder welche Spezialgebiete auch immer zur Erstellung eines Produkts benötigt werden. Dadurch soll zum einen die Entwicklung in Richtung T-Profil unterstützt werden, zum anderen aber auch ein Gefühl für die gemeinsam getragene Verantwortung für das Ergebnis gestärkt werden.

Als dritte und letzte Rolle beschreibt der Scrumguide den Scrum MasterScrum Master. Für die meisten Unternehmen, die Scrum einführen, ist diese Rolle ein absolutes Novum, denn in den allerseltensten Fällen gab es zuvor eine Rolle, die eine vergleichbare Aufgabe hatte. Auf der einen Seite soll der Scrum Master das Scrum Rahmenwerk fördern und unterstützen. Er hilft also dem Team zu verstehen, wie genau Scrum funktioniert, und wie ein Rädchen in das andere greift. Zudem besteht sein Hauptfokus aber darauf, die Zusammenarbeit des Teams zu optimieren.

Der Scrum Master hat dafür drei große Fokuspunkte, auf die er sich konzentriert. Zum einen unterstützt er den Product Owner. Er hilft ihm, die Anforderungen zu priorisieren und mit dem Entwicklungsteam in kleine, zu bearbeitende Aufgaben zu zerlegen. Zudem hilft er dem PO, sich in der agilen Produktplanung zurechtzufinden.

Als Zweites richtet der Scrum Master seine Aufmerksamkeit auf das Entwicklungsteam. Hier liegt sein Fokus darauf, das Team zu einer Selbstorganisation zu befähigen und die Zusammenarbeit zu verbessern. Dafür muss der Scrum Master ganz auf seine Überzeugungskraft und seine Coaching-Fähigkeiten zurückgreifen, denn in Scrum ist niemand vorgesehen, auch nicht PO oder Scrum Master, der in irgendeiner Form weisungsbefugt wäre.

Und zuletzt ist die Rolle des Scrum Masters auch dazu gedacht, in die Organisation hineinzuwirken. Wenn man mit Scrum beginnt, wird man schnell feststellen, dass gewisse Hindernisse, die eine selbstorganisierte Arbeit verhindern, nicht nur innerhalb der Teamgrenzen zu finden sind. Viele Probleme und Herausforderungen sind teamübergreifend und zum Beispiel in vorhandenen Strukturen oder Prozessen begründet. Es ist unvermeidlich, dass ein Unternehmen, das sich agil aufstellen möchte und dafür Scrum einführt, sich auch organisatorisch deutlich verändern muss.

Exkurs | Rollen und Positionen

Scrum definiert drei Rollen. In vielen klassischen Organisationen besteht eine sehr starke Fokussierung auf Positionen. Auch wenn beide Begriffe oft synonym verwendet werden, besteht hier ein deutlicher Unterschied. Eine Position ist untrennbar mit einer Person verknüpft. Frau Maier oder Herr Müller haben eine Position inne. An diese Position wiederum sind gewisse Rechte und Pflichten geknüpft. Ein Projektleiter trägt die Verantwortung für ein bestimmtes Projekt und hat vielleicht ein Budget zur Verfügung und dann auch eine Weisungsbefugnis für die Projektbeteiligten. Positionen sind in der Regel ein Kästchen in einem Organigramm, in dem ein bestimmter Name steht.

Rollen hingegen definieren erst einmal nur Verantwortlichkeiten, sind aber nicht personenbezogen. Das heißt, die in einer Rolle definierten Verantwortlichkeiten müssen erfüllt werden, aber es ist nicht unbedingt festgelegt, welche Person dies tut. Somit kann eine Rolle auch durch mehr als eine Person ausgefüllt werden, indem man beispielsweise die Verantwortlichkeiten aufteilt.

In sehr vielen Unternehmen wird eine Rolle an eine Position geknüpft. In manchen Fällen ist der Product Owner, der in Scrum als Rolle definiert ist, eine feste Position mit einer zugeordneten Person. Andernorts sind an die Position (das Kästchen im Organigramm) noch zusätzliche (nicht im Scrumguide definierte) Aufgaben, Rechte oder Pflichten geknüpft. Hier findet schnell eine Vermischung von Rolle und Position statt, die am Ende zu einem falschen Verständnis von den eigentlichen Rollen führen kann.

Neben diesen Rollen gibt Scrum auch ziemlich genau vor, welche Bestandteile es gibt und zu welchen Anlässen und wann die Teams zusammenkommen (Scrum Artefakte und Events).

Das Product BacklogProduct Backlog haben Sie ja schon kennengelernt. Es handelt sich dabei um eine Liste, die alle Arbeit enthält, die vom Team zu erledigen ist, um ein Produkt herzustellen. Diese Liste ist geordnet und die wichtigste Aufgabe befindet sich an der Spitze dieser Liste. Der Product Owner ist dafür verantwortlich, das Product Backlog aktuell zu halten und die Reihenfolge der Arbeit festzulegen. Die einzelnen Bestandteile des Backlogs nennt man Product Backlog Items. Diese werden oftmals in Form einer User Story (also aus der Sicht des Benutzers) geschrieben. Product Backlog Item ist alles, was eine Änderung am bestehenden Produkt darstellt, also zum Beispiel neue Anforderungen, Fehlerbehebungen oder die Beseitigung technischer Schulden.

Die Abarbeitung der Product Backlog Items erfolgt in Iterationen, sogenannten SprintsSprint. Ein Sprint ist per Definition maximal vier Wochen lang. Da die Vorausplanung mit zunehmender Länge der Iteration immer ungenauer wird, legt der Scrumguide hier diese Obergrenze fest. Für die meisten Teams hat sich eine Sprintdauer von zwei Wochen in der Praxis als guter Startwert herausgestellt. Es gibt aber auch Scrum Teams, deren Sprints nur einen Tag dauern, oder die sogar mehrere Sprints an ein und demselben Tag durchführen.

In einem gemeinsam Scrum Event (so nennt man bei Scrum die gemeinsamen Termine in Abgrenzung zu den gemeinhin oftmals als unproduktiv angesehenen „Meetings“), dem sogenannten Sprint PlanningSprint Planning, setzt sich das gesamte Scrum Team (Product Owner, Scrum MasterScrum Master und Entwicklungsteam) zusammen und überlegt, was es im nächsten Sprint voraussichtlich liefern kann. Dafür wird erst einmal ein Sprintziel festgelegt und dann Aufgaben aus dem Product Backlog ausgewählt, die zur Erreichung des Ziels notwendig sind.

Diese Aufgaben werden dann in das Sprint BacklogSprint Backlog übertragen. Dieses stellt somit eine Teilmenge des Product Backlogs dar und wird jeden Sprint neu angelegt. Die Aufgaben im Sprint Backlog werden so verfeinert, dass das Team jederzeit überprüfen kann, wie sein Fortschritt in Hinblick auf die Erreichung des Sprintziels ist. Es werden nur so viele Aufgaben in das Sprint Backlog übernommen, wie das Team meint, im nächsten Sprint fertigstellen zu können.

Im Laufe des Sprints erstellt das Entwicklungsteam ein Inkrement. Ein Inkrement besteht aus dem Ergebnis des aktuellen Sprints sowie den Ergebnissen aller vorheriger Sprints. Ein Produkt Inkrement wird also von Sprint zu Sprint immer größer und umfangreicher.

Damit die Arbeit selbstorganisiert stattfindet und möglichst gut abgestimmt wird, trifft sich das Entwicklungsteam täglich zur selben Zeit am gleichen Ort für ein Planungs- und Abstimmungsmeeting, dem Daily Scrum. Das Daily Scrum findet in aller Regel im Stehen statt (daher auch der alternative Name Daily-Stand-Up). Dies soll dazu dienen, dass die Teilnehmer sich kurzfassen und schnell zum Wesentlichen kommen. Alle Scrum Events haben eine Timebox (Zeitrahmen), also eine maximale Dauer, die nicht überschritten werden darf. Das Daily Scrum soll maximal 15 Minuten dauern und ist somit das kürzeste Scrum Event. Hervorzuheben ist, dass das Daily Scrum nicht dazu gedacht ist, den aktuellen Status zu berichten. Das Team soll sich gezielt abstimmen, wo man im Hinblick auf das Sprint Ziel steht, was noch zu tun ist, was in den nächsten 24 Stunden (bis zum nächsten Daily Scrum) erledigt werden kann und wie man sich am sinnvollsten aufteilt. Zudem sollen Hindernisse (Impediments) sichtbar gemacht werden, die die Arbeit behindern oder sogar verhindern.

Damit eine Aufgabe vom Team als erledigt gekennzeichnet werden kann, muss sie der Definition von Fertig (Definition of Done) entsprechen. Diese Definition stellt eine Checkliste dar, die alles enthält, was erfüllt sein muss, damit eine Aufgabe fertiggestellt ist. Diese wird häufig von dem Unternehmen vorgegeben, damit alle Scrum Teams nach den gleichen Qualitätsstandards arbeiten. Wenn auch nur eine geringe Kleinigkeit fehlt, darf eine Aufgabe nicht als fertig deklariert werden.

Am Ende des Sprints präsentiert das Scrum Team allen Interessierten das fertige Inkrement (also alle Aufgaben, die gemäß der Definition von fertig abgeschlossen wurden). Dies geschieht im sogenannten Sprint Review, das eine öffentliche Veranstaltung ist und zu dem der Product Owner alle interessierten Stakeholder einlädt. Gemäß dem Leitsatz von Scrum – Inspect & Adapt (Feedback einholen und Anpassen) – wird hier das Produkt Inkrement gezeigt und Feedback eingesammelt. Auch das Review ist somit kein einfaches Statusmeeting, um einen Fortschritt zu präsentieren, sondern eine wichtige Gelegenheit, um Feedback einzuholen und strategische Entscheidungen zu treffen. Neue Erkenntnisse hält der Product Owner im Backlog fest, mit dem er dann in das nächste Sprint Planning gehen kann.

Im Anschluss erfolgt dann ein weiterer Schritt, der dazu dient, Feedback einzuholen und eventuelle Anpassungen vorzunehmen: die Sprint Retrospektive. Hier kommt das Scrum Team zusammen und reflektiert gemeinsam den Entwicklungsprozess mit dem Ziel, Verbesserungsmaßnahmen zu definieren, die im Laufe des nächsten Sprints angewendet und in der folgenden Retrospektive auf ihre Wirksamkeit hin untersucht werden können. Diese werden dann auch gleich in das Sprint Backlog des nächsten Sprints eingetragen, damit das Team bei der Planung diese Aufwände mitberücksichtigen kann.

Prinzipiell geht der Zyklus an dieser Stelle wieder von vorne los, allerdings zeigt die Erfahrung, dass das Team auch eine gewisse Zeit in die Pflege und die Verfeinerung des Product Backlogs investieren muss. Diese Aktivität wird als Refinement bezeichnet. Der Scrumguide macht hier, im Gegensatz zu den klar definierten Scrum Events, keine klaren Vorgaben, wie das Refinement abzulaufen hat. Aber er gibt eine Empfehlung, die darin besteht, dass das Team bis zu 10 % seiner Zeit im Sprint für Refinement aufwenden sollte. Das Ergebnis – ein gepflegtes und feingranulares Product Backlog – wird dann als Eingabe für das nächste Sprintplanning genutzt.

Auch in Scrum gibt es Metriken, die helfen sollen, den Prozess kontinuierlich zu verbessern. Allerdings schreibt Scrum hier nichts vor. Viele Praktiker messen zum Beispiel gerne die Menge der Arbeit, die das Entwicklungsteam in einem Sprint erledigt hat. Dies wird dann als Velocity bezeichnet. Dafür muss die Größe der Aufgaben berücksichtigt werden, so dass man entweder alle Aufgaben in die gleiche Größe bringt oder aber die Größe schätzen und in Relation zueinander setzen muss. Hierfür werden meist Story Points verwendet. Dementsprechend wird auch die Velocity eines Teams in der Regel in Story Points pro Sprint angegeben.

Scrum und Kanban erheben beide nicht den Anspruch perfekt zu sein und die Antwort auf alle Fragen zu liefern. Im Gegenteil, sie ermutigen die Anwender dazu, Anpassungen vorzunehmen, um die Vorgehensweisen zu verbessern. Dies ist sicherlich eine gute Idee, denn die Erfinder konnten nicht jeden erdenklichen Kontext in ihre Überlegungen einbeziehen.