Vier Fallstricke der agilen Arbeit in Data Science-Teams (und wie ihr sie vermeiden könnt)
- Von Natalia Grinberg
- Agil, Data Science, Projektmanagement
Share post:
Hintergrund
Das Agile Manifest wurde 2001 von 17 Softwareentwicklern verfasst, die die typischen Softwareentwicklungsprojekte ihrer Zeit neu denken wollten: Statt detaillierter Planungen für Aufgaben, die Jahre in der Zukunft liegen, unrealistischer Zeitvorgaben und einer Fülle unnötiger Dokumentationen plädierten sie dafür, Software zu liefern, die funktioniert und die Bedürfnisse 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 Softwareentwicklung, sondern auch in fachverwandten Bereichen wie z. B. Data Science.
Wer agile Methoden sowohl in der Softwareentwicklung als auch in der Data Science praktiziert hat, wird festgestellt haben, dass sich die Auswirkungen auf Datenprodukte sowie Data Science Projekte von denen auf Software-Teams erheblich unterscheiden können. Es gibt eine Reihe häufiger Fallstricke, die dazu führen können, dass es schwierig wird, den Stakeholdern und Kunden den gewünschten Wert zu liefern, und die in der Zwischenzeit zu viel Frustration bei allen Beteiligten führen können. In diesem Blog-Beitrag werden wir vier häufige Muster untersuchen und einige Möglichkeiten aufzeigen, wie ihr vermeiden könnt, dass eure Data-Science-Ziele im Sande verlaufen.
Große Arbeitspakete lassen sich nur schwer herunterbrechen und schätzen
Aufgrund ihrer explorativen Natur sind insbesondere die frühen Phasen in Data Science Projekten schwierig abzuschätzen!
Vor allem die frühen Phasen eines jeden Data-Science-Projekts sind explorativer Natur. Ganz gleich, ob es sich um die eigentliche Datenexplorationsphase oder um die Beseitigung von Ausreißern und anderen Problemen in den Datensä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 aufzuteilen, da man einfach nicht vorhersehen kann, womit man es am Ende zu tun haben wird. Bei der Softwareentwicklung ist dieses Problem in der Regel nicht so groß, und die agilen Frameworks bieten keine einfachen Lösungen für dieses Problem. Eine Möglichkeit, mit diesen Problemen umzugehen, besteht darin, allzu strikte Vorschriften darüber, wie Tickets zu schreiben und zu schätzen sind, loszulassen, unabhängig davon, wie nützlich und gut gemeint sie in Softwareentwicklungsteams sein können.
DO:
Versucht euer Bestes, die Stories und Aufgaben so granular wie möglich zu gestalten und lasst irgendwann „gut genug“ gut genug sein. Definiere glasklare Akzeptanzkriterien für jedes Inkrement und vertraue denjenigen, die an der Aufgabe arbeiten, dass sie einen Weg finden, um das gewünschte Ziel zu erreichen. Wenn es hilfreich erscheint, die Data Scientists im Laufe der Bearbeitung Subtasks erstellen zu lassen, um die Transparenz und Struktur im Team zu erhöhen, solltet ihr das auf jeden Fall ausprobieren.
DON'T:
Lasst ein Arbeitspaket 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 effektive und regelmäßige Kommunikation innerhalb des Teams, ob sinnvolle Fortschritte gemacht werden. Die Festlegung von Timeboxes für bestimmte Aufgaben (z. B. „Wir sollten diese Idee höchstens zwei Tage lang ausprobieren, um zu sehen, ob sie überhaupt funktioniert“) ist ebenfalls ein bewährter Weg, um mit der kostbaren Entwicklungszeit sparsam umzugehen, ohne das Experimentieren zu vernachlässigen.
Abhängigkeiten zu anderen Teams bremsen den Fortschritt
Data-Science-Teams sind besonders anfällig dafür, von anderen Teams abhängig zu sein, wenn es darum geht, notwendige Inputs oder Feedback zu erhalten. Die Daten werden vielleicht von einem speziellen DWH-Team verwaltet, die Cloud-Infrastruktur liegt in den Händen der internen IT-Abteilung und die Stakeholder sind über die ganze Firma verstreut. Vielleicht arbeitet ihr mit einem Kunden zusammen, der etwas länger braucht, um euch Informationen zu übermitteln. Die Hindernisse, die sich aus diesen Umständen ergeben, sind eine häufige Beschwerde in agilen Retrospektiven. Was könnte man tun, abgesehen davon, dass man die gesamte Organisation umgestaltet, um den Bedürfnissen der Data-Science-Abteilung gerecht zu werden, um diesen Umstand zu beheben?
Data-Science-Teams sind besonders anfällig dafür, von anderen Teams abhängig zu sein
DO:
Klärt innerhalb des Teams, was ihr regelmäßig von anderen Personen oder Abteilungen benötigt, und schlagt vor, wie das Gegenüber diese Dinge mit geringem Aufwand bereitstellen kann. Eine effektive Kommunikation mit den richtigen Leuten kann über den Erfolg eines Data-Science-Projekts oder Datenprodukts entscheiden. Dies gilt gleichermaßen für Kundenprojekte und alle möglichen Initiativen innerhalb eines Unternehmens.
DON'T:
Lasst euch in Dailies und Retrospektiven nicht zu Fingerpointing verleiten, ohne die Verantwortung für den Erfolg des Projekts zu übernehmen und Wege zu erarbeiten, wie eure Ziele trotz organisatorischer Defizite verwirklicht werden können. Hier können engagierte Agile Coaches einen großen Unterschied für den Einfluss des Teams auf das Unternehmen oder den Kunden machen.
Kommunikation und Geschäftsziele sind nicht mit dem Data-Science-Team im Einklang
Data-Science-Teams sprechen (ähnlich wie Softwareentwicklungsteams) manchmal eine ganz andere Sprache als ihre Stakeholder 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. Nichtsdestotrotz kann und sollte jeder in einem agilen Team dazu beitragen, die Unternehmensziele zu erreichen und eine effiziente Kommunikation mit Stakeholdern und Kunden zu gewährleisten.
Jedes Mitglied des Data science Teams sollte seinen/ihren Beitrag zu den Unternehmenszielen kennen
DO:
Macht euch klar, was eure Stakeholder oder Kunden eigentlich erreichen wollen und wie das Data-Science-Team zu diesen Zielen beiträgt. Stellt sicher, dass die Stakeholder bei den Reviews und anderen Meetings nachvollziehen können, welche Fortschritte gemacht werden und welcher Nutzen für das Unternehmen oder den Kunden entsteht. Wenn eure Stakeholder von einem Crash-Kurs über Data-Science-Terminologie und -Konzepte profitieren würden, zögert nicht, ihnen eine solche Schulung anzubieten, denn sie wird die Kommunikation in Zukunft sicherlich verbessern. Letztendlich profitiert das Data-Science-Team am meisten von der Beteiligung und den Vorschlägen seiner Stakeholder.
DON'T:
Vermeidet es in Reviews in Anwesenheit eines fachfremden Publikum hochtechnische Diskussionen zu führen, auch wenn diese vielleicht aus Data-Science-Gesichtspunkten sehr spannend wären. Die Reviews sind eine wertvolle Gelegenheit, um das Feedback der Stakeholdern einzuholen und die Ergebnisse für das Unternehmen zu verbessern. Technische Diskussionen sollten in einem anderen Rahmen stattfinden, wenn die Beteiligten nicht alle in der Lage sind, einen sinnvollen Beitrag zu leisten.
Die Akzeptanz der agilen Denkweise erweist sich als Herausforderung
Die Data Science als Disziplin boomt seit etwas mehr als einem Jahrzehnt, und spezialisierte Studiengänge sind im Laufe der Jahre immer häufiger geworden. Dennoch rekrutiert sich die Mehrheit der Data Scientists nach wie vor aus MINT-Fächern, Wirtschaftswissenschaften und anderen quantitativen Fächern, die an Hochschulen gelehrt werden. Ein solcher akademischer Hintergrund bringt eine Reihe von Werten und Einstellungen mit sich, die beispielsweise Gründlichkeit und individuelle Leistung gegenüber Experimentierfreudigkeit und Teamarbeit stellen. Sich mit den Werten und Erwartungen des agilen Arbeitens vertraut zu machen, kann für viele Menschen anspruchsvoll und unintuitiv sein. Es braucht sicherlich Zeit und eine gehörige Portion Mut.
Es braucht Mut, sich auf die agile Arbeitsweise einzulassen
DO:
Seid euch über die Erwartungen des Teams in Bezug auf agile Werte und eure kulturelle Normen im Klaren. Gebt konstruktives Feedback und diskutiert offen darüber, was funktioniert und was nicht.
DON'T:
Fallt nicht auf Stereotypen über bestimmte Berufe oder akademische Hintergrü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 Anreizstrukturen, in denen sich Menschen bewegen, prägen die Art und Weise, wie sie mit ihrer Umgebung interagieren. Daher ist es eine wichtige Aufgabe für Führungspersonen, diese Kultur und die Anreize so zu gestalten, dass die gewünschten Ergebnisse erzielt werden.
Fazit
Auch wenn die agilen Methoden nicht unbedingt maßgeschneidert für die Data Science ersonnen wurden, können sie mit ein paar Anpassungen als zielführende Arbeitsweise dienen. Kommunikation und ein Growth-Mindset sind für den Erfolg eines Datenprodukts oder -projekts genauso wichtig wie der Code und die Mathematik.
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 Scientists regelmäßig vor Herausforderungen stellen. Da künstliche Intelligenz heutzutage immer mehr an Bedeutung gewinnt, werden zwangsläufig neue Phänomene im agilen Alltag auftauchen, die es womöglich in einem zweiten Teil zu beleuchten gilt.
Natalia Grinberg
Lead Data Scientist