Ashley: Taktsoft Campus Podcast! Willkommen zurück! Schön, dass ihr wieder dabei seid. Das Scared Agile Framework ist heute ein sehr bekannter Begriff und soll Unternehmen helfen, agile Methoden zu adaptieren. Wir wollen hören, ob dies tatsächlich so ist und ich freue mich, heute mit Michaela Kielburger sprechen zu können. Michaela hat jahrelange internationale Erfahrungen in eCommerce, Energie und Telekom Umfeld und ist heute als Product Owner in einem internationalen Großunternehmen tätig. Wir reden gleich darüber, ob die Überleitung aus einem eigenständigen Scrum Team in einem SAF-Umfeld funktioniert. Welche Herausforderungen gibt es und hilft das? Ich freue mich auf das Gespräch. Und wie immer, wenn ihr Themen habt, die ihr gerne in einem Podcast beleuchtet haben möchtet, schick uns eine Email an Podcast@taktsoft.com. 
Ashley: Hallo, Michaela. 
Michaela: Hi, Ashley. 
Ashley: Wie geht es dir heute? 
Michaela: Ja, alles gut. Danke. Wie geht's dir? 
Ashley: Ja, alles gut. Alles gut. Wie war dein Arbeitstag? Erfolgreich, hoffe ich. Wunderbar. Wie immer. Wie immer. Aus Produkt. Das ist eigentlich das Thema, was wir heute besprechen wollten. Das Thema Produkt. Und vor allen Dingen deinem, einem agilen Umfeld. Aber auch da ist so ein Großunternehmen vielleicht mal so die die Unterschiede und die Herausforderungen, die man in so einem Umfeld hat. Aber fangen wir erst mal an aus in einem agilen Umfeld. Was sind dann eigentlich deine Hauptaufgaben? Was was musst du eigentlich tun? 
Michaela: Also du kannst es dir gerne so vorstellen, dass ein Product Owner ist wie eine Art CEO für das eigene Produkt. Das heißt, du musst die ganze Vision haben. Was sollte denn dein Produkt tun? Du soll stets den Kunden im Vordergrund haben und dann bist du dafür da, dass du halt die ganze, das ganze Prozess der Entstehung des Produktes bis zu Market Launch und bis zum Life Cycle auf dem Markt einfach mal begleitest, mitgestaltet und dein Team so richtig steuerst, dass das Produkt zu einem Erfolg wird. 
Ashley: Und wenn du sagst ein Team, welche Arten von Leuten hat man typischerweise im Team? So Entwickler XY? Gibt es aber auch andere Leute, die wirklich ein Produkt gestalten von der physikalischen Seite oder kommt es darauf an, was von dem Produkt? 
Michaela: Das ist eine gute Frage und das ist denke ich, keine einfache Frage, weil du hast ja unterschiedliche Produkte. Wenn wir jetzt über Jeans als Produkt reden, wirst du halt andere Aufgaben haben, weil es ja ein physisches Produkt ist. Als wenn wir jetzt sage ich, sagen wir mal, über eine mobile App oder eine Webseite sprechen, wo du dann als Product Owner die Verantwortung ist da, da wird dein Team anders sein und aus anderen Skills oder Kollegen bestehen. Wenn wir jetzt ein eine digitale User Experience oder ein Produkt nehmen, dann sicherlich brauchst du Designer, die dir so eine Experience gestalten können und kreieren können. Du brauchst Entwickler, die dir so was bauen. Du brauchst Tester, die das nach testen können. Sicherlich bist du dann derjenige oder diejenige, die auch mitmacht und mitgestaltet und mit testet. Ich würde sagen mitentwickelt. Vielleicht auch, wenn man sich das zumutet. Aber eigentlich theoretisch ist das nicht Bestandteil deiner Product Owner Rolle. Deine deine Aufgabe ist eigentlich, die Vision über das ganze Produkt parat zu haben, zu die zu kreieren, die zu gestalten, damit du halt weißt, wo der Weg hingeht und damit du das an dein Team kommunizieren kannst. Und dann diese Vision in unterschiedliche Customer Journey User Stories und halt kleinere Elemente zu zu verteilen und so priorisieren, dass dein Team immer weiß, wo der Weg hingeht. Und was sind jetzt so die wichtigsten Aufgaben? Meilensteine, die man erreichen muss, damit man dann zu einem gewissen Zeitpunkt mit dem Produkt entweder im Markt landet oder halt eine große Verbesserung auf den Markt bringt oder ähnliches. 
Ashley: Und du bist dann eben in so einem digitalen Umfeld unterwegs und du bist auch in einem Großunternehmen. Gibt es dann so eine besondere Herausforderung, ihn so als Product Owner in einem Großunternehmen? Es ist gegenüber ein Start up, wo man vielleicht nur vier oder fünf Leute im Unternehmen hat. Aber wenn man wirklich in einem Großunternehmen unterwegs ist, gibt es dann Herausforderungen, Einschränkungen? Wie ist das agile Leben in einem so einem Großunternehmen? 
Michaela: Ja, also wenn wir uns das aus dieser Perspektive der Agilität anschauen, dann würde ich sagen Wollen alle schneller, besser, effizienter, kostengünstiger und so weiter arbeiten, je nach der Priorität. Manchmal gibt es auch viele Prioritäten, die sich zusammentun und dann muss man richtig balancieren. Ich denke, dass der Unterschied zwischen einem Startup oder einem kleinen Unternehmen ist. Als ein Großunternehmen ist die Komplexität und Anzahl der Stakeholder, die man einbeziehen muss. Und zwar geht es nämlich darum, dass in einem Startup Wenn ich einfach ein hypothetisches Beispiel mache, dann hat man im Team fünf Leute, sechs Leute, ein paar Designer, paar Entwickler, paar Tester, dann den Product Owner. Sicherlich, da kann man sich deutlich schneller abstimmen, was man macht, wie man es macht. Und vielleicht kann man schnell bestimmte Sachen ausprobieren, ob die funktionieren oder nicht. Durch Tests. Und dann je nachdem entscheiden. Okay, machen wir so weiter, oder? Oder nämlich nicht. In einem Großunternehmen wird man nicht nur über Personen, sondern über Abteilungen und ganze Teams. Und dadurch, dass die Großunternehmen auch komplexe Prozesse haben. Da ist vielleicht komplexer Regulierung im Spiel, die man betrachten muss. Und so weiter. Da geht es dann darum, wie bringt man diese Ansammlung an unterschiedlichen Stakeholdern zusammen, so dass man trotzdem immer noch agil bleibt und möglichst schnell nach vorne kommt und so, dass man möglichst wenig Geld und Zeit und Resources verschwendet. So, und die Komplexität liegt auch darin, dass obwohl man zum Beispiel selber sagt Ja, ich möchte jetzt agil arbeiten, meine Abteilung arbeitet agil, wir entwickeln Produkte agil. Es ist nicht gegeben, dass alle Abteilungen genauso arbeiten. Daher da hat man schon immer wieder, sage ich mal, einen Zusammenstoß oder so ein Clash von unterschiedlichen Welten, wo halt bestimmte Abteilungen und Teams zwar agil arbeiten und schnell unterwegs sein wollen. Und gleichzeitig hat man Abteilungen, die zum Beispiel immer Wasserfall artige Methodologie verfolgen, weil es nämlich zum Beispiel zu dem, was sie machen, gerade passt. 
Ashley: Stichpunkten dazu Scout Orion Framework 2011 würde das eingeführt, mittlerweile sind wir bei Seife fünf, so, das heißt jetzt zehn Jahre später. Und wenn man da liest, Safe, also Framework, beschreibt, wie agile Methoden auf Unternehmensebene genutzt werden können. Das ist aber so Die offizielle Positionierung von Safe hilft das? Hast du auch in so einem Safe Umfeld gearbeitet und hilft dieses Framework, um genau diese Komplexitäten, die du beschreibst, in einem Großunternehmen zu vereinfachen oder gar wirklich wegzuräumen? 
Michaela: Das ist eine gute Frage und interessante Frage und eigentlich ziemlich passend, weil ich gerade vor kurzem so eine Erfahrung machen konnte oder machen kann. Und zwar habe ich die Möglichkeit gehabt an einem Projekt zu arbeiten, welches diese Safe Methodologie halt benutzt. Ähm, ich sage mal so Safe wird jetzt nicht. Die Lösung für dein Produkt. Sein Safe wird dir dir als Product Owner jetzt nicht das abnehmen, wie man das Produkt strukturiert, wie man rangeht, wie wie man die Kundenbedürfnisse erfüllen möchte oder kann. Safe ist aber denke ich, ein ganz nützliches Werkzeug dazu, um einfach mal solche komplexe Umgebung, wie man das halt in Großunternehmen hat, besser zu strukturieren, transparenter zu machen und vom Anfang an, also von Anfang an des Projektes möglichst alle relevanten Stakeholder des Teams einfach miteinzubeziehen und und transparent aufzustellen, wo man steht. Was, was liegt vor einem, was erwartet einen und möglichst versuchen, es in kleineren Abschnitten zu planen, statt in Jahres Plänen oder Monats Plänen, so dass man dann eher in kleineren Iterationen nach vorne kommt. Gemeinsam statt einzeln in sag ich mal so Silos, wo halt Abteilungen vielleicht untereinander nicht sprechen oder sich nicht abstimmen. 
Ashley: Und wie habe ich mir das vorzustellen? Du sagst, dass die Komplexität damit verringert werden kann. Aber gibt es eine bestimmte Art von Zeremonien, die man einhält, nicht nur innerhalb eines eines Teams, sondern auf der ist? Um so auf der Program Ebene gibt es dann Zeremonien oder oder Events, die einem helfen, um diese Komplexität vielleicht erst mal darzustellen und dann zu reduzieren. 
Michaela: Also ja, das auf jeden Fall. Um auf die Frage zu werden, zu antworten Das ist. 
Ashley: Gut, danke. 
Michaela: Also Safe basiert grundsätzlich auf agilen Methoden. Das heißt, diese Harmonien, die man so aus einem Scrum zum Beispiel kennt, wie Daily Standup Meetings, die halt sehr kurz sind oder Meetings mit dem ganzen Team, wo man halt über bestimmte Themen, Features, Funktionalitäten näher spricht, um die einfach mal besser zu verstehen und zu definieren. Die gibt's weiterhin eine Retrospektive für jede kleine Iteration für den Sprint. Und so weiter. Dadurch aber das Safe versucht diese diese Methodologie halt zu skalieren, damit die in komplexen um in einer komplexen Umgebung angewendet werden können, müssen sich auch die Teams untereinander treffen und austauschen. Und es geht nicht nur um das Geschehen in einem Team, sondern wie skaliert du das oder wie überträgst du das? So dass die Teams untereinander auch immer gleichzeitig abgestimmt sind, möglichst über Abhängigkeiten wissen und die verstehen und die adressieren können und dann möglichst schnell und idealerweise von Anfang an transparent bleiben. Die Risiken immer wieder hervorheben, wenn die entstehen und nicht einfach mal warten, bis man einen Meilenstein erreicht oder sage ich mal eine Iteration beendet und erst dann ein gewisses Reporting zum Beispiel macht. So, und dazu hat Safe bestimmte Zeremonien, die als Best Practices on top von dem, was man von dem ganzen agilen Arbeiten kennen, dazu kommen. Und das ist zum Beispiel eine eine große Zeremonie, für die sich der Planung einer ganzen Iteration widmet. So eine große Iteration kann 6 bis 8 Sprints oder ich mal zweieinhalb drei Monate dauern. Und da zum Beispiel trifft sich das ganze Programm oder große Projekt. Es kann, keine Ahnung, 20501 100 Leute sein, je nach Größe und wo es dann darum geht, gemeinsam, aber dann auch gezielt in Teams sich die Zeit zu nehmen und einfach auf einem gewissen High Level. Es ist ja nicht detailliert, einfach mal zu planen, wo geht die Reise hin in den nächsten drei Monaten? Was ist eigentlich realistisch und machbar zu erreichen? 
Ashley: Und das heißt dann, es ist nicht mehr nur auf der einzelne Team Ebene, sondern dass die Teams im Programm zusammenkommen und genau dann dieses Austausch haben. 
Michaela: Genau. Stell dir das vor wie eine Art Speed Dating. 
Ashley: Wie wir das jetzt machen. 
Michaela: Genau. Ja, genau so, wie wir das jetzt machen. Man trifft sich halt idealerweise als Präsenz Veranstaltung in einem Raum oder in einer Location. Jetzt geht es leider nicht. Daher auch virtuell. Dafür gibt es auch viele interessante und coole Tools. Und dann hast du halt bestimmte Abschnitte an halt einer. Und eine Agenda, die halt gemeinsam stattfinden, wo das ganze Team halt zuhört oder halt irgendwelche Themenbereiche erklärt bekommt. Gleichzeitig hast du dann aber bestimmte Punkte oder Abschnitte, wo du Zeit dich dir nimmst, nur in deinem Team und versuchst einfach mal zu verstehen, wo wollen wir als Team hin? Da kommen aber immer wieder Fragen auf und werden immer wieder Abhängigkeiten identifiziert, Meilensteine definiert. Und so weiter. Und dann macht es immer wieder Sinn. Und da komme ich zurück zu dem zu dem Ansatz von Speed Dating, dass man sich so eine Art Speed Date mit einem anderen Team vereinbart. Keine Ahnung. 15 20 Minuten, um einfach mal rauszufinden, ob das andere Team das gleiche Thema, aber von einem anderen Blickwinkel genauso sieht. In Bezug auf die Abhängigkeiten Meilensteine, damit man eigentlich sich schon mal gemeinsam trifft. Zum Thema Ja, arbeiten wir an dem Thema. Ja, wir wissen Bescheid, dass wir da eine Überlappung haben. Ja, wir wissen wir es und wir müssen uns abstimmen. Aber ja, eigentlich, wir sehen das genauso, dass wir das in der nächsten, in dem nächsten Zeitraum schaffen. 
Ashley: Und ich denke auch genau dieses, wenn man alle Teams zusammenbringt, dass man ein gemeinsames Verständnis für das Gesamtprodukt hat. Sprich diese Vision, wovon du gesprochen hast, dass das wirklich jeder weiß. Okay, wir arbeiten dorthin oder dahin. Und dass man dadurch dann einfacher die Abhängigkeiten herausfinden kann. Und wie du sagst, damit im Speed Dating Ansatz in Anführungsstrichen, dass man wirklich schnell sagen kann, okay, ich muss jetzt mit zehn Exceptions über eine bestimmte Sache reden und dass die Leute vor allen Dingen alle präsent sind, entweder online oder oder oder wirklich vor Ort. Aber dass die alle Leute, die die sind präsent, sodass man diese kurze Abstimmungs Wege dann hat. 
Michaela: Ja, genau. Ja, ich denke auch, es hat auch einen weiteren Vorteil. Und zwar es erklärt nicht nur in ganzen Teams, wo die Reise hingeht und worauf man denn zusammen hinarbeitet, sondern es gibt auch die Möglichkeit einem Produktmanager oder dann auch einem Programm oder Portfoliomanager. Stell dir vor, du hast mehrere solche Programme. Es gibt dann halt die Möglichkeit, diesen Stakeholdern eine transparente Kommunikation Richtung Management zu gewährleisten und sage ich mal, einen Status immer in Realtime ableiten zu können und Risiken aufbringen zu können, Abhängigkeiten richtig kommunizieren zu können. Daher ich denke, wenn man es gekonnt nutzt, bringt die Framework an sich schon einige Vorteile. Sicherlich muss das dem Kontext, dem Produkt und der Umfeld passen. 
Ashley: Und die provokative Frage jetzt Ich sage mal so Du hast gesagt, du warst in im normalen agilen Projekten unterwegs. Du bist jetzt in diesem Safe Umfeld und unterwegs. Wenn wir sechs Wochen nach vorne spülen und ich dich fragen würde okay, als das, was du gerade erzählt hast, ein bisschen in Theorie von safe hat, hat es wirklich was gebracht für dich in diesem Großunternehmen Umfeld? Hat hat Seife wirklich die Sachen transparenter gemacht? Die hat es einfacher gemacht die Abhängigkeiten zu finden. Wie hast du das dann so erlebt in deinem tagtäglichen Job als Product Owner in so ein Umfeld? 
Michaela: Also wenn ich jetzt so sechs Wochen nach vorne schaue, denke ich schon, dass es hilft, weil es eigentlich diese Transparenz von Anfang an bietet. Das Gute ist, dass wenn man halt gemeinsam plant mit eigenem Team und das machen dann alle Teams genauso oder in parallel pflanzt du ja zusammen, das heißt es du. Es ist nicht nur deine Aufgabe, einfach mal vorzugeben, was das Team zu liefern hat. Du gestaltest es gemeinsam mit deinem Team, weil jeder im Team ist ein Experte in dem eigenen Feld. So und deswegen so eine Planung zum Beispiel liefert oder gewährleistet so eine Art einen Wegweiser für das gesamte Team, wo es hingehen soll aus unterschiedlichen Perspektiven. Wenn man sich jetzt das eigene Produkt anschaut und es würde dir jetzt als Product Owner nicht die Aufgabe irgendwie entnehmen, dass du immer noch deinen Kunden im Fokus haben kannst, das musst, dass du immer noch überlegen musst Wie werden die Customer Journey gestaltet? Wie werden die User Stories geschrieben? Welche Funktionalitäten ergeben sich daraus und was muss das Produkt haben, um einfach mal ein cooles Produkt zu sein? Wenn das dann auf dem Markt ist oder wenn, dann. Die nächste Verbesserung kommt. Aber es gibt dir immer noch eine Art Guide, um die du immer noch an der Hand hast und da kannst du ein bisschen rückblicken. Ach ja, was haben wir uns da so überlegt? Wie wollten wir das machen? Sind wir gut on track oder auf dem Weg? Sind wir immer noch? Gehen wir immer noch die Richtung, die wir, die wir uns vorgenommen haben? Wenn es sich ergibt Hey, wir sind gerade blockiert. Wir können nicht weiter machen, dann gibt es dir die Möglichkeit zu sagen. Ja, das, was wir uns da vorgenommen haben, ist vielleicht nicht das passendste. Lasst uns mal überlegen, wie der neue Weg jetzt aussehen soll. Daher diese Art Kontrolle. Und es hilft dir als Product Owner, deine Vision nicht zu verlieren. Wo möchtest du denn hin? Also stell dir das vor als eine Art Lighthouse, der dir. 
Ashley: Dann immer zu leuchtet. 
Michaela: Und gibt dir halt die Richtung. 
Ashley: Vor. Und ich denke auch wenn du abhängig bist von jemand anders, du brauchst etwas von jemand anders, um dein Produkt zu bauen. Du brauchst einen bestimmten Stück Software von jemand anders, dass du auch früher das ansprechen kannst und auch sehen kannst. Gut, wie ist die Planung dann von dieser externe Team, dass du so, dass du dann da im Produkt insgesamt sehen kannst, auch mit den Inputs von denen von den anderen Themen. 
Michaela: Also das Safe baut auch auf aus dieser Hinsicht, auf den agilen Prinzipien, die halt vorsehen, dass du in eher lieber in kleinen, inkrementelle oder in kleinen Abschnitten arbeitest. Am Ende werden immer halt möglichst ein Produkt Teil, welches Mehrwert bietet, dasteht. Und hier im Save wird das weiter gelebt oder fortgeführt. Das heißt, es gibt nicht nur die kleinen Iterationen, die man im agilen Sprint nennt und in Save jetzt Iteration, sondern es gibt auch diese, sage ich mal, sechs acht Sprints oder zwei drei Monate langen Abschnitte, die man dann halt planen und wo auch am Ende eine Art Retrospektive vorgesehen ist, eine Art Demo Session vorgesehen ist, wo es dann nicht darum geht, Team A hat das und das geliefert, Team B hat anderes geliefert, sondern was haben wir als ganze Programm gemeinsam Ende zu Ende geliefert und ich denke, dann wird es spannend, weil dann kannst du vom Anfang an in Schritten sehen, wie das Produkt entsteht. 
Ashley: Und gibt es irgendwas was dir fehlt im Safe Umfeld? Gibt es etwas, wo du sagst Ah, es wäre schön, wenn ich noch ein bisschen mehr von A, B oder C hätte oder oder oder. Denkst du, dass dieses Framework gibt wirklich so viel vor? Man muss das leben und jeder muss muss muss seinen Beitrag dazu leisten. Gibt es genug oder gibt es irgendwelche Punkt wo du sagst Menschen, es wäre gut, wenn wir in dem Umfeld ein bisschen mehr Hilfe bekommen, kann das so ein bisschen mehr Struktur oder Guidelines bekommen könntest oder ein Best Practice in einem bestimmten Umfeld. 
Michaela: Also ich denke, es hängt vom Produkt, von Umfeld und von dem gemeinsamen Setup. Aus meiner Erfahrung, es ist interessant zu beobachten, wie unterschiedliche Abteilungen Kollegen mit dem Thema umgehen und wie schnell oder langsamer so ein Thema gelebt wird. Daher, wenn es Richtung Best Practice ist, ist klar ist wir am idealsten, wenn alle Teams sich nach der gleichen Methodologie orientieren, die leben. Es gibt keine sag ich mal Konflikt Tätigkeiten oder Projekte, die dann dieses gelebte irgendwie bisschen stören können. Ja, aber das ist teil des des tagesgeschäft. 
Ashley: Das ist das Leben sozusagen. 
Michaela: Damit muss man leben. Daher die Realität. Ist halt so, dass einige Teams so eine Methodologie eher nutzen, vielleicht eher fortgeschritten sind, die anderen vielleicht auch durch die Natur des Produktes oder des Components, welches die bauen oder kreieren, es nicht so voll durchleben können. Und da muss man sich je nach dem arrangieren und ich sage mal so, so ein bisschen das Negative kann sein oder kann dadurch entstehen, dass man mit allzu vielen Terminen und Abstimmungen endet, wo man halt mit dabei sein muss und wo man trotz trotz der ganzen Methodologie immer noch die zwei oder mehrere Welten, die in der Realität so koexistieren, wo man die zusammenbringen kann und muss. 
Ashley: Das war das war ein sehr interessantes Gespräch für mich. Ich habe da wirklich mitgenommen, dass das Frame Framework oder Safe Frame gibt er wirklich Guidance, wie man agil im Unternehmen oder im Großunternehmen arbeiten. Kann. Und vor allen Dingen das zwei Punkte sind bei mir wirklich im Kopf geblieben. Einmal das Thema Vision, eine gemeinsame Vision auf dem Programm Ebene und nicht mehr aufteilen auf den Themen Ebene und die Früherkennung von Abhängigkeiten bzw die Möglichkeit früh mit anderen Teams zu planen, dass man wirklich insgesamt ein Erfolg hat. Aber der PO wird nicht ersetzt durch Seife, da es immer noch eine Rolle als PO in diesem Umfeld. Das ist eine gute Zusammenfassung. Es ist doch schön für dich. Michelle, das war super. Vielen, vielen herzlichen Dank für das Gespräch. Danke, dass du Zeit für uns gefunden hast. 
Michaela: Vielen Dank für die Einladung. War Spaß und hat Spaß gemacht. 
Ashley: Und ich würde sagen, mal bis die Tage. 
Michaela: Bis die Tage. Danke schön. 
Michaela: Ciao! 
Michaela: Taktsoft Campus Podcast! Der Podcast für Software IT Professionals Im Taktsoft Campus Podcast beschäftigen wir uns mit einem breiten Themenspektrum, um euch zu helfen. Praxis Fragen zu Technologie, aber genauso Fragen zur Umsetzung, Prozessen oder Projektorganisation. Danke, dass ihr dabei wart. Euer Takttsoft Campus Podcast Team.