16Scrum in Data-Science-Projekten

Caroline Kleist · Olaf Pier

Das folgende Kapitel diskutiert die Eignung des Scrum-Frameworks für Data-Science-Projekte. Hierzu werden nach einem Überblick über klassische Herausforderungen von Data-Science-Projekten die Vorteile erläutert, die das Data-Science-Team der Volkswagen Financial Services AG durch den Einsatz von Scrum realisieren konnte. Die Autoren kommen zu dem Ergebnis, dass Scrum gute Voraussetzungen für Data-Science-Projekte bietet, da diese oft durch ein hohes Maß an Komplexität geprägt sind. Es werden erste Empfehlungen für die Verwendung von Scrum im Data-Science-Umfeld gegeben, und die Hypothese aufgestellt, dass Scrum das Potenzial hat, zu einem neuen Best-Practice-Vorgehen für Data-Science-Teams zu werden.

16.1Einleitung

Data Science und Scrum haben eine unerwartete Gemeinsamkeit: Beide Konzepte sind nicht neu, sie stammen aus dem vergangenen Jahrtausend. Künstliche neuronale Netze als ein Beispiel für Verfahren des maschinellen Lernens, die heutzutage wieder großen Anklang im Data-Science-Universum finden, waren schon in den 1960er-Jahren im kommerziellen Einsatz zur Echtzeit-Echofilterung in Analogtelefonen. Spätestens in den 1990er-Jahren begannen immer mehr Unternehmen aus verschiedenen Branchen mithilfe von statistischen Verfahren und maschinellem Lernen, neue Erkenntnisse aus Unternehmensdaten zu extrahieren. Auch Scrum hat seinen Ursprung in den frühen 1990er-Jahren, in denen es zur Produktentwicklung eingesetzt wurde.

Aufgrund dieser Historie ist es erstaunlich, dass bisher kaum Literatur zur Kombination beider Themen existiert: zur Verwendung von Scrum als Rahmenwerk für Data-Science-Projekte. Diese Lücke soll dieser Erfahrungsbericht, der auf dem Einsatz von Scrum für ein Data-Science-Team der Volkswagen Financial Services AG basiert, schließen.

Für Leser ohne Kenntnis von Scrum bietet Abschnitt 16.2 einen schnellen Überblick über das Scrum-Framework. Abschnitt 16.3 beschreibt einige Herausforderungen von Data-Science-Projekten und Abschnitt 16.4 die konkrete Adaption von Scrum für ein Data-Science-Team der Volkswagen Financial Service AG. Den Kern dieser Abhandlung bilden schließlich die Kapitel zu den durch Scrum realisierbaren Vorteilen in Data-Science-Projekten, den entstehenden Herausforderungen sowie den abschließenden Empfehlungen zum Einsatz von Scrum für Data-Science-Teams.

16.2Kurzüberblick Scrum

Scrum ist ein Framework zum agilen Projektvorgehen, das speziell zur Entwicklung »komplexer Produkte« dienen soll. Der Scrum Guide selbst definiert Scrum folgendermaßen: »A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value« [Schwaber & Sutherland 2017]. Das in den 1990er-Jahren entstandene Vorgehensmodell wurde als Alternative zu klassischen Projektmanagementmethoden für die Erstellung von Software entwickelt. Der Trend der letzten Jahre zeigt indes, dass Scrum auch in anderen innovationsgetriebenen Branchen eingesetzt wird, wie beispielsweise zur Produktneuentwicklung [Scrum Alliance 2017].

Für das folgende Kapitel wird als grundlegende Referenz der offizielle Scrum Guide verwendet [Schwaber & Sutherland 2017]. Dieser Abschnitt erhebt keinesfalls den Anspruch, ein Benutzerhandbuch zu ersetzen, sondern soll lediglich dem schnellen Überblick dienen.

Bei Scrum wird das Projekt in kleinere Etappen – die Sprints – aufgeteilt und durch Selbstorganisation der Teammitglieder inkrementell und iterativ bearbeitet. Am Ende jedes Sprints steht ein auslieferbares Produkt (Product Increment), das zusammen mit dem Auftraggeber validiert wird. Abbildung 16–1 zeigt schemenhaft die wichtigsten Komponenten von Scrum und deren Ablauf.

image

Abb. 16–1Scrum-Vorgehensmodell (eigene Darstellung in Anlehnung an Scrum.org)

Verglichen mit klassischem Projektmanagement stehen bei agilem Projektvorgehen nach Scrum andere Prinzipien im Fokus. Laut den »Scrum Values« wird Wert darauf gelegt, dass sich in einem Projekt häufig Anforderungsänderungen ergeben und auf diese angemessen reagiert werden kann. Die iterative Natur des Frameworks fördert dies. Außerdem sollen die Stakeholder durch ständige Überprüfung der Zwischenergebnisse stärker eingebunden werden, wodurch Projekte transparenter werden. Eine weitere wichtige Grundlage in Scrum ist die Selbstorganisation des Teams, weswegen es auch keinen Projektleiter im herkömmlichen Sinne gibt.

Die regelmäßigen und sich je Sprint wiederholenden Aktivitäten bei Scrum sind der Sprint selbst, Sprint Planning, Daily Scrum, Sprint-Review und Sprint-Retrospektive.

Die Scrum-Artefakte sind das Product Backlog, Sprint Backlog und Product Increment und sollen die Transparenz über die Projekte fördern:

Die wichtigsten Scrum-Rollen werden in nachfolgender Infobox genauer erläutert:

Scrum Master
image

Ist verantwortlich für den reibungslosen Ablauf des Projektalltags; beseitigt Hindernisse und steigert so die Performance; stellt Kommunikation innerhalb des Teams und mit dem Product Owner sicher; moderiert Meetings.

Product Owner
image

Entwickelt und vertritt die konkrete Vision des Produkts; formuliert Epics und Sprint-Ziele; legt fachliche Anforderungen an das Produkt fest und priorisiert diese.

Entwicklungsteam
image

Besteht aus spezialisierten Fachkräften und entwickelt das Produkt; liefert die geforderten Eigenschaften des Produkts wie vom Product Owner priorisiert; das Team organisiert sich selbst.

16.3Data-Science-Projekte in der Praxis

Data-Science-Projekte weichen in vielerlei Hinsicht von anderen IT-Projekten ab wie beispielsweise in der Softwareentwicklung. Eingebettet im Kontext von Wirtschaftlichkeitsanforderungen sind Data-Science-Projekte sehr vielschichtig, iterativ, unsicher und komplex. Im folgenden Abschnitt wird auf Praxisaspekte von Data-Science-Projekten sowie typische Anforderungen und Herausforderungen eingegangen. Die Aufgaben und Arbeitsschritte werden nicht erneut erläutert und es wird lediglich auf CRISP-DM als klassisches Vorgehensmodell im Bereich Data Science verwiesen [Chapman et al. 2000].

Es gibt keine eindeutige und trennscharfe Definition von »Data Science« [Provost & Fawcett 2013]. An dieser Stelle soll daher auch keine Begriffsklärung vorgenommen werden, sondern es werden die wichtigsten Aspekte erläutert – ohne Anspruch auf Vollständigkeit. In Data-Science-Projekten geht es im Kern darum, nicht triviale und valide Erkenntnisse aus Daten zu gewinnen. Das ist keine grundlegend neue Idee, jedoch ist man seit der jüngeren Vergangenheit in der luxuriösen Situation, dass man dies nicht mehr hypothesengetrieben tun muss, sondern dass die immensen Datenmengen kombiniert mit ausreichend großer Rechenpower eine datengetriebene Vorgehensweise zulassen. Dieser Ansatz bringt zwar einerseits einen uneingeschränkten Blick auf die Daten mit sich und somit die größten Chancen auf spannende Erkenntnisse, andererseits jedoch auch ein herausforderndes Charakteristikum für Data-Science-Projekte in der betriebswirtschaftlichen Realität: Die Arbeit ist oft von experimenteller Natur. Wenn man vorab also nicht weiß, was man konkret erwartet, so kann man dies a priori auch nur schwer definieren. Das bringt aus Projektmanagementsicht ein großes Maß an Unsicherheit mit sich. Das ist jedoch nicht die einzige Quelle der Unsicherheit. Die Arbeit mit Daten selbst ist stets mit Unsicherheit behaftet [Philip Chen & Zhang 2014]: Sind die benötigten Daten verfügbar? Ist die Datenqualität für die Anwendung bestimmter Data-Science-Verfahren ausreichend? Sind die Daten fachlich geeignet? Man kann vorab und ohne ausführliche Datensichtungen nur schwer sagen, ob die Antworten auf diese Fragen positiv ausfallen werden. Insbesondere in größeren Unternehmen ist man mit komplexen Data-Warehousing-Architekturen konfrontiert sowie entsprechend umfangreichen Datenverarbeitungsprozessen. Fehler in diesen Prozessen führen oft zu unerwarteten Mehraufwänden. Besonders dann, wenn diese Fehler erst spät erkannt werden, da für die stetig steigenden Datenmengen oft nur rudimentäre Monitoring-Prozesse existieren, die verschiedene Formen von Datenproblemen nicht erkennen. Für viele der möglichen Datenprobleme gibt es Lösungen, diese führen jedoch oft zu Verzögerungen oder erfordern es, die Vorgehensweise zu ändern. Daraus wird ein weiteres Charakteristikum von Data-Science-Projekten in der Praxis deutlich: Sie sind iterativ und erfordern Flexibilität. Man kann aus Erfahrung heraus sagen, zwischen welchen Arbeitsschritten typischerweise häufiger Iterationen auftreten, wie beispielsweise zwischen den Datentransformationen und der Modellierung – jedoch ist es vorab schwierig abzuschätzen, wie viele Iterationen genau durchlaufen werden. Es können prinzipiell zwischen allen notwendigen Arbeitsschritten Iterationen nötig sein. Das macht Data-Science-Projekte aus planerischer Sicht herausfordernd. Klassische Wasserfallmodelle sind für Data-Science-Projekte aufgrund dieser Eigenschaften eher ungeeignet.

