Agiles Projektmanagement in Data Science Projekten

Vier Fallstricke der agilen Arbeit in Data Science-Teams (und wie ihr sie vermeiden könnt)

Share post:

Hinter­grund

Das Agile Manifest wurde 2001 von 17 Software­ent­wick­lern verfasst, die die typischen Software­ent­wick­lungs­pro­jekte ihrer Zeit neu denken wollten: Statt detail­lierter Planungen für Aufgaben, die Jahre in der Zukunft liegen, unrea­lis­ti­scher Zeitvor­gaben und einer Fülle unnötiger Dokumen­ta­tionen plädierten sie dafür, Software zu liefern, die funktio­niert und die Bedürf­nisse des Kunden zeitnah erfüllt.

Mehr als zwei Jahrzehnte später sind agile Methoden wie Scrum zum De-facto-Standard geworden, nicht nur in der Software­ent­wick­lung, sondern auch in fachver­wandten Berei­chen wie z. B. Data Science.

Wer agile Methoden sowohl in der Software­ent­wick­lung als auch in der Data Science prakti­ziert hat, wird festge­stellt haben, dass sich die Auswir­kungen auf Daten­pro­dukte sowie Data Science Projekte von denen auf Software-Teams erheb­lich unter­scheiden können. Es gibt eine Reihe häufiger Fallstricke, die dazu führen können, dass es schwierig wird, den Stake­hol­dern und Kunden den gewünschten Wert zu liefern, und die in der Zwischen­zeit zu viel Frustra­tion bei allen Betei­ligten führen können. In diesem Blog-Beitrag werden wir vier häufige Muster unter­su­chen und einige Möglich­keiten aufzeigen, wie ihr vermeiden könnt, dass eure Data-Science-Ziele im Sande verlaufen.

Große Arbeits­pa­kete lassen sich nur schwer herun­ter­bre­chen und schätzen

Aufgrund ihrer explo­ra­tiven Natur sind insbe­son­dere die frühen Phasen in Data Science Projekten schwierig abzuschätzen!

Vor allem die frühen Phasen eines jeden Data-Science-Projekts sind explo­ra­tiver Natur. Ganz gleich, ob es sich um die eigent­liche Daten­ex­plo­ra­ti­ons­phase oder um die Besei­ti­gung von Ausrei­ßern und anderen Problemen in den Daten­sätzen handelt: in den meisten Fällen kann man einfach nicht sagen, wie lange es dauern wird. Ebenso schwierig kann es sein, eine große Aufgabe in kleinere Schritte aufzu­teilen, da man einfach nicht vorher­sehen kann, womit man es am Ende zu tun haben wird. Bei der Software­ent­wick­lung ist dieses Problem in der Regel nicht so groß, und die agilen Frame­works bieten keine einfa­chen Lösungen für dieses Problem. Eine Möglich­keit, mit diesen Problemen umzugehen, besteht darin, allzu strikte Vorschriften darüber, wie Tickets zu schreiben und zu schätzen sind, loszu­lassen, unabhängig davon, wie nützlich und gut gemeint sie in Software­ent­wick­lungs­teams sein können.

DO:

Versucht euer Bestes, die Stories und Aufgaben so granular wie möglich zu gestalten und lasst irgend­wann „gut genug“ gut genug sein. Definiere glasklare Akzep­tanz­kri­te­rien für jedes Inkre­ment und vertraue denje­nigen, die an der Aufgabe arbeiten, dass sie einen Weg finden, um das gewünschte Ziel zu errei­chen. Wenn es hilfreich erscheint, die Data Scien­tists im Laufe der Bearbei­tung Subtasks erstellen zu lassen, um die Trans­pa­renz und Struktur im Team zu erhöhen, solltet ihr das auf jeden Fall auspro­bieren.

DON'T:

Lasst ein Arbeits­paket nicht zu einer never-ending-story werden, ohne dass ein klares Ergebnis in Sicht ist. Nur weil der Weg zu einem Ziel vorab nicht ganz klar ist, bedeutet das nicht, dass Zeit und Ressourcen nicht gesteuert werden können. Wenn das Ziel klar definiert ist, zeigt eine effek­tive und regel­mä­ßige Kommu­ni­ka­tion inner­halb des Teams, ob sinnvolle Fortschritte gemacht werden. Die Festle­gung von Timeboxes für bestimmte Aufgaben (z. B. „Wir sollten diese Idee höchs­tens zwei Tage lang auspro­bieren, um zu sehen, ob sie überhaupt funktio­niert“) ist ebenfalls ein bewährter Weg, um mit der kostbaren Entwick­lungs­zeit sparsam umzugehen, ohne das Experi­men­tieren zu vernach­läs­sigen.

Abhän­gig­keiten zu anderen Teams bremsen den Fortschritt

Data-Science-Teams sind beson­ders anfällig dafür, von anderen Teams abhängig zu sein, wenn es darum geht, notwen­dige Inputs oder Feedback zu erhalten. Die Daten werden vielleicht von einem spezi­ellen DWH-Team verwaltet, die Cloud-Infra­struktur liegt in den Händen der internen IT-Abtei­lung und die Stake­holder sind über die ganze Firma verstreut. Vielleicht arbeitet ihr mit einem Kunden zusammen, der etwas länger braucht, um euch Infor­ma­tionen zu übermit­teln. Die Hinder­nisse, die sich aus diesen Umständen ergeben, sind eine häufige Beschwerde in agilen Retro­spek­tiven. Was könnte man tun, abgesehen davon, dass man die gesamte Organi­sa­tion umgestaltet, um den Bedürf­nissen der Data-Science-Abtei­lung gerecht zu werden, um diesen Umstand zu beheben?

Team Abhängigkeiten
Data-Science-Teams sind beson­ders anfällig dafür, von anderen Teams abhängig zu sein

DO:

Klärt inner­halb des Teams, was ihr regel­mäßig von anderen Personen oder Abtei­lungen benötigt, und schlagt vor, wie das Gegen­über diese Dinge mit geringem Aufwand bereit­stellen kann. Eine effek­tive Kommu­ni­ka­tion mit den richtigen Leuten kann über den Erfolg eines Data-Science-Projekts oder Daten­pro­dukts entscheiden. Dies gilt gleicher­maßen für Kunden­pro­jekte und alle mögli­chen Initia­tiven inner­halb eines Unter­neh­mens.

DON'T:

Lasst euch in Dailies und Retro­spek­tiven nicht zu Finger­poin­ting verleiten, ohne die Verant­wor­tung für den Erfolg des Projekts zu übernehmen und Wege zu erarbeiten, wie eure Ziele trotz organi­sa­to­ri­scher Defizite verwirk­licht werden können. Hier können engagierte Agile Coaches einen großen Unter­schied für den Einfluss des Teams auf das Unter­nehmen oder den Kunden machen.

Kommu­ni­ka­tion und Geschäfts­ziele sind nicht mit dem Data-Science-Team im Einklang

Sprache

Data-Science-Teams sprechen (ähnlich wie Software­ent­wick­lungs­teams) manchmal eine ganz andere Sprache als ihre Stake­holder oder Kunden. Es ist nicht unüblich, den Beitrag eines Product Owners daran zu messen, wie effektiv er oder sie diese Kluft überbrü­cken kann. Nichts­des­to­trotz kann und sollte jeder in einem agilen Team dazu beitragen, die Unter­neh­mens­ziele zu errei­chen und eine effizi­ente Kommu­ni­ka­tion mit Stake­hol­dern und Kunden zu gewähr­leisten.

Jedes Mitglied des Data science Teams sollte seinen/ihren Beitrag zu den Unter­neh­mens­zielen kennen

DO:

Macht euch klar, was eure Stake­holder oder Kunden eigent­lich errei­chen wollen und wie das Data-Science-Team zu diesen Zielen beiträgt. Stellt sicher, dass die Stake­holder bei den Reviews und anderen Meetings nachvoll­ziehen können, welche Fortschritte gemacht werden und welcher Nutzen für das Unter­nehmen oder den Kunden entsteht. Wenn eure Stake­holder von einem Crash-Kurs über Data-Science-Termi­no­logie und -Konzepte profi­tieren würden, zögert nicht, ihnen eine solche Schulung anzubieten, denn sie wird die Kommu­ni­ka­tion in Zukunft sicher­lich verbes­sern. Letzt­end­lich profi­tiert das Data-Science-Team am meisten von der Betei­li­gung und den Vorschlägen seiner Stake­holder.

DON'T:

Vermeidet es in Reviews in Anwesen­heit eines fachfremden Publikum hochtech­ni­sche Diskus­sionen zu führen, auch wenn diese vielleicht aus Data-Science-Gesichts­punkten sehr spannend wären. Die Reviews sind eine wertvolle Gelegen­heit, um das Feedback der Stake­hol­dern einzu­holen und die Ergeb­nisse für das Unter­nehmen zu verbes­sern. Techni­sche Diskus­sionen sollten in einem anderen Rahmen statt­finden, wenn die Betei­ligten nicht alle in der Lage sind, einen sinnvollen Beitrag zu leisten.

Die Akzep­tanz der agilen Denkweise erweist sich als Heraus­for­de­rung

Die Data Science als Diszi­plin boomt seit etwas mehr als einem Jahrzehnt, und spezia­li­sierte Studi­en­gänge sind im Laufe der Jahre immer häufiger geworden. Dennoch rekru­tiert sich die Mehrheit der Data Scien­tists nach wie vor aus MINT-Fächern, Wirtschafts­wis­sen­schaften und anderen quanti­ta­tiven Fächern, die an Hochschulen gelehrt werden. Ein solcher akade­mi­scher Hinter­grund bringt eine Reihe von Werten und Einstel­lungen mit sich, die beispiels­weise Gründ­lich­keit und indivi­du­elle Leistung gegen­über Experi­men­tier­freu­dig­keit und Teamar­beit stellen. Sich mit den Werten und Erwar­tungen des agilen Arbei­tens vertraut zu machen, kann für viele Menschen anspruchs­voll und unintuitiv sein. Es braucht sicher­lich Zeit und eine gehörige Portion Mut.

Es braucht Mut, sich auf die agile Arbeits­weise einzu­lassen
Mut

DO:

Seid euch über die Erwar­tungen des Teams in Bezug auf agile Werte und eure kultu­relle Normen im Klaren. Gebt konstruk­tives Feedback und disku­tiert offen darüber, was funktio­niert und was nicht.

DON'T:

Fallt nicht auf Stereo­typen über bestimmte Berufe oder akade­mi­sche Hinter­gründe herein. Menschen lernen und passen sich ihrer Umgebung schneller an, als wir es manchmal für möglich halten. Die Kultur der Gruppe und die Anreiz­struk­turen, in denen sich Menschen bewegen, prägen die Art und Weise, wie sie mit ihrer Umgebung inter­agieren. Daher ist es eine wichtige Aufgabe für Führungs­per­sonen, diese Kultur und die Anreize so zu gestalten, dass die gewünschten Ergeb­nisse erzielt werden.

Fazit

Auch wenn die agilen Methoden nicht unbedingt maßge­schnei­dert für die Data Science ersonnen wurden, können sie mit ein paar Anpas­sungen als zielfüh­rende Arbeits­weise dienen. Kommu­ni­ka­tion und ein Growth-Mindset sind für den Erfolg eines Daten­pro­dukts oder -projekts genauso wichtig wie der Code und die Mathe­matik.

Diese Liste ist bei weitem nicht vollständig, sondern wagt den Versuch, einige häufige Muster zu beleuchten, die viele Product Owner, Agile Coaches und Data Scien­tists regel­mäßig vor Heraus­for­de­rungen stellen. Da künst­liche Intel­li­genz heutzu­tage immer mehr an Bedeu­tung gewinnt, werden zwangs­läufig neue Phäno­mene im agilen Alltag auftau­chen, die es womög­lich in einem zweiten Teil zu beleuchten gilt.

Picture of Natalia Grinberg

Natalia Grinberg

Lead Data Scien­tist

Projektanfrage

Vielen Dank für Ihr Interesse an den Leistungen von m²hycon. Wir freuen uns sehr, von Ihrem Projekt zu erfahren und legen großen Wert darauf, Sie ausführlich zu beraten.

Von Ihnen im Formular eingegebene Daten speichern und verwenden wir ausschließlich zur Bearbeitung Ihrer Anfrage. Ihre Daten werden verschlüsselt übermittelt. Wir verarbeiten Ihre personenbezogenen Daten im Einklang mit unserer Datenschutzerklärung.