Scrum & Agilität im Bereich Data-Science

00:00:00: So die nächste Folge des Ailionauten Podcast und ich muss ehrlich zugeben ich habe gar nicht nachgezählt bei welcher Folge jetzt genau sind wir haben ein zwei Folgen und veröffentlicht im Kasten das macht die Vorhersage ziemlich schwierig aber nichtsdestotrotz wir sind noch auf unserer Finca in Mallorca auf der Firmen Rundfahrt und ich habe

00:00:18: wieder den Alex vor mir ich stelle ihn gleich vor oder er sich selbst kurz als Einleitung zum Thema es geht heute insbesondere um Scrum in Data-Science

00:00:27: Projekt na Alex erzähl gern was zu Dir hey alles ja ich bin Geschäftsführer der Elio war das ganze jetzt seit 8 Jahren

00:00:37: habe innerhalb der letzten acht Jahren Timos zwölf Leuten aufgebaut dass ich mit Data-Science und künstlicher Intelligenz beschäftigt und wir setzen Projekte gemeinsam um.

00:00:46: Für Kunden jeglicher Größenordnung und da bin ich vor allem als Berater konzeptionist und scrum-master mit in den Entwicklungen dabei und Steuer die

00:00:56: du bist scrum-master an bevor wir auf deine Rolle insbesondere eingehen erklär vielleicht gerne gerne gerne mal was ist Guam eigentlich ganz allgemein.

00:01:05: Ich glaube da musst du zwei Begriffe bisschen unterscheiden oft wird Agilität und trial und Scrum.

00:01:11: Die gleiche Tonne geworfen und gemeinsam genannt Scrum ist im Prinzip in den Prozessen in Framework der relativ klar.

00:01:18: War das relativ klar vorschreibt wie in den Team gemeinsam arbeiten sollen ne da gibt es verschiedene Artefakte wie z.b. einen Back Lock wo alle.

00:01:28: Dinge drinne stehen die ST Morgen Mama erledigen möchte ein Sprint Backlog wo die Dinge drinne stehen die esteem in nächster Zeit erledigen möchte in der nächsten Iteration

00:01:38: und ein paar Meetings die vorgegeben sind wie z.b. in daily

00:01:43: den das Team sich täglich austauschen refinement in den Dustin die nächsten Themen besprechen and planning in dem das Team den Plan für die nächste Iteration festlegt und eine Retro in den Dustin bisschen zurück

00:01:55: blickst was musst du denn besser machen können in der Vergangenheit und wie es in der Zukunft sich optimieren kann.

00:02:01: Aber erstmal eine Reihe voller Prozess Meetings wie sich das gerade anhört genau und das kann man bisschen unterscheiden von entscheide was eigentlich ehernen mindset ist und man sagt ok man möchte Namen Kunden entwickeln man möchte

00:02:14: keine Verschwendung haben sondern im Zweifelsfall wenn man eine Fehlentwicklung hat das schnell.

00:02:19: Wegwerfen und was neues machen und Scrum ist halt ein Framework das Central begünstigt mit dem man agil arbeiten kann aber das eine ist nicht gleich das andere.

00:02:30: Ganz.

00:02:30: Am Rand noch ein anderer Begriff Kempen das ist jetzt nicht 100% unser Thema aber das ist ja auch eine agida Arbeit Methode kannst du da vielleicht noch ein paar Sätze zu.

00:02:40: Event klar Kevin ist im Prinzip eine Vereinfachung und Scrum würde ich sagen beim Scrum setzt man sich ja im planning alle

00:02:49: paar Wochen je nachdem wie lange die Iteration immer geht zusammen und macht den kompletten Plan für das nächste für die nächste Iteration und bei Kevin arbeitet man er priorisiert die Themen ab die auftauchen heißt kämmen ist z.b. vor allem für Teams geeignet sie

00:03:05: na adv upsetting arbeiten wo regelmäßig Inzidenz reinkommen und wo man Purpur auf die Tages Situation reagieren muss und Scrum ist vor allem für Team Sky

00:03:15: wo man bisschen vorausplanen kann jetzt auch wieder ein bisschen weg vom Thema mal eingeworfen nehmen wir mal an wie entwickeln etwas von from scratch.

00:03:24: Und habe noch nicht wirklich so den Plan wie das ganze Produkt am Ende aussehen wird würdest du das eher Sony Scrum Kategorie oder er soll die canvan Kategorie einordnen.

00:03:35: Ich glaube das kommt stark auf die Person an die zusammenarbeiten und auf die Situation ich glaub es lässt sich nicht verallgemeinern aber ich glaube Scrum

00:03:43: ist in dem Team von drei bis neun Leuten in der Regeln in sehr sehr gutes Framework um Produkte zu entwickeln.

00:03:49: Wie weit muss man bei Scrum vorausplanen für mich klingt das so als sei es drum sehr sehr durchgetaktet und durchgeplant ich meine allein das Backlog muss es ja erstmal geben ne.

00:03:59: Also so ein klassisches Projekt von der grünen Wiese fängt ja erstmal relativ schlank an das heißt.

00:04:06: Da gibt es verschiedene angehensweise manchmal Staatsmann im spring sie Ronin Designs print wo man erstmal so die Grundlage schafft das Back Lock bisschen füllt Gäste Konzepte erstellt.

00:04:15: Andere Teams Kinder anders ran oder der Spring Zero ist schon irgendwie vorher passiert oder es gibt schon im Konzept für das ganze Produkt und der Product Owner hat schon erste TM angelegt hat er procto ne Essen im Scrum-Team quasi die Person die die product Vision entwickelt und die Story schreibt sie das Team entwickeln soll