Für den betriebswirtschaftlichen Erfolg eines Data-Science-Projekts sind mindestens folgende Faktoren von großer Bedeutung:

  1. Ein hohes Maß an zielgerichteter Kommunikation und ehrliches Erwartungsmanagement
  2. Ausgeprägtes Business Understanding und das anschließende Matching zum Data Understanding
  3. Iteratives Vorgehen bei gleichzeitigem Mut zu Entscheidungen mit Fokus auf Fortschritt

Zahlreiche Artikel und Berichte unterstreichen diese Erfahrungswerte (siehe beispielsweise [Demirkan & Dal 2014; Gronau et al. 2016]). Aus den Erläuterungen wird deutlich, dass Data-Science-Projekte häufig hohe Anforderungen an die Durchführenden stellen.

Neben bereits genannten Punkten ist eine weitere praktische Herausforderung, dass das geforderte Skillset für einen Data Scientist divers und sehr anspruchsvoll ist. Die Interdisziplinarität des Feldes fordert unweigerlich ebenso interdisziplinär ausgebildete, hochgradig spezialisierte Experten, die sowohl in der Statistik und Mathematik als auch in der Informatik über ein breites Spektrum an Methodenwissen verfügen und möglichst ebenso umfangreiche Erfahrungen bei der Anwendung dieser vielfältigen Methoden auf betriebswirtschaftliche Fragestellungen mitbringen. Die Suche nach Talenten gestaltet sich demnach als schwierig – und die Qualifikation junger Nachwuchskräfte benötigt dementsprechend viel Zeit. Viele Unternehmen haben erst in den letzten Jahren damit begonnen, Data Science für sich nutzbar zu machen. Daher ist der Kompetenzaufbau und das ständige Lernen neuer Methoden ein weiterer wichtiger Aspekt von vielen Data-Science-Projekten in der Praxis. Neben theoretischen Trainings erweist sich »Training on the Job« in vielen Fällen als unverzichtbar. Vor dem Hintergrund der iterativen Natur von Data-Science-Projekten und deren Komplexität ist dies aus planerischer Sicht allerdings eine weitere Herausforderung. Aus Sicht der Autoren bietet Scrum hierauf eine gute Antwort (siehe Abschnitt 16.4.2).

16.4Der Einsatz von Scrum in Data-Science-Projekten

Grundlage dieses Beitrags bilden die Erfahrungen des Data-Science-Teams der Volkswagen Financial Services AG. Seit 2014 hat das Team eine Vielzahl von Data-Science-Anwendungsfällen umgesetzt. Während die Weiterentwicklung des Themengebiets einer Strategie folgt, wurde die Arbeitsweise des seither wachsenden Teams stets flexibel den ebenso steigenden Anforderungen angepasst. 2017 hat das Team entschieden, testweise Scrum als Vorgehensweise einzuführen. Aufgrund der positiven Erfahrungen ist Scrum bis heute im Einsatz, mittlerweile mit einigen Adaptionen.

16.4.1Eigene Adaption

Teamaufstellung

Das Scrum-Team besteht zum Zeitpunkt der Verfassung dieses Beitrags aus einem Product Owner, einem Scrum Master und einem Entwicklungsteam mit sechs Data Scientists, zwei Data Analysts und einem Data Engineer. Die Rollenabgrenzung ist dabei aber nur als Orientierung zu verstehen.

Das Scrum-Team ist initial mit einer Größe von insgesamt fünf Mitgliedern gestartet und wächst noch weiter. Mit einer Teamgröße von neun Mitgliedern wurde bereits die im Scrum Guide empfohlene Maximalgröße erreicht [Schwaber & Sutherland 2017].

Aktivitäten

Die Sprint-Länge beträgt seit Beginn zwei Wochen und wurde nicht verändert. Diese Länge erweist sich als sehr passend für die Umsetzung diverser Teilprojekte: Es ist genügend Zeit, um greifbare Ergebnisse zu produzieren, und nicht zu viel Zeit, um nicht zu lange in eine nicht vielversprechende Richtung zu arbeiten.

Das Daily Scrum ist auf die maximal zulässige Dauer von täglich 15 Minuten angesetzt – die tatsächliche Dauer liegt in der Regel zwischen 10 und 15 Minuten. Maßgabe ist, dass während des Daily Scrum keine umfangreichen, fachlichen Diskussionen entstehen.

An dem »Sprint-Tag« findet alle zwei Wochen das Sprint-Review, die Retrospektive und das Planning für den kommenden Sprint statt. Insgesamt werden für das Review mittlerweile eine Stunde angesetzt, für die Retrospektive ebenso und für das Planning I und II insgesamt zwei Stunden. Die Termine finden mit Pausen aufeinanderfolgend statt. Die Dauer der einzelnen Termine wurde bereits mehrfach angepasst.

Das Sprint-Review findet in variierend großen Runden statt. Immer anwesend sind dabei das gesamte Entwicklungsteam, der Product Owner und der Scrum Master. Die Teilnahme verschiedener Stakeholder variiert. Die Teammitglieder sind angehalten, die Vorbereitungszeit für das Review auf etwa eine Stunde zu beschränken und die Ergebnisse nach Möglichkeit direkt in den verwendeten Systemen oder Tools zu präsentieren. Je nach Projektphase sind unter Umständen auch einzelne oder wenige Präsentationsfolien sinnvoll. Maßgeblich ist, dass jedes Teammitglied kurz und prägnant die jeweils produzierten Ergebnisse des vergangenen Sprints präsentiert.

Die Retrospektive bezieht sich abwechselnd auf den vergangenen Sprint oder auch auf globalere Themen wie die Nutzung von Scrum allgemein. Dementsprechend können die Formate sehr stark variieren, in denen die Retrospektive durchgeführt wird.

Das insgesamt zweistündige Planning ist in zwei Phasen aufgeteilt: Planning I und II. Im Planning I stellt der Product Owner alle zu bearbeitenden Product-Backlog-Einträge vor. Diese werden so lange erläutert und offen diskutiert, bis alle Teammitglieder signalisieren, dass sie Inhalte, Ziele und Abnahmekriterien des Product-Backlog-Eintrags verstanden haben. Daraufhin wird der Aufwand für die Implementierung des vorgestellten Eintrags durch das Entwicklungsteam geschätzt. Der Aufwand wird dabei in relativen Story Points geschätzt, und die Schätzung erfolgt im Planning-Poker-Verfahren. Dabei schätzen grundsätzlich alle Teammitglieder alle Aufgaben, auch wenn einzelne Teammitglieder nicht für jeden Product-Backlog-Eintrag über angemessenes Hintergrundwissen verfügen. Die Schätzungen werden so oft wiederholt, bis das Team einen Konsens findet.

Nachdem alle für den folgenden Sprint relevanten Product-Backlog-Einträge vorgestellt, diskutiert und mit Aufwandsschätzungen versehen wurden, gibt das Entwicklungsteam ein Commitment ab, wie viele der nach Priorität geordneten Einträge es im nächsten Sprint realisieren kann.

Im Anschluss daran beginnt Planning II, bei dem alle Mitglieder des Entwicklungsteams sich zunächst untereinander koordinieren, wer an welchen Themen arbeiten wird, und dann selbst die jeweiligen Tasks formulieren, die benötigt werden, um die Sprint-Ziele zu erreichen. Jedes Teammitglied ist hierbei völlig autark und darf selbst entscheiden, wie es welche Tasks formuliert und angeht, ebenso in welcher Reihenfolge. Als Orientierung dient dabei, dass ein Task nicht länger als ein Tag zur Bearbeitung dauern soll, ansonsten wird er wiederum in mehrere Tasks zerlegt.

Artefakte

Das Data-Science-Scrum-Team ist im Unternehmen als Projekt organisiert. Betrachtet man jedoch die verschiedenen vom Projektteam bearbeiteten Anwendungsfälle, so ließe sich jeder einzelne Anwendungsfall auch als ein eigenständiges Projekt oder als Teilprojekt ansehen. Dabei haben die unterschiedlichen Anwendungsfälle im Unternehmen auch verschiedene Stakeholder.

Um diesem Umstand gerecht zu werden, werden Epics als logische Gruppierung von Product-Backlog-Einträgen verwendet. Ein Epic entspricht dabei einem Anwendungsfall. Diese Epics variieren stark in Umfang und Komplexität, sind aber typischerweise zu klein, um dafür den zusätzlichen Aufwand für eine separate Projektorganisation zu rechtfertigen. Jeder Product-Backlog-Eintrag ist einem Epic zugeordnet.

Für das Product Increment bedeutet dies, dass es am Ende eines Sprints nicht ein Product Increment gibt, sondern mehrere, nämlich genau so viele Increments, wie Epics im Sprint bearbeitet werden.

Dadurch, dass das Product Backlog Einträge zu verschiedenen Epics enthält, ist die durch den Product Owner durchgeführte Priorisierung auch interpretierbar als eine Projektportfoliomanagement-Tätigkeit.

Der Umfang der Product-Backlog-Einträge wird vom Product Owner so bemessen, dass sie innerhalb eines Sprints implementierbar sind. Jedes Teammitglied entscheidet eigenverantwortlich, wie viele und wie granular Tasks erstellt werden sollen. Die Akzeptanzkriterien werden so formuliert, dass durch diese Kriterien sichergestellt wird, dass das Arbeitsergebnis den Vorstellungen des Product Owners entspricht und dass der Erfüllungsgrad im Rahmen des Sprint-Reviews messbar und ersichtlich wird. Die folgende Infobox zeigt beispielhaft die Formulierung eines Product-Backlog-Eintrags, seiner Akzeptanzkriterien und des dazugehörigen Epic:

image

Abb. 16–2Product Backlog mit Akzeptanzkriterien und Epic

Tools

Für die Verwaltung des Product Backlog, somit also auch der Epics und der Product-Backlog-Einträge sowie der Sprint Backlogs, nutzt das Scrum-Team die Software JIRA. Die zuvor verwendeten, mit Office-Software improvisierten Listen haben sich mit einer steigenden Anzahl von gleichzeitig zu bearbeitenden Anwendungsfällen als unzureichend herausgestellt.

Zusätzlich verwendet das Team ein physisches Sprint-Board, auf dem in jedem Sprint die operative Planung der Sprint-Durchführung erledigt wird. Werden Product-Backlog-Einträge durch Teammitglieder mit Tasks versehen, so werden diese als Klebezettel auf dem Sprint-Board platziert. Das Sprint-Board wird durch die Teammitglieder vor dem Daily Scrum aktualisiert.

Auch wenn die verwendete Software die Taskplanung ebenfalls unterstützen würde, hat das Team entschieden, weiterhin ein physisches Sprint-Board für die operative Sprint-Durchführung zu verwenden.

16.4.2Realisierte Vorteile

Die Einführung und Etablierung von Scrum im Bereich Data Science der Volkswagen Financial Services AG bringt aus Sicht der Autoren viele Vorteile mit sich, die im Folgenden dezidiert erläutert werden. Insbesondere den in Abschnitt 16.3 erläuterten typischen Herausforderungen von Data-Science-Projekten kann man durch Scrum gut begegnen.

Schnelle Adaption an neue Voraussetzungen

Scrum ist ein Framework, um speziell komplexe und adaptive Probleme zu adressieren [Schwaber & Sutherland 2017]. Scrum ist somit per Definition auf Änderungen vorbereitet. Änderungen sind, wie in Abschnitt 16.3 bereits aufgezeigt, Data-Science-Projekten inhärent. Bei der Arbeit mit großen Datenbeständen und komplexen Datenstrukturen treten kontinuierlich neue Erkenntnisse zutage. Fehlende Dokumentationen von Datenbeständen und die sich daran anschließende Herausforderung, undokumentierte Daten fachlich zu verstehen, erfordern flexible Anpassungen der Vorgehensweisen. Bei explorativen Vorgehensweisen, insbesondere bei der Verwendung unüberwachter Lernverfahren, kann die Unsicherheit noch größer werden, da das fachliche Ziel vorab nicht immer klar bestimmt sein muss. Um Data-Science-Projekte zum Erfolg führen zu können, ist es somit unerlässlich, auf sich ändernde Bedingungen einzugehen und neue Anforderungen dynamisch aufzunehmen. Nicht agile Vorgehensmodelle versuchen hingegen eher, Risiken a priori zu minimieren und mögliche Änderungen zu antizipieren, indem vorab möglichst genau geplant und konzipiert wird. Aufgrund der beschriebenen Eigenschaften ist dies für Data-Science-Projekte ineffizient. Scrum hingegen nimmt sich der Änderungen an und rückt Unsicherheit und Projektkomplexität in den Fokus [Schwaber & Sutherland 2017]. Dadurch können schneller verwertbare Ergebnisse produziert werden.

Sprint-Reviews in kurzen Zyklen ermöglichen Risikominimierung durch umfassendere Transparenz über den Fortschritt

Die Transparenz über den Fortschritt entsteht in Scrum primär im Sprint-Review. Klassische, nicht agile Projektvorgehensmodelle verfügen durchaus über erprobte Methoden zur Fortschrittsmessung, jedoch sind diese typischerweise auf eine quantitative Betrachtung fokussiert. Viele Data-Science-Anwendungsfälle bringen, wie bereits erläutert, ein höheres Maß an Unsicherheit mit sich als beispielsweise klassische Softwareentwicklungsprojekte. Oft ist vorab etwa völlig unklar, ob die vorhandene Datengrundlage ausreichend ist, um eine vorgegebene fachliche Fragestellung lösen zu können. Quantitative Fortschrittsmessungen sind dadurch in den meisten Fällen nicht zielführend und es müssen vor allem die inhaltlichen Fortschritte bewertet und gegebenenfalls Ziele angepasst werden.

Scrum institutionalisiert mit dem Sprint-Review einen Termin, in dem alle Stakeholder die Möglichkeit haben, den Fortschritt des Teams auch inhaltlich zu verstehen und zu hinterfragen. Vor allem für den Product Owner ist dieser regelmäßige Termin eine Chance, die Risiken, die durch große Unsicherheiten in Data-Science-Anwendungsfällen entstehen, zu minimieren. Wenig aussichtsreiche und wirtschaftlich nicht lösbare Anwendungsfälle können so frühzeitig erkannt und gegebenenfalls abgebrochen werden. Die Qualität der Entscheidung kann durch Einbeziehung verschiedener Experten im Review sogar ad hoc erhöht werden. Voraussetzung für die Realisierung dieses Vorteils ist ein hohes Maß an Data-Science-Kompetenz beim Product Owner, gleichzeitig aber auch eine klare Fokussierung auf die wirtschaftlichen Rahmenbedingungen der Data-Science-Anwendungsfälle.

Qualitätssteigerungen durch Transparenz und Selbstorganisation des Teams

Von der durch die Sprint-Reviews hergestellten Transparenz profitieren nicht nur Product Owner und andere Stakeholder, sondern auch die Mitglieder des Entwicklungsteams selbst. Für die Lösung von Data-Science-Fragestellungen sind der Kreativität kaum Grenzen gesetzt, selten gibt es eindeutig »richtige« und »falsche« Lösungsansätze. In der Praxis existieren viele Fälle, in denen es verschiedene Modellierungsansätze gibt, die jeweils ihre Vor- und Nachteile haben. Für Recommendation Engines können beispielsweise unter anderem Prognosemodelle, Clusterings oder Matrixfaktorisierungen als Modellierungsansätze infrage kommen. Wie bei vielen Fragestellungen kann man hier von zusätzlichen Expertenmeinungen profitieren und die Lösung potenziell verbessern. Voraussetzung dafür ist, dass man als Teammitglied aktiv weitere Expertenmeinungen hinzuzieht. Das Sprint-Review bietet die Möglichkeit, einen solchen Austausch zu fördern. Das gesamte Team erhält auch Einblicke in die von anderen Teammitgliedern erarbeiteten Ergebnisse, selbst wenn die Kollegen nicht aktiv den Austausch gesucht haben. Oft haben Teammitglieder wertvolle Hinweise und Empfehlungen parat, die die Qualität der Ergebnisse steigern. Voraussetzung für die Realisierung dieses Vorteils ist ein geeignetes Diskussions- bzw. Präsentationslevel. Dieses Level hängt üblicherweise vom regelmäßigen Teilnehmerkreis ab und kann stark schwanken. Denkbar ist ein sehr technisches Level mit viel Fokus auf die Art und Weise, wie Aufgaben gelöst wurden. Dieses Level ist jedoch problematisch für Reviews, an denen viele Stakeholder aus dem Management ohne jegliches Data-Science-Verständnis teilnehmen.

Weitere Qualitätsverbesserungen sind möglich, indem der Scrum Master Teammitglieder während des Planning motiviert, an einzelnen Aufgaben mit mehreren Leuten zu arbeiten. Scrum bietet hierfür eine geeignete Plattform: Durch die Selbstorganisation des Teams können die Teammitglieder untereinander selbst entscheiden, an welchen Themen sie arbeiten, insbesondere ist es auch möglich, dass mehrere Teammitglieder sich mit derselben Aufgabe beschäftigen. In der klassischen Softwareentwicklung gibt es weitgehend positive Erfahrungen mit ähnlichen Methoden, wie z.B. dem Pair Programming. Ein vergleichbares Vorgehen für Data-Science-Anwendungsfälle lässt sich in Scrum nahtlos integrieren. Allerdings erfordert es unter Umständen noch zusätzliche Impulse vom Scrum Master oder Product Owner, um den Teammitgliedern diese Möglichkeiten zu erläutern und sie gegebenenfalls aktiv zu motivieren, solche Zusammenarbeitsmodelle zu testen. Durch den regelmäßigen Austausch lernt das Team die Arbeitsweise aller genau kennen und damit auch die Stärken der einzelnen Mitglieder. Dies ermöglicht eine sich stets verbessernde Zusammenarbeit mit Potenzialen für Qualitätssteigerungen und Produktivitätsgewinne.

An dieser Stelle zeigt sich ein weiterer großer Vorteil von Scrum: Die Selbstorganisation des Entwicklungsteams, insbesondere im Rahmen des Sprint Planning, bietet den Teammitgliedern Entscheidungsmöglichkeiten und Gestaltungsspielraum. So können sich die einzelnen Personen an Aufgaben beteiligen, die ihr Interesse wecken und ihren Fähigkeiten entsprechen. Dieser Vorteil lässt sich natürlich nur realisieren, wenn das Data-Science-Anwendungsfallportfolio des Unternehmens ausreichend umfangreich ist und eine gewisse Heterogenität an Aufgaben bietet.

Scrum schafft gute Rahmenbedingungen für den Aufbau eines Data-Science-Teams

Die oben beschriebenen positiven Effekte der durch Scrum und die Selbstorganisation des Teams geförderten Zusammenarbeitsmodelle lassen sich auf verschiedene Art und Weise kanalisieren. Ein möglicher Benefit ist die Qualitätsverbesserung des Ergebnisses. Beim Pair Programming in der klassischen Softwareentwicklung wird auch ein Produktivitätsgewinn als positiver Effekt benannt. Dafür wird jedoch empfohlen, dass die jeweiligen Partner eine vergleichbare fachliche Kompetenz einbringen. Insofern erscheint dieser Vorteil nur auf erfahrene Data-Science-Teams übertragbar. In vielen Unternehmen sind die Data-Science-Teams jedoch gerade erst im Aufbau, und die Erfahrungslevel der Data Scientists sind sehr unterschiedlich. Viele Unternehmen haben das Ziel, ihr Know-how im Bereich Data Science deutlich auszubauen. Auch dafür bietet Scrum ein hilfreiches Rahmenwerk. Geht das Team offen mit unterschiedlichen Erfahrungslevels der Teammitglieder um, so funktioniert das voneinander Lernen fast von allein. Während des Sprint Planning finden die einzelnen Teammitglieder über die anstehenden Aufgaben zueinander, und Teammitglieder mit weniger Erfahrung können gezielt die Zusammenarbeit mit erfahreneren Kollegen suchen. Da das Team sich im Planning gemeinsam auf ein Sprint Backlog einigt und hierfür ein Commitment abgibt, wird eine Grundlage für einen Gemeinschaftssinn gelegt, in dem es für alle hilfreich und oft auch nötig ist, sich gegenseitig zu helfen.

Seit vielen Jahren kämpfen (deutsche) Unternehmen um talentierte Data Scientists [McKinsey 2011]. Dieser Vorteil für den Aufbau eines Data-Science-Teams ist angesichts der geringen Zahl der am Arbeitsmarkt verfügbaren Spezialisten für Data Science daher nicht zu unterschätzen. Während das voneinander Lernen kurzfristig zusätzlichen Aufwand und Produktivitätsrückgänge verursachen kann, sind mittel- bis langfristig erhebliche Effizienzgewinne durch den geförderten Austausch zu erwarten. Überdies wird eine gute Arbeitsatmosphäre geschaffen, in der sich die Mitarbeiter wohlfühlen. Damit kann man übermäßige Personalfluktuationen verringern, um so die Weiterentwicklung des Data-Science-Teams nicht zu gefährden.

Motivation durch Wertschätzung und Anerkennung in Sprint-Reviews

Wertschätzung und Anerkennung sind eine entscheidende Grundlage für die Motivation und die Zufriedenheit vieler Menschen im Beruf.

Eine Umfrage unter Data Scientists hat gezeigt, dass ein großer Teil der in diesem Umfeld tätigen Menschen eher introvertierte Charakterzüge aufweist [SAS Institute 2014]. Die persönlichen Erfahrungen der Autoren unterstützen diese These.

Klassische Formate wie Präsentationen und Vorträge vor großem Publikum bieten sich für viele Data Scientists aus diesem Grunde eher nicht als geeigneter Weg zur Erlangung von Wertschätzung an. Sprint-Reviews sind hingegen eine durchaus geeignete Plattform, um den Mitgliedern des Entwicklungsteams Wertschätzung und Anerkennung entgegenzubringen. Zum einen bieten die Reviews einen geschützten Raum mit bekannten Kollegen. Durch die Selbstorganisation des Teams bleibt es den einzelnen Mitgliedern überlassen, welche Personen einen Teil des Product Increment vorstellen. Zurückhaltende Mitglieder können somit entscheiden, entweder gar nicht aktiv an der Präsentation teilzunehmen – ein gut funktionierendes Team würde an dieser Stelle den Beitrag der nicht vortragenden Kollegen lobend hervorheben – oder einzelne Teammitglieder können die Teile des Product Increment vorstellen, mit denen sie am besten vertraut sind. Der Rest des Entwicklungsteams ist dabei sowohl Rückendeckung und kann den Vortragenden jederzeit unterstützen als auch Teil des Wertschätzung spendenden Publikums. Denn vielen Experten bedeutet gerade die Wertschätzung anderer Experten mehr als die Anerkennung von Führungskräften, die die Ergebnisse komplexer Data-Science-Projekte im Detail nicht immer nachvollziehen können.

Voraussetzung für die Realisierung dieses Vorteils ist ein geeignetes Präsentationslevel in den Sprint-Reviews sowie ein entsprechend angemessener Einladungskreis zu diesem Termin (siehe Abschnitt 16.5).

Fokus als zentraler Scrum-Wert hilft, die wesentlichen Ziele ständig zu verfolgen

Die Bedürfnisse der einzelnen Data Scientists haben erfahrungsgemäß oft auch eine Kehrseite: Folgt man allzu sehr diesen Bedürfnissen, findet man sich in Data-Science-Anwendungsfällen nicht selten gefangen in einer Schleife aus Datenvorverarbeitung und Modellierung. Denn hier ist der Ehrgeiz des Data Scientist geweckt: Was kann ich tun, um das Modell noch besser zu machen? Für viele Anwendungsfälle ist es jedoch gar nicht entscheidend, ob das neueste neuronale Netz die Prognosegüte um weitere 0,01% verbessern kann. Jedenfalls dann nicht, wenn die Entwicklung dieses Modells signifikanten Aufwand verursacht. An dieser Stelle bietet Scrum die Möglichkeit, zunächst Transparenz über diese Aufgaben und deren Ressourceneinsatz zu schaffen. Um diesen Vorteil zu realisieren, darf die Dauer der Sprints nicht zu lang sein. Die Autoren empfehlen 14 Tage. Darüber hinaus lässt sich der Ressourceneinsatz optimieren, indem der Product Owner die Product-Backlog-Einträge angemessen definiert und priorisiert. So können die Teamressourcen gezielt eingesetzt werden, ohne die Teammitglieder allzu stark in ihrem Gestaltungsspielraum einzuschränken.

Durch das inkrementelle Vorgehen und die Flexibilität, die Scrum bietet, können außerdem »Fail-Fast«-Ansätze mühelos im Projektalltag integriert werden. Typischerweise werden für Prognosemodellierungsprojekte schnelle Prototypen erstellt. Durch schnelles und zügiges Prototyping kann besser eingeschätzt werden, wie gut das Prognosemodell funktionieren wird. Zeigt sich, dass das Modellierungsvorhaben aus unterschiedlichen Gründen ineffizient sein sollte, so wird dies im Sprint-Review transparent. Der Product Owner kann die Situation entsprechend neu bewerten und eine Entscheidung treffen, ob der Anwendungsfall weiter verfolgt wird.

Institutionalisierte Selbstoptimierung durch Retrospektiven/Erhöhung der Zufriedenheit

Je nach Sprint-Länge gibt es verschiedene Empfehlungen zur Dauer einer Retrospektive, der Scrum Guide aus 2013 nannte eine Dauer von drei Stunden für eine Sprint-Länge von vier Wochen [Schwaber & Sutherland 2013]. Die Autoren nehmen sich 60 Minuten Zeit für eine Retrospektive bei einer Sprint-Länge von zwei Wochen. Das entspricht ungefähr 2,5% der gesamten Sprint-Länge, also ein vergleichsweise geringer Anteil.

Trotzdem berichten viele Scrum Master immer wieder von der Unwilligkeit ihres Teams, Retrospektiven durchzuführen. Es sind viele Gründe dafür vorstellbar, auch die Autoren haben schon einzelne Retrospektiven erlebt, die man mit der Frage nach der konkreten Wertschöpfung dieses Treffens verlässt. Nicht in jeder Retrospektive treten Erkenntnisse oder Ideen mit konkret quantifizierbarem Produktivitätsgewinn zutage. Betrachtet man jedoch die Entwicklung des Sprint-Teams über einen längeren Zeitraum, insbesondere im Hinblick auf die aus Retrospektiven entstandenen Verbesserungen der Zusammenarbeit, so ist das Autorenteam davon überzeugt, dass der Nutzen ein Vielfaches der investierten Zeit beträgt, selbst wenn man nur den gefühlten (in Ermangelung sinnvoll attribuierbarer Messbarkeit) Produktivitätsgewinn betrachtet.

Zusätzlich ist auch ein weiterer, insbesondere für Data-Science-Teams sinnvoll erscheinender Vorteil von regelmäßigen Retrospektiven erkennbar. Die Retrospektive ist auch eine Gelegenheit, um Probleme offen anzusprechen. Vorausgesetzt der Scrum Master schafft es, eine Atmosphäre des gegenseitigen Vertrauens, des Respekts und der Anerkennung zu etablieren, so sind die Hürden für einen introvertierten Menschen in diesem geschützten Raum geringer, ein mögliches Problem anzusprechen. Insbesondere weil der Scrum Master durch verschiedene Formate und Techniken jedes Teammitglied einbindet und auffordert, Feedback zu geben, werden auch Teammitglieder motiviert, die rein aus Eigeninitiative mögliche Probleme oder Potenziale zur Verbesserung nicht proaktiv angesprochen hätten (siehe [SAS Institute 2014] Proaktiver vs. Reaktiver Typ). Der Vorteil von regelmäßigen Retrospektiven besteht also auch in der potenziellen Erhöhung der Zufriedenheit des Teams. Zufriedene, positive Teams wiederum bringen nachweislich auch bessere Leistung [Cameron et al. 2011].

Daily Scrum fördert Austausch im Team

Scrum bietet mit dem Daily Scrum eine Möglichkeit, den Austausch untereinander zu fördern, ohne allzu viel Zeit in Anspruch zu nehmen. Dadurch, dass jedes Teammitglied aufgefordert wird, über den vergangenen sowie den anstehenden Tag und über eventuelle Behinderungen zu berichten, werden bisweilen Themen angesprochen, die zurückhaltendere Teammitglieder ohne einen derartig institutionalisierten Termin rein aus Eigeninitiative hin vermutlich eher nicht angesprochen hätten. Der Austausch erfolgt dabei in einem geschützten Raum, unter bekannten Kollegen, in dem jedes Teammitglied denkbar geringe Hürden haben sollte, sämtliche Themen offen anzusprechen.

Höhere Effizienz und besseres Verständnis der Anforderungen durch Planning Poker

Eines der am kontroversesten in der agilen Community diskutierten Themen sind Aufwandsschätzungen. Die Bewegung #NoEstimates, die die Sinnhaftigkeit von Aufwandsschätzungen infrage stellt, hat eine wachsende Menge an Anhängern, jedoch gibt es ebenso überzeugte Verfechter traditioneller Aufwandsschätzungen. Bei der Durchführung von Schätzungen wiederum gibt es eine große Bandbreite an verschiedenen Verfahren, zum einen die klassische Schätzung in Stunden, zum anderen relative Methoden wie Story Points oder T-Shirt-Größen.

Interessanterweise finden sich im Scrum-Framework keinerlei Aussagen zu Schätzmethoden bzw. Empfehlungen zur Sinnhaftigkeit von Schätzungen. Story Points sind also eines von vielen Konzepten, die in der Scrum-Praxis weit verbreitet sind, jedoch genau wie beispielsweise »User Stories« nicht ursprünglich dem Scrum-Framework entstammen.

Das Autorenteam ist zu der Einschätzung gelangt, dass Aufwandsschätzungen für die Product-Backlog-Einträge deutlich wahrnehmbare, wertvolle Vorteile einbringen können, während der eigentliche Schätzaufwand in überschaubaren Grenzen bleibt (ca. 30 Minuten pro Sprint). In den ersten Monaten nach Einführung von Scrum verzichteten die Autoren vollständig auf Aufwandsschätzungen von Product-Backlog-Einträgen. Aus planerischer Sicht brachte dies überraschend gute Resultate: Das Entwicklungsteam hatte auch ohne Aufwandsschätzungen einzelner Arbeitspakete ein gutes Gefühl dafür, wie viele Product-Backlog-Einträge in einem Sprint umsetzbar sind. Aus planerischer Sicht waren Aufwandsschätzungen also nicht zwingend erforderlich. Nach der Einführung von Planning Poker als Schätzverfahren (mit relativen Story Points) waren außerhalb einer rein planerischen Sicht jedoch mehrere Verbesserungen feststellbar:

In den Sprints, die ohne Aufwandsschätzungen durchgeführt wurden, kam es gelegentlich dazu, dass das Product Increment nicht den Vorstellungen des Product Owners entsprach. Die naheliegende Lösung hier ist die Qualität, häufig einhergehend mit dem Umfang und der Forderung, die Beschreibungen der Product-Backlog-Einträge zu erhöhen und Abnahmekriterien stärker zu detaillieren. Eine weitere Möglichkeit ist Planning Poker: Gerade bei interdisziplinär zusammengestellten Teams gibt es immer Teammitglieder, die wegen ihres Hintergrunds einzelne Product-Backlog-Einträge nur schwerlich abschätzen können. Dies führt oft zu voneinander abweichenden Aufwandsschätzungen und Nachfragen, die die Aufgabenstellung aus verschiedenen Blickwinkeln beleuchten. Daraus wiederum entstehen rege Diskussionen im Team, die nicht selten auch bei mühsam detailliert beschriebenen Product-Backlog-Einträgen neue Aspekte zutage fördern, die der Product Owner nicht bedacht hat. Diese Diskussionen tragen oft zu einem besseren Verständnis der Anforderungen bei und haben dazu geführt, dass die erreichten Sprint-Ziele besser mit den Erwartungen des Product Owners übereinstimmen.

Ein weiterer positiver Effekt der entstehenden Diskussionen über Aufwände sind Effizienz- oder Qualitätsgewinne. Dadurch, dass jedes Teammitglied alle Product-Backlog-Einträge schätzt, auch diejenigen, an denen es möglicherweise nicht mitarbeitet, treten schon sehr früh unterschiedliche Lösungswege zutage. Data Science ist ein breites Anwendungsgebiet mit vielzähligen Verfahren und vielen Möglichkeiten, Aufgabenstellungen zu lösen. Alle Teammitglieder haben unterschiedliche Erfahrungen und Ideen, wie man eine beschriebene Aufgabe lösen könnte. Durch unterschiedlich hohe Aufwandsschätzungen werden diese verschiedenen Lösungswege in der Diskussion für das gesamte Team transparent. Diejenigen Teammitglieder, die den Product-Backlog-Eintrag bearbeiten werden, bekommen oft wertvolle Impulse zu verschiedenen Lösungsansätzen, noch bevor die eigentliche Arbeit daran begonnen hat. Diese Impulse können sich im Laufe des Sprints als Effizienzgewinn oder auch als Qualitätsverbesserung manifestieren.

16.4.3Herausforderungen

Neben den zahlreichen realisierten Vorteilen, die die Einführung von Scrum für Data-Science-Projekte mit sich bringt, gibt es jedoch auch einige Herausforderungen.

Was ist das Produkt?

Product Owner, Product Backlog und Product Increment: In Scrum dreht sich alles um das Produkt. Am Ende eines jeden Sprints soll ein potenziell auslieferbares Produkt stehen. Betrachtet man den Ursprung von Scrum, die Softwareentwicklung, so ist die Frage nach dem Produkt üblicherweise trivial zu beantworten: In der Regel wird ein Stück Software entwickelt. Ebenso im klassischen Produktmanagement, auch hier ist die Frage nach dem Produkt bereits implizit beantwortet.

Für Data-Science-Scrum-Teams gibt es allerdings selten nur ein Produkt. Der Grund dafür ist, dass viele Unternehmen – aus nachvollziehbaren Gründen – ihr Data-Science-Know-how innerhalb des Unternehmens bündeln. Die Vorteile liegen nahe: Gerade da am Arbeitsmarkt seit vielen Jahren ein stetiger Mangel an qualifizierten Data Scientists herrscht, erscheint es sinnvoll, das Know-how dieser Mitarbeiter möglichst effizient einzusetzen und Data Scientists zusätzlich die Möglichkeit zu geben, voneinander zu lernen und ihr Methodenspektrum zu verbreitern. Insofern sind Data-Science-Teams zu jedem Zeitpunkt typischerweise mit vielen verschiedenen Anwendungsfällen konfrontiert (eine gewisse Größe des Teams und des Unternehmens vorausgesetzt).

Daraus resultieren gleich mehrere Herausforderungen. In der reinen Form geht Scrum davon aus, dass es ein Produkt gibt. Sämtliche Product-Backlog-Einträge beschreiben Eigenschaften oder Funktionalitäten dieses einen Produkts, und die Einträge werden durch den Product Owner priorisiert, möglichst nach dem Wert, den sie dem Kunden, Anwender oder Auftraggeber bringen. Wie soll der Product Owner nun Product-Backlog-Einträge priorisieren, die sich auf verschiedene Anwendungsfälle mit verschiedenen Stakeholdern beziehen? Auf Ebene der Anwendungsfälle ist dies eine typische Aufgabe des Projektportfoliomanagements. Die Komplexität wird durch die Ebene der Product-Backlog-Einträge weiter erhöht: Möglicherweise ist Anwendungsfall A im folgenden Sprint wichtiger als Anwendungsfall B. Trotzdem gibt es vielleicht Product-Backlog-Einträge für Anwendungsfall B, die wichtiger sind als einige Product-Backlog-Einträge für Anwendungsfall A. Die Abwägung der Priorität erfolgt also für jeden einzelnen Product-Backlog-Eintrag separat. Bei vielen verschiedenen, gleichzeitig in einem Sprint zu bearbeitenden Anwendungsfällen entsteht daraus ein nicht trivialer Abwägungsprozess.

Weitere Herausforderungen ergeben sich für die operative Planung der Sprint-Durchführung, die das Entwicklungsteam im Rahmen des Planning II selbstständig erledigt. Laut Scrum ist es wünschenswert und förderlich, wenn jedes Teammitglied frei Aufgaben auswählt, die es bearbeiten möchte. Gäbe es nur ein Produkt, so bliebe der Kontext für alle Teammitglieder gleich, unabhängig von den zu bearbeitenden Product-Backlog-Einträgen. Aufgrund der hohen Komplexität der verschiedenen Data-Science-Fragestellungen ist ein vollständig dynamischer Austausch von zuständigen Teammitgliedern allerdings kaum zu bewerkstelligen, da durch die hohen Einarbeitungsaufwände starke Effizienz- oder Qualitätsverluste zu befürchten sind.

Eine kommunikative Herausforderung entsteht dadurch, dass durch viele verschiedene Anwendungsfälle oft auch viele verschiedene Stakeholder involviert werden. Gibt es nur ein Produkt, so bietet sich das Sprint-Review an, um die kommunikativen Anforderungen der Stakeholder zu befriedigen. Dieses Vorgehen ist bei vielen verschiedenen Anwendungsfällen mit verschiedenen Stakeholdern und variierenden Bearbeitungsintensitäten je Sprint und Anwendungsfall wenig effizient und für die Stakeholder oft unbefriedigend. Für den Product Owner und für Data-Science-Scrum-Teams entsteht somit ein erhöhter Aufwand zur Koordination der Interessen und Erwartungshaltungen der verschiedenen Stakeholder.

Die kommunikative Herausforderung wird weiter erschwert durch die Eigenschaft von Data-Science-Projekten, in den seltensten Fällen ein wirklich anfassbares Produkt zu generieren, wie zum Beispiel eine Software mit einer grafischen Benutzeroberfläche. Die Ergebnisse von Data-Science-Anwendungsfällen sind in vielen Fällen abstrakt, oft auch komplex. Somit ist es nicht trivial, diese Ergebnisse Stakeholdern ohne rudimentäres Hintergrundwissen über Daten und deren Verarbeitung in adäquater Form vorzustellen. Es erscheint fragwürdig, ob allein die vom Scrum-Framework vorgesehenen Events in der Lage sind, selbst die grundlegendsten Bedürfnisse der Stakeholder zu befriedigen.

Agile Teams in nicht agilem Umfeld

In der Theorie soll sich das Entwicklerteam in Scrum komplett autark organisieren [Schwaber & Sutherland 2017]. In der Praxis gibt es jedoch wenige Unternehmen, die auf allen Ebenen vollständig agil organisiert sind. So besteht neben der Rollenverteilung im Scrum-Kontext zudem noch die organisatorische Rollenverteilung mit verschieden stark ausgeprägten Hierarchien. So wird auch im Scrum-Report 2017 beschrieben, dass zwei Drittel aller Befragten zumindest leichte Spannungen empfinden zwischen der Art und Weise, wie die Scrum-Teams organisiert sind, und der Art, wie das Unternehmen sonst geführt wird [Scrum Alliance 2017]. Dabei haben 30% angegeben, dass die sich möglicherweise ändernden Berichtslinien zu Spannungen führen. Auf diese möglichen Rollenkonflikte sollte man vorbereitet sein und sich im Vorfeld überlegen, wie man damit umgehen möchte. Denn gerade für Data-Science-Scrum-Teams ist die cross-funktionale Zusammenstellung des Teams ein kritischer Erfolgsfaktor. Zusätzlich zu den Data Scientists werden zumindest Fachexperten für betroffene Unternehmensprozesse sowie Experten für die in den betrachteten Prozessen anfallenden Daten benötigt. Fehlendes fachliches Verständnis von Unternehmensprozessen und den zugehörigen Daten erhöht die Wahrscheinlichkeit des Scheiterns von Data-Science-Projekten dramatisch. Dadurch wird bereits die initiale Zusammenstellung des Teams zur Herausforderung, denn die benötigten Experten stehen selten als Vollzeit-Teammitglieder zur Verfügung.

Im weiteren Verlauf der Zusammenarbeit erzeugt Scrum außerdem eine hohe Transparenz und ein höheres Maß an Nähe als andere Modelle der Zusammenarbeit. Existierende betriebliche Hierarchien und Rollen außerhalb des agilen Kontexts vollständig zu ignorieren, erscheint hier unrealistisch.

Eine weitere Herausforderung besteht durch die Zusammenarbeit mit anderen Teams oder Unternehmenseinheiten, die nicht agil organisiert sind. In vielen Data-Science-Anwendungsfällen ist es erstrebenswert, die Projektergebnisse in automatisierte Unternehmensprozesse einzubinden. In Großkonzernen, bei denen Qualität und Stabilität für die Kernprozesse essenziell sind, sind die zuständigen Einheiten häufig nicht agil organisiert. Dadurch können einige Vorteile, die ein Data-Science-Team durch Scrum erzielen kann, wieder zunichte gemacht werden, wie zum Beispiel die Umsetzungsgeschwindigkeit. Insbesondere an zwei Stellen sind typischerweise Verzögerungen zu erwarten. Zum einen in frühen Projektphasen bei der Datenbeschaffung, die unter Einhaltung etablierter Unternehmensprozesse vollzogen werden muss, zum anderen in der Deploymentphase, wenn erarbeitete Ergebnisse in die bestehende IT-Infrastruktur integriert werden müssen.

Einführung von Scrum durch gemeinsames Testen und Lernen

Scrum hat verschiedene Artefakte, Aktivitäten und Rollen. Während Scrum zwar einzelne sehr spezifische Vorgaben mitbringt, so besteht das Vorgehensmodell insgesamt doch nur aus sehr wenigen Regeln. Wie das Autorenteam die wesentlichen Scrum-Bestandteile für sich ausgestaltet hat, wird in Abschnitt 16.4.1 erläutert. Dies ist allerdings bereits das Resultat eines immerwährenden Lernprozesses. Wie lange sollten die Aktivitäten dauern, wie werden sie ausgestaltet? Wie ist das Scrum-Team in den organisatorischen Kontext eingebettet? Um ein wünschenswertes Performance-Level zu erreichen, müssen Lösungen für viele Fragestellungen gefunden werden, für die es keine allgemeingültigen Vorgaben gibt.

Scrum einzuführen und nach Scrum zu arbeiten bedeutet für ein Team, vieles auszuprobieren und den besten Weg für sich zu finden. Das heißt gleichzeitig auch, dass das Arbeitstempo und die Effizienz des Teams kurzfristig zunächst verringert werden. Erst mittel- bis langfristig können dann die in Abschnitt 16.4.2 beschriebenen Vorteile vollständig realisiert werden. Wie lang diese Zeiträume tatsächlich ausfallen, hängt wesentlich von der Erfahrung des Unternehmens in der Anwendung agiler Vorgehensmodelle ab. Für Unternehmen, für die agile Vorgehensmodelle und auch die Verwendung von Data-Science-Methoden zur Gewinnung von Erkenntnissen aus Daten relativ neue Konzepte sind, wird die Herausforderung, in absehbarer Zeit ein gewünschtes Produktivitätsniveau zu erreichen, noch einmal deutlich größer.

Die Schlüsselrolle des Product Owners

Der Product Owner trägt die Verantwortung für den wirtschaftlichen Erfolg des Produkts. Für ein rein virtuelles Data-Science-»Produkt«, das aus mehreren Anwendungsfällen besteht, stellt dies aus fachlicher Sicht bereits eine umfangreiche Aufgabe dar, vergleichbar mit der eines Projektportfoliomanagers im klassischen Projektvorgehen. Allerdings ist der Product Owner kein reiner Koordinator oder Verwalter, er ist auch inhaltlich verantwortlich für alle Eigenschaften des Produkts bzw. der verschiedenen Produkte im Data-Science-Scrum-Team. Die Anforderungen an das fachliche Hintergrundwissen, das für den wirtschaftlichen Erfolg der einzelnen Anwendungsfälle, die aus unterschiedlichsten Unternehmensbereichen stammen können, notwendig ist, sowie das Verständnis über die Bedürfnisse und Anforderungen der zahlreichen Stakeholder schränken den Personenkreis möglicher Kandidaten für diese Rolle bereits stark ein.

Zusätzlich ist eine der zentralen Aufgaben des Product Owners, die Product-Backlog-Einträge zu formulieren. Dabei reicht ein oberflächliches Wissen über Data-Science-Konzepte nicht aus. Einzelne Anwendungsfälle können in der Umsetzung mehrere Monate an Zeit in Anspruch nehmen. Einzelne Product-Backlog-Einträge, deren Implementierungsumfang die Dauer eines Sprints nicht überschreiten sollte, bringen meist recht granulare Teilergebnisse hervor, deren Inhalte und Akzeptanzkriterien nicht nur umfangreiches theoretisches Data-Science-Fachwissen erfordern, sondern ebenso umfangreiche Erfahrungen in der Umsetzung von Data-Science-Projekten. Mit anderen Worten: Der Product Owner sollte ein erfahrener Data Scientist sein.

Diese Anforderung steht im direkten Konflikt zu dem bereits beschriebenen Mangel an Data Scientists auf dem Arbeitsmarkt. Um Rollenkonflikte zu vermeiden, sollte der Product Owner nicht gleichzeitig auch Mitglied des Entwicklungsteams sein (sofern dies zeitlich überhaupt denkbar wäre). Daraus wiederum kann ein Mangel an erfahrenen Data Scientists im Entwicklungsteam resultieren.

Durchführung von Sprint-Reviews

Ein häufig berichteter Vorteil der Nutzung von Scrum ist die insgesamt höhere Zufriedenheit der Stakeholder [Larson & Chang 2016]. In der Theorie haben alle Stakeholder die Möglichkeit, sich in kurzen Abständen in den Sprint-Reviews über den Fortschritt des Projekts zu informieren und die anfassbaren Resultate zu begutachten. Zusätzlich haben sie die Gelegenheit, Feedback zu den gezeigten Eigenschaften des Produkts zu geben, um somit sicherzustellen, dass ihre Anforderungen und Wünsche in möglichst hohem Maße berücksichtigt werden.

Die erste Herausforderung in der Praxis klingt banal: Für Stakeholder aus dem höheren Management ist es unter Umständen nicht trivial, die regelmäßige Teilnahme an einem 14-tägigen, feststehenden und bis zu zweistündigen Termin zu ermöglichen. Eine unregelmäßige Teilnahme wiederum führt aufgrund der Komplexität der Data-Science-Fragestellungen sehr schnell zu einer Entfremdung von den aktuellen Entwicklungen, da in den Sprint-Reviews der Fokus der Präsentation auf den im vergangenen Sprint erarbeiteten Ergebnissen liegt.

Auch der Umstand der vielen verschiedenen, zum Teil voneinander unabhängigen Produkte, die im Sprint-Review vorgestellt werden, erhöht die Anforderungen an die Ablauforganisation des Termins.

Als zentrale Herausforderung für Data-Science-Scrum-Teams empfinden die Autoren jedoch, überhaupt ein geeignetes Präsentations- und Diskussionsniveau für das Sprint-Review festzulegen. Dabei ist eine Abwägung zwischen Detailtiefe und leichter Verständlichkeit für externe Stakeholder erforderlich. Um die kommunikativen Bedürfnisse einer Vielzahl an Stakeholdern aus verschiedenen Bereichen des Unternehmens mit verschieden ausgeprägtem Hintergrundwissen innerhalb eines Termins zu befriedigen, sind deutlich umfangreichere Vorbereitungsarbeiten durch das Entwicklungsteam nötig. Zusätzlich verbleibt im Termin selbst wenig Zeit für detailliertere Ausgestaltungen verschiedener Produkteigenschaften. Durch wechselnde und nur unregelmäßig teilnehmende Stakeholder entsteht außerdem der Bedarf, Vorstellungen und Erläuterungen gegebenenfalls mehrfach zu wiederholen, was den verbleibenden Zeitraum für Detaildiskussionen verringert. Durch eine solch starke Fokussierung auf die Einbindung der Stakeholder in die Reviewtermine besteht die Gefahr, andere wesentliche Vorteile dieses Termins nicht realisieren zu können, insbesondere die Risikominimierung durch umfassendere Transparenz über den Fortschritt (siehe Abschnitt 16.4.2) wie auch mögliche Qualitätsverbesserungen durch einen offenen Austausch unter Experten.

Legt man andererseits den Fokus des Sprint-Reviews auf eine möglichst intensive Diskussion über den qualitativen Fortschritt und bespricht die umgesetzten Produkteigenschaften im Detail, so ist für die meisten Data-Science-Anwendungsfälle schnell eine Gesprächsebene erreicht, der nur noch versierte Experten mit Data-Science-Erfahrung folgen können. Dadurch, dass gerade Zwischenergebnisse in Data-Science-Fragestellungen oft von sehr abstrakter Art sind, werden die Anforderungen an die Teilnehmer des Reviews noch weiter erhöht. Ein solches Präsentationsniveau führt in der Praxis letztlich nahezu unweigerlich zum dauerhaften Fernbleiben wichtiger Stakeholder aus den Sprint-Reviews.

16.5Empfehlungen

Scrum-Werte

Wichtiger als die Ausgestaltung und Anpassung einzelner Scrum-Artefakte und Events an die spezifischen Bedürfnisse von Data-Science-Projekten ist aus Sicht der Autoren die Beachtung, Verinnerlichung und Integration der fünf Scrum-Werte in den Projektalltag: Commitment, Fokus, Offenheit, Respekt und Mut sind zunächst einmal Werte, von denen vermutlich die allermeisten Projekte profitieren können, ganz unabhängig vom Einsatzgebiet.

Darüber hinaus sind die Autoren davon überzeugt, dass diese Werte eine elementare Voraussetzung sind, um die in diesem Kapitel beschriebenen Vorteile auch realisieren zu können. Zwei dieser Werte sind außerdem gleichzeitig seit jeher auch kritische Erfolgsfaktoren für Data-Science-Projekte: Erfahrungsberichte aus der Industrie zeigen, dass in der Vergangenheit viele Data-Science-Projekte aus einem Mangel an Fokus gescheitert sind. Nur wenn die Data-Science-Lösungen auch ganz konkret ein sehr deutlich formuliertes, messbares, fachliches Ziel bedienen und auf die aus den Daten gewonnenen Erkenntnisse auch Handlungen folgen, die den Unternehmen einen konkreten Mehrwert bieten, wird ein Data-Science-Projekt als erfolgreich angesehen.

Um diese Erkenntnisse zu erreichen, ist Offenheit eine notwendige Grundbedingung. Lösungen für komplexe Data-Science-Fragestellungen zu finden, die im Zuge der Digitalisierung der Unternehmenslandschaften häufig bestehende Prozesse und Abläufe infrage stellen, ist ohne ein sehr hohes Maß an Offenheit kaum vorstellbar.

Um Fokus im Projektalltag zu verankern, bringt Scrum bereits wertvolle Hilfsmittel mit: die Rolle des Product Owners sowie Product und Sprint Backlog. Darüber hinaus empfehlen die Autoren, für alle Data-Science-Anwendungsfälle mit den Stakeholdern sehr klar zu definieren, welche Handlungen auf Basis von Data-Science-Ergebnissen durchgeführt werden, wie diese Handlungen zu Mehrwerten für das Unternehmen führen und wie diese Mehrwerte messbar sind. Diese Fragen sind zwar nicht immer zu Beginn jedes Data-Science-Anwendungsfalls beantwortbar, sollten aber im Projektverlauf zu dem frühestmöglichen Zeitpunkt beantwortet werden. Auf Basis dieser beantworteten Fragen wird es dem Product Owner leichtfallen, dem Scrum-Team stetigen Fokus zu geben.

Den größten Einfluss auf die Offenheit innerhalb des Teams hat die initiale Zusammenstellung des Teams. Bringen die Teammitglieder nicht ein gewisses Maß an Offenheit mit, so wird es schwierig, die nötige Offenheit durch fördernde Maßnahmen herbeizuführen. Offenheit bei mittelbar an Data-Science-Projekten beteiligten Unternehmensbereichen zu fördern, stellt bisweilen eine nicht triviale Herausforderung dar. Insbesondere dann, wenn Data-Science-Ergebnisse dazu führen, dass Prozesse stärker automatisiert und in einigen Unternehmensteilen effizienter durchgeführt werden, so darf mit erheblichen Widerständen gerechnet werden. Falls dies in Data-Science-Anwendungsfällen absehbar wird, empfehlen die Autoren, relevante Stakeholder aus den betroffenen Bereichen mit in das Data-Science-Scrum-Team zu integrieren, frühzeitig das zuständige Senior Level Management zu involvieren sowie in diffizilen Fällen einen Change-Management-Experten zurate zu ziehen.

Projektorganisation und Einbettung in den organisatorischen Kontext

Eine der grundlegendsten Fragen für die Organisation von Data-Science-Teams – zunächst noch ganz unabhängig vom verwendeten Vorgehensmodell – ist die Frage, ob Data Science im Unternehmen eher zentral oder eher dezentral organisiert wird. Während zentrale Data-Science-Teams Vorteile beim Wissensaufbau und -austausch bieten, profitieren dezentrale Data-Science-Teams typischerweise von einer stärkeren Nähe zu Fachabteilungen und den geschäftlichen Abläufen, Fragestellungen und Herausforderungen, was vielmals als wichtiges Erfolgskriterium für Data-Science-Fragestellungen angesehen wird.

Die Autoren konnten die in diesem Kapitel beschriebenen Vorteile mit einem zentral organisierten Data-Science-Team realisieren. Ebenso beziehen sich die beschriebenen Herausforderungen und Empfehlungen auf diese Form der Organisation. Um mit dieser Art der Organisation erfolgreich zu sein, empfehlen die Autoren, dem Data-Science-Scrum-Team einen vollständigen Fokus auf tatsächliche Data-Science-Fragestellungen zu ermöglichen. Hierzu müssen in den Fachabteilungen klare Verantwortlichkeiten zur Begleitung der Data-Science-Projekte definiert werden, sodass die Arbeitsergebnisse des Data-Science-Scrum-Teams in der betrieblichen Praxis auch angewendet und der entstandene Mehrwert gemessen werden kann. Ebenso benötigt das Team zusätzliche Unterstützung bei der Bereitstellung geeigneter Data-Science-Tools sowie bei der Bereitstellung von Daten. Nur so kann das Data-Science-Team ein wirklich hohes Niveau an Produktivität durch Fokus auf die wesentlichen Data-Science-Tätigkeiten erreichen.

Trotz der positiven Erfahrungen und der langen Liste an realisierten Vorteilen können die Autoren keine uneingeschränkte Empfehlung für die zentrale Organisation abgeben. Für eine geeignete Größe von Scrum-Teams gibt es klare Empfehlungen, die Autoren liegen mit einem Entwicklungsteam von neun Personen schon an der oberen Grenze der empfohlenen Größe. Insofern steht die Skalierbarkeit dieses Ansatzes infrage, falls große Unternehmen mehr Data-Science-Anwendungsfälle umsetzen möchten, als ein Data-Science-Scrum-Team mit etwa 10 Personen gleichzeitig bearbeiten kann. Für die Organisation mehrerer Scrum-Teams gibt es sogenannte »scaled frameworks«, allerdings erscheint es sinnvoll, in diesem Fall auch die Vorteile einer dezentralen Organisation mit in die Abwägung einzubeziehen. Ein Wissensaustausch über Teamgrenzen hinweg ist zwar etwas aufwendiger, aber durchaus zu bewerkstelligen.

Unabhängig davon, ob man sich als Unternehmen für eine zentrale oder dezentrale Organisation von Data-Science-Teams entscheidet, ist in großen Unternehmen heute davon auszugehen, dass große Teile der Unternehmen nicht agil organisiert sind. Um die Schnelligkeit als wichtigen Vorteil, den man als Data-Science-Team mithilfe von Scrum realisieren kann, nicht zu gefährden, empfehlen die Autoren, bereits in einer frühen Phase des Projekt-Setups Schnittstellen zu anderen relevanten Unternehmensbereichen aufzubauen und Wege der Zusammenarbeit zu vereinbaren, die einen Kompromiss aus Verlässlichkeit stabiler Unternehmenskernprozesse und Schnelligkeit von Data-Science-Innovationen herbeiführen. In der Scrum-Theorie könnte man dieser Herausforderung auch durch die Integration von Mitarbeitern aus vielen verschiedenen betroffenen Unternehmensbereichen in ein wahrlich cross-funktionales Data-Science-Team begegnen. Diese Option erscheint jedoch nur für dezentral organisierte Data-Science-Teams in Unternehmen umsetzbar, da ansonsten aufgrund der Vielzahl von Anwendungsfällen innerhalb eines zentralen Teams die Anzahl der Teammitglieder Größenordnungen erreicht, bei denen die Anwendung von Scrum nicht vorteilhaft erscheint.

Konkrete Ausgestaltung von Scrum für Data Science

Die grundlegendste Empfehlung in Bezug auf die Ausgestaltung von Scrum für Data Science lautet wenig überraschend: Ausprobieren und an die individuellen Bedürfnisse anpassen. Allgemeingültige Empfehlungen abzugeben, ist an dieser Stelle daher unangemessen, jedoch mögen die Empfehlungen durchaus einer ersten Orientierung dienen.

Einführung von Scrum

Für viele große Unternehmen sind agile Vorgehensmodelle noch vergleichsweise neue Konzepte. Die Einführung von Scrum stellt somit temporär eine zusätzliche Herausforderung für Data-Science-Teams dar. Die Ergebnisse des Scrum-Reports 2017 unterstreichen das: Über 40% der Befragten empfanden die Transition von traditionellen Vorgehensmethoden hin zu Scrum als schwierig [Scrum Alliance 2017], auch wenn sich zugleich 83% der Befragten einig sind, dass Scrum die Qualität ihres Arbeitslebens verbessert.

Sind agile Konzepte im Unternehmen noch wenig verbreitet, so erhöht sich der Umfang der erforderlichen Kommunikationsarbeit deutlich und eine starke Unterstützung aus dem Topmanagement wird unerlässlich.

Um kurzfristige Leistungseinbußen des Data-Science-Teams durch die Einführung von Scrum zu verringern, ist die Beauftragung eines erfahrenen Scrum Masters zu empfehlen, wenn nötig als unternehmensexterne Unterstützung. Dabei ist es auch denkbar, agile Konzepte zunächst schrittweise einzuführen. Allerdings empfehlen die Autoren jedem Team, nicht vorab schon jedes Element von Scrum zu hinterfragen und anzupassen, sondern zumindest einmal einen Zustand zu erreichen, in dem die wenigen Vorgaben, die Scrum macht, in der Gesamtheit umgesetzt sind. Dies bietet eine gute Referenz, um die Güte eigener Anpassungen fundiert bewerten zu können.

Product-Owner-Rolle besetzen

Aufgrund der beschriebenen Herausforderungen liegt es nahe, die Rolle des Product Owners durch eine Person zu besetzen, die über eine möglichst große Erfahrung im Unternehmen verfügt und dabei nach Möglichkeit bereits mit wichtigen fachlichen Domänen vertraut ist. Im Idealfall sollte diese Person außerdem über eine möglichst umfangreiche Data-Science-Erfahrung verfügen, zumindest aber ein Verständnis über die Möglichkeiten und die Grundkonzepte des Data-Science-Universums mitbringen. In letzterem Fall sollten die erfahrensten Data Scientists aus dem Entwicklungsteam dabei helfen, Product-Backlog-Einträge zu erstellen.

Sprint-Länge

Aufgrund der explorativen Natur vieler Data-Science-Fragestellungen und der dadurch im Projektalltag entstehenden Dynamik empfehlen die Autoren für die Sprint-Länge einen Zeitraum von nicht mehr als 14 Tagen. Bei längeren Sprints entsteht ansonsten häufig der Bedarf von Neuverhandlung des Scopes und anderen Anpassungen und man läuft Gefahr, einen wichtigen Vorteil, den Scrum für Data-Science-Projekte bietet, nämlich die Risikominimierung durch umfassendere Transparenz über den Fortschritt des Projekts, nicht realisieren zu können.

Aufwandsschätzungen

Bei Aufwandsschätzungen im Allgemeinen ist es empfehlenswert, sich ständig zu vergewissern, ob der Benefit der Schätzungen größer ist als der Aufwand, den man für die Schätzungen investieren muss. Bei einer Sprint-Länge von 14 Tagen und einem erfahrenen Data-Science-Scrum-Team sind Aufwandsschätzungen zu Planungszwecken verzichtbar. Aufgrund der hohen Komplexität von Data-Science-Aufgabenstellungen und dem damit einhergehenden hohen Maß an Unsicherheit empfehlen die Autoren jedoch, Planning Poker als Schätzverfahren zumindest testweise einzuführen und zu beobachten, ob positive Effekte bei der Erreichung der Sprint-Ziele erkennbar sind. Um den Aufwand des Schätzens in Grenzen zu halten, bieten sich relative Schätzgrößen wie Story Points oder T-Shirt-Größen an.

Sprint-Reviews und Kommunikation

Für ein zentral organisiertes Data-Science-Scrum-Team, das je Sprint parallel mehrere voneinander unabhängige Anwendungsfälle bearbeitet, empfehlen die Autoren die Durchführung von Sprint-Reviews auf Data-Science-Experten-Level. Die dadurch erzielbaren Vorteile überwiegen aus Sicht der Autoren die zusätzlichen Kommunikationsaufwände des Product Owners zur Befriedigung der Bedürfnisse der Stakeholder deutlich. Abhängig von den Wünschen der wichtigsten Stakeholder ist es zudem möglich, zu Beginn der Reviews die Product Increments in einer Kurzvorstellung auf Managementniveau zu präsentieren. In jedem Fall sollte der Product Owner ausreichend Zeit einplanen, um eine dauerhaft enge Abstimmung mit den wichtigsten Stakeholdern sicherzustellen. Die Scrum-Events reichen hierzu üblicherweise bei Weitem nicht aus. Selbiges gilt für Projektmarketingaktivitäten. Auch bei offen gestalteten Sprint-Reviews ist es in großen Unternehmen unabdingbar, Data-Science-Projekterfolge über die im Unternehmen etablierten Kanäle zu kommunizieren.

Selbstorganisation und Arbeitsatmosphäre

Die Selbstorganisation des Entwicklungsteams kann durchaus als ein zentraler Faktor dafür angesehen werden, dass Data-Science-Teams mit Scrum als Vorgehensmodell diverse in diesem Beitrag beschriebene Vorteile realisieren können.

Für das theoretische Konzept der Selbstorganisation in der Praxis können mehrere Problemstellungen bestehen. Insbesondere zwischenmenschliche Beziehungen gepaart mit unterschiedlich stark ausgeprägten Erfahrungshintergründen einzelner Mitglieder und verschiedene unternehmenspolitische Interessen eines cross-funktionalen Data-Science-Teams, das sich im Aufbau befindet, können herausfordernd sein. Wenn jedoch nicht nur der Scrum-Wert Respekt einen zentralen Grundpfeiler der Zusammenarbeit darstellt, sondern darüber hinaus auch im gesamten Team ein hohes Maß an gegenseitigem Vertrauen herrscht, so ist die Selbstorganisation des Teams dennoch nicht gefährdet.

Zu den wichtigsten Aufgaben von Scrum Master und Product Owner gehört es daher, eine positive, auf gegenseitiger Wertschätzung und Anerkennung basierende Arbeitsumgebung zu kreieren, in der sich das Team optimal entfalten kann. Da Vertrauensaufbau jedoch ein längerer Prozess sein kann, empfehlen die Autoren, das Konzept der Selbstorganisation des Teams nicht erst in der operativen Arbeit anzuwenden, sondern bereits während des Entstehungsprozesses und der Weiterentwicklung des Teams. Das Team selbst kann oftmals am besten abschätzen, welche Personen eine geeignete Ergänzung für das Team darstellen. Kann das Team also selbstständig nicht nur über seine Arbeitsweise, sondern auch schon über die initiale Teamzusammenstellung und folgende Teamerweiterungen bestimmen, ist damit eine entscheidende Voraussetzung für eine positive Arbeitsatmosphäre und den daraus resultierenden Produktivitätsgewinn gelegt.

Im operativen Betrieb nach Scrum kann es außerdem hilfreich sein, wenn der Scrum Master dem Team zusätzliche Impulse für Möglichkeiten der Zusammenarbeit gibt, um das voneinander Lernen stärker zu fördern. Davon können gerade Data-Science-Scrum-Teams im Aufbau profitieren.

Retrospektiven und Selbstoptimierung

Retrospektiven sind die institutionalisierte Gelegenheit, die Art und Weise, wie das Team arbeitet, stetig zu verbessern. Dazu gehört auch die Ausgestaltung der diversen Scrum-Events und Artefakte. Auch hier ist es empfehlenswert, dem Team die Hoheit darüber zu belassen, in welcher Form die Scrum-Rahmenbedingungen dem Team am dienlichsten sind. Obwohl Scrum ein vergleichsweise leichtgewichtiges Framework mit wenigen Regeln ist, kann das auch dazu führen, dass das Team Anpassungen diskutiert, die nicht mit dem Scrum-Framework in Einklang zu bringen sind. Auch dies ist aus Sicht der Autoren durchaus wünschenswert, es entspricht den Grundgedanken des Agilen Manifests. Im Hinblick auf den Einsatz von Scrum in Data Science erscheint jedoch eine Ausnahme als beachtenswert: Die Durchführung von Retrospektiven allzu stark einzuschränken oder gar ganz abzuschaffen birgt die Gefahr, auf zentrale Vorteile von Scrum zu verzichten. Herrscht Unzufriedenheit im Team mit der Durchführung der Retrospektiven, sollte stattdessen an der Ausgestaltung dieses Events gearbeitet werden. Um gute Fortschritte realisieren zu können, ist auch hier ein gewisses Vertrauensniveau essenziell sowie geeignete Moderationsmaßnahmen des Scrum Masters, die sicherstellen, dass sich wirklich alle Teammitglieder gerne beteiligen und ihren Teil zur Selbstoptimierung des Teams beitragen.

16.6Fazit

Das Scrum-Framework wurde entwickelt, um komplexe und adaptive Aufgabenstellungen zu bearbeiten. Um Risiken zu verwalten, verfolgt es dabei einen iterativen, inkrementellen Ansatz. Dadurch bietet Scrum hervorragende Voraussetzungen für Data-Science-Projekte, die durch ihre Komplexität ein hohes Maß an Unsicherheit mit sich bringen und deren natürlicher Verlauf ebenfalls sehr iterativ geprägt ist. Die Herausforderungen, die durch die Anwendung von Scrum für Data-Science-Projekte entstehen, sind beherrschbar und treten angesichts der umfangreichen, möglichen Vorteile in den Hintergrund.

Während sich Agilität in vielen Unternehmenskulturen stärker verbreitet, hat Scrum das Potenzial, zu einem neuen Best-Practice-Vorgehen für Data-Science-Teams zu werden. Ein guter Startpunkt für eine Transition in die agile Welt ist es allemal.