00:04:33: und.

00:04:35: LMMS klassischen Scrum-Prozess hat man Sprint der 1 bis 4 Wochen dauert die meisten Teams arbeite in ein Wochen oder zwei Wochen Sprints das ist wohl der Klassiker

00:04:45: ich habe auch schon mit Teams gearbeitet und Teams gesehen die in drei oder vier Wochen Sprint zu arbeiten aber das sind dann eher Ausnahme sie nachher meiner Erfahrung nach.

00:04:54: Bevor wir jetzt.

00:04:55: Endlich vielleicht in Deinen Alltag gehen und auf das eigentliche Thema und du hast ein paar Begriffe einfach so beiläufig raus gejobbt sage ich mal

00:05:05: der erste wäre Spring Zero wenn ich das richtig verstehe ist das quasi der spinnt vor dem eigentlichen Arbeitsprozess habe ich das richtig verstanden ja das ist so ein bisschen so eine Philosophie Frage

00:05:15: in der ganz offiziellen Lehre existierte so etwas nicht

00:05:19: und ist blasphemie so in der inoffizielle Handbuch gibt's sowas nicht und wenn man sich jetzt irgendwie ein Zertifikat machen möchte und dafür auswendig lernst dann

00:05:28: später vielleicht auch eine Frage kommen gibst du etwas und die Richter Antwort ist nein aber es gibt halt einige Teams und bräuchte die das so praktizieren dass man irgendwie mal starten muss mit einer Design und Konzeptphase und dann nennen die das manchmal spinnt Zero wie man sitzen and sei auch dahingestellt man braucht es auch gar nicht Pensionen man kann auch einfach mit dem ersten Sprint starten und

00:05:48: in der Regel ist am Anfang auch noch nicht alles durchgeplant und ein weiterer Begriff den du beiläufig fallen gelassen hast sind.

00:05:56: Ich sage jetzt mal verallgemeinert die Rollen kannst du vielleicht noch ein bisschen was zu den einzelnen Rollen in einem Scrum Teams erzählen klar eigentlich gibt es drei Rollen die relevant sind zwei sind ja schon bisschen erwähnt wurden erst ist der Scrum Master

00:06:08: der Held im Prinzip die Regeln 1 schützt das Team vor äußeren Einflüssen wie bösen Chef der die ganze Zeit an welche Deadline setzen möchte und den Leuten auf den Sack geht

00:06:21: und moderiert die Meetings und versuchten Ansprechpartner für das Team zu sein vertrauenswürdiger ein bisschen Product Owner habe ich ja schon bisschen gezählt der

00:06:31: hat die Frisur product Vision der stimmt

00:06:33: die Anforderungen an das Produkt mit Kunden mit internen Stakeholdern also quasi Leuten die Interesse an dem Produkt haben anderen Abteilung und so weiter ab und priorisiert quasi was die sinnvollsten Dinge zu tun sind in naher Zukunft bei Erding Gesamtüberblick hat

00:06:49: um und dann gibt es das development team.

00:06:52: In dem die Developer sind und da gibt's quasi keine Rollen Unterteilung da gibt es nicht den Senior Architekten und Ingenieur der von sonst was sein Gebiss einfach nur in developer.

00:07:01: Was.com sind alle gleichgestellt und arbeiten auf Augenhöhe mit der kompletten Verantwortung an dem Produkt.

00:07:09: Und sind halt des development teams.

00:07:12: Sehr sehr gut der letzte Begriff den ich noch eben Abfragen würde der wird sich vielleicht auch von selbst erklären im Kontext aber ins print was ist denn los infantes im Prinzip ja Iteration hat sich auch schon wieder so Fachchinesisch an.

00:07:26: In Scrum denkt man sehr interaktiv weil man immer wieder innen.

00:07:30: Gleichen Länge in dem gleichen Zyklus ein Plan erstellt z.b. alle zwei Wochen werden die nächsten zwei Wochen geplant und die Idee dahinter ist dass ich in einem

00:07:39: jeder Iteration hinterfrage was habe ich in der Vergangenheit gemacht weil das gut oder schlecht wie kann ich mich verbessern und dann in der nächsten Planung das Miteinbeziehung und mich mit jeder älter Ration verbesser

00:07:52: und inspect and adapt wären so die fachini sich schon begrifflich inspizieren immer was habe ich in der Vergangenheit gemacht und passe mich an um besser zu werden.

00:08:00: Also eins print ist quasi eine Iteration mit allen Prozessen die du vorher beschrieben hast also mit allen Artefakt genau also immer schön Sprint kann festgelegt 2 Wochen dauern oder hat.

00:08:11: Das Team.

00:08:12: Immer ein Sprinter 2 Wochen dauert und in dem Sprint macht es dann auch 1 Retro 1 review and planning refinement und die Dailys was ich eben erzählt hatte was you die Scrum meetings sind

00:08:23: cool dann gehen wir jetzt mal in deine Richtung und die wird

00:08:27: bestimmt noch ein bisschen mehr in Richtung Data-Science gehen zumindest aus der scrum-master Perspektive denn neben deiner Tätigkeit Eisgeschäft

00:08:34: Führer hast du dir noch angetan in einzelnen Projekten scrum-master zu sein erzähl doch gerne mal wie sieht's denn da aus wie kann man sich dein Alltag vorstellen in der Rolle.

00:08:44: Delta.com Master ist glaube ich auch sehr sehr individuell auf das Team zugeschnitten mit dem man arbeitet.

00:08:53: Und Heimtücke ScrumMaster versteht mir alle servant leadership also dass man jetzt nicht als der klassische breakmono.jar Leuten sagt das hast du zu tun und mache das so wie ich dir sage sondern man ist er jemand der

00:09:04: deutsche dabei unterstützt dass sie ihr Bestes geben können heißt wenn irgendwelche Probleme auf dem Weg auftauchen dann versuche ich diese zu lösen und den Leuten zu helfen dass es sie möglichst wenig von der Arbeit abhält

00:09:15: wenn das Team in irgendwelcher Weise personelle persönliche Differenzen Hardwareprobleme versuche ich die zu lösen versuchen möglichst gutes Teamgefühl aufzubauen und Teamspirit damit die Leute besser zusammenarbeiten können die Idee von den ganzen Scrum Konzept ist eigentlich eine Person

00:09:31: Einzelperson kann sich vielleicht um 10-20 30% B verbessern

00:09:36: wenn sie an sich arbeitet an intim kann sich auch um 500 oder 1000 Prozent verbessern wenn es ein wirklich gutes Team ist anstelle von dem schlechten Team und darum ist der Hebel den man hat.

00:09:47: Im Team besser zu machen sehr hoch im Vergleich wenn der Person einzeln für sich selber arbeitet.

00:09:52: Azad Scrum Master schützmann Dustin ist wenn ich dich richtig verstanden habe nicht ausschließlich.

00:10:00: Nur vor äußeren Einflüssen und versucht den Scrum-Prozess einzuhalten sondern in Deinem speziellen Fall.

00:10:08: Komm dann auch sehr viel zwischenmenschliche Geschichten rein und eben auch sehr viel Team Optimierung also quasi wenn man sich das Hierarchie vorstellen möchte schon eine Art Führungsposition.

00:10:21: Genau richtig es heißt aber Sorgen leadership leadership hat ja die Führungsposition

00:10:26: aber am Ende des Tages es sage ich den Leuten nicht wie sie ihre Prozesse zu gestalten haben Dennis Quandt ihm soll immer die komplette Verantwortung für das Produkt übernehmen das development team

00:10:38: und ich selber.

00:10:42: Kann ihm nicht sagen wie sie ihre Prozesse zu handhaben haben weil dann würde ich ja die Verantwortung für das Produkt übernehmen und ich das development team dass die Philosophie ist eigentlich dass die Entwickler selber

00:10:53: die besten Weg finden wie sie arbeiten können dass ihre Verantwortung ist und ich sie in die richtige Richtung stupse und den Prozess moderiere wie sie dahin kommen den richtigen Weg zu finden

00:11:02: okay also doch sehr moderierend auch ohne dass man Produktverantwortung übernimmt sondern mehr die teamverantwortung nee das trifft das

00:11:11: sehr sehr schön jetzt Schlange noch mal die Kurve rüber zum Data-Science ich meine wir haben den Scrum-Prozess jetzt mehr oder weniger mal angerissen und.

00:11:20: Elementare Dinge erklärt aber wie funktioniert das denn jetzt alles im Konzept mit dem Data-Science sind da ist es ja.

00:11:28: Doch nicht immer ganz planbar welche Hürden siehst du da so.

00:11:33: Ich würde vielleicht erstmal den klassischen Prozess in der Softwareentwicklung gegenüberstellen damit man in Vergleich sieht weil der ist glaube ich ganz spannend du bist ja selber Entwickler in Scrum Teams gewesen jetzt die letzten Jahre und hast deine

00:11:45: eigenen Erfahrung gemacht was werden z.b. bei dir so.

00:11:50: Die Erwartungshaltung an dem planning was da rauskommen soll am Ende also ich muss ganz ehrlich sagen.

00:11:58: Es ist immer so die Frage ob man selbst uns dran glaubt oder nicht und ich glaube jedes Team hat seine eigene Philosophie von Scrum dementsprechend.

00:12:08: Wenn ich mir überlege was ein gutes planning ist dann natürlich dass die nächsten Wochen oder Tage zumindest klar sind und dass ich weiß was ich als Entwickler oder gegebenenfalls auch Entwicklerin.

00:12:20: Von meinem Kollegen und Kolleginnen erwarten kann und was ich selbst zu tun habe.

00:12:25: Das wären so meine Erwartungen von einer klassischen Zeit jetzt mal Spin Planung ich möchte wissen was passiert in diesem Sprint und was muss geleistet werden.

00:12:34: Und wenn du es jetzt mal aus der Sicht des Product Owner siehst der quasi am Ende.

00:12:41: Mit dem Team und gemeinsam sagt ok der Sprint den starten wir so und vorgibt wie die Prioritäten sind

00:12:47: was würdest du sagen was der protone von dem Team erwartet der Product Owner will natürlich dass am Ende Resultate entstehen das heißt etwas für ihn greifbares und messbares für den Erfolg

00:13:00: so würde ich es zumindest als Product Owner tun.

00:13:02: Kärntner Handbuchseite ich jetzt mal so nach Scrum Lehrbuch ist es ja so dass nach jedem sprinten nutzbares Inkrement das in irgendeiner Form das Produkt verbessert rauskommen soll das ist jetzt eine relativ.

00:13:17: Offen gehalten Definition der interpretiert jedes Unternehmen und jedes Team ein bisschen was anderes rein aber ich glaube.

00:13:26: Die normale Situation in der Softwareentwicklung vielleicht sind deine Erfahrung anders

00:13:31: ist dass man relativ gut planen kann was man umsetzen möchte und die Frage er ist wie viel Aufwand es ist das umzusetzen.

00:13:42: Oder wie sind da deine Erfahrungen.

00:13:46: Der kleine Entwickler schätzt nicht in Zeit sondern Aufwand das ist ganz ganz klar eine Aufgabe hat viel Aufwand oder wenig Aufwand

00:13:53: denke aber schon dass es je nachdem wie Aufgaben geschnitten sind und wie groß sie sind das heißt wie gut sind sie eigentlich geplant und wie kleinteilig sind sie zerlegt kann man als Entwickler oder Entwicklerin immer sehr sehr gut abschätzen ob das in einer Zeit von 1 bis 2 Wochen machbar ist oder nicht

00:14:08: das bedeutet ich denke schon dass eine generelle Machbarkeit der Planung funktioniert.

00:14:16: Wenn die Aufgaben richtig geschnitten sind und ich sehe da ganz große Probleme in Projekten die jetzt gerade neu beginnen in Systemen die man jetzt gerade neu auf zieht weil es da dann doch

00:14:26: ja wieder ein bisschen diffus ist und dort können dann auch gerne mal Planungen fehlschlagen.

00:14:33: Das ist ein gutes Stichwort also im Data-Science Bereich habe z.b. als Android Coach und Scrum Master in einem Unternehmen gearbeitet das ziemlich groß ist das waren das war ein Konzern

00:14:45: und die haben sich wirklich vor allem mit Daten beschäftigt das war quasi die ihren Geschäftsmodellen am Ende haben die Daten ausgewertet und darüber einen Mehrwert für ihre Partner geschossen

00:14:57: und dieses Unternehmen hatte entsprechend mehrere der hat seinen Steam steasy dann verschiedenste Projekte hatten

00:15:04: und in den Projekten mit denen ich zu tun hatte war meine persönliche Erfahrung das gerade in so großen Projekten wo dann wirklich mal nicht ein Data scientist oder 2 1 System aus arbeitet was bei den meisten mittelständischen Unternehmen ja der Fall ist sondern wirklich ein ganzes Team

00:15:21: eine Problemstellung arbeitet die entsprechend größer ist und planning sehr sehr schwierig ist in Scrum Meier.

00:15:28: Am Industries erwartest du ja dass du in dem kleinen Fest legst was möchte ich erreichen in nächsten zwei Wochen

00:15:34: und im Data-Science Bereich sind da sehr viele wenn dann Bedingungen wenn ich in den ersten zwei Tagen gute Ergebnisse habe in dem Use Case den ich dort plane

00:15:45: dann arbeite ich weiter an ihm und investiere die Zeit und bringen den online und dann brauche ich auch noch ein Data engineer und Cloud engineer um das Ganze live zu bringen und weiter zu testen falls nicht

00:15:59: fange ich noch mal von vorne an und machen was ganz anderes und.

00:16:03: Gerade wenn ganz viele verschiedene Aspekt des Projekts in diese Richtung einschlagen dann ist es ziemlich schwer

00:16:09: gute Plan aufzustellen beim Ende oft der Fall ist ja vielleicht machen wir es so aber es kann auch sehr gut sein dass wir in zwei Tagen eigentlich alles neu planen können und alles umschmeißen.

00:16:19: Und das ist glaube ich eine Herausforderung die im Data-Science Bereich größer ist als im Software Entwicklungsbereich im klassischen da man natürlich auch da Komplexität hat und Abhängigkeiten aber diese.

00:16:32: Leichter Plan bei unverständliches sind unsichtbar als im Data-Science Bereich.

00:16:37: Ich habe direkt ein paar Fragen ich muss ja jetzt direkt mal Fieber Weise reingrätschen seid sagst du natürlich es kann in relativ kurzer Zeit dazu führen dass man gegen Problemen läuft.

00:16:49: Da wäre jetzt meine Frage

00:16:51: es ist natürlich sehr unvorhersehbar wie man Data-Science Projekte von Anfang an wenn sie jetzt gerade von der grünen Wiese entstehen gestaltet oder selbst wenn nicht man hat immer so ein paar Abhängigkeiten in andere Themen gerade als data scientist

00:17:05: sehr von den Resultaten anderer abhängig ist und Daten braucht die vielleicht nicht im eigentlichen Team liegen mein Frage ist aber.

00:17:14: Würdest sich dann nicht eventuell lohnen kürzeres Prinz zu machen statt zwei Wochen vielleicht eine Woche und

00:17:21: wenn jetzt nach zwei Tagen ein Problem auftritt dann versuchen uns am dritten Tag zu lösen und dann 4. und 5. kümmert sich man sich dann um.

00:17:29: Die nächste Iteration quasi und versucht die in die Zukunft zu sehen oder stelle ich mir das zu einfach und naiv vor.

00:17:36: Ich glaube das ist genau der richtige Weg tatsächlich in.

00:17:41: Der bricht Situation dich eben gehört habe haben wir genau das gemacht wir haben festgestellt ok Januar zwei Wochen Sprints was eigentlich schon jetzt nicht die längsten sind so normalen den ich das jetzt mal von der Länge her und wir haben festgestellt.

00:17:55: Nach einer Woche schmeißen wir oft alles über den Haufen und haben viel Planungsaufwand in der Situation gesteckt die am Ende gar nicht eintritt in irgendeiner Form und das frustriert dann natürlich auch ne dann fragen da fragt man wozu planen wir überhaupt wenn.

00:18:10: Das was wir planen niemals eintritt wozu der Aufwand und macht Scrum überhaupt Sinn und so weiter und diese frustrierte Situation haben wir tatsächlich auch gut verbessern können indem ihr von 2 Wochen auf 1 Wochen Sprints gewechselt sind

00:18:24: und.

00:18:26: Am Anfang haben sich auch da einige Fragen gestellt ist das dann nicht vielmehr Meeting Aufwand man muss alle Meetings dann doppelt machen also doppelt so oft innerhalb von zwei Wochen als vorher aber die Meetings sind natürlich auch viel kürzer wenn man viel weniger

00:18:39: Content zu besprechen hat sehr viel weniger passiert in der Woche man muss weniger vorausplanen es heißt das hat sich eigentlich nicht wirklich was genommen

00:18:47: und das ganze Team hat deutlich mehr Impulse mitgenommen was es in der nächsten Woche machen kann es hat ziemlich gut geklappt.

00:18:57: Stichwort Meeting.

00:18:59: Habt ihr alle Scrum meetings abgehalten also natürlich daily steht außer Frage das muss immer es gibt ja noch die sprintplanung es gibt die Reviews gibt die Retro habt ihr alles gemacht jede Woche.

00:19:10: Also in den 1 Wochen Sprints haben wir es dann so gehalten dass wir alles gemacht haben ich denke die meisten Sachen sind auch unabdingbar

00:19:18: refinement ist wichtig weil wenn du nicht planst was du nächste Woche machen möchtest und das mal vor besprichst dann stehst du blank da im planning und hast keine Themen wenn du kein Review machst dann wissen deine Stakeholder nicht

00:19:31: was in dem Projekt passiert wenn du keine Retro machst dann verbesserst du dich nicht und hast einen essentiellen Teil des ganzen Prozesses und der Agilität verloren aber was wir gemacht haben ist die Themen Review und Retro zu entkoppeln und weiterhin nur alle zwei Wochen zu machen weil sich einfach.

00:19:48: Verein veranstaltet klar war dass wir nicht jede Woche in sinnvolle Retro machen können und dass sie Stakeholder auch gar nicht jede Woche zu einem Review kommen wollen weil es einfach nichts Neues gibt unbedingt nach einer Woche was für die Stakeholder super spannend ist das auf Dauer

00:20:03: viel beschäftigte Leute sind sie jetzt einen vollen Terminkalender haben und dann das Interesse verlieren wenn.

00:20:09: Wenn das Team nichts Interessantes zu erzählen hat darum haben wir die Sachen tatsächlich auf einem 2er Platz 2 Wochenbasis belassen und alles andere refinement planning und daily ganz normal jeden Sprint gemacht jede Woche.

00:20:22: Das ist dann quasi der Fall wo.

00:20:25: Ihr als Team euren eigenen Scrum-Prozess gemacht hat der nicht mehr nach Lehrbuch ist und das greift genau in die Kerbe die ich vorhin erwähnt habe am Ende macht jedes

00:20:34: Team seine eigene Art von Scrum also genau wie ihr da jetzt auf jeden Fall ich würde sogar sagen jedes Unternehmen macht seine eigene Art von Agilität

00:20:44: gerade bei größeren Unternehmen kann man sich dann so eine ganze Abteilung versucht agil und nach Scrum oder welchem Framework man aufnimmt zu arbeiten

00:20:53: ist das immer so eine kleine Welt ich war jetzt in 4 wirklich sehr großen Unternehmen als etwa Coach und Scrum Master.

00:21:01: Und habe da festgestellt dass jedes Unternehmen wirklich ein kleiner Kulturschock war

00:21:07: in den ich reingeraten bin und mir immer dachte ja das habe ich aber ganz anders gemacht beim anderen Unternehmen ist das ist das denn so richtig

00:21:14: aber am Ende ist heiß gibt es kein richtig oder falsch sondern nur funktioniert das für die Konstellation an Menschen die Branche und die Problemstellung gut oder nicht gut und wenn nicht dann muss man sich verbessern.

00:21:24: Was war das denn so für Unternehmen also hatten die schon eine bestehende Produktpalette oder.

00:21:30: In den Arm oder bestehende Produktpaletten in denen

00:21:34: Data-Science schon vorhanden war und man Data-Science erweitert hat oder neue machine learning Algorithmen eingebunden hat oder hast du mehr oder weniger häufig von grünen Wiesen gearbeitet zu uns die Prozessors etabliert.

00:21:49: In den meisten Fällen habe ich bei jedem Unternehmen mit mehreren Teams gearbeitet und da waren dann Teams dabei den bestehenden Service oder ein bestehendes Produkt weiterentwickelt haben aber auch Teams die von der grünen Wiese wirklich bei Null gestartet sind.

00:22:02: Kempf die Frage die ich mir jetzt Stelle im Data-Science allgemein macht Scrum da immer Sinn.

00:22:11: Ich glaube nicht unbedingt generell ist Agilität glaube ich wichtiger.

00:22:16: Es ist framework was dahintersteckt es gibt ja verschiedenste agile frameworks das kann Scrum sein das kann Kanban sein hast du ja am Anfang schon mal rein geworfen es gibt auch andere agile frameworks mit den ich mich jetzt nicht so gut auskenne.

00:22:31: Und am Ende des Tages ist es glaube ich für mich zumindest vor allem wichtig dass man Agilität lebt das heißt nah am Kunden entwickeln nicht erstmal zwei Jahre vorausplanen das umsetzen und dann mal gucken ob das jemand sehen möchte

00:22:45: Transparenz Offenheit und Ehrlichkeit Leben und so weiter und so fort das sind alles agile

00:22:50: Werte und das agile manifest soll schon mal eine interessante Anekdote es gibt eine Studie das vom Silicon Valley das

00:22:57: ich verstehe dir eine Frage was würdest du schätzen wie viel Prozent der Zeit von Softwareentwicklern verschwendet ist und weggeworfen wurde im Schnitt

00:23:06: im Silicon Valley oder weltweit das war eine Studie aus dem Silicon Valley aber sie ist mal als Branchendurchschnitt allgemein Kay.

00:23:15: Auch ihr könnt nicht mit einer Anekdote Antworten die lasse ich jetzt mal unter den Tisch fallen ich würde sagen 80% wird weggeworfen.

00:23:23: Das ist eine sehr genaue Schätzung die ich ich glaube es waren 70 oder 80% irgendwas in dem Bereich die meisten schätzen er 30 bis 40% wenn ich sie frage also da warst du da warst du schon sehr Treffer genau hoffe ich hinauswollte mit der Anekdote ist es ist wichtiger seine Zeit sinnvoll einzusetzen

00:23:38: als möglichst viele Features zu entwickeln und gerade Unternehmen wie Apple oder Amazon zeigen ziemlich gut dass ne Nutzer gerichtete Entwicklung.

00:23:48: Und weniger ist mehr

00:23:50: viel mehr Erfolg bringt als einfach nur seine App oder was auch immer das technische Produkt ist mit Features zu zu bomben was so der klassischer Ansatz viele Unternehmen ist Features und Output gleich gute Leistung.

00:24:03: Einfachheit ist viel mehr wert und das ist mal schön agilis Prinzip was was unglaublich wertvoll ist und was wenn man es wirklich lebt

00:24:11: und Mehrwert schaffen kann und wenn man es wieder den Bogen schlägt wo wir eigentlich angefangen haben zu welchem macht es Kram immer Sinn bei Data-Science am Ende des Tages muss das Team

00:24:21: Weg finden gemeinsam gut zu arbeiten und Scrum ist ein Prozess der sehr gut in der Lage ist die Komplexität von 5679 die gemeinsam arbeiten an den gleichen Produkten zu beherrschen.

00:24:33: Aber es ist nicht die die Wahrheit auf alles.

00:24:37: Ich will dich nicht ganz so leicht ankommen lassen mit den ganzen Sachen nicht finde es wird gerade erst richtig interessant zumindest für mich denn es geht jetzt so ein bisschen in Richtung Team Struck

00:24:46: Tuan da würde mich mal interessieren wie sind denn so Data-Science Teams

00:24:51: aufgebaut die du in deinen Projekten bisher hattest welcher welche Art von Skills hat ein Team welche Art von Personen sind dann drin erzähle gerne mal kurz was drüber

00:25:01: das eine coole Frage tatsächlich ich weiß.

00:25:05: Würde coole Frage weil ich glaube dass viele Unternehmen gerade große Unternehmen da.

00:25:11: Strukturellen Fehler man zumindest aus den Erfahrungen die ich gemacht habe und zwar denken.

00:25:17: Unternehmen in der Regel in Rollen z.b. ich brauche ein Cloud engineer ich brauche ein Data scientist ich brauche ein machine learning engineer ich brauche eine Softwareentwickler und.

00:25:29: Die Leute wären dann in diesen Rollen geheilt und sollen dann auch genau das machen und daran Experten sein man wird so ein klassisches Data-Science Projekt neben dann ist eigentlich Data-Science

00:25:38: kleiner Teil von dem Data-Science Projekt dass das lustige da dran

00:25:43: am Ende des Tages ist es viel mehr Aufwand data Engineering zu betreiben dass die Pipelines aufzubauen damit die Daten überhaupt vorhanden sind und transformiert werden können das ganze in die Cloud zu bringen dafür einen Frontend zu bauen dass die Nutzer auch Input geben können oder die Ergebnisse sehen.

00:25:59: Nur STEP einzubauen das mit den Ergebnissen gearbeitet werden kann das kann sie eine Schnittstelle besteht zu internen oder externen Anwendungen das gehört alles zu so einem vernünftigen Data-Science Projekt das irgendwann noch auf die Straße kommen soll dazu und ist halt

00:26:13: viel mehr Arbeit als der Data-Science part in dem Projekt und jetzt wenn man jetzt diese

00:26:18: Team aus 6 Leuten hat dann ist der klassische Ansatz von dem großen Unternehmen zu sagen ok wir brauchen einen Data-Science ist ein Cloud engineer ein Software-Entwickler ein Frontend Entwickler und.

00:26:29: Vielleicht noch irgendeinen erfahrenen irgendwas egal und am Ende des Tages arbeitet dich ist ihm dann oft so

00:26:37: das ist Scheuklappen hat das heißt der data scientist

00:26:41: spielt mit Daten und Zahlen Mathematik rum und überlegt sich was hat aber keine Ahnung von Software-Entwicklung wie man skalierbaren guten Code schreibt und ob das Ganze

00:26:49: so sind von in der Cloud laufen kann der hat dann den machine learning engineer der ihm dann hilft die Zinnkraut skalierbar

00:26:56: und gut zu machen und in die Cloud zu bringen dann gibt's noch eine Cloud Ingenieur der die ganze Architektur macht und das ganze diploid und dafür sicherstellt dass das sicher ist und Security wenn sichergestellt ist RCA dann bauten Softwareentwickler der von den ganzen anderen Kram keine Ahnung hat

00:27:11: öffne REST API und irgendwer bringt das noch ins Frontend und diese Insel Lösung

00:27:17: haben einfach das Problem dass keiner über seinen Tellerrand hinaus schaut und im Prinzip das ist ja eine Verkettung von Prozessen das was er Data-Science ist Macht.

00:27:27: Passt dann irgendwann einfach überhaupt nicht mehr zu den anderen.

00:27:31: Silodenken und verliert sich untereinander und da geht viel Effizienz verloren viele Projekte sind Hahn haben sehr viel Aufwand

00:27:38: gehabt durchschleifen die immer wieder kommen weil wir dann irgendwann beim Software-Entwickler gemerkt haben das Konzept das ist nicht stimmig und wir müssen noch mal von vorne anfangen bei der mit dem was die Leute vorher gemacht haben nichts anfangen kann

00:27:51: das ist gar nicht schwer die ganzen Leute die nur im silodenken

00:27:55: aufeinander abzustimmen und eine gemeinsame gute Lösung zu finden und darum bin ich der Meinung dass man da mehr Generalisten braucht und weniger Spezialisten.

00:28:03: Ich würde einigen Punkten ehrlichgesagt vehement ganz vehement widersprechen vielleicht tue ich das gleich oder zumindest

00:28:10: einige Punkte würde ich auch sehr gerne Infragestellen wenn es wirklich so ist dass es vielleicht ein bisschen schöner formuliert aber hast du ein zwei konkrete Verbesserungsvorschläge.

00:28:20: Demgegenüber was du jetzt gerade mehr oder weniger als suboptimal beschrieben hast.

00:28:27: Ich glaube es ist sehr wertvoll wenn vor allem die data scientist.

00:28:34: Wissen über die Infrastruktur und allgemein

00:28:40: gute Softwareentwicklung haben wenn man sich damit sehr viele feedbackschleifen Iteration spart bei denen man am Ende zu ihnen Dinge zurückgeworfen werden.

00:28:50: Am Ende des Tages spart man sich darüber auch viel Kommunikation und Streitigkeiten meiner Erfahrung nach bei der data scientist einfach von Anfang an in der Lage ist zu bedenken.

00:29:00: Das eherne Konzept und Erlösung baut auf Data-Science Basis mit der die anderen gut arbeiten können das heißt ich sie vor allem dass er data scientist

00:29:08: der in der Regel Ausnahmen Soziologie Umfeld kommt oder aus dem wissenschaftlichen Umfeld und in vielen Fällen er.

00:29:16: Maggi nähere softwareentwicklungs Skills Hard Enterprise softwareentwicklungs Skills hat sehr davon profitieren würde dort besser aufgestellt zu sein.

00:29:25: Okay ich würde ganz gerne einmal kurz.

00:29:30: Meiner Erfahrung nennen dass ich dir Frauen gemacht habe das sehr wohl data scientisten auch in der Lage sind eigene APIs aufzubauen ich habe sogar schon mal aus der Nähe gesehen.

00:29:43: Davon.

00:29:44: Ganz abgesehen habe ich auch die Erfahrung gemacht dass Data-Science Projekte in Unternehmen häufig angedockt werden und Unternehmen häufig schon Strukturen haben sowas wie ein operations Team Wien Entwicklungsteam Wien.

00:29:59: Ja data engineering team ist ein bisschen Glückssache ob man sowas jetzt im Einzelnen hat aber es gibt auf jeden Fall verschiedene Datenquellen aus dem man sich dann immer bedienen kann und dann die man als Data-Science.

00:30:10: Person.com muss und demnach habe ich gar nicht so die Erfahrung gemacht dass alle Rollen.

00:30:17: In einem neuen Team wenn man ein Projekt erstellen möchte.

00:30:22: Vereint werden müssen oder bedient werden müssen weil man einfach sehr viel teamübergreifende Arbeit hat teilweise würdest du in diesem Prozess auch ein Problem sehen oder würdest du diesen Prozess vielleicht ein bisschen optimaler bezeichnen wenn es diese Kompetenzen von operations also

00:30:38: Architektur aufsetzen bzw sind ja dann Architekten aber die auch am Leben halten die Eiche

00:30:43: Tour des Monitoring Entsafter Scheibenrahmen gibt und schon Teams gibt die das bedienen können.

00:30:49: Würdest du es dann nicht vorteilhaft sehen einfach ein reines Data-Science Team aufzustellen welches dann mit den anderen Teams kommuniziert.

00:30:58: Die Situation die du jetzt Schilder sind ja quasi.

00:31:01: Fachliche Teams dass man quasi sagt okay die haben Ahorn Bereich Data-Science die haben auch im Bereich Engineering die haben noch im Bereich ob's und es gibt.

00:31:12: Sicher Unternehmen die sich so aufstellen ich habe bisher persönlich er Erfahrung mit Produkt getrieben in Unternehmen gehabt die sagen okay wir wollen den Service aufbauen

00:31:22: und wir holen alle Leute in das Team Heim die wir brauchen vom nachher um den kompletten Service

00:31:28: umzusetzen und zu betreiben und das Team hat die komplette ownership und die komplette responsibility vor den Service was heißt das muss die Pollenkorn es muss warten können es muss testen können ich muss die Security sicherstellen und so weiter und so fort.

00:31:41: Und in diesem Produkt getriebenen Unternehmen gibt es auch.

00:31:45: DevOps Team gibt es auch nicht viel tut ihm all diese Leute haben keine Umsetzungskompetenz in dem Produkt sondern diesen eigentlich nur Berater.

00:31:55: Das heißt

00:31:55: die schauen dann über verschiedene Teams mit so einer Vogelperspektive drüber und helfen dabei ein gemeinsames Konzept für Fragestellung und Probleme zu finden aber die gehen jetzt nicht hin und setzen irgendwas um innerhalb des Teams das liegt immer innerhalb des Teams das ist.

00:32:10: Im Prinzip nur Frage auf der Philosophie des Unternehmens wie es Produkte und Projekte umgesetzt und ich glaube weder das eine noch das andere sind um Ding falsch oder besser oder richtig.

00:32:21: Weil du schon festgestellt haben jedes Unternehmen und seine eigene Welt und seine eigene Komposition aus Menschen und seine eigenen Branche.

00:32:28: Und was du für den einen richtig ist und extrem gut funktioniert kann für den anderen Katastrophe sein das stimmt.

00:32:37: Wenn du dir was wünschen würdest für deine Arbeit was alles vereinfachen würde in deinem Prozessen hättest du da einen Wunsch wie.

00:32:46: Dein Traum Team aussehen sollte oder das Traum Unternehmen dass du kommen würdest wenn es jetzt an Data-Science Projekte geht.

00:32:54: Ich glaube das wichtigste ist abseits von den fachlichen Kenntnissen die Leute haben dass das Team vor allem miteinander gut kommuniziert und einen guten team-spirit habt ich glaube alles drum herum lässt sich.

00:33:07: Lösen wenn das gegeben ist alles drum herum ist quasi das Feintuning sei jetzt mal das heißt noch die Problemstellungen die ich jetzt genannt habe.

00:33:16: Jasmina data scientist marginales Software Entwicklungs Know How Harz und das andere Leute übernehmen sollen das kann vielleicht auch funktionieren

00:33:25: aber wenn das Team extrem gut zusammen spielt wenn wir jetzt mal ehrlich sind ist meine Beobachtung bei meisten Unternehmen dass die Teams zusammen gewürfelt sind

00:33:33: Austin paar freelance Hunter externen paar intern die Leute die man halt so zusammenkratzen kann weil Fachkräftemangel herrscht und weil man sich halt nicht einfach immer sein Traum Team zusammenstellen kann und gerade wenn dann die Teamchemie vielleicht nicht perfekt

00:33:47: ist und man nicht perfekt aufeinander abgestimmt ist dann können solche

00:33:52: Schwierigkeiten und Kommunikationsbarrieren sehr mühsam werden weiß vor allem halt gut zusammengestellte Teams die aufeinander

00:33:59: Lust haben gemeinsam zu arbeiten und gutes Team darzustellen und Problem zu lösen zum glaube ich der Schlüssel zum Erfolg

00:34:06: ich bin in Zoo und das was ich ganz ganz ganz besonders interessant an diesem Punkt finde ist das dein schlusswort jetzt quasi.

00:34:13: Gar nicht mal so Data-Science Team spezifisches ich glaube das lässt sich auf jedes Team übertragen

00:34:19: und von dem Thema welches wir jetzt anreißen wollten

00:34:23: Data-Science und Scrum Prozessen war das wirklich Data-Science spezifische wahrscheinlich eher die unplanbarkeit an einzelnen Aufgaben denen man wahrscheinlich am besten mit kürzerem Sprints entgegentritt

00:34:36: oder würdest du noch eine andere essence aus diesem Gespräch ziehen.

00:34:40: Ich glaube am Ende findet jedes Team seine eigenen Lösung für seine Probleme indem es Erfahrungen sammelt merkt was schlecht gelaufen ist und besser wird

00:34:49: aber was meine persönlichen Erfahrungen die ich hatte war wirklich zum einen die kürzere Sprint Dauer sehr hilfreich dann

00:34:57: etwas was wir noch gar nicht erwähnt haben dass wir gar nicht erst versuchen unbedingt immer das Feature gleich zu planen so als würde man.

00:35:05: Als Story verstehen in Scrum in Feature was für einen Kunden umgesetzt wird sondern vielleicht auch erst mal einfach ein Konzept und einen Analyse oder einen Test.

00:35:15: In den Sprint rein zu nehmen und dann auf Basis der Ergebnisse von diesem Konzept dann im nächsten Sprint die Umsetzung zu

00:35:22: Plan viele Teams versuchen immer gleich das Feature zu planen und zu schätzen und den Aufwand zu schätzen und umzusetzen und das ein bisschen zu entkoppeln und erstmal Konzept zu machen das übrigens auch aus meiner Sicht im Softwarebereich keine schlechter Ansatz nicht immer gleich versuchen sofort umzusetzen sollen erstmal ein gutes Konzept zu erstellen

00:35:40: das kann man auch wunderbar einem agieren Team machen und in dem Scrum Team Scrum heißt nicht dass man die ganze Zeit nur Stories durch ballern muss und sich nicht über etwas im Voraus Gedanken machen muss das war auch sehr hilfreich mehr.

00:35:52: Das stimmt damit würde ich ganz gerne abschließen weil ich glaub wir können noch eine Stunde weiterreden aber.

00:35:58: Das Thema das haben wir eingerissen und falls es dann noch mehr Interesse zu gedrückt Fragen oder was auch immer gerne jederzeit nachfragen Alex ich bedanke mich sehr sehr bei dir und wir hören uns bestimmt noch mal.