Wie Du Deine Weihnachtsretrospektive moderieren kannst

Wir teilen mit Dir ein Format, wie wir einmal auf andere Art und Weise unser Jahr reflektieren werden. Du erhältst den genauen Ablauf mit Beispielen erklärt und noch die ein oder andere Sache rund um Retrospektiven als unser kleines Abschlussgeschenk für dieses Jahr. Viel Spaß beim Reinhören.


Buch: The War of Art: Break Through the Blocks and Win Your Inner Creative Battles https://www.amazon.de/War-Art-Through-Creative-Battles/dp/1936891026

 

Der Retromat: https://retromat.org/de/

 

Podcastfolge: „Paar-Retrospektiven – Geheimzutat für gesunde Beziehungen“ https://agilegrowth.de/paar-retrospektiven-geheimzutat-fuer-gesunde-beziehungen/

Der Product Owner verständlich erklärt

Was macht eigentlich ein Product Owner? Wofür braucht es ihn oder sie, und warum ist diese Verantwortlichkeit in vielen Unternehmen falsch besetzt?

Wie wachse ich in dieser Rolle und was macht das Zusammenspiel mit dem Entwicklungsteam wirklich wertvoll?

Jasmine und Kai beleuchten diese spannende Verantwortlichkeit des Scrum Rahmenwerks in der Tiefe und zeigen Wege auf, wie eine Weiterentwicklung aussehen kann.

 

Werde selbst Agile Coach: https://agilegrowth.de/agile-coach-ausbildung-einleitung/

Jasmine

Herzlich willkommen zum Agile Growth Podcast. Ich freue mich total, dass du wieder mit dabei bist. Heute dreht sich alles rund um den Product Owner. Die Product Ownerin, eine unglaublich wichtige Rolle im Scrum Rahmenwerk. Aber was macht denn der oder die überhaupt? Und wozu braucht es den? Was macht der Product Owner oder die Product Owner nicht? Und wie wachse ich überhaupt in diese Rolle rein? All das beleuchten Kai und ich in den nächsten paar Minuten.

Sprecher

Herzlich willkommen zum Agile Growth Podcast, dem Podcast für alle Agile Interessierten mit hilfreichen Ideen und erprobten Werkzeugen, die dich weiterbringen. Von und mit den Two Agilists.

Kai

Herzlich willkommen zum Agile Growth Podcast. Wir sind Jasmine und Kai und wir helfen Menschen dabei, die versprechen, Agiler Vorgehensweisen in der Praxis einzulösen, ohne IT-Wissen vorauszusetzen. Und heute geht es um eine Rolle, die für mich viele Jahre lang irgendwie eher ein Buch mit sieben Siegeln war. Mittlerweile hat sich das Gott sei Dank verändert, denn sie ist unglaublich wichtig, wenn man agil arbeiten möchte. Denn heute geht es um den Product Owner oder die Product Ownerin

Jasmine

Und ja, es ist der Product Owner. Es ist nicht der Project Owner. Da sind wir, glaube ich, schon am ersten Punkt der großen Unterscheidung. Wenn ich jetzt so von meiner Organisation, von einer ganz klassischen Projektorganisation, vielleicht in eine eher Produkt Organisation umdenke, dann reicht es nicht, meine Projekte auf einmal Produkte zu nennen, weil zwischen dem Projekt und dem Produkt gibt es erhebliche Unterschiede. Ein Produkt ist dazu gedacht, langlebig zu sein. Ein Produkt wird anders wahrgenommen, anders klassifiziert. Das heißt, wenn ich einfach meine ganze Projektorganisation nehme und sage Okay, jetzt haben wir überall Project Owners drin und vielleicht noch Scrum Master und ihr seid jetzt halt Scrum Teams. Dann wird das Ganze da nicht funktionieren. Und auch das, was der Projektleiter früher gemacht hat, das ist was anderes als das, was der Product Owner machen wird. Da gibt es sicherlich Überschneidungen. So, und wenn du jetzt als Projektleiter unterwegs warst oder vielleicht auch als Produktmanager unterwegs  warst, dann wird es Überschneidungen geben mit dieser Product Owner Rolle.

Jasmine

Sehr viele sogar. Und du wirst ganz viele Fähigkeiten, die du schon pre agil genutzt hast, weiter nutzen. Aber diese Product Owner Rolle für uns ist ein Umdenken und wir hören halt diesen Project Owner bei vielen unseren Kunden immer noch und da wissen wir schon Aha, da müssen wir vielleicht noch mal rangehen. Also wir würden gerne anfangen mit was macht denn so ein Product Owner überhaupt?

Kai

Ja, der owned das Produkt, also das gehört demjenigen oder derjenigen. Und das bedeutet auch, so was wie eine Vision überhaupt mal zu haben. Was wollen wir denn hier materialisieren? Also was gibt es im Moment nur in unseren Köpfen und Vorstellungen? Und was soll denn mal als Produkt entstehen hier? Und dazu braucht es viel Dialoge mit Leuten, die irgendwie Anforderungen haben an dieses Produkt, dann an die Stakeholder, um das rauszufinden, um das mit zu gestalten, was denn da drin sein soll. Und es braucht natürlich Leute, die das dann umsetzen, mit denen Produkt oder auch ganz stark zusammenarbeitet.

Jasmine

Das heißt in Kurz Diese Product Owner Rolle ist eine sehr, sehr kommunikative Rolle. Also wenn du stark in der Kommunikation bist und es dir auch Spaß macht, mit Leuten zu interagieren, Visionen zu spinnen, ich würde schon fast sagen zu träumen, weil daraus entstehen oft ganz, ganz gute Produktideen, dann kann das deine Rolle sein. Und wir tun das mit unterschiedlichsten Zielgruppen. Also idealerweise mit den Stakeholdern, mit deinen Endusern, die das Produkt dann auch wirklich benutzen. Das können andere Gruppen sein, sind in den meisten Fällen andere Gruppen mit den Geldgebern, aber auch mit den Leuten, die das Ganze umsetzen werden. Also deine Entwickler und Entwicklerinnen.

Kai

Und ich finde immer so das Bild von einem Start up Unternehmen oder einer Start up Unternehmerin ganz gut. Da gibt es meistens so einen Vor Träumer, der hat eine Idee davon, was dann in der Welt existieren soll und der besorgt sich eben auch die Mittel dazu, das tun zu können und stellt sich ein Team zusammen, um das dann zu erreichen, dass es meistens jemand, der auch gut kommunizieren kann, also der auch pitchen kann für diese Idee und der überzeugen kann für diese Idee. Der ist also kommunikativ stark und auch oft entscheidungsfreudig unterwegs.

Jasmine

Und Kai hat gerade was Gutes erwähnt, der besorgt sich auch, oder die besorgt sich die Mittel, um diese Idee umzusetzen. Ein guter, befreundeter Trainer von uns sagt immer: Der Product Owner hat der Arsch in der Hose. Schnelle Entscheidungen und Geld in der Tasche. Und ich finde, mit diesem Spruch reinzugehen in viele Organisationen trennt schon die Spreu vom Weizen. Viele Product Owner, die wir wahrnehmen, sind Ticket Schubser. Also Leute, die Anforderungen aufschreiben dürfen, aber nicht drüber entscheiden und die irgendwie ins Team rein schubsen dürfen.

Kai

Klingt jetzt ein bisschen böse. Auch das kann in einem Scrum Team sehr viel Wert haben, wenn Menschen sind, die eine tiefe Requirements Engineering Fähigkeit besitzen, eine tiefe Business Analysefähigkeit. Nur dass wir dieses Beispiel aus dem Blickwinkel von Scrum Rahmenwerk als Teammitglieder sehen würden, weil der Product Owner eben entsprechend dieser strategische Visionär ist, der Entscheidungsberechtigt und befugt ist. Eine gute Lackmustest Frage, die man sich stellen kann, ist auch, ob ich der Product Owner bin. Kann ich eine wichtige Product Funktionalität streichen? Kann ich das Produkt vielleicht sogar einstampfen? Daran kann man das oft festmachen. Und was wir sehen in Organisation ist, dass diese Rolle unglaublich oft falsch besetzt ist. Da ist dies nicht mit der richtigen Entscheidungsbefugnis versehen, das heißt meistens der Product Owner Ebene zu tief in den Teams, also auch in der Unternehmens Hierarchie. Wenn das ein klassisches Unternehmen ist, bräuchte man jemanden eine Stufe höher in der Hierarchie. Oft heißen die Produktmanager oder Programmmanager oder so was. Das sind eigentlich häufig die, die dann eine Befugnis haben. Die Frage kannst du dich selber stellen.

Kai

Das heißt hier der Product Owner, dem soll das Produkt wirklich gehören? Der ist also nicht nur ein Verwaltender Aspekt,  zu dem irgendwas runter delegiert worden ist, sondern dem gehört das Produkt. Und das ist oft schon eine radikale Veränderung, gerade wenn ich aus dem klassischen Umfeld komme.

Jasmine

Und da gibt es natürlich dann zwei Arten, wie ich mit dieser Dysfunktion umgehen kann, wenn dem Product Owner das Produkt nicht gehört. Also entweder kann ich den wahren Product Owner suchen und meinen Product Owner zum Teammitglied machen, weil diese Business Requirements Fähigkeiten, die brauche ich als Team auch und die sind unglaublich wertvoll. Aber ich brauche doch jemand, der schnell Entscheidungen treffen darf und kann und tut. Oder ich gucke dass mein Product Owner, meine Product Ownerin, die ich gerade habe, dass ich die befähigen kann. Das heißt, ich starte. Ich fange an, mit der Organisation zu arbeiten und zu gucken: Ach okay, wir haben Programm Management drüber. Was brauchen die denn, damit der Product Owner, die Product Ownerin, die wir haben, schnelle Entscheidungen treffen kann und damit das Geld in der Tasche ist und der Arsch in der Hose. Also entweder kann ich’s aufbauen oder ich kann gucken. Wir suchen den richtigen oder die richtige Product Ownerin.

Kai

Und diese Entscheidungsfähigkeit ist eine Haupt-Dienstleistung vom Product Owner gegenüber seinem Entwicklungsteam und gegenüber den Stakeholdern. Denn vielleicht kennst du das auch, wenn er so einen Kreis mal hast, wo eine Entscheidung dann vorgelegt wird. Der trifft sich alle Nase lang. Dann dauern diese Entscheidungen unglaublich lange. Und das ist uns im agilen Arbeiten nicht effizient genug. Wir wollen eine Entscheidung zügig haben, und es ist ja schon schwierig genug, sich als einen Menschen Kopf zu machen. Da will ich nicht noch mehrere Menschen beteiligen. Deswegen gibt es da eine ganz klare einzelne Verantwortung hier an dieser Stelle, und das ist dann die Dienstleistung, schnell zu entscheiden, auch in der Unsicherheit. Und das ist natürlich da, wo agiles Arbeiten vorwiegend genutzt wird, nicht da, wo ich noch mit weiterer Analyse total gut verstehen kann, was der Masterplan ist. Da brauche ich nicht agil arbeiten. Es ist ja eher wie Autofahren im Nebel. Da wo ich viel Überraschungen habe, da habe ich Unwägbarkeiten, manch einer benutzt diesen VUCA-Begriff ich. Mag den nicht so unglaublich gern, der ist so plattgetreten mittlerweile, aber

Kai

auch da ist natürlich was dran. Eine Welt, die volatil ist, die unsicher ist, die komplex ist und die Doppeldeutigkeiten hat und sich durch diesen Nebel da durch zu fräsen und einfach trotzdem Entscheidungen zu treffen ist ein Produkt Owner Job.

Jasmine

Und da sind wir schon an der Frage Warum braucht es denn eigentlich Product Owner? Weil wir eben in dieser hochkomplexen Welt sind, wo es nicht die richtige Entscheidung gibt, sondern es gibt eine unzählige Anzahl an Möglichkeiten und wir müssen uns ganz oft sehr schnell entscheiden, einfach mal was auszuprobieren  damit wir lernen. Und das ist ja das ganze Ziel von Scrum, es ist ein Lern Framework. Wir wollen lernen, damit wir unser Produkt möglichst schnell und gut an den Markt bringen. Das heißt, wir wollen sehr viele Fehler möglichst früh machen. Wir wollen sehr schnell lernen und da braucht es auch schnelle Entscheidungen. Und da brauche ich einen Product Owner, der die Entscheidung trifft und dann auch dahinter steht. Oder eine Product Ownerin. Und wir waren jetzt gerade in mehreren Projekten drin, wo das nicht der Fall war. Und das ist frustrierend, sowohl für die Product Owner wie auch für die Entwickler und Entwicklerinnen, aber auch für die gesamte Organisation. Also wenn es dann immer so ja, wenn aber doch Entscheidungen gibt, und man rechts, links, aber auch geradeaus fahren müsste, dann macht das das Endprodukt auch einfach unglaublich komplex, viel komplexer als es sein müsste.

Jasmine

Es braucht viel mehr Entwicklungszeit, das verschwendet unglaublich viele Ressourcen. Und am Ende haben wir eine eierlegende Wollmilchsau, die weder Eier legt, noch Milch gibt, noch Wolle gibt.

Kai

Und dafür braucht unser Produkt ohne Fähigkeiten zum Customer Discovery. Also der muss wirklich den Kunden immer wieder entdecken. Auch das ist eher ein kontinuierlicher Prozess. Also was einmaliges, ein gutes Ohr am Markt haben verschiedene Möglichkeiten über Daten getrieben, über Customer Interviews irgendwie rausfinden. Was brauchten denn die Leute als nächstes und wo darf ich meinen Fokus drauf legen, damit dieses Ding ein Erfolg wird? Und dass das eine ziemlich schwierige Herausforderung ist, sieht man auch an den Fehlschlag Quoten von Start ups. Das scheitert natürlich nicht immer nur an dem Produkt, das nicht zum Markt passt. Das scheitert auch mal an anderen Dingen, dass es menschelt oder was auch immer. Aber es ist eben auch ein Faktor, dass man dann am Markt vorbei entwickelt. Und um genau diese Schleife immer wieder zu schließen – Jasmine hat es Lernframework genannt Scrum haben wir unser Sprint Review, wo wir dann immer wieder auch, ja potenziell freundliche Nutzer treffen oder auch Stakeholder, mit denen wir dann schnell rausfinden, ob das, was wir gebaut haben, irgendwie das ist, was der Markt auch braucht.

Jasmine

Also ein guter Product Owner für mich oder eine gute Product Ownerin, die unterhält sich kontinuierlich mit End Nutzern. Kontinuierlich. Und das sind nicht drei Interviews, die ich mal mache im Monat. Das sind, das sind eher 20 oder 30, wo ich mit einem Endnutzer mich unterhalte und frage „Hey! Hast du das Produkt benutzt? Was würdest du dir noch wünschen? Wo funktioniert’s? Wo erleichtert dieses Produkt dein Leben? Wo noch nicht?“ Und so weiter. Also ganz, ganz viel von dieser Discovery macht der Product Owner die Product Ownerin, um wieder neue Ideen zu haben, neue Visionen zu haben, wo es weitergehen könnte und die auch wieder den Stakeholdern, Auftraggebern, den Geldgebern pitchen zu können, aber auch das Team motivieren zu können. Also da zu sagen Hey, ich habe mit den Leuten gesprochen, eine signifikante Zielgruppe von uns vermisst das und das, weil die möchten das und das tun damit. Und das ist sehr viel motivierender für ein Entwicklungsteam zu wissen, warum sie Dinge tun, wie, das das Leben von anderen Menschen erleichtern würde.

Jasmine

Was für ein Impact, das Feature oder die Feature Gruppe, die man gerade baut für den Endnutzer hat es so viel erstens motivierender, aber zweitens beeinflusst auch die Lösung enorm, wenn ich ein gutes Verständnis darüber habe, was der Nutzer denn tun möchte, was er vermisst. Manchmal kann der Nutzer ja nicht sagen, was er tun möchte oder sagt sehr genau, was er tun möchte. Aber es ist überhaupt nicht das, was er will. Aber wenn ich ein Verständnis dafür habe, wie arbeitet der denn damit? Oder die? Und was vermisst der? Dann wird die Lösung einfach auch erheblich beeinflusst und sehr oft vereinfacht.

Kai

Und vielleicht hast du schon mal gehört Verkaufen zum Beispiel ist ein emotionaler Prozess. Keiner der durch Fakten funktioniert. Wir Menschen kaufen was, weil wir es irgendwie geil finden. Und dann sucht unsere Ratio Gründe dafür, warum wir das dann auch wirklich tun. Also ganz viel unserer Verkaufsprozess und Kaufprozess passieren auf so einer Bauch Ebene, hätte ich fast gesagt. Und als Produkt verkauft man auch unglaublich oft Dinge, nämlich die Vision gegenüber dem Team und Features gegenüber dem Team und die Vision gegenüber Kunden und Stakeholdern. Und so weiter. Und weil das eben so ein emotionaler Prozess ist, geht es da darum, die zusammenzubringen, also das Entwicklungsteam mit den Anwendern zusammenzubringen. Weil da passiert die Emotions-Übertragung zwischen diesen zwei Welten. Und wenn ich das immer abstrahieren und weg halte von meinem Team, dann verpasse ich eine unglaublich starke motivatorische Qualität, die ich sonst haben könnte. Insofern ist der Product Owner auch so eine Art Meddler, hätte ich gesagt. Wie sagt man auf Deutsch? Mittelmann, ne Strippenzieher gefällt  mir fast noch besser.

Kai

Also ein Strippenzieher, der das zusammenbringt, die Leute, die das Produkt brauchen und die, die es bauen.

Jasmine

Und vielleicht bist du jetzt am Punkt und sagst Ah ja, gut und recht schön, dass ihr mir das sagt jasmine und Kai. Aber mein Team hat überhaupt keinen Bock darauf. Die interessiert das gar nicht. Das kann sein. Das habe ich schon öfters erlebt, dass im ersten Moment Teams das gar nicht interessiert.

Kai

Die wollen coden, die wollen programmieren, die wollen in Ruhe gelassen werden und hinter ihren Rechnern sein. Ich bin jetzt voll im Informatiker Klischeebild Ich darf das ja, weil ich Informatiker bin. Ich mache das ja auch ganz gerne.

Jasmine

Ich wollt gerade sagen, mir geht es ja auch so.

Jasmine

Bleib mir weg mit deinem Feedback. Ich will jetzt einfach meine Idee umsetzen.

Kai

Und das ist aber dann auch nur die halbe Wahrheit, weil ich natürlich auch geile Lösungen bauen möchte. Und wenn ich natürlich merke, dass ich da was entwickle, was dann nachher keiner braucht, frustriert mich das auch. Unglaublich. Und das ist auch so meine Wahrnehmung. Wenn man dann mal anfängt, weiß ich nicht, in einem Microsoft Teams Kanal dann Anwender mit dem Entwicklungsteam zusammenzubringen und dann schreiben die Anwender irgendwas, was sie stört oder wo sie Probleme haben. Dann geht ganz oft dann bei den Ingenieuren auch das Herz auf oder der Lösungsmechanismus. Die Leute stürzen sich da drauf. Wie können sie das besser machen? Vielleicht auch, weil sie sich in der Ehre gekränkt von was auch immer, das im Einzelnen sein mag. Aber daraus entsteht dann was, von wem man eigentlich vorher dachte. Das braucht gar nicht und es will auch niemand. Passiert es trotzdem.

Jasmine

Und. Es kann noch andere Gründe haben, ganz viele andere Gründe. Also woran werden die Entwicklungsteam gemessen, wenn die an Zeilen Code gemessen werden oder irgendwann mal gemessen wurden? Das muss gar nicht mehr so sein. Das kann vor zehn Jahren so gewesen sein. Aber das ist eingebrannt in die Firmen DNA. Das ist, in ORSC würde man sagen. Das ist eine Ghost Voice oder eine Ghost Role, die ist immer noch da. Dann empfinden die das natürlich als Zeitverschwendung, mit einem Kunden zu reden, weil daran werden sie ja nicht gemessen. Also Sie werden nicht für gute Zeilen Code gemessen, sondern für viele Zeilen code zum Beispiel. Kann sein, es kann aber auch einfach eine Angst sein, weil wir sind ja eh schon ausgelastet. Ganz ehrlich, wir sind ausgeplant bis 2023. Ist ja schön, wenn mir jetzt jemand noch Feedback gibt. Aber wann soll ich denn das noch tun? Ja, wenn ich kein Slack drin habe und eben mein Product Owner oder meine Product Owner keine Entscheidungen treffen kann und auch der Kurs unseres Backlogs nicht verändern kann, dann macht dieses Feedback nicht viel Sinn, weil dann geht es irgendwie Back of Backlog, irgendwo ist es dann drin, aber da hätte ich mir sparen können

Jasmine

Mit dem Kunden zu reden, das frustriert ja nur alle Seiten.

Kai

So, das ist so eine Art Entrepreneur, haben wir gesagt. In größeren Umfeldern kann man sich das vorstellen und das klingt wahrscheinlich alles total logisch. Wird das diese Rolle beschreiben? Und die Chance ist hoch, dass wenn du gerade zuhörst, dass du denkst, aber bei uns ist das anders. Und das geht uns natürlich auch so Ich würde sagen, in 78,35 % der Fälle ist der Product Owner, den wir antreffen, im agilen Umfeld, der das irgendwo auf seiner Visitenkarte draufstehen hat kein wirklicher Product Owner, sondern eben, wie eben beschrieben, ein Business Analyst, Requirements Engineer, jemand, der etwas mittelbar verwaltet. Was dazukommt ohne diese emotionale Visions Verkaufs Qualität und ohne die Entscheidungsfreude und ohne das Vorangehen. Das heißt, diese Leute findet man auch gar nicht so leicht im Unternehmen. Und das ist dann natürlich auch so ein Ding, wo man als Scrum Master rangeht und guckt, okay, der Mensch, der da steht, will der sich weiterentwickeln, traut er sich das selber zu, dem mal die Rolle aufzuzeigen und Product Owner zu begleiten oder dann eben auch irgendwann zu schauen

Kai

Okay, wenn das so nicht funktioniert, welche anderen Möglichkeiten haben wir?

Jasmine

Und wenn wir jetzt so gucken, welche Charakteristiken würden wir sagen, braucht ein Product Owner ich? Ich würde mal sagen. Es muss ein visionärer Mensch sein, ein Mensch, der gerne in die Zukunft denkt und das dann mit der Gegenwart verbindet. Für mich sollte ein Product Owner oder eine Product Owner auch ein Mensch sein, der gerne Risiken eingeht. Natürlich kalkulierbare Risiken. Aber wenn, wenn du ein sehr Angst behafteter Mensch bist, sehr viel Sicherheit brauchst, dann kann das vielleicht bei gewissen Produkten wie ich weiß nicht, Medizin Tech Bereich oder so okay sein, aber auch da nicht.

Kai

Na ich glaube, da muss man auch ganz schön vordenken, je nachdem, was man da kreieren will.

Jasmine

Eigentlich schon.

Kai

Also da würde ich, glaube ich, eher die ängstlichen oder die sicherheits orientierten Menschen als Teil des Entwicklungsteams sehen, um da entsprechend dafür Sorge zu tragen, dass dann auch entsprechend alle Vorschriften usw eingehalten sind und dass man dann noch mal die extra Meile in der Qualitätssicherung geht. Aber ich glaube schon beim Vordenker, das ist eher, das ist schon diese Visions Qualität, die da auch ganz viel reinkommt.

Jasmine

Genau. Ein Product Owner ist oft auch nicht der Mensch der eine Vision von irgendwo braucht. Also der, sagt er, das muss jetzt das Unternehmen sagen, wo ich hingehen soll. So ein Product Owner ist wirklich ganz oft so auch ein bisschen wie der Scrum Master, so der Unternehmens Anarchist, der sagt ja, okay, gib eine Unternehmens Vision. Ich habe eine geile Idee, die wird uns vorantreiben als Unternehmen. Also machen wir das jetzt einfach mal.

Kai

Und da drin ist glaube ich, der Product Owner auch mehr Politiker als Ingenieur, weil es ja da auch darum geht, dann entsprechend politische Entscheidungen durchzusetzen und den Buy In zu gewinnen. Ich glaube heute haben wir ein Bullshit Bingo in der Folge.

Jasmine

Sehr Denglisch heute bei uns

Kai

Um die Unterstützung der Leute zu gewinnen, die dann auch funktionale Wünsche haben an das Produkt und die halt eben auch den Budgetrahmen mit beeinflussen. Und so weiter. Also da eher ein strategischer Politiker als ein Ingenieur. Und ganz schwierig ist es oft für sehr technische Menschen, die dann in die Product Owner Rolle reinkommen. Wieso? Weil die oft im Lösungs Raum unterwegs sind. Und ich habe gestern einen Joke auf LinkedIn hingeschrieben. Was macht der Product Owner im Lösungs Raum?

Jasmine

Sich zurückziehen.

Kai

Ist n Flachwitz, ne? Genau. Der Lösungsraum gehört den Entwicklern, also den Produktentwicklern im Scrum Rahmenwerk. Und die dürfen sich die Lösung dafür überlegen. Und dem Product Owner gehört der Problem Raum. Den teilte sich mit den Kunden und den Anwendern zusammen. Also was sind die Probleme, die gelöst werden sollen? Und die sammelt er zusammen und bringt in der Reihenfolge der Wichtigkeit und Dringlichkeit der Probleme. Und da merkt man schon so, dass es an der Stelle ja eher ein gutes Gespür dafür braucht, was jetzt der Markt und die Leute brauchen und das auch noch verkaufen zu können. Warum man diese Strecke lang geht? Stichwort Politiker als das zu analysieren im Detail.

Jasmine

Und da sind wir vielleicht schon am Punkt von was macht der Product Owner denn alles nicht? Ganz oft höre ich von den Entwickler und Entwicklerinnen Ja, wir brauchen Product Owner, der uns jetzt diese Tickets oder diese, egal was er nutzt, also ob ihr jetzt ein Miro Board nutzt mit euren Zettelchen drauf oder Jira oder was auch immer, der uns das genau spezifiziert. Das würde in meinen Augen ein Product Owner nicht machen. Das heißt nicht, dass er kein Jira Ticket schreibt oder sie. Natürlich tun die das aber eher im Sinn von ein Versprechen auf ein Gespräch. Also ob ich jetzt dieses User Story Format da verwende, „als hmhmhm möchte ich hmhmhm damit hmhmhm“ schreib ich das mal so auf und im Hinterkopf habe ich ja natürlich als Nutzer. Ja, welcher Nutzer? Ist es die Marie, die 22 ist und super viel mit dem Computer macht und einfach Digital Native sowieso, drag and drop und alles geht. Oder ist es Tante Erna oder oder? Also diese Gedanken macht sich der Product Owner und die Product Ownerin Zielgruppe. Auf welche spezialisieren wir uns gerade?

Jasmine

Welche gucken wir an? Für wen ist dieses Feature? Wer will was damit tun, aber ausspezifizieren, wie denn jetzt genau die Lösung auszusehen hat. Das machen Product Owner nicht. Das machen wir zusammen mit den Entwickler und mit den Entwicklerinnen im Refinement. Und das Refinement ist dadurch meistens nicht ein zwei Stunden Termin, den ich azyklisch zum Sprint Wechsel habe, weil das reicht ja gar nicht, sondern es ist vielleicht ein zwei Stunden Termin azyklisch zum Sprint Wechsel, wo ich die Sachen mal durchgehe, wo wir dann aber auch gucken, wer unterhält sich denn jetzt weiter über diese Anforderung, wer spezifiziert da aus, wer schreibt da mögliche Lösungsansätze schon mal rein? Wer interagiert von unserem Team miteinander und vielleicht sogar mit dem Endnutzer? Um das sehr spezifisch hinzubekommen. Das muss nicht unbedingt ein Product Owner oder eine Product Ownerin sein. Und da haben wir schon so das Wachstumspotenzial. Erstens vom Product Owner, von der Product Ownerin, rein aus diesem raus zu gehen, aber auch vom Team. Weil die Entwickler und die Entwicklerinnen sind das oft ja auch nicht gewohnt, das zu tun.

Kai

Die sind ja fürs Programmieren angestellt worden. Steht auch im Arbeitsvertrag. Übrigens

Jasmine

Genau.

Jasmine

Also wenn die anfangen das tun zu dürfen und sollen, dann darf ich als Scrum Master oder Scrum Masterin ganz viel unterstützen, damit das Team auch dahin kommt, das tun zu können. Und vielleicht ist das dann stückchenweise. Oder ich habe eben diese Business Analysten Fähigkeit im Team drin, die mich dabei unterstützen. Aber auch da wieder immer mit den Entwicklerinnen zusammen.

Kai

Also wenn du jetzt selber Product Owner bist und merkst: Oh, das weicht aber bei mir ein bisschen ab davon, was wir beide hier erzählen. Die gute Nachricht ist Jasmin und ich sind beide sehr große Freunde vom Growth Mindset. Wir glauben daran, dass sich Menschen entwickeln können, wenn sie es wollen. Wenn du es bei dir feststellst und du dich in so eine Richtung entwickeln willst.

Jasmine

Und auch Organisationen können sich entwickeln, wenn sie wollen.

Kai

Dann ist die Chance hoch, dass du das auch kannst, in diese Richtung zu gehen. Auf der anderen Seite habe ich jetzt auch öfters erlebt, dass Leute auf dieser Reise feststellen Vielleicht ist das doch gar nicht so meine Präferenz und das, was ich so unglaublich gerne tue. Und da muss man halt schauen Was heißt das? Ich habe auch Product Owner erlebt, die dann entsprechend in das Team, in die Entwicklungsteam Rolle Entwickler oder und Entwicklerinnerolle. Hach, Scrum Guide Umbenennungen, anstrengend. Also die jetzt im Entwicklungsteam mit drin sind und da entsprechend von innen heraus die Details des Produkts mitgestalten, das denen viel besser gefällt. Und da glaube ich ehrlich zu sich selbst zu sein ist auch wichtig. Also zum einen Potenzial in sich zu spüren, wo könnte es hingehen und wohin will ich mich entwickeln? Und ein guter Scrum Master darf sich darin auch gerne begleiten. Da gibt es ja auch einiges an Methodik und Handwerkszeug, was man als Product Owner kennen und lernen darf. Also ich. Und wenn ich so zugebe ich habe Scrum Master 2007 gemacht.

Kai

Ich habe eigentlich erst 2014 angefangen, mich intensiv mit der Product Owner Rolle auseinanderzusetzen. Also ich habe eine ganze Weile so als einäugiger Scrum Master eigentlich so die eine Perspektive verfolgt. Und doch muss ich sagen, in der Produktentwicklung gibt es auch echt eine ganze Menge an hilfreichen Ideen und Modellen, die man sich rausziehen darf, wenn man Product Owner ist. Und da darf ein Scrum Master es auch gerne begleiten.

Jasmine

Genau. Und neben diesen hilfreichen Ideen und Modellen, die eher dann meistens Produkt lastig sind, darf ich mir ja noch ein bissl was an Marketing aneignen, weil nichts anderes ist, eine Vision rüberzubringen. Es ist Marketing. Also ein bisschen was an Vermarktung darf ich mir auch noch aneignen und ein bisschen was an Kommunikation darf ich mir auch noch aneignen. Und vielleicht fällt dir das eine oder andere schon extrem leicht und vielleicht das eine oder andere nicht. Und dann hilft es, mit einem Scrum Master zusammenzuarbeiten oder auch mit einem Coach zusammenzuarbeiten. Sagen: Hey, ich möchte meine Product Owner Fähigkeiten hier stärken. Etwas, was mir noch auffällt ist Was machen Product Owner nicht habe ich jetzt schon gesagt, sondern Sachen ganz, ganz spezifisch aus detaillieren. In meinen Augen mache ich das mit dem Team zusammen. Ich mache das nicht alleine. Oft wird ja gesagt, ein Product Owner sagt ganz oft Nein. Ich würde sagen, das stimmt so halb. Wahrscheinlich werde ich immer mehr Anforderungen haben an meinem Produkt, als ich umsetzen kann. Deswegen sage ich Nein als Product Owner.

Jasmine

Ja, das stimmt. Aber mehr als das Neinsagen sagt der Product Owner auch mit ganzem Herzen ja. Und das Ja bedingt, das Nein oder das Nein bedingt das Ja. Das heißt der Product Owner oder die Product Ownerin, die dürfen sehr standfest in ihren Entscheidungen sein, natürlich da auch reflektiert da drin. Wenn es eine falsche Entscheidung war, dann muss man viel sortieren. Alles fein, aber dem Team den Rücken freihalten, indem ich eben ein ganz klares Nein und ein ganz klares Ja äußere. Das ist etwas, was ein Product Owner macht. Und ein Product Owner sagt durchaus auch Ja zu ganz vielen Dingen. Wir wollen ja das Produkt vorantreiben für unseren Nutzer.

Kai

Wenn ich jetzt wachsen möchte als Product Owner in meiner Verantwortlichkeit, dann ist die eine Idee. Sprich mal deinen Scrum Master an, ob du mit dem spezifisch an Product Ownership Themen arbeiten kannst. Ich habe vor kurzem noch mal das Buch von Roman Pichler durchgelesen. Agiles Produktmanagement mit Scrum. Ich finde das ist ein gutes Überblicks Werk. Da bekommt man noch mal etliche Impulse, auch ein paar Werkzeuge vom Roman. Bei dem habe ich ja auch damals meine Scrum Master Ausbildung gemacht und ich finde, er hat sich da ganz gut reingefuchst. Da kriegt man auf jeden Fall ein paar gute Ideen und auch noch mal eine Haltung und auch so was eigentlich Sachen, die nicht so gut funktionieren. Also sich da einfach mal ein bisschen einlesen, finde ich hilfreich. Dann ein paar Videos von Jeff Patton finde ich unglaublich gut. Verlinken wir auch mal eins hier in den Shownotes untendrunter. Im Umgang mit Dialog basierter Produktentwicklung würde ich das mal nennen. Das ist eine sehr tolle Quelle.

Jasmine

Was ich auch immer ganz gut finde ist Melissa Perry, glaube ich. Nennt sich die.

Kai

Ähm raus aus der Feature Falle.

Jasmine

Genau. Gibt es mittlerweile auf Deutsch. Wir haben es auch auf Englisch. Spannend. Es gibts mittlerweile auch auf Deutsch. Also ob du jetzt Product Owner bist oder Scrum Master Ich finde diese Bücher und ein bisschen was von Jeff Patton zu sehen lohnt sich für beide Rollen immens. Es kann nämlich auch sein, wenn du Product Owner bist und mit deinem Scrum Master anfängst zu sprechen, dass du merkst, dass dein Scrum Master deine Scrum Masterin nicht so viel Product Ownership Erfahrung hat und dir da nicht so richtig weiterhelfen kann. Dann könnt ihr eine Lerngemeinschaft bilden und euch beide gemeinsam da weiterentwickeln und gucken, wie ihr das Gelernte anwenden könnt in eurem Produkt. Oder eben wo ich ja immer ein großer großer Fan von bin. Such dir einen Mentor. Die Produktwerker haben auch einen ganz tollen Podcast. Zum Beispiel. Es gibt noch andere Menschen in der deutschen Community, die sich eher auf Produkt spezialisieren. Aber such dir da einen Mentor, mit dem du dich ab und zu unterhalten kannst. Ich hatte das am Anfang von meiner Scrum Master Karriere habe ich mit einem Mentor zusammengearbeitet.

Jasmine

Freitags. Es hätte jede Woche sein sollen. Es hat nicht jede Woche stattgefunden, aber wir haben uns unterhalten. Er hat mir immer wieder Tipps und Tricks mit an die Hand gegeben, was ich weiter ausprobieren könnte und so wurde ich zu einem besseren Scrum Master.

Kai

Also da gibt es einen guten Fundus an Methoden, an Haltungen mit denen man rangehen kann. Ich finde auch viel so in dieser ganzen Entrepreneurship Szene kann man sich was abgucken. So das was so Alex Osterwalder da mit Business Model Generation treibt. Da sind viele Impulse drin. Und wenn man so ein bisschen in Richtung Silicon Valley guckt, wie die über Produkte nachdenken, die haben da ja oft eine ganz andere Herangehensweise. Stichwort Fehlerkultur oder so Minimal Viable Product, wie hat der Ried Hoffmann das mal gesagt der ehemalige LinkedIn CTO, „If you aren’t embarassed by your first Product Release then you releases too late.“ Also wenn du nicht so ein bisschen angewidert bist von deiner ersten Produkt Auslieferung, hast du zu spät ausgeliefert. Nun, was ja sehr irgendwie aus unserem deutschen oder auch dem Schweizer dem Qualitäts denken irgendwie widerstrebt erst mal auch als eine kulturelle Komponente. Aber so dieser diese ganze Gedankennukleus, das hilft schon dabei, sich da mal darauf einzulassen, weil man eben mit Agilem Produktmanagement doch anders unterwegs ist, als wenn man jetzt aus dem klassischen Projektmanagement kommt und dann eine Product Owner Rolle übernimmt.

Kai

Da ist also schon auch eine gedanklich andere Haltung dahinter. Und da hilft einem natürlich auch wieder das Agile Manifest, Folge Nummer vier in unserem Podcast haben wir mal drüber gesprochen. Ich glaube, es war vier. Und da auch mal reinzuhören. Was ist die Haltung und zum Beispiel die Kunst, die Menge nicht getaner Arbeit zu maximieren ist essenziell. Also wir wollen auf Outcome und nicht auf Output optimieren. Wir wollen nicht noch mehr Output, sondern wir wollen halt einen Impact damit, wollen einen Outcome haben, Dinge die dabei rauskommen. Da fällt mir immer wieder ein wie die Southpark Szene von den Gnomen die die Unterwäsche sammeln irgendwie hier, drei Schritte Geschäftsplan Phase eins Unterhosen sammeln Phase zwei hmm, keine Ahnung. Phase drei Profit und so Gewinne machen. Und oft ist so diese Verknüpfung von wir machen noch ne Story mehr. Wir machen noch irgendwie einen Blogeintrag mehr also Stichwort mehr Unterhosen hinzu und und wie hilft uns das jetzt irgendwie geschäftlich weiter? Macht da draußen irgendwie glücklich? Hat das irgendeine Wirkung? Das ist total unbeantwortet. Und diese Lücke zu schließen Phase zwei ist Product Owner Job.

Jasmine

Genau. Also wenn ich jetzt von diesem klassischen Projektmanager, der in Time in Budget in Scope abliefern möchte, wegkomme, ähm, dann streiche ich meinen Scope weg. Scope Gut und recht. Aber das, was ich ganz am Anfang von einem Projekt oder von der Produktentwicklung als Scope definiert habe, ist zu 80 % fürs Klo. Weil das ist ja der dümmste Moment, wo ich anfangen kann. Dazwischen lerne ich ja ganz viel. Also wie bescheuert ist es denn, meine Metrik drauf anzusetzen, in nem Scope zu liefern, den ich mir an dem dümmsten Moment gewählt habe. Das ist, als würde ich einen Erstklässler fragen Was willst du mal werden? Und er sagt Arzt. Und dann sage ich ihm am Ende seines Studiums: Jetzt hast du aber voll gefehlt. Du bist Chemiker geworden, nicht Arzt.

Kai

Und und da fragen sie natürlich Warum machen wir Menschen das? Nicht weil wir  nicht mehr alle an der Waffel haben. Nein, weil das System das oft begünstigt, dass wir so Sachen tun. Zum Beispiel, weil man gelernt hat aus der Vergangenheit oder weil man Projekt hat, aber so aufgesetzt ist, dass wenn ich nicht am Anfang alles rein kippe, ich nachher keine Chance mehr habe, diese Anforderung noch einzubringen, weil es eben kein dynamisches Backlog gibt, sondern weil ich so vorgegangen bin bisher und das gelernt habe, dass wenn ich am Anfang nicht alles reinkippe, was ich mal brauchen könnte, es dann nicht stattfindet. Und ja, das ist natürlich ein ganz anderes Spiel, was wir da spielen. Deswegen geht Scrum Guide drauf die gültigen Spielregeln für dieses Scrum Spiel, weil es eben eine andere Art der kollaborativen Produktentwicklung ist, die völlig anders funktioniert.

Jasmine

Genau in Time drehen wir auch um. Wir liefern einfach am Ende von jedem Sprint. Wir liefern immer in time, am Ende von jedem Sprint. Und wenn wir das nicht tun, dann kommen wir zu einem ganz wichtigen Punkt, der in unserem Podcast abrundet. Dann kollaborieren wir als Product Owner und als Entwickler und Entwicklerinnen mit unseren Scrum Master zusammen, um zu lernen, wie wir am Ende von jedem Sprint liefern und in Budget. Ja, das ist auch ziemlich einfach zu berechnen. Ein Sprint kostet x Kohle und da kann ich irgendwann mal weiß ich, wie viel ich da ungefähr umsetze. Und dann bin ich auch kontinuierlich in Budget und ich muss halt das Gespräch mit meinen Stakeholdern und Geldgebern führen. Ist es euch das wert oder nicht? Und das Gespräch darf ich vielleicht auch mal mit meinen Entwicklern und Entwicklerinnen führen, wenn ich sage ein Sprint kostet uns 70.000? Du sagst mir, wir wollen hier ein Update machen, dann irgendwas und hier das und das und der Kunde sieht gar nichts davon. Sind die 70.000 dann wirklich gut investiert?

Jasmine

Das kann ja sein, aber es kann auch nein sein. Meine Erfahrung wenn ich diese Budget Diskussion auch mal in das Team nehme, mit den Entwicklern, mit den Entwicklerinnen diskutiere, dann gibt es auf einmal ganz andere Lösungen, weil die Leute ein Bewusstsein dafür bekommen. Wie viel kostet denn das Ganze hier überhaupt? Und es liegt nicht nur an dieser einen Person, die Druck auf andere Personen ausüben muss, damit wir irgendwie im Budget bleiben. Und wenn das jetzt alles ganz viel war und du sagst Hey, an der Stelle sind wir als Organisation nicht, an der Stelle sind wir als Team nicht. Mein Team kann das noch gar nicht so ausspezifizieren etc.. Dann sind wir an dem Punkt von Ja. Da spielt der Scrum Master eine ganz wichtige Rolle rein. Also. Ich habe Teams erlebt, wo der Product Owner und der Scrum Master oder die Product Ownerinnen und der Scrum Masterinnen, sich nicht unterhalten während dem Sprint. Das ist komisch. Weil grundsätzlich stecken die ja die Rahmenbedingungen rund um das System, das ein Produkt baut, und so was wie Teamentwicklung etcetera.

Jasmine

Das gestalten wir gemeinsam aus einer Product Owner Sicht und aus einer Scrum Master Sicht. Das ist wie Ying und Yang, das bedingt sich, das braucht sich. Das heißt, da muss eine ganz, ganz enge Kollaboration stattfinden, so wie der Product Owner die Product Ownerin mit den Endkunden bitte zu reden hat. Hat der Scrum Master oder die Scrum Masterin, mit auch den Product Owner kontinuierlich zu reden und zu sagen: Hey, was könnten wir denn tun? Wie könnten wir es denn verbessern? Wo müssen wir an der Vision schärfen? Wo müssen wir eine Strategie schärfen? Wie geht das Zusammenspiel Product Owner, Entwicklerinnen besser etc.? Also all diese Dinge müssen Scrum Master mit der Product Owner, mit dem Product Owner besprechen und auch die ganzen  organisatorischen Komponenten drumherum. Was brauchen wir denn, damit du als Product Owner, als Product Ownerin in dieser Organisation besser gesehen wirst? Was können wir da machen, damit du effizienter bist, damit du bessere Entscheidungen treffen kannst, schnellere Entscheidungen treffen kannst etc..

Jasmine

Wir freuen uns total, dich oder deine Scrum Master Deine Coaches in unserer Ausbildung im Herbst zu sehen und wir wünschen dir eine wunderbare Woche.

Scrum verständlich erklärt

Scrum – das beliebteste agile Rahmenwerk hat sich stark in der Welt verbreitet. Es bietet eine hervorragende Chance, mit der Komplexität der heutigen Welt umzugehen und eignet sich zum Management von Wissensarbeit. Wir beleuchten die Herkunft, Einsatzgründe und die wichtigsten Elemente von Scrum, damit du dir einen Überblick verschaffen kannst und einen Einstieg in das Thema findest.

 

Buche jetzt eine Certified Scrum Master Schulung bei uns unter https://agilegrowth.de/trainings

Kai

Scrum, das beliebteste Agile Rahmenwerk schauen wir uns heute einmal an, und zwar einfach so zum Einstieg, damit du verstehen kannst, wofür eignet sich das überhaupt? Was steckt da so drin? Und was sind vielleicht auch Herausforderungen, die damit einher kommen? Wir freuen uns, wenn du dir in dieser Folge den Überblick verschaffts über Scrum.

 

Sprecher

Herzlich Willkommen zum Agile Growth Podcast, dem Podcast für alle Agile Interessierten mit hilfreichen Ideen und erprobten Werkzeugen, die dich weiterbringen. Von und mit den Two Agilists.

 

Kai

Herzlich willkommen zum Agile Growth Podcast. Hier sind Jasmine und Kai und wir helfen Menschen dabei, die Versprechen Agiler Vorgehensweisen in der Praxis einzulösen, ohne IT Wissen vorauszusetzen. Schön, dass du wieder zuhörst zu einer Folge, die wir vielleicht ganz am Anfang mal hätten machen sollen. Und wir haben die ganze Zeit gedacht So, ach, wir stehen noch so oft im Seminarraum und erklären Menschen, was Scrum ist, dass wir diese Folge jetzt ganz, ganz spät eigentlich aufnehmen in unserem Podcast, nämlich die Frage stellen: Was ist eigentlich Scrum?

 

Jasmine

Und vielleicht auch Was hat das mit Agil zu tun?

 

Kai

Und das fühlt sich ein bisschen an wie die Endgegner Frage Weil ja gut, im Seminar haben wir so zwei, drei Tage, um das Ganze zu entpacken, was da alles so dranhängt und drinsteckt. Das heißt, heute werden wir auf jeden Fall mal in der Adler Perspektive unterwegs sein, was dazugehört und wieso überhaupt Scrum – wie sich das alles entwickelt hat, ist ja doch irgendwie ein sehr beliebtes Rahmenwerk geworden, was sehr viele Menschen einsetzen mittlerweile. Und da stellt sich schon auch die Frage, wie kam es eigentlich dazu, dass das so viele Menschen benutzen?

 

Jasmine

Und da vielleicht. Warum reden wir über Scrum und nicht über irgendwas anderes? Warum reden wir nicht über allgemein agiles Arbeiten? Ganz ehrlich Weil ich nicht weiß, was agiles Arbeiten sein soll, wenn ich nicht irgendein Rahmenwerk dahinter einsetze. Und das ist immer so die erste Klärung, die ich ganz oft mache, wenn ein Kunde auf mich zukommt, wenn eine Person auf mich zukommt mit einer Frage und sagt, ich bin da so in einem Agilen Projekt, dann ist meine Gegenfrage oft: Was ist denn ein agiles Projekt für dich? Ja, wir machen das halt agil. Okay. Was heißt denn das für dich? Und da hilft es für mich, mal so ein bisschen in die Historie rein zu gucken. Was ist dieses Agil für mich in meiner Definition oder auch in der Definition des Agilen Manifests? Und was ist Scrum? Und was viele nicht wissen und auch erstaunt ist, dass Scrum eigentlich älter ist als das Agile Manifest. Bestimmt nicht älter als die Ideen des Agilen Manifests, aber älter als das Agile Manifest.

 

Kai

Genau. Denn Ende der 90er Jahre wurde Scrum zum Ersten Mal ausprobiert und da gab es das erste Scrum Team. Auch wenn das noch ein bisschen anders definiert war, vielleicht als das, wie es jetzt heutzutage ist. Denn auch Scrum ist natürlich gereift im Laufe der Zeit und erst 2001 war dann das Agile Manifest. Wir haben dazu ja auch schon mal eine Podcastfolge gemacht. Ich glaube Folge vier ist es zum Thema Was ist eigentlich Agilität? Und Scrum ist halt die beliebteste Agile Vorgehensweise und das beliebteste Agile Rahmenwerk, was die meisten Leute einsetzen. Ein Großteil der Leute, die agil arbeiten, nutzen das. Wie gut das ausgeprägt ist in der einzelnen Praxis, da würde ich sagen, das ist sehr durchmischt, also von Teams, die das so machen, wie das definiert ist. Bis Leuten, die sich so einzelne Konzepte irgendwie rausschneiden und das noch mit einer Prise von Missverständnissen obendrauf garnieren, gibt es da alle möglichen Facetten und du weißt wahrscheinlich besser als wir, was bei dir in deinem Umfeld Agiles Arbeiten ist, falls sie das schon macht.

 

Jasmine

Genau. Und da beginnen wir schon. Scrum ist ein Rahmenwerk. Das heißt, Scrum hat für mich fest definierte Regeln, die ich befolgen darf, wenn ich Scrum mache. Der Scrum Guide sagt auch ich darf da nichts weglassen. Also wenn Kunden zu uns kommen, die direkt sagen, ja, wir wollen ja mal lernen, was das Scrum ist, damit wir es direkt auf uns adaptieren können. Dann kriege ich schon bissle Bauchschmerzen, weil dieses Rahmenwerk ist eigentlich ziemlich leichtgewichtig. Und wenn du schon mit dem Gedanken rein gehst mit ich guck da mal rein, damit ich gucken kann, wie ich es adaptieren kann, was ich alles weglassen kann. Dann würde ich an einer anderen Stelle anfangen, nämlich gucken, was kannst du in deiner täglichen Arbeit denn alles weglassen? Was ist denn alles Waste in deiner täglichen Arbeit, damit ich Scrum gut implementieren kann, wenn ich denn das möchte und das für meinen Kontext passt? Wir gehen später noch mal drauf ein, was denn in diesem Rahmenwerk alles drin ist. Aber mir ist der Kontext ganz, ganz wichtig.

 

Jasmine

Also Scrum ist ein Rahmenwerk zur Produktentwicklung. Das heißt, wenn ich meine Dienstleistung, mein IT Produkt, mein vielleicht ist es sogar ein ein Hardware Produkt, vielleicht ist es ein Auto etc. Aber wenn ich das als Produkt umpacken kann, dann hilf mir Scrum, wenn ich Multi Projektmanagement mache, dafür Scrum nicht gedacht. Es war noch nicht gedacht. Ich kann versuchen irgendwie Scrum Rahmenwerk da drüber zu legen. Das braucht aber dann relativ viel Gehirnschmalz, wie das irgendwie für uns funktioniert. Ich habe das schon mit Kunden gemacht. Wir kamen zu ganz befriedigenden Lösungen und es hat auch viele ihre Probleme aufgedeckt und wir haben sie dann lösen können. Das war toll. Aber ganz wichtig  – Es ist ein Rahmenwerk zur Produktentwicklung.

 

Kai

Und ja, jetzt hörst du uns hier sagen man, man sollte das so machen, wie das definiert ist und so, das kommt immer so rüber, als ob das so hier so zwei Certified Scrum Trainer, die sind die Hardliner sagen Du musst das so machen, du kannst das nicht anders machen. Wir machen das jetzt auch schon eine Weile und da vielleicht so ein bisschen im Hintergrund, damit du verstehst, wo wir herkommen. Diese ganzen Muster in Scrum, die einem dabei helfen, bessere Produkte zu entwickeln und anders zusammenzuarbeiten, nach anderen Spielregeln zu arbeiten. Die gibt es jetzt ja einfach schon eine Weile auf diesem Planeten. Die haben schon ihre Jahre auf dem Buckel und in der Zeit hat man einfach ausprobiert, was hilft einem konkret und was braucht man nicht. Und das hat sich so zusammengestellt zu dem Muster Katalog der Sammlung, die Scrum eben jetzt aktuell ist in der aktuellen Definition von den Dingen, die tatsächlich hilfreich sind, wenn man gemeinschaftlich Produktentwicklung betreiben will. Da ist jetzt also nicht mehr viel Schmuck am Nachthemd dran. Man hat das, der  Scrum Guide.

 

Kai

Die Definition von Scrum ist auch immer kürzer geworden. Da sind immer mehr Sachen rausgefallen. Das ist immer auch IT-agnostischer geworden. Da steht gar nichts mehr drin in Bezug auf IT-Vorgehen, sondern es ist mittlerweile ein Wissensmanagement Rahmenwerk. Und wenn man das aus der Brille heraus betrachtet, dass das schon quasi immer weiter bereinigt worden ist, immer einfacher geworden ist, dann sind halt eben nur noch ein paar Dinge da und die sind wirklich, wirklich wichtig, weil wenn die fehlen, dann stimmt meistens was dahinter nicht. Also man lässt diese Sachen dann weg, weil etwas in der Firmenkultur nicht stimmt. Multi Projektmanagement hat Jasmine gerade genannt oder andere Faktoren dazu beitragen, dass man Dinge weglässt. Deswegen ist so das Plädoyer für uns für den Anfang – Lasst uns mal starten, so wie das gedacht ist, weil die Dinge haben alle eine Funktion da drin. Und wenn Dinge nicht funktionieren, dann haben wir Gott sei Dank noch so’n Scrum Master da drin, der sich damit auseinandersetzen kann, wieso die Dinge nicht funktionieren und wie man das als Zielbild dann nehmen kann, um da mal hinzukommen, so zu arbeiten.

 

Kai

Denn eigentlich ist dieses nach Scrum Arbeiten ein total natürliches Vorgehen von Menschen, die ein Problem an der Backe haben, könnte man sagen.

 

Jasmine

Und vielleicht, um dir noch so eine Analogie zu geben, ich bin überhaupt kein Verfechter von jetzt, zum Beispiel einer Low Carb Diät oder so, aber dieses Dinge weglassen hört sich für mich immer so an wie ja, ich will eine Diät machen, ich möchte abnehmen. Ich weiß sehr genau mein Ziel. Ich habe mir jetzt eine Low Carb Diät rausgesucht, möchte mein Ernährungsverhalten entsprechend umstellen, aber morgens brauche ich mein Marmeladen-Brötchen. Dass es sich dann trotzdem aber irgendwie nehme ich nicht ab. Ja. Okay, kannst du so machen. Ist dann halt doof. Das heißt  da hinter zu gucken, zu gucken. Okay, warum brauche ich mein Marmeladenbrot morgens trotzdem.

 

Kai

Emotionales essen.

 

Jasmine

Zum Beispiel? Also für mich. Mein Marmeladenbrötchen ist mir übrigens heilig. Einfach. Das ist für mich das totale ankommen, morgens Marmeladenbrot essen zu dürfen. Das heißt ich würde mir diese Diät auch nicht raussuchen. Aber. Das hilft auch beim Scrum Rahmenwerk zu gucken. Wenn wir Dinge nicht tun können, wenn die nicht funktionieren, statt sie weg zu lassen, den härteren Weg zu gehen und zu gucken Hey, wie können wir es vielleicht doch hinkriegen? Oder warum geht das gerade nicht? Hilft. So, jetzt hat Kai gesagt, es ist ein Rahmenwerk zu Wissensarbeit. Das heißt, es ist ein Rahmenwerk, das ich in einem bestimmten Umfeld einsetze. Und wir nennen es ganz oft dieses komplexe Umfeld, das heißt das Umfeld, wo Anforderung und Umsetzung unklar sind. Also da, wo mir vielleicht mein Endkunde nicht genau sagen kann, was er möchte. Das heißt nicht, dass mein Kunde nicht denkt, dass er weiß, was er genau möchte. Das begegnet mir ganz, ganz oft, dass der Endkunde, der Stakeholder, der Key User wer auch immer sehr, sehr genaue Vorstellungen hat, was er möchte.

 

Jasmine

Und wenn es dann umgesetzt ist, merkt er so – Nö, das wollte ich gar nicht. Und dann beginnt das Hickhack. So. Also wenn ich in diesen Umfeldern bin, wo der Anwender, der Endkunde etc. gar nicht richtig Versprachlichen kann, was er möchte. Vielleicht, weil’s einfach hoch innovativ ist. Und vielleicht ändern sich aber auch die Arten der Umsetzung sehr schnell. Und das ist halt in der IT der Fall. Also neue Technologien kommen dazu etc. Die Art der Umsetzung kann sich da auch sehr, sehr schnell ändern. Ist sehr volatil. Wenn ich in diesem Umfeld bin und oder die Anforderung sich schnell ändern kann und nicht genau versprachlicht ich werden kann oder die und die Umsetzung noch unklar ist, dann bin ich in einem komplexen Umfeld. Das ist bei Wissensarbeit ganz oft der Fall. Das ist in der IT ganz oft der Fall. Das ist bei Innovationsarbeit der Fall. Das ist im Prinzip in allen Veränderungsprojekten der Fall.

 

Kai

Ich vergleiche das ganz gerne mal mit Autofahren im Nebel. Das heißt dichter Nebel. So eine richtige Suppe. Und dann fahre ich ein paar Meter und muss dann schauen, dass ich nicht von der Straße abkomm, sagen wir mal es ist eine Landstraße, auf der ich gerade unterwegs bin. Natürlich, alle fahren langsam, weil es ist eine dichte Suppe. Und dann fahre ich ein Stück und dann muss ich wieder schauen, wo ist denn der Randstreifen, wenn ich den da sehe, dass ich da nicht vom Bordstein runterkommen kann? Ich bin ein Stück fahren und dann muss ich wieder ein bisschen nachsteuern, damit, falls da gerade eine Kurve ist, ich nicht von der Fahrbahn runter komme. Manchmal kann es sogar passieren, das rechte Reifen dann, wenn ich gerade irgendwie die Straße nach links abgeknickt, dass der dann auch wirklich runterkommt. Und da muss ich ihn wieder draufsetzen. Also da passieren dann regelmäßig so kleinere Fehler. Auch könnte man das nennen. Und die brauche ich aber, um meine Richtung zu korrigieren. Und so ist das dann auch mit so einem Scrum, was ja Sprints besitzt.

 

Kai

Also so Iterationen, Schleifen, die mir immer mal wieder den Kopf hochheben und schauen, wo stehen wir denn eigentlich gerade? Und eben checken – Ist das das, was wir eigentlich bauen wollten? Hilft das den Leuten wirklich weiter? Wir drücken aus denen in die Hand und lernen mit denen. Ist das hier hilfreich für das Problem, was wir haben und was wir zu lösen versuchen?

 

Jasmine

Das heißt Scrum hilft dir da, wo du im Nebel fährst. Ich sage auch ganz gerne dieses wo wir nicht wissen, was wir nicht wissen. Da wo wir wissen, was wir nicht wissen, können wir es analysieren, können unseren Plan machen, gehen vorwärts. Da hilft uns klassisches Projektmanagement total gut und da würde ich auch nicht Scrum einsetzen wollen. Aber da, wo noch relativ viel unklar ist, da wo ich nicht weiß, wie mein meine Zuhörerschaft irgendwas akzeptiert, da hilft mir Scrum, weil da ist das einzige was ich tun kann, ist lernen. Und lernen tue ich über Feedback und Scrum ist ein Rahmenwerk, das diese Feedback Zyklen extrem kurz hält. Also sagt mach’s nicht länger als ein Monat, wenn du kannst, am besten noch kürzer. Und worüber sammeln wir Feedback? Wir sammeln Feedback über unser Produkt. Das tun wir im Review nennt sich das also ein Workshop, wo ich mit Endkunden, mit Anwendern, wenn es geht, mit aber auch allen Stakeholdern auf das Produkt drauf gucke und Feedback sammle.

 

Jasmine

Das ist mir ganz wichtig. Das Review ist wirklich ein Workshop, kein Abnahme Meeting, sondern es geht darum zu lernen. Abnahme klingt so wie – Haste gut gemacht, haste nicht gut gemacht. Und schimpfe schimpfe, wenn nicht gut. Sondern es geht darum zu lernen. Es ist ein Workshop, wo wir gemeinsam lernen. Das heißt, ich habe einmal eine Feedback Schleife auf mein Produkt. Ich habe aber in der Retrospektive, wo wir in die Introspektion gehen, als gesamtes Team auch eine Feedback Schleife auf unsere Arbeitsweise, unserem Prozess, der Umgebung, in der wir sind, wie könnten wir das alles verbessern? Das heißt auch da das komplexe menschliche System, das ich baue, wenn ich als Team zusammenarbeite und das ist immer komplex und nicht einfach, auch da habe ich eine Feedback Schleife drüber und ich hab täglich treffe ich mich mit meinem Team mindestens einmal für 15 Minuten, wo wir eine Feedback Schleife drüber haben. Hey, wie gut sind wir denn gerade unterwegs im Erreichen unseres Ziels, dass wir uns für diese Iteration gesetzt haben?

 

Kai

Und genau dieses Ziel setzen wir uns in der Sprint Planung. Das ist am Beginn von jedem Sprint, von dieser immer festen Zeiteinheit, die wir für uns gewählt haben, die maximal einen Monat lang ist, wie gerade sagte. Und da planen wir dann halt, was wir zu erreichen suchen. Und das Ganze ist ein bisschen ja angehaucht und inspiriert durch LEAN dieser LEAN Philosophie, also Verschwendungen zu vermeiden und uns darauf zu konzentrieren, dass wir wirklich die Dinge bauen, die Wert bringen und alles andere weglassen. Den Schmuck am Nachthemd und Gold Plating sagt man immer ganz gerne. Mal so eine goldene Schraube vorne dran sitzen. Das lassen wir weg, damit wir uns auf das Wesentliche konzentrieren. Und das hilft dann dabei, dass wir und deswegen auch diese Art des Arbeitens bei Startups ganz beliebt, dass wir einfach schlank und mit einer budgetfreundlichen Variante die Dinge bauen, die für den Anwender einen Unterschied machen.

 

Jasmine

Und da kommen wir schon zum Punkt von was braucht es denn überhaupt, wenn ich jetzt Scrum machen möchte? Und das erste, was es braucht, ist die Akzeptanz dessen, dass wir in einer komplexen Umgebung sind. In meiner Erfahrung ist das ganz schwierig für Firmen zu akzeptieren. Gerade für Firmen, die aus einer eher komplizierten Domäne rauskommen. Logistik oder Bahnverkehr oder.

 

Kai

Sachbearbeitung im Finanzbereich.

 

Jasmine

Etc.. Also es ist eher eine komplizierte Domäne und vielleicht durch die Umwelt jetzt einfach komplex geworden. Und da braucht es erst mal die Akzeptanz dessen, dass ich nicht alles analysieren kann, also dass ich nicht mehr im Raum bin, wo ich weiß, was ich nicht weiß, es analysieren kann und dann einfach mit einem guten Plan zu einem guten Ergebnis komme. Sondern dass ich im Raum bin und ich nicht mehr weiß, was ich nicht weiß. Das heißt, dass ich Experimente machen muss, dass ich da Anführungszeichen, Fehler drin machen muss und daraus lernen kann, dass Lernen meine einzige Überlebensstrategie ist. Und da kommen wir zum nächsten Punkt – Es braucht die Akzeptanz, dass wir in einem komplexen Umfeld sind. Und der nächste Punkt ist dann – Es braucht eine gute Lernkultur dahinter. Weil wenn ich immer Schelte und Schimpfe kriege als Team, weil irgendwas noch nicht so perfekt ist, dann wird das nicht funktionieren. Dann wird das Team irgendwann mal die Dinge nicht mehr rausgeben oder diese Feedback Zyklen so groß machen dass wir wieder zu kurz dran sind.

 

Kai

Die gute Nachricht dabei – Scrum ist auch ein Wert-Katalysator. Also selbst wenn diese Werte noch nicht da sind, wenn man anfängt das zu tun, durch das Verhalten der Leute entsteht dann ja ein neues Denken und eine neue Handlungsweise, die dann so als Schatten der Kultur auf die Organisation fällt. Insofern, wenn du jetzt rauslässt, wir machen das gar nicht so und wir haben irgendwie eine schlechte Fehlerkultur. Das muss jetzt nicht unbedingt ein Grund sein, weswegen man das gar nicht anfängt. Aber es ist halt ein Thema, was einem auf jeden Fall dann unterwegs begegnet an der Stelle.

 

Jasmine

Was auch hilft oder wo wo Scrum auch ein Katalysator ist. Es braucht eine neue Kommunikationskultur. Wir hatten letztens einen ACSM und ich hatte da ein super spannendes Gespräch mit einem Scrum Master, der schon sehr, sehr lange unterwegs ist. Er meinte Ah, mir ist gerade aufgefallen, wir brauchen echt eine neue Kommunikationskultur, sowohl im Team wie auch außerhalb des Teams. Und das kann sehr fordernd sein. Da hilft einem Scrum. Aber es braucht die Bereitschaft, diese neue Kommunikationskultur zu etablieren. Weil da, wo wir die gemeinsame Intelligenz einer Gruppe benutzen wollen, führt es auch zu Reibung. Und diese Reibungen sind wichtig. Kai und ich hatten Gestern haben wir einen Workshop abgeschlossen und im Feedback kam ihr funktioniert total gut als Trainerpaar und ich haben ein bisschen geschmunzelt und meinten nur – Ja, ihr habt unsere Streits in der Pause ja nicht mitgekriegt. Also auch Kai und ich. Und das lernen wir jeden Tag noch ein bisschen besser, müssen eine völlig neue Kommunikationskultur für uns etablieren. Also das ist für mich Paradebeispiel von psychologischer Sicherheit.

 

Jasmine

Bei uns läuft es nicht rund. Wir zoffen uns richtig derbe. Aber wir wissen, wofür wir uns streiten. Und wir wissen, dass diese Reibung des Streits, diese Disharmonie zu einfach unglaublich viel besseren Ergebnissen führt, weil wir alles äußern können, was zum Zweck des besseren Ergebnisses dient. Und das ist manchmal nicht Harmonie und Friede, Freude, Eierkuchen und ja, ich stimme dir hier zu, sondern das ist ganz ehrlich, hast du einen an der Klatsche? Das können wir so nicht tun. Manchmal sage ich so und manchmal sage ich es auch ein bisschen netter.

 

Kai

Und auch da ist wieder die gute Nachricht – Diese psychologische Sicherheit, von der es gesprochen hat. Auch dazu haben wir schon mal eine Podcastfolge gemacht. Dazu gibt es jemanden, der da immer wieder rein investiert. Unsere Scrum Master, unsere Scrum Master hat diverse Funktionen in dem Rahmenwerk, das natürlich erst mal den anderen zu erklären und dafür zu sorgen, dass das auch so gelebt wird wie gedacht. Es gehört aber eben auch dazu, dieses Team zu entwickeln, denn da ist, da ist noch das ganze Scrum Team besteht aus drei Verantwortlichkeiten, nämlich Product Owner bzw Product Ownerin  Entwicklern und Entwicklerinnen und einer Scrum Master oder Scrum Masterinnen. Und diese drei Verantwortlichkeiten reichen aus, um ein Produkt zu bauen. Denn ja, unser Product Owner ist so der Visionär, der hat entsprechend das Bild davon, was für ein Problem in der Welt gelöst werden muss, kann das auch kommunizieren und sorgt dafür, Unterstützung zu gewinnen und mit den Stakeholdern zu arbeiten.

 

Jasmine

Und dafür erstellt der Product Owner ein sogenanntes Backlog und ein Backlog ist kein Lasten Pflichtenheft. Ein Backlog ist auch keine Abarbeitungs-Liste im ursprünglichen Sinn, sondern ich finde, es ist sehr viel einfacher, wenn wir uns das visualisieren. Also ein Backlog ist eine ganze Liste von Experimenten, die geordnet sind, die wir durchführen wollen, weil wir annehmen, dass es unser Produkt voranbringt. Und dafür ist der Product Owner verantwortlich, dass wir diese Liste von Experimenten haben und dass wir die auch immer wieder bereinigen. Das heißt, Experimente, wo wir sagen, wir haben Neues gelernt, brauchen wir gar nicht, schmeißen wir raus. Also nicht Lasten und Pflichtenheft bleibt da drin, für immer, bis es dann auch gemacht ist. Sondern wenn wir es nicht. Wenn es nichts taugt, schmeißen wir es raus und auch neue Sachen wieder reinkommen, weil wir ja Feedback generieren.

 

Kai

Und das ist also eine gute Quelle von Arbeit, aus der dann die Entwickler konkret sich dann Experimente aussuchen können für den Sprint, geführt durch die Priorisierung, also die Sortierung von Product Owner, der das in der Reihenfolge gebracht hat, damit klar ist, was ist eigentlich besonders wertvoll, denn unser Product Owner spricht ja ständig mit den Anwendern und den Kunden und den Stakeholdern, um zu wissen Was ist denn wertvoll für die? Welche Funktionalitäten brauchen die? Insofern ist das dann natürlich in dieser Liste des Backlogs ganz oben. Und wenn wir eine Sprint Planung reingehen, dann suchen sich die Entwickler so viel Arbeit aus von diesem ganz oben, also von den wichtigen Dingen, dass sie das in der guten Qualität machen können, entsprechend ihrer Definition von fertig, Definition Of Done dann genannt, also der Einigung darauf, was fertig heißt. Und ja, so haben sie dann vor allen Dingen nur so viel Arbeit genommen, wie sie auch machen können. Und vielleicht kennst du das von dir selbst, wenn du manchmal so gegen Deadlines gearbeitet hast, vielleicht der Ausbildung im Studium und das wird dann irgendwie knapp, dann mauschelt man ja doch schon mal ganz gerne an der Qualität und das ist nichts, was wir wollen an der Stelle, denn dazu haben wir ja auch schon mal eine Podcastfolge macht.

 

Kai

Technische Schulden wollen wir nicht aufbauen, sondern wir wollen immer die Teile, die wir dann zu den wir ja gesagt haben, auch in der vorgestellten Qualität liefern können. Und da sind wir dann wieder bei diesen Lean Gedanken, bei der Toyota Produktions Philosophie und bei dem Pull Prozess nämlich die Leute an der Arbeitsbank pullen sich nur so viel Arbeit, wie sie wollen, anstatt dass wir push ihnen noch was drauf satteln.

 

Jasmine

Dafür übergeben wir aber auch die gesamte Verantwortung der Qualität an die Entwickler und Entwicklerinnen. Und mit Entwickler und Entwicklerinnen meinen wir nicht Softwareentwickler. Wir meinen nicht die, die nur Code schreiben, sondern alle Leute, die es braucht, um dieses Produkt zu erstellen. Das heißt, könnte sein, dass du ein Business Analyst bist und es braucht  deine Business Analyse Skills, um Dinge genauer zu verstehen, damit wir sie danach, wenn wir ein Software Produkt machen, in Code gießen. Dann bist du genau so ein Entwickler, eine Entwicklerin wie jemand, der jetzt produktiven Code schreibt etc.. Also alle Leute, die wir brauchen, damit wir das Produkt erstellen können. Ich habe auch schon mal für eine Fitness App gearbeitet, da hatten wir Psychologen drin, wir hatten Sportwissenschaftler drin, wir hatten Marketing drin. Weil all das braucht es für eine Fitness App zudem, dass wir halt noch Softwareentwickler und Entwicklerinnen drin haben. Aber diese Verantwortungs-Übergabe der Qualität und des „Wie werden die Dinge umgesetzt“ in das Entwicklerteam, das nicht mehr Entwicklerteam heißt im neuen Scrum Guide

 

Jasmine

Das ist noch nicht in meinem Kopf angekommen. Zu den Entwicklern und Entwicklerinnen ist ein ganz, ganz wichtiger Faktor. Also Scrum schiebt die Verantwortung dahin, wo sie auch getragen werden kann.

 

Kai

Also noch mal ganz wichtig :Mit Entwickler meinen wir alle Leute, die am Produkt bauen. Das ist wirklich so eine Umstellung im Kopf, ich weiß, dass es sprachlich nicht so ganz glücklich hier sind Produktentwickler gemeint, also nicht irgendwie Programmierer, sondern wirklich alle, die es braucht, um ein Stück Produkt zu bauen.

 

Jasmine

Genau. Und so sind wir eigentlich schon an dem Punkt, wo wir, glaube ich, ganz viele Dinge gesagt haben Was ist denn dieses Scrum? Man kann das auch wirklich in Zahlen runterbrechen. Also wenn man es in Zahlen herunterbricht, was ist dieses Scrum? Scrum basiert auf fünf Werten. Wir haben fünf Werte, nämlich Mut, Fokus, Offenheit, Respekt und Commitment. Das sind die fünf Werte, die im Scrum Team verkörpert werden, aber auch in der Organisation verkörpert werden sollten oder wir darauf hinarbeiten dürfen, damit die auch in der Organisation der verkörpert werden. Dann funktioniert Scrum relativ gut. Wir haben die jetzt sprachlich umrissen in unserer Podcastfolge bis jetzt. Aber im Prinzip sind es diese fünf Kernwerte und dann haben wir drei Verantwortlichkeiten.

 

Kai

Genau habe ich gerade schon genannt Product Owner, Entwickler, Scrum Master. Und die erwecken das Ganze zum Leben. Das ist also jemand, der konkret in eine gewisse Richtung zieht, könnte man auch sagen, in Richtung möglichst viel getan bekommen. Die Product Vision zum Leben bringen und deswegen auch der Wunsch danach viel getan zu bekommen, damit das halt ins Leben kommt. Dann die Entwickler, die sagen Ich möchte das in einer guten Qualität machen. Ich möchte, dass das auch noch wartbar ist in Zukunft. Ich möchte, dass die Lösung irgendwie gut ist. Und dann noch Scrum Master, die dafür sorgen, dass dieses Wechselspiel zwischen diesen Parteien hier gut funktioniert und dass die Konflikte aufgelöst werden und dass das ein hoch produktives Team wird.

 

Jasmine

Und dann habe ich fünf Events. Der Sprint ist einer dieser Events, also das Überspannende Event im Prinzip, unsere Iteration, die darf bis einen Monat lang sein. Man sollte die kürzeste Zeit, die man schafft, um ein Produktinkrement, also ein wertvoller. Produkt Abschnitt, wo ich Feedback drauf generieren kann, zu erstellen. Also der kürzeste Zeitabschnitt dafür sollte verwendet werden. Dann habe ich, wie wir schon gesagt haben, das Planning. Wo wir planen. Was werden wir in dieser Iteration machen? Wir treffen uns jeden Tag zu einem Daily Scrum. 15 Minuten kurz und knackig. Wie gut sind wir unterwegs im Hinblick auf unser Ziel, das wir uns gesetzt haben? Was müssen wir tun, damit wir das erreichen können? Im Sinn von Arbeit, aber auch im Sinn von Hindernisse aus dem Weg räumen. Nach der Iteration, also, wenn die zum Ende neigt, treffen wir uns zu einem Review. Das haben wir schon umrissen. Einen Workshop, wo wir mit Endkunden, Stakeholdern, CEOs etc. auf unser Produkt draufgucken, wirklich gucken, was funktioniert, was funktioniert noch nicht?

 

Jasmine

Wie können wir es besser machen? Neue Ideen generieren für unser Produkt Backlog. Danach zieht sich das Scrum Team, also Scrum Master, Product Owner, Entwickler und Entwicklerinnen zurück und gehen in die Introspektion. Gucken, was können wir besser mache, unsere Arbeitsweise an der Interaktion mit Stakeholdern, an der Qualität etc.. Und dann beginnt das Ganze wieder von vorne.

 

Kai

So, dann gibt es drei Artefakte, eines hat Jasmine gerade schon genannt. Das ist also ja sozusagen der aktuelle Zustand des Produktes, der da entstanden ist. Inkrementell, also in einzelnen Schritten wird das Produkt aufgebaut, nicht so als eine riesen Lieferung, sondern zwei Jahren. So hier, lieber Kunde, ist das Produkt, sondern wir bauen das schrittweise auf, über das wir Feedback sammeln. Es gibt das Produkt Backlog, das ist die Liste der Anforderungen, die wir zusammengetragen haben, die Dinge, die noch fehlen in unserem Produkt. Und es gibt das Sprint Backlog, was dann eben die konkrete Auswahl durch unser Entwickler ist, was wir in einem Sprint umgesetzt bekommen, inklusive noch ein bisschen Schlachtplan dahinter kann man sich vorstellen, wie so eine kollektive To Do Liste, wo dann noch Tätigkeiten dranhängen? Wer macht denn eigentlich was? Und darüber organisieren die sich häufig über so ein visuelles Management Board wie zum Beispiel ein Task Board wird sowas abgebildet, ganz gern mit Klebezettel. Das ist auch das, was man so häufig sieht in der physikalischen Zeit, oder

 

Kai

Heutzutage gibt es ja viele digitale Werkzeuge, die sowas auch abbilden können.

 

Jasmine

Du siehst, es ist relativ schlank, da ist nicht so viel dran. Aber vielleicht, wenn du deine bestehende Arbeits-Realität hast, dann könnte es sein, dass das zu viel ist. Das heißt Scrum einfach on top von bestehender Arbeits-Realität einzusetzen ist immer relativ schwierig. Mir hilft es oder unseren Kunden hilft es ganz oft, wenn wir sagen – Hey, wenn wir alles weglassen, was wir tun und nur Scrum anwenden und danach die Dinge, die wir merken, dass wir sie doch brauchen, wieder hinzunehmen, dann hilft dieser Weg oft mehr, als zu sagen: Wir machen alles genauso weiter, wie wir es tun und machen Scrum on top. Dann kommt ganz, ganz schnell die Aussage von – es ist es zu viel Arbeit mit Meetings? Wenn wir es aber mal ausrechnen, wie viel diese Events auch wirklich in Anspruch nehmen, dann verbringen wir 20 % unserer Arbeitszeit in diesen Events. Meine Erfahrung ist, dass wir ganz viele Termine, die wir sonst noch so haben, eigentlich in diesen Events abgebildet bekommen. Das heißt dann gar nicht so viele Meetings, eigentlich mehr haben drumherum, weil wir diese  in die Events reinpacken können.

 

Kai

So 10 bis 15 Millionen Menschen machen das weltweit, dieses Scrum Rahmenwerk. Das ist also tatsächlich sehr beliebt geworden in letzter Zeit immer mehr. Ich glaube, es ist auch nach wie vor ein Thema, das wichtig ist, denn vielleicht merkst du das selbst. Unsere Welt ist zunehmend volatiler geworden. Wir haben viele Doppeldeutigkeiten da draußen, viele Unsicherheiten, mit denen wir umgehen müssen. Und dazu hilft es halt, durch Komplexität, durch navigieren zu können. Und das lernen Menschen, die in diesem Rahmenwerk arbeiten. Und was auch noch gut tut, ist, dass durch die Art und Weise, dass wir regelmäßig reflektieren über unsere Arbeit auch ein Unternehmenslernen. Ein Lernprozess, da ist für die Menschen innerhalb der Organisation und vielleicht kennen du das selbst nur so im Persönlichkeits und Bildungsmarkt sagt jeder, schreibt Tagebuch, mache Praktiken, die dir dabei helfen, dass du selber reflektieren kannst. Und das machen wir auf der Organisations ebene dann auch. Also verschiedene Gründe, warum das so beliebt geworden ist und in der Umsetzung ja durchaus herausfordernd. Ich glaube, das hat man so vielleicht auch schon mitbekommen.

 

Kai

Weswegen hat eine Begleitung auch total Sinn macht und der Scrum Master ist die eingebaute Begleitung, die dann dazu da ist. Und wir hoffen, wir konnten uns einen guten Überblick geben über das Rahmenwerk, die fünf Werte, die fünf Ereignisse, drei Verantwortlichkeiten und drei Artefakte. Also so viel ist das nicht. Deswegen auch so was kann ich davon weglassen? Wie kann ich das verbiegen? Es ist ja fast nichts dran. Würde ich ja fast so ein bisschen überspitzt sagen wollen. Und wenn du dich da tiefer reinknien willst – wir haben regelmäßig Certified Scrum Master Schulungen. Die sind nicht unbedingt eine Rollen Schulung. Also nur in dieser Verantwortung. Da kannst du auch dieses ganze Rahmenwerk noch mal im Detail mit uns zusammen durchgehen und verstehen. Da herzliche Einladung. Wenn du oder tiefer rein willst, freuen wir uns, wenn wir dich im Seminar wiedersehen.

 

Jasmine

Und damit wünschen wir dir eine wunderbare Woche. Genießt das Frühlingswetter, genießt die Sonne und wir hören uns hoffentlich nächste Woche.

 

Jasmine’s Weg zur Certified Scrum Trainerin (CST®) (Interview)

Diese Folge ist ein Interview von Sabine Canditt, die als Gesprächspartnerin Jasmine zu ihrem Weg als Certified Scrum-Trainerin befragt. Das Inteview wurde vom ScrumAlliance DACH-Chapter aufgenommen, welches der deutsche Ableger der Scrum Alliance ist. Mehr dazu unter https://scrumdach.org

 

Buche jetzt eine Certified Scrum Master Schulung bei uns unter https://agilegrowth.de/trainings

Kai

Ja. Als Coach gehört es genauso dazu, dass man regelmäßig Wissen vermittelt in Bezug auf agiles Vorgehen. Und vielleicht kennst du das selber, gerade wenn man Stakeholder hat um einen herum, die agiles Vorgehen nicht gewöhnt sind, dass das sehr wichtig ist, damit man innerhalb seines eigenen Teams agil arbeiten kann. Und dazu hilft es, seine Trainer Facette weiter auszugestalten. Jasmine hat den Weg zur zertifizierten Scrum Trainerin bei der Scrum Alliance gemacht und wird heute interviewt. In diesem Podcast von Sabine Canditt und Sabine Canditt ist an dieser Stelle stellvertretend für die Scrum Alliance DACH organisation. Das ist der deutsche Ableger der Scrum Alliance hier ein eigener Verband von der größten Dachorganisation der Scrum Anwender weltweit, der Scrum Alliance, in der ich schon seit 15 Jahren Mitglied bin. Und heute hörst du ein spannendes Interview dazu, wie man eigentlich diese Facette weiter ausgestalten kann und was das man dazu tun musste, um zertifizierte Trainerin zu werden.

 

Sprecher

Herzlich willkommen zum Agile Growth Cast. Deine regelmäßige Dosis Wachstum zum Hören. Ehrlich, authentisch, agil. Von und mit den Two Agilists.

 

Sabine

Ja. Hallo zusammen, ich bin die Sabine behandelt und ich war bisher die einzige weibliche Certified Scrum Trainerin im deutsch sprechenden Raum. Aber das ist jetzt nicht mehr so, weil jetzt gibt es auch die Jasmine. Und deswegen habe ich mir gedacht, es wäre toll, wenn ich mit der Jasmine ein Interview führen könnte, wo sie einfach was über ihren Werdegang als Trainerin erzählen kann, sodass ihr auch einen Eindruck von ihr bekommen könnt. Und ich mache das in meiner Nebenfunktion als Vorstand im Scrum DACH Chapter. Wir haben uns auch unter anderem zur Aufgabe gemacht, dass wir halt die Trainer:innen und Coach:innen, die im deutschsprachigen Raum unterwegs sind, denen die Gelegenheit zu geben, sich vorzustellen, ihre Arbeit vorzustellen, aber auch als auch sich als Person. Ja, und ich freue mich sehr, die Jasmin heute im Zoom Call zu haben und auf unser Gespräch. Ja, liebe Jasmin, schön, dass wir uns mal wieder sehen, wenn es auch nur in einem Zoom Fenster ist. Ich bin total glücklich. Habe mich echt gefreut über die Nachricht von dir, dass du jetzt auch Certified Scrum Trainerin geworden bist, dass ich jetzt Verstärkung bekommen habe im deutschsprachigen Raum.

 

Sabine

Und deswegen freue ich mich sehr, dass wir heute dieses Gespräch miteinander machen können.

 

Jasmine

Ich freue mich auch total.

 

Sabine

Super.

 

Jasmine

Sowohl Trainerin zu sein, wie auch für das Gespräch.

 

Sabine

Also wirklich klasse. Ja, dann lass uns doch einfach gleich loslegen. Okay, ja. Wie ist es denn zu so dazu gekommen, dass du überhaupt dich schon mit agilen Vorgehensweisen auseinandergesetzt hast? Wie hat deine Reise als Trainerin angefangen?

 

Jasmine

Ich glaube, es gibt. Es gibt bei mir so zwei Reisen. Das eine ist so dieses Trainierende, das hat wesentlich vor der Agilität angefangen. Ich ich wollt ja mal Lehrerin werden.

 

Sabine

Ja.

 

Jasmine

Dann hab ich das auch mal angefangen zu studieren und habe dann gemerkt, dass das Schweizer Studium, wenn man Gymnasiallehrern macht, sehr wenig Pädagogik drin hat. Mir war das zu wenig. Und dann bin ich auf Psychologie umgeschwenkt. So, habe aber. Von wann an von 14 an Nachhilfe gegeben und habe im Studium dann auch ganz, ganz viel Aushilfsjobs gehabt an Schulen. Und mein letzter Studienjob war mit Schulabgänger, also mit 16, 17, 18-jährigen Schülern, die so was wie ein Freiwilliges Soziales Jahr machen. Jedoch war das eingebettet in die Schule. Sie waren mittwochs bei uns in der Schule, da habe ich Mathe und Englisch gemacht. Aber in Mathe haben wir so Sachen gemacht wie Steuererklärung ausfüllen und so sehr lebensnahe Sachen – Prozent rechnen. Wenn deine Hose normalerweise 90 € kostet und jetzt 30 % reduziert ist, wie viel kostet sie noch? Weil diese Schüler eine extreme Angst vor Zahlen überhaupt hatten. Das habe ich vorher noch nie erlebt. So, dieses. Da steht ein Bruchstrich. Da geht gar nichts mehr. Und warum erzähle ich das?

 

Jasmine

War das für mich ganz viel mit Training zu tun hat – wir haben ja immer, auch immer wieder Leute, die sagen Ach, dieses Agile oder dieses Scrum, irgendwie alter Wein in neuen Schläuchen bleibt mir gestohlen. Also wo wir auch schon Widerstände haben und ich habe gemerkt, mit diesen Jugendlichen zu arbeiten, hat mir einfach unglaublich viel Spaß gemacht. Mir macht es viel Spaß, neue, andere Wege zu finden, wie man Sachen lernen kann. Weil dieser schulische Weg, wie wir ihn kennen, jemand sagt dir: Guck mal, hier ist Arbeitsblatt. Füll aus, ich erkläre es dir noch. Das ist einfach nicht für jedermann oder jede Frau so, insbesondere in der Erwachsenenbildung oder wenn es um Scrum geht, wo ich ja Dinge vielleicht auch mehr erfahren muss. Wir wäre denn das in so einem Scrum Team zu sein. Was ist denn der Paradigmenwechsel da drin? Das ist ja eine Welt, in die habe ich vielleicht schon mal reingeschnuppert, aber viele haben die auch noch nie erlebt. Genau da hat so meine Passion angefangen für wie vermittle ich Inhalte, ohne dass das schulisch rüberkommt, ohne dass das rein kognitiv ist.

 

Jasmine

Also wenn jetzt ein Teilnehmer sagt: Hey, ich brauche Training, das sehr, sehr kognitiv ist, dann bin ich nicht die richtige Trainerin. Da haben wir andere Trainer in unserer Community wo wir sagen können: Dann geh da hin, weil der ist dann besser oder die ist am besten. Die ist leider auch nie aber der ist besser geeignet dafür. So genau und zu Scrum bin ich später gekommen. Also ich habe Psychologie studiert, bin dann ins HR gewechselt und dann hat ein guter Freund von mir. Ich habe dann immer ein bisschen gemotzt, so, jetzt ist es zu weit weg von den Leuten. Ich weiß gar nicht, was ich so richtig tun. Wir machen tolle Change Initiativen und es bringt nichts. Dann hat ein Freund von mir mal gesagt Scrum Master ist deine Position. Und damals vor zehn Jahren war es ja nur in der IT. Meine Antwort so ganz ehrlich – Wenn mein Computer ein Update mach, kriege ich die Krise. Was soll ich denn in der IT?

 

Jasmine

Ja. Lange Rede, kurzer Sinn ich habe mich dann trotzdem beworben. Auf diese Scrum Master Stelle habe ich auch eine Vollzeit Scrum Master Stelle bekommen, was vor zehn Jahren echt nicht oft vorkam. Und habe gemerkt, dass ich da die Organisationsentwicklung, die ich sonst aus der HR Perspektive gemacht habe, mit den Teams machen kann. Da, wo Wertschöpfung geschieht. Und das ist das, was mich immer noch begleitet, dieses Vereinen von Menschlichkeit und Produktivität, weil ich glaube, nur dann, wenn wir Menschlichkeit mit Produktivität vereinen, kann wirklich was Gutes geschehen. Kann Innovation geschehen – können wir so zusammenkommen, dass wir Produkte kreieren, die uns dienen, dem Kunden dienen, der Firma dienen? Also das muss für mich alles drei drin sein. Kunden-Ausrichtung ist schön, aber wir arbeiten 40 Stunden die Woche. Das ist sehr, sehr viel Zeit. Das darf und muss Spaß machen sonst. Funktioniert es nicht oder funktionieren wir als Mensch auch irgendwann mal nicht mehr

 

Sabine

Absolut. Ein sehr nachhaltiger Gedanke finde ich, an sich selber zu denken. Gerade in diesen Zeiten, wo wir jetzt haben mit Corona, wo man zu Hause ist und wirklich darauf achten muss, wie es einem selber auch geht. Für andere nicht vernünftig Dinge tun. Okay, also da bist du dann durch deine frühe Ambitionen zum Trainieren oder zum Unterrichten um zusätzlich da eine Erfahrung, die du als Scrum Master machen durftest und diesen Freund, der vielleicht einen wichtigen Impuls gesetzt hat für dich, dass Certified Scrum Trainerin was für dich sein könnte. Bist du dann auf die Idee gekommen, genau das zu werden? Erzähl doch mal ein bisschen davon, wie das über die Schritte war, die dich dann davon gebracht haben. So von dieser, dieser Entscheidung. Ja, das könnte was für mich sein. Bis dahin, wo du es nun tatsächlich geworden bist.

 

Jasmine

Ich glaube, ich bin in meiner Karriereplanung etwas atypisch, oder? Bzw. Ich weiß nicht. Jeder kennt wahrscheinlich diese Interviewfrage Wo sehen Sie sich in zehn Jahren? Da stehe ich so da und denk so, hm. Ich weiß manchmal gar nicht, wo ich mich morgen Abend sehe. Also schwierig. Von daher. Genau der David hat mich damals in diese Scrum Master Position rein geschubst und da habe ich auch wirklich so mein berufliches Zuhause gefunden. Nicht weil ich Agilität und Scrum jetzt missionarisch toll finde, sondern weil es einfach Sinn macht, so zu arbeiten in gewissen Umfeldern, in anderen nicht aber in denen, wo ich unterwegs war, sehr oft und da gehört hat, aber auch in der Organisationsentwicklung Veränderungs Maßnahmen Firmen dazu und alles was komplex ist, da macht es einfach Sinn so zu arbeiten. Und genau da bin ich in diese Position rein geschubst worden. Konnte mich da auch einfach echt gut entwickeln. Hab für mich sehr viele Lernfeld entdeckt. Das ist für mich immer wichtig. Ich bin ein Mensch, der muss sich kontinuierlich weiterentwickeln. Und ich bin nicht unbedingt ein Buch- Literatur Weiterentwickler, sondern ich brauche das über Erfahrungen.

 

Jasmine

Und dann habe ich dann an die Schrieb kennengelernt, von „Das Scrum Team“ und der hat mich in ein Training mitgenommen und meinte „Komm trainieren, kann doch was für dich sein.“ Und ich weiß noch, das war ein sehr, sehr spannendes Training. Es war ein In HOuse Training, es waren zwei. Also eine Abteilung, aber von zwei Standorten. Der eine Standort eher so ein bisschen hipp und jung und lass uns das machen. Der andere Standort sehr traditionell, sehr gebeutelt auch. Und am Ende des Trainings, am Ende von diesen drei Tagen, hatten wir wirklich Leute, die nur mit Andy geredet haben und Leute nur mit mir geredet haben. Also wir haben da ein bisschen viel Spiegel hochgehalten. Das war ein spannendes Training, aber ich habe so gemerkt Ach, das macht Spaß. Es war nicht ein einfaches Training. Also wir haben, glaube ich, während dem Training unseren Trainingsplan fünfmal umgeschmissen. Weil wir gemerkt haben, auch die Gruppe braucht was anderes, die brauchen mehr Verbindung zueinander, mehr Gespräch, sondern also immer wieder auch umschmeißen.

 

Jasmine

Und da habe ich gemerkt Ach, wenn Training so ist, dann macht’s Spaß. Also wenn es nicht ist, ich geht jetzt das Gleiche irgendwie drei Tage die Woche immer wieder runter. Das wäre nichts für mich. Aber wenn ich wirklich mit der Gruppe interagieren kann ich habe meine Lernziele, die will ich erfüllen. Natürlich. Und auf der anderen Seite kann ich aber auch auf die Bedürfnisse der Gruppe eingehen. Das Anpassen auf die Gruppe da macht’s Spaß. Genau da hat meine Reise angefangen vor. Viereinhalb Jahren war das, glaube ich, so, also auch eine lange Zeit. Ich habe mir dann auch wirklich Zeit genommen, habe einfach das eine oder andere Co-Training dazugenommen. Jetzt auch gar nicht mit dem Hintergrund Ich muss unbedingt Scrum Trainer werden, sondern ich habe für mich festgestellt, ich war dann schon selbstständig, habe Firmen beraten, habe für mich festgestellt, wenn ich ein besserer Trainer werde, werde ich auch ein besserer Coach. Und diese Verbindung, und die haben, glaube ich, noch nicht so viele. Aber ich habe einfach gemerkt, dadurch, dass.

 

Jasmine

Ich das Training modular aufgebaut habe und von den Trainern auch so Module mitbekommen habe, konnte ich diese Module auch im Coaching immer wieder verwenden. Ich bin gerade in einem Team. Wir haben ein Problem mit der Definition Of Done. Okay, da machen wir nur eine kurze Trainings Sequenz, wo wir uns von unserem Problem lösen können, zum einen sagen können okay, wir gehen jetzt auf die Metaebene, guck mal an, was ist diese Definition Of Done überhaupt? Warum brauche ich sie? Was passiert, wenn wir sie nicht haben? Dass wir dann die Entscheidung treffen können, wollen wir sie? Wollen wir sie nicht? Wenn wir sie nicht wollen, welche Konsequenzen handeln wir uns damit ein? Und wie erstellen wir jetzt eine Definition Of Done für uns? Und da habe ich gemerkt, ich werde auch einfach zu einer besseren Beraterin. Und ich kann meine Arbeit besser machen.

 

Sabine

Ja.

 

Jasmine

Genau. Und dann kamen nach und nach mehr Trainings dazu, bis ich irgendwann entschieden habe Okay.

 

Sabine

Ja.

 

Jasmine

Jetzt ist vielleicht auch gut genug. Jetzt kann ich auch diesen Schritt zum und zum Scrum Trainer gehen. Das braucht bei mir persönlich immer ein bisschen länger.

 

Sabine

Ja, ich kann mir gut vorstellen, dass du dann Trainings Sequenzen in deinem Coaching einbringst. Auch umgekehrt. Wir haben gemeinsam auch das Training gemacht. Das habe ich auch noch in Erinnerung, dass wir halt sehr viel so auch so oft eine Erfahrung damit einbringen konnte, was natürlich für die Trainings Teilnehmenden dann auch sehr spannend ist, so mitzukriegen von jemandem, der eben auch in der Praxis ist. Also apropos, dieses Training damals, das war ja alles beim Training nur für Scrum Masterinnen als angehende, das habe ich noch in Erinnerung, dass wir uns vorgenommen haben, auch mit der Anna Huda damals zusammen. Wir machen das als drei Frauen für lauter Frauen. Welche Erinnerungen hast du da noch dran?

 

Jasmine

Also ich weiß noch, ist vielleicht auch ein bisschen mit dem Tränchen anzufangen, dass die Frauen dann meinten ach ja, sie werden auch in ein anderes Training gegangen und es hätte einfach grad so gepasst. So okay. Auf der anderen Seite habe ich gemerkt, wir hatten einfach eine unglaublich schöne Atmosphäre und ich habe das Gefühl, dass auch Frauen, die ich in sonstigen Training wahrscheinlich als sehr zurückhaltend wahrgenommen haben, sich in der Atmosphäre sehr viel mehr getraut haben. Also es. Wenn wir jetzt aus einer psychologischen Perspektive draufgucken, dann sagen wir ja immer, diverse Gruppen sind besser. Also wo wir auch wirklich mischen. Als so rein uniforme Gruppen. Nichtsdestotrotz hatte ich das Gefühl, diese Atmosphäre hat hat uns sehr gut getan. Wir hatten echt ein sehr schönes Training. Also da kann ich mich dran erinnern und auch, ähm, wir haben ja da auch so Coaching Sequenzen drin gehabt. Wir haben zum Beispiel auch ein Troika Consulting noch mal gemacht. Ich fande die Frauen sind da sehr aus sich rausgegangen, auch wieder in die Lösungsfindung.

 

Jasmine

Was könnte ich denn jetzt in diesem Kontext machen, der noch nicht perfekt ist? Genau. Okay, ich weiß nicht, ob das so deine Erfahrung oder deinen deine Erinnerung widerspiegelt.

 

Sabine

Das kann ich voll nachvollziehen und so ist es mir auch gegangen. Also ganz ähnliche Eindrücke, die du auch mitgenommen hast. Und wir haben uns ja damals entschieden, dass wir das erstmal dabei belassen. Wer hat versucht werden zu wollen? Einfach noch mal ausprobieren.

 

Jasmine

Und sagen Genau, man kann vielleicht es online dann noch mal einfacher oder?Also auf jeden Fall. Für mich war das ein bemerkenswerter Moment, so ein besonderes Training. Das hat einfach dadurch besonders herausgestellt und hat mit drei Trainerinnen, drei Trainerinnen und sogar nicht mal mit Theater zu machen. Nur mit Frauen. Für dich gab es sicherlich auch noch andere bemerkenswerte Momente in deiner Trainer Laufbahn. Was war denn da sonst noch irgendwelche Dinge, wo du sagst Oh, das war ein toller Impuls und da habe ich wirklich was mitgenommen oder vielleicht auch was wo was man nicht so gut funktioniert hat und wo du doch was draus gelernt hast.

 

Jasmine

Hmm.

 

Jasmine

Ich glaube, ich durfte mich selber wirklich finden in dieser Trainerrolle und das fand ich sehr spannend und das ist vielleicht auch für diejenige, die sich auf den Weg begeben. Ich habe angefangen mit: Ich kann das doch schon so und ich habe jetzt schon ganz viel unterrichtet. Ich weiß was zu Scrum. Das geht schon so und dann in diese bewusste Inkompetenz rein zu kommen. So okay, es ist nicht schlecht was du machst, aber da gibt es noch viel mehr. War cool. Also sobald ich mich entschieden habe. Okay, jetzt werde ich CST. Und mich dann auch noch mal auf verschiedene Trainer waren’s dann halt weil es gibt ja fast nur männliche Trainer einzulassen und zu gucken, okay, was sind diese verschiedenen Stile, wer trainiert wie und da gibt es wirklich vom fast schon Improvisations-Trainer bis hin zum sehr standardisierten gescripteten Trainer gibt es alles und es hat alles so seine Berechtigung und es hat alles. Es funktioniert für die jeweiligen Trainer und auch für die jeweiligen Gruppen. Ich glaube die meisten Teilnehmer kommen oft über Mund zu Mund Propaganda und die wissen dann auch schon ein bisschen, wie der Trainer ist und mich da drin zu finden.

 

Jasmine

Wer bin ich? Da drin war spannend und da gab es natürlich auch viele Fettnäpfchen, was ausprobiert habe, was der andere gemacht hat und dann so gemerkt habe so. Das weiß ich so gut, dass passt jetzt gar nicht zu mir.

 

Sabine

Hast du da ein Beispiel?

 

Jasmine

Ähm, ja. Zum Beispiel ein Trainer, der kann unglaublich gut Geschichten erzählen und er übt die auch ständig. Und wenn ich das aber versuche zu tun, dann wirkt das auf einmal sehr überzogen. Und dann weiß mein Gegenüber gar nicht mehr Ist das jetzt Jasmines Geschichte oder erzählt sie das jetzt einfach oder will sie sich profilieren? Und das führt dann zu ganz komischen Situationen, besonders im Co-Training. Und genau da für mich so zu merken Wo bin ich authentisch, welche Geschichte kann ich authentisch erzählen? Wie? Ich habe einen großen Glaubenssatz von ich bin nicht lustig. Und meine Trainings sind dann sehr ernst, oder das ist, so mein Glaubenssatz, da drin, dass ich da viel zu ernst bin. Und dann habe ich versucht, sehr lustige Geschichten da reinzubringen. Da hab ich gemerkt, die funktionieren so gar nicht. Und meine Trainings sind, ohne dass ich sie versuche lustig zu machen sehr viel lockerer. Genau. Und auf der anderen Seite bin ich aber dankbar für diese Erfahrungen. Ich finde, übers Kopieren lernen wir ja auch ganz viel.

 

Jasmine

So, wenn ich jetzt meine Kinder angucke, wie viel die kopieren. Und dann darin rausfinden. Okay? Was? Was bin ich da drin? Was? Was will ich überhaupt?

 

Sabine

Na ja. Du hast schon über den unterschiedlichen Stil gesprochen, den unterschiedliche Trainer auch haben und auch ein bisschen was über deinen eigenen Stil erzählt, du hast gesagt bei dir geht es immer sehr viel um das Erleben und du bist nicht so ein kognitiver Mensch. Und du hast gesagt, du bist nicht lustig. Was ist denn sonst noch dein – wie würdest du deinen Stil beschreiben?

 

Jasmine

Ähm. Ich verknüpfe sehr viele verschiedene Bereiche. Also ich bin, glaube ich, ich bin sehr enthusiastisch, weil für mich Scrum einfach funktioniert. Und da bin ich sehr, sehr enthusiastisch. Das ist ein Teil von mir von meinem Stil. Der zweite Teil ist, dass ich im Training wirklich gucke, dass wir zusammen Scrum erleben. Gerade für die Teilnehmerinnen, die noch nie in einem Scrum Team waren oder die das noch nie funktionierend erlebt haben, ist das oft eine sehr gute Referenz Erfahrung. Wie hat sich das angefühlt? Wie fühlt sich denn ein Planning an, wenn wir in kompletter Unsicherheit sind? Es fühlt sich nicht toll an, aber irgendwie kommt trotzdem was raus und aus diesen Gesprächen kommt was raus. Also dieses sehr nah wahre, sehr, sehr reale. Das ist glaube ich was Besonderes an meinem Stil und dass ich halt die Psychologie immer wieder rein verknüpfe. Es gibt wenig Trainer, die jetzt auch einen psychologischen Hintergrund haben. Viele haben noch einen Coaching Hintergrund, aber dass ich da auch wirklich psychologische Modelle etc. wieder rein integriere.

 

Jasmine

Da wird es ein bisschen kognitiver. Ich weiß nicht, wenn man diese 4 -C Modell von Learning From The Back of the Room kennt, da schafft man immer eine Referenz Erfahrung. Oft macht man da ein Modell erleben und noch mal Transfer. Was ich ganz oft mache ist Referenz-Erfahrung, Erleben, Modell, Transfer, weil ich einfach merke, das ist so, wie ich lerne. Und für viele ist es einfacher, wenn wir in einem Raum sind, der ganz neu ist. Wenn wir in einem Raum sind, wo wir an vieles anknüpfen können, dann geht das mit dem Modell und dann der Erfahrung ganz gut. Aber wenn es ganz Neue ist wird’s, schwieriger. Genau.

 

Sabine

Du kannst mit dem Modell auch mehr anfangen. Wenn du das vorher schon mal erlebt hast, dann weißt du, wo du mit dem Modell andocken kannst du

 

Jasmine

Genau.

 

Sabine

Wann würdest du sagen Fühlst du dich so richtig glücklich und zufrieden? Was, wenn du dann Training gegeben hast, dass du sagst, das war eine runde Sache?

 

Jasmine

Ich glaube, wenn die Teilnehmerinnen rausgehen und für sich ein gutes Verständnis haben. Was Sie anwenden können, wie sie es anwenden können, was Ihre nächsten Schritte sind. Ich muss nicht Teilnehmer überzeugen, Scrum anzuwenden in einem Training. Für mich ist es völlig legitim, dass jemand nach zwei oder drei Tagen Training sagt Es war eine gute Erfahrung und ich weiß, für meinen Bereich passt es nicht. Dann ist es völlig legitim und dann bin ich auch glücklich so bzw. Ich hatte auch mal einen Teilnehmer, der macht Bau-Unterführungen. Der hat auch schon gesagt, ich wurde jetzt hier hingeschickt. Ich weiß gar nicht, was ich damit machen soll. Sobald eine Baugenehmigung da ist in Iteration planen. Und nach nur 3/4 Jahr hat er meine E Mail geschrieben und gesagt , okay, ich kann nicht so viel anwenden, aber Dailies und Retro mache ich und die sind der Burner. Da haben wir auch ein Telefonat geführt haben. Ich sag dir was zu, die sei gesagt jeden Freitagabend mit einem Bier, wichtig. Es gibt ein Feierabend-Bier und dann machen wir ne Retro für ne Stunde und gucken, was können wir verbessern für die nächsten zwei Wochen?

 

Jasmine

Was wollen wir anders machen? Was lief nicht so gut und ich denke, das macht mich glücklich. Du hast irgendwas gefunden, was deine Arbeitszeit verbessert, die Arbeitswelt von deinen Mitarbeitern verbessert. Das ist super und auch für deine Firma Mehrwert generiert.

 

Sabine

Ja, ja, und das ist ja auch ein schönes Beispiel dafür, dass man sich so und so ein Bestandteil aus dem Scrum Framework raus greifen kann. Und das hätte dieser Mensch von dem erzählt, das auch nicht gemacht, wenn er nicht wirklich interessiert an Verbesserung gewesen wäre, bereit gewesen wäre, zusammen mit den Leuten, mit denen er zusammenarbeitet, sich weiterzuentwickeln. Und wenn das was ist, was du ihm vermitteln konntest. Aha darum geht es letztendlich bei Scrum. Und erst ein paar Tools an der Hand, mit denen wir das machen kannst in deinem Bereich, dann ist es wirklich schöner Erfolg.

 

Jasmine

Ja, ich glaube auch nicht erlebt hätte von ja, wir machen ne Retro, wir machen aber nicht eine Retro im Sinne von wie man es in anderen Trainings vielleicht macht. Ich sage, was mir hier alles stinkt, lieber Trainer und du machst dann für mich bitte, dass es für mich passt, sondern wir machen Retro im Sinne von – Wir gucken, was stinkt mir denn hier oder was passt gerade nicht, was fühlt sich noch nicht stimmig an für mich und und uns als Gruppe. Und wir suchen zusammen in unserer Verantwortlichkeit Lösungen dafür. Und da bin ich genauso involviert wie in dem Sagen, was mir nicht passt. Und ich glaube, diese Erfahrung war für diesen Teilnehmer ganz wichtig. Dieses Ah, eine Retro bedeutet nicht – Frag meine Mitarbeiter, was alles nicht passt und ich muss dann springen, sondern wir finden zusammen Lösungen. Und die sind wahrscheinlich besser als die, die ich mir selber überlege.

 

Sabine

Ja, Jasmine, dann sind wir schon langsam am Ende von unserem Gespräch. Hat mich sehr gefreut, mit dir zu reden. Ich denke, dass auch unsere Zuhörer oder Zuschauer einen guten Eindruck davon bekommen haben, wie du bist als Trainerin. Und wie gesagt, ich freue mich total, dass du jetzt hier auch auf dem nicht nur deutschsprachigen, sondern überhaupt auf dem Agilen Markt als Trainerin unterwegs sein kannst mit deiner Zertifizierung. Also noch mal schönen herzlichen Glückwunsch dazu.

 

Jasmine

Dankeschön.

 

Wie überzeuge ich mein Gegenüber?

Ich habe doch die besseren Argumente?

 

Die Konfrontation und Auseinandersetzung mit meinem Gegenüber ist meistens nicht so fruchtvoll, wie ich mir das erhofft habe.

 

Wir sezieren einen spannenden Artikel zum Thema und schauen hinter die psychologischen Gegebenheiten, wieso uns Fakten meistens nicht überzeugen und was das für uns als agile Coaches, Scrum Master, Manager und Teammitglieder heißt.

Jasmine

Herzlich willkommen zum Agile Growth Podcast! Schön, dass du mit dabei bist. Heute beschäftigen wir uns mit dem Thema, warum Menschen ihre Meinung einfach nicht ändern, obwohl ich die geilsten Argumente habe.

 

Sprecher

Herzlich Willkommen zum Agile Growth Podcast, dem Podcast für alle Agil Interessierten mit hilfreichen Ideen und erprobten Werkzeugen, die dich weiterbringen. Von und mit den Two Agilists.

 

Kai

Herzlich willkommen zum Agile Growth Podcast – Hier sind Jasmine und Kai und wir helfen Menschen dabei, die versprechen Agiler Vorgehensweisen in der Praxis einzulösen. Ohne IT-Wissen vorauszusetzen. Schön, dass du zuhörst zu dieser Folge.

 

Jasmine

Wir sind angekommen im Jahr 2022. Irgendwie zumindest für uns ist das Jahr 2021 irgendwie verflogen. Gar nicht so richtig präsent gewesen. Und deswegen freuen wir uns auf einen frischen, bewussteren Start ins Jahr 2022. Wir haben hier ganz, ganz viel vor, haben uns tolle Ziele gesetzt und ich hoffe, du auch. Und eins unserer Ziele ist wieder ganz, ganz regelmäßig zu podcasten, zu Themen, die uns gerade umtreiben und beschäftigen. Und vielleicht bist du auch schon in der Situation gewesen, du hast ein Gegenüber gehabt oder viele Gegenüber. Du hast dich vorbereitet. Du hast gute Argumente zur Hand, warum wir jetzt die eine oder die andere Entscheidung treffen können. Und dein Gegenüber hat einfach eine andere Meinung. Und es lässt sich auch nicht umstimmen, obwohl du ganz objektiv die besseren Argumente hast und vielleicht sogar recht hast.

 

Kai

Jetzt gibt es ja schon auch viel Debattenkultur oder Argumente oder auch Talkshows, wo man sieht, dass die Leute irgendwie Argumente vorbringen. Und das ist ja auch eine ganz alte Tradition, dass man um Dinge argumentiert, um seinen Punkt zu machen. Und da geht es ja darum, wenn dann zwei Menschen miteinander sprechen, wer gewinnt? Also eigentlich so der Austausch miteinander, darum wer hat jetzt Recht? Und irgendwie gibt es ja auch das Zuhören, wo es darum geht, den anderen zu verstehen, also beim Gegenüber zu sein, was irgendwie was anderes ist, als in diesen Wettstreit miteinander zu gehen.

 

Jasmine

Und wenn du dich jetzt fragst Was hat denn das jetzt so mit Agilität und so weiter zu tun? Wir finden, sehr, sehr viel, weil eine der Fragen, die uns ganz oft gestellt wird, sei es beim Kunden oder in öffentlichen Trainings, ist. Habt ihr eine Argumentationshilfe für uns, wie wir Führungskräfte, Vorstände, Geschäftsführer, füge ein, was du einfügen möchtest, Teams überzeugen können, warum Scrum gut ist. Warum Agil gut ist. Warum wir Kanban machen sollen. Und ja, natürlich haben wir das. Wir haben schlagende Argumente. Wir bauen im Training ja ganz viel Wissen auf, warum in gewissen Kontexten Agilität gut ist, warum sie uns hilft, warum die Werkzeuge, die wir in diesem ganzen Agile Space haben, uns helfen, der Komplexität in einer komplexen Domäne zu begegnen. Und nichtsdestotrotz helfen sie dir nichts, sobald du in diese Debatte einsteigt von – wer gewinnt. Darum soll diese Podcastfolge gehen.

 

Kai

Inspiriert hat uns ein Artikel dazu von James Clear. Und der heißt – Why Facts Don’t change our Minds. Und so die grundlegende Aussage daran ist, dass wir ja schon auch ein Interesse an Wahrheit haben, aber es unglaublich hilfreich ist, als Mensch auch einem sozialen Tribe anzugehören, also einer Gemeinschaft von anderen Menschen – und die Frage ist sozusagen, was nützt einem eine Information? Und manchmal tauschen wir deswegen ganz gerne die Wahrheit aus gegen etwas, was auch praktisch ist, zu glauben und zwar sozial praktisch zu glauben. Etwas, was uns einen gewissen Stellenwert innerhalb einer Gruppe bringt oder mit den Menschen, mit denen wir da zusammen sind. Da schludern wir dann so ein bisschen und verzichten dann auch mal darauf, vielleicht so das wirklich Wahre oder objektive Wahre zu glauben, sofern es das gibt. Da könnte man jetzt noch ein bisschen philosophisch zu werden, weil wir eben auch einen Vorteil davon haben, einer Gruppe zuzugehören. Und dieser Vorteil ist eben ein ganz alter, weil wir Menschen so lange schon aufeinander angewiesen sind und ja auch so geboren werden als Resonanzwesen,

 

Kai

Wesen, die schon von der ersten Minute an Mama oder Papa brauchen, um uns einen eigenen präfrontalen Cortex zusammenzubauen. Also dieses Zusammengehören gibt es schon ganz lange und das ist auch eine wichtige Triebfeder für uns, dass wir uns nicht explodieren von einem Tribe. Und weil das eben treibt, machen wir manchmal auch einen Kompromiss bei der Wahrheit.

 

Jasmine

Und das heißt jetzt nicht, dass wir uns dann selber belügen oder dass ein bewusster Prozess ist, sondern das ist ein sehr, sehr unbewusster Prozess. Ich habe meine Daten und Fakten, auf die ich meine Meinung beruhe, in meinem Kopf und wahrscheinlich entsprechen die nicht unbedingt der objektiven Wahrheit, insofern es die denn gibt, weil wir Menschen einfach und da gehen wir jetzt so in diese Informationsverarbeitung, etc., Kahnemann hat da ganz viel coole Sachen dazu gemacht, weil wir Menschen einfach auch nicht gut sind in der Informationsverarbeitung. Wir können große Datenmengen nicht gut verarbeiten. Wir glauben Geschichten eher, als dass wir Zahlen glauben etc. Wir sind nicht sehr rational in der Datenverarbeitung per se schon mal! Und dann habe ich meine Fakten, auf die meine Meinung beruht. Die ist in meiner Historie drin. Das ist unterbewusst. Darauf greift mein Gehirn zurück und die bindet mich natürlich auch an die Gruppe, der ich zugehöre. Zum Beispiel in meiner Firma. Also wenn du dieses Argument hörst von – das haben wir immer schon so gemacht. Für viele ist das ja so das – boah, das ist voll das Totschlagargument, oder

 

Jasmine

Oh, mit so Leuten kann ich nicht arbeiten. Da ist die Frage – was hilft mir, wenn ich dann so ein Ausruf mache? Oder was hilft mir diese diese Haltung dagegen? Ich arbeite gerne mit solchen Leuten zusammen. Triggert mich das? Ja, es triggert mich enorm. Nervt es mich, dass die Leute diese Einstellung haben? Ja, natürlich. Aber was mir diese Einstellung eigentlich sagt, ist – ich fühle mich gerade wohl, wo ich bin. Ich gehöre hier einer Gemeinschaft zu, die Dinge in einer gewissen Weise, geregelter Weise für mich tun. Und das gibt mir eine Einordnung. Das hilft mir, meinen Alltag zu bestreiten. Und jetzt kommst du und sagst: Wir tun’s anders oder wir sollen es anders tun oder das, was wir getan haben, ist schlecht. Das heißt, was ich dann mache, wenn ich komme und sage: Komm, lass jetzt mal Agile oder lass mal Scrum. Und der andere sagt nö, wir haben das immer schon so gemacht, ist zu sagen – Bitte verlass mal deine Gemeinschaft und komm zu meiner Gemeinschaft und mach Scrum.

 

Jasmine

Das ist ein Riesenschritt für einen Menschen.

 

Kai

Deswegen starten wir auch ganz oft bei der Einführung von Agilität, indem wir das dann ja einfach mal begreifbar machen in Simulationen und so weiter und dann einfach die Frage stellen – Wollt ihr das in diesem Team machen? Und mit der Entscheidung, es dann zu machen, sind wir natürlich auch in einer Form von neuer  „Schicksalsgemeinschaft“ dann, für dieses Experiment, diese Zeit, wo wir das mal ausprobieren wollen. Also da ergibt sich dann schon auch ein mitverändern. Das Team ist ja schon eine vielleicht vorher bestehende Gemeinschaft, wenn sich das jetzt nicht gerade für das Projekt neu formt und das dann da mitzugehen und auch wir, die sich als Agile Coaches da einfügen in diese Gemeinschaft, sind dann Menschen, die das beeinflussen. Und wahrscheinlich ist es am einfachsten zu lernen von den Leuten, die so 98 prozent ähnlich sind. Zu mir selbst – das ist auch was, was der James Clear da in seinem Artikel herausstellt. Weil wenn man eh schon so nah dran ist an dem anderen und spürt, wir schwingen gut miteinander, dann kann man auch mal eine Idee mehr auch noch mitnehmen.

 

Kai

Das ist dann gar nicht so schwierig, das dann noch für sich zu verinnerlichen. Das heißt so dieses direkte Umfeld und vielleicht hast du dieses Sprichwort auch schon mal gehört, ist so. Ja, du wirst im Durchschnitt zu dem Menschen, der so im Schnitt ist wie die fünf, sechs Leute, die ganz nah um dich herum sind. Deswegen prägt ja auch Familie so sehr, wenn man groß wird oder sonst in der Firma. Nur wenn du ein kleines Unternehmen das was eine sehr starke Startup ähnliche Kultur hat, dann prägt das gegenseitig sehr, sehr stark. Oder deine Team Kultur, die dich täglich mit beeinflusst. Das sind alles so Quellen, von denen du Neuigkeit, Innovation viel, viel leichter adaptieren kannst, wenn du dich dem zugehörig fühlst.

 

Jasmine

Also was machen wir jetzt mit dem Menschen, der sagt – das haben wir hier immer schon so gemacht? Wir versuchen zu ergründen, was sind denn die positiven Dinge, die für dich rausgesprungen sind oder rausspringen, wenn du Dinge so tust, wie du sie immer schon gemacht hast? Welcher Gemeinschaft gehörst du gerade an, die die Dinge so tut und warum tut ihr sie so? Und dann mache ich eben nicht das, was viele machen – ich hau mit Fakten dagegen und sage, warum das alles doof ist, was sie tun. Weil was ich dann ja tue ist zu sagen: Deine Gemeinschaft ist doof, deine Gruppe ist doof. Was du bis jetzt getan hast, ist doof. Sprich ich gehe direkt auf das Selbstkonzept des Menschen, auch wenn ich mir das Schönrede und das verrationalisiere und sage Boah, aber rational gesehen ist es ja alles doof. Also bin ich im Recht und dann bin ich wieder in diesem Streit drin. Wer hat jetzt recht? Aber beide, wie wir beide, haben subjektiv für uns Recht. In unserer Gemeinschaft macht das, was wir tun halt einfach mehr Sinn.

 

Jasmine

Also das zusammen zu suchen. Wo sind wir uns denn ähnlich? Wo haben wir gleiche Interessen? Wo können wir gemeinsam eine Interessengemeinschaft bilden, um dann zu gucken – wie tun wir die Dinge anders? Wo können wir im Sinne der Interessensgemeinschaft vielleicht Dinge loslassen, die wir immer schon so getan haben und neue Dinge dazunehmen? Weil dann macht es viel weniger Angst. Die Angst, die in unserem Gehirn entsteht, ist, wenn ich die Dinge jetzt nicht mehr so tue, wie wir sie immer getan haben, und meinen Kollegen, meinen Teamkollegen, meiner Abteilung, wem auch immer ich dazugehöre, den Rücken drehe, dann bin ich auf einmal alleine. Und was unser Gehirn dann damit macht, ist – dann bin ich nicht mehr überlebensfähig. Wir wissen natürlich rational, dass das Murks ist. Natürlich sind wir überlebensfähig. Ist vielleicht doch nicht mehr so schön, aber überlebensfähig bleiben wir. Aber unser Gehirn weiß es nicht.

 

Kai

Ich hatte mal in so einer Multi Teams Scrum Einführung das Vergnügen mit dem Team zu arbeiten, wo die letzten Mohikaner irgendwie drauf waren. Also die Leute die irgendwie so weg gesprungen waren immer die irgendwie absolut keine Lust hatten. Mohikaner kann man eigentlich noch sagen heutzutage? Ich weiß nicht wie man die, die noch übrig waren und die, die eigentlich gar keine Lust hatten auf Scrum. Und ja, da war dann irgendwie einer drin, der wirklich auch relativ offen kundgetan hat, dass er das ziemlich blöd findet, was hier gerade alles in der Firma passiert. Und ich hatte, das ist auch schon eine ganze Weile her, ich hatte. Ich hatte damals den Impuls, den muss ich irgendwie überzeugen, den muss ich irgendwie reinziehen, den muss ich irgendwie überreden und bin dann noch abends länger geblieben und habe immer geguckt, dass wir irgendeine Verbindung miteinander finden. Wir hatten nicht so eine unglaublich gute Chemie miteinander, aber das kam dann so mittelfristig und – lange Geschichte kurz. Das hat bis zum Ende nicht wirklich funktioniert. Und dazu gibt es auch einen spannenden Punkt in dem Artikel von James Clear, weil der sagt Na ja, die heißesten Debatten gibt es halt zwischen den Leuten, die an dem unterschiedlichen Ende des Spektrums sind, also Gegner von Agile und Agile Fans, könnte man sagen.

 

Kai

Aber das meiste Lernen passiert zwischen den Leuten, die sich ähnlich sind, also die eher nah beieinander sind in den Gedanken. Wenn man das mal weiterspinnt, ist halt so die Frage als Agile Coach oder jemand, der auf so einen Agilen Raum irgendwie einwirken will. Mit wem beschäftige ich mich vorwiegend? Wo stürze sich die meiste Energie drauf? Und auch wenn wir diesen Impuls immer wieder haben, dass wir Leute, die im Widerstand sind, reinziehen wollen, die einfach überzeugen wollen, noch ein bisschen länger mit ihnen reden, damit das irgendwie funktioniert, ist das Fruchtbarere doch mit denen zu arbeiten, die wollen oder zumindest mal bereit sind, etwas auszuprobieren und den anderen denen irgendwie zu begegnen in dieser Konfrontation. Aber da jetzt den Fokus darauf zu legen, das hat auch bei dem Team damals gar nichts gebracht, da die meiste Energie drauf zu setzen.

 

Jasmine

Und das hat auch wieder einen Hintergrund. Warum geschieht das meiste Lernen bei Menschen, die mir doch ähnlich sind oder? Oder die irgendwo in diesem Spektrum an Gegensätzlichkeit nicht ganz an den Außenquellen sind? Das ist, weil mein Selbstkonzept das gar nicht integrieren kann. Das ist so ein bisschen. Ich habe im Studium haben sie mir damals das Beispiel genannt, das für mich total plausibel ist. Ich weiß nicht, ob es für dich plausibel ist, aber wenn man einem Menschen ein Kompliment macht und dieser Mensch ein gewisses Selbstkonzept hat und dieses Kompliment sehr, sehr weit außerhalb dieses Selbstkonzept ist und das es übrigens auch mit jeglichem Feedback so dann entsteht eine kognitive Dissonanz in dem Menschen und etwas, was unser, unser Gehirn, unser Sein überhaupt nicht mag, sind kognitive Dissonanzen. Und damit können wir nicht gut umgehen, wenn die zu groß sind. Das heißt als ganz einfaches Beispiel – wenn ich mich als Mensch als eher dick empfinde oder als  fülliger empfinde und ich das Kompliment bekomme Oh, du siehst total schlank aus oder du siehst total gut aus.

 

Jasmine

Dann erzeugt das eine Dissonanz in mir drin. Und  das will mein Gehirn nicht und deswegen kann ich auf zwei Arten damit umgehen als Mensch. Entweder bin ich dann selbst abwertend dadrin. Ah, siehst du. Der oder die macht das nur, weil der oder die nicht will, dass du weißt, wie fett du eigentlich bist. Also wirklich, diese Selbstabwertungs-Spirale könnte ich gehen oder ich kann die andere Spirale gehen, das ich meinte, dass ich den Kompliment oder Feedback-Geber abwerte und sage, der hat ja überhaupt keine Ahnung. Jetzt wenn es darum geht, eine Meinung zu ändern, werde ich wahrscheinlich nicht selbst abwertend einhergehen. Wenn wir an einem ganz anderen Spektrum von einer Meinung sind, also Anti-Agilisten gegen Agilisten, sondern die werden anfangen die Agilisten abzuwerten. Und da kommen wir ja ganz schnell in diese Stereotypisierung von ähm, ich weiß nicht, das sind die Baumumarmer und die Hippies. Oder die haben ja von nichts eine Ahnung. Die wissen ja gar nicht, wie richtiges Business läuft, oder

 

Jasmine

Ist ja alles schön und gut, wenn man sich nur um Innovations Zeugs kümmern kann. Aber wir bringen halt das Geld rein hier. Was auch immer ihr in eurer Firma alles hört zu den Agilisten vs. die andere Stereotypisierung und das ist ja das ist eine ganz aktive Abwertung des Gegenübers, der äußeren Gruppe, die wir tun. Das sind die, die nie was verändern wollen. Die stehen der Innovation im Weg. Ja, die griesgrämigen alten weißen Männer und so weiter. Und wenn unser Gehirn das schon macht, das Gegenüber so abzuwerten, dann sind wir natürlich auch nicht offen dafür, dass wir vom Gegenüber lernen. Das heißt zwei Punkte hier – das eine ist Ich kann mich hinterfragen – wo, wo investiere ich meine Energie rein, von wem kann ich lernen, wer kann von mir lernen? Und das vielleicht für mich auch immer weiter auszuweiten und auch sehr, sehr achtsam als zweiter Punkt damit zu sein – wo werte ich andere Menschen ab? Und vielleicht mal ganz bewusst dahin zu gehen, wo ich Menschen abwerte und sage – Okay.

 

Jasmine

Wenn ich gerade weiß, dass ich das tue. Vielleicht kann ich da ins Gespräch gehen und einfach mal von diesem Menschen lernen. Und es geht nicht darum, dass ich die Meinung des Menschen ändere oder viel von mir preisgebe, sondern dass ich einfach mal lerne. Warum ist der an dem Punkt, wo er ist? Welcher Gemeinschaft gehört er an? Was für positive Effekte entstehen durch die Haltung, die dieser Mensch hat, also wirklich zu lernen – diesen Abwertungen ganz, ganz, ganz bewusst zu begegnen. Und dann mit dieser Information zurück zu gehen und zu gucken- und was müssten wir diesem Menschen bieten, damit er einen Schritt auf uns zukommen kann?

 

Kai

Ja, Widerstand ist auch eine Information. Sagen die Systemiker ja gern dazu. Das ist natürlich manchmal emotional einfach herausfordernd, dann trotzdem mit der Konfrontation umzugehen. Da greift dann wieder das ganze Thema – wie bin ich sozialisiert in Konflikten? Wir hatten auch schon mal eine Podcastfolge über Konflikte, um dieses Störfeuer der Auseinandersetzung einfach auszuhalten und dann in diese konstruktive Phase reinzugehen, nachdem man es verarbeitet hat und zu schauen, wie es mir das gerade beschrieben hat. Wie kann ich da eine andere Form von Gemeinschaft schaffen? Wie kann ich mich an den gleichen Tisch setzen? Und ich glaube, das ist jetzt in der Corona-Zeit, mit dem an den gleichen Tisch setzen, mit digitalen Kaffees, ja, irgendwie funktioniert das auch. Das war noch so ein bisschen einfacher, als wir so in den gleichen Firmengebäuden rum gewandelt sind und uns tatsächlich vielleicht mal in der Cafeteria oder beim Essen hingesetzt haben. Jetzt muss man halt schauen, wie kriegt man das irgendwie hin, je nach aktueller Firmenkultur.

 

Jasmine

Wenn ich persönlich das mache, muss ich in einem sehr, sehr guten Zustand sein und da darf ich auch sehr achtsam mit mir selber sein. Kann ich das heute gerade oder kann ich das nicht? Weil wenn ich gerade nicht in einem guten Zustand bin, wenn unsere Tochter uns nachts aufgeweckt hat und ich nicht ausgeschlafen bin etc., dann ist es für mich sehr, sehr schwierig, mit Menschen umzugehen, die sehr anders sind als ich. Da habe ich gelernt, darf ich sehr ehrlich zu mir sein. Das kann bei jedem anders sein. Bei mir ist es so, das heißt, ich bin da sehr achtsam mit mir selber. Wann kann ich das leisten? Wann möchte ich das leisten und und wann kann ich das gerade nicht leisten? Also wann? Wann brauche ich auch einfach mal die heile Welt? Wann umgebe ich mich mal einfach mit meinen Agilisten? Und wir erträumen uns die Welt da draus nehm ich auch Kraft? Und das ist auch ein Teil dieses sich Gemeinschaften aufbauen und dann Leute in die Gemeinschaft einladen und dieses sich    zusammen an einen Tisch setzen.

 

Jasmine

Das ist in Corona sehr viel schwieriger geworden, aber das ist eine ganz, ganz, ganz einfache und gängige Methode, wie wir Gemeinschaft stiften können. Und das vielleicht jetzt schon zum Abschluss von diesem Podcast. Wenn wir wollen, dass Menschen ihre Meinung ändern, dann geht es oft nicht darum, ihnen Fakten vorzuführen, sondern es geht darum, eine neue Gemeinschaft für sie zu erschaffen. Und egal welche Meinung wir haben, wenn wir es schaffen, eine gemeinsame Mahlzeit einzunehmen, ein Spaziergang zusammen zu machen und da dürfen wir bestimmt einfach noch lernen. Wie funktioniert es Corona konform? Oder hoffentlich ist dann die lange nur Homeoffice Zeit auch irgendwie mal vorbei. Dass wir immer wieder so Gemeinschaftsstiftende Elemente integrieren können, weil dann wenn wir eine neue Gemeinschaft zusammen erschaffen, dann sind wir auch bereit unsere Meinung zu ändern und eine gemeinsame neue Wahrheit für uns zu finden.

 

Kai

So, damit hoffen wir, dass wir wieder ein weiteres Puzzlestück gegeben haben, was du für dich benutzen kannst. Zur Arbeit in agilen Umfeldern oder solche, die es noch werden dürfen. Und wenn du es lieber ein bisschen praktischer hättest und ein bisschen mehr Fleisch am Knochen oder Seitan am Reis, dann ist vielleicht die beste Variante dafür unsere liebevoll erdachte und konzipierte Agile Coach Ausbildung, die jetzt im Februar startet im Pilot. Gibt es ein zwei -Wochenend Seminar dazu. Von Freitag bis sonntags, wo wir sehr intensiv uns reinknien in die Themen, die einen Advanced Certified Scrum Master beschäftigen. Und wenn du dazu noch Fragen hast, guck einfach auf agilegrowth.de , da haben wir schon relativ viel dazu geschrieben und schreib uns an, so dass wir Fragen im direkten Dialog mit dir einfach klären können.

 

Jasmine

Wir wünschen dir eine ganz wunderbare Woche und freuen uns aufs nächste Mal.

 

(X-Mas-Bonus) – Der Scrum-Guide als AudioBook (Deutsche Version) – Gelesen von Kai H. Simons

Der Scrum Guide enthält die gültigen Spielregeln, nach denen das “kollaborative Spiel” der Scrum-Produktentwicklung gespielt wird. 


In der deutschen Fassung vom Oktober 2020 sind wieder einige Änderungen vorgenommen worden, um den Einsatz des beliebten Scrum-Management-Rahmenwerks zu optimieren. 

Der Sinn des Scrum Guides

 

Wir haben Scrum in den frühen 1990er‐Jahren entwickelt. Wir haben die erste Version des Scrum Guides im Jahr 2010 geschrieben, um Menschen auf der ganzen Welt dabei zu helfen, Scrum zu verstehen. Wir haben den Guide seitdem durch kleine, funktionale Aktualisierungen weiterentwickelt. Wir stehen gemeinsam dahinter. Der Scrum Guide enthält die Definition von Scrum. Jedes Element von Scrum dient einem bestimmten Zweck, der für den Gesamtwert und die mit Scrum erzielten Ergebnisse wesentlich ist. Den Kern oder die Grundideen von Scrum zu verändern, Elemente wegzulassen oder den Regeln von Scrum nicht zu folgen, verdeckt Probleme, begrenzt den Nutzen und macht Scrum im Zweifel sogar nutzlos.    Wir verfolgen den zunehmenden Einsatz von Scrum in einer stetig komplexer werdenden Welt. Wir sehen demütig, wie Scrum in zahlreichen Bereichen komplexer Arbeit über die Softwareentwicklung hinaus ‐ wo Scrum seine Wurzeln hat ‐ eingesetzt wird. Während sich die Verwendung von Scrum weiter verbreitet, wird diese Arbeit von Entwickler:innen, Forscher:innen, Analyst:innen, Wissenschaftler:innen und anderen Spezialist:innen getan. Wir verwenden das Wort “Developer:innen” in Scrum nicht, um jemanden auszuschließen, sondern um zu vereinfachen. Wer auch immer vom Einsatz von Scrum profitiert, soll sich angesprochen fühlen. Beim Einsatz von Scrum können Muster, Prozesse und Erkenntnisse angewendet und entwickelt werden, die zum Scrum‐Rahmenwerk passen, wie es in diesem Dokument beschrieben ist. Ihre Beschreibung geht über den Zweck des Scrum Guides hinaus, da sie kontextabhängig sind und sich, je nachdem wie Scrum eingesetzt wird, stark unterscheiden. Solche Taktiken für die Anwendung innerhalb des Scrum‐ Rahmenwerks variieren stark und werden an anderer Stelle beschrieben.   

 

Ken Schwaber & Jeff Sutherland, November 2020

 

Scrum‐Definition Scrum ist ein leichtgewichtiges Rahmenwerk, welches Menschen, Teams und Organisationen hilft, Wert durch adaptive Lösungen für komplexe Probleme zu generieren.   Kurz gesagt fordert Scrum, dass ein:e Scrum Master:in ein Umfeld fördert, in dem    1. ein:e Product Owner:in die Arbeit für ein komplexes Problem in ein Product Backlog einsortiert; 2. das Scrum Team aus einer Auswahl dieser Arbeit innerhalb eines Sprints ein wertvolles Increment erzeugt; 3. das Scrum Team und dessen Stakeholder:innen die Ergebnisse überprüfen und für den nächsten Sprint anpassen; 4. diese Schritte wiederholt werden. Scrum ist einfach. Probiere es so aus, wie es ist, und finde heraus, ob seine Philosophie, Theorie und Struktur dabei helfen, Ziele zu erreichen und Wert zu schaffen. Das Scrum‐Rahmenwerk ist absichtlich unvollständig und definiert nur die Teile, die zur Umsetzung der Scrum‐Theorie erforderlich sind. Scrum baut auf der kollektiven Intelligenz der Personen auf, die es anwenden. Anstatt den Menschen detaillierte Anweisungen zu geben, leiten die Regeln von Scrum ihre Beziehungen und Interaktionen. Innerhalb des Rahmenwerks können verschiedene Prozesse, Techniken und Methoden eingesetzt werden. Scrum umhüllt bestehende Praktiken oder macht sie überflüssig. Scrum macht die relative Wirksamkeit des aktuellen Managements, der Umgebung und der Arbeitstechniken sichtbar, so dass Verbesserungen vorgenommen werden können.

 

Scrum‐Theorie Scrum basiert auf Empirie und Lean Thinking. Empirie bedeutet, dass Wissen aus Erfahrung gewonnen wird und Entscheidungen auf der Grundlage von Beobachtungen getroffen werden. Lean Thinking reduziert Verschwendung und fokussiert auf das Wesentliche. Scrum verwendet einen iterativen, inkrementellen Ansatz zur Optimierung der Vorhersagbarkeit und zur Risikokontrolle. Scrum setzt auf Personengruppen, die gemeinsam über alle Fähigkeiten und Fachkenntnisse verfügen, um die Arbeit zu erledigen und solche Fähigkeiten im Bedarfsfall zu teilen oder zu erwerben. Scrum kombiniert vier formale Events zur Überprüfung und Anpassung innerhalb eines umspannenden Events, des Sprints. Diese Events funktionieren, weil sie die empirischen Scrum‐Säulen Transparenz, Überprüfung und Anpassung implementieren. 4 Transparenz Der sich entwickelnde Prozess und die entstehende Arbeit müssen sowohl für diejenigen sichtbar sein, die die Arbeit ausführen, als auch für diejenigen, die die Arbeit empfangen. Bei Scrum basieren wichtige Entscheidungen auf dem wahrgenommenen Zustand seiner drei formalen Artefakte. Artefakte, die wenig transparent sind, können zu Entscheidungen führen, die den Wert mindern und das Risiko erhöhen. Transparenz ermöglicht Überprüfung. Eine Überprüfung ohne Transparenz ist irreführend und verschwenderisch. Überprüfung Die Scrum‐Artefakte und der Fortschritt in Richtung der vereinbarten Ziele müssen häufig und sorgfältig überprüft werden, um potenziell unerwünschte Abweichungen oder Probleme aufzudecken. Um bei der Überprüfung zu helfen, bietet Scrum eine Kadenz in Form seiner fünf Events.    Überprüfung ermöglicht Anpassung. Überprüfung ohne Anpassung wird als unsinnig betrachtet. Scrum Events sind darauf ausgerichtet, Veränderungen zu bewirken. Anpassung Wenn einzelne Aspekte eines Prozesses von akzeptablen Grenzen abweichen oder wenn das resultierende Produkt nicht akzeptabel ist, müssen der angewandte Prozess oder die produzierten Ergebnisse angepasst werden. Die Anpassung muss so schnell wie möglich erfolgen, um weitere Abweichungen zu minimieren.    Die Anpassung wird schwieriger, wenn die beteiligten Personen nicht bevollmächtigt (empowered) sind oder sich nicht selbst managen können. Von einem Scrum Team wird erwartet, dass es sich in dem Moment anpasst, in dem es durch Überprüfung etwas Neues lernt. Scrum‐Werte Die erfolgreiche Anwendung von Scrum hängt davon ab, dass die Menschen immer besser in der Lage sind, fünf Werte zu leben: Commitment, Fokus, Offenheit, Respekt und Mut Das Scrum Team committet sich, seine Ziele zu erreichen und sich gegenseitig zu unterstützen. Sein primärer Fokus liegt auf der Arbeit des Sprints, um den bestmöglichen Fortschritt in Richtung dieser 5 Ziele zu bewirken. Das Scrum Team und dessen Stakeholder:innen sind offen in Bezug auf die Arbeit und die Herausforderungen. Die Mitglieder des Scrum Teams respektieren sich gegenseitig als fähige, unabhängige Personen und werden als solche auch von den Menschen, mit denen sie zusammenarbeiten, respektiert. Die Mitglieder des Scrum Teams haben den Mut, das Richtige zu tun: an schwierigen Problemen zu arbeiten. Diese Werte geben dem Scrum Team die Richtung vor, was seine Arbeit, seine Handlungen und sein Verhalten betrifft. Die Entscheidungen, die getroffen werden, die Schritte, die unternommen werden, und die Art und Weise, wie Scrum angewendet wird, sollten diese Werte stärken und nicht schmälern oder untergraben. Die Mitglieder des Scrum Teams lernen und erforschen die Werte, während sie in den Events und mit den Artefakten von Scrum arbeiten. Wenn diese Werte durch das Scrum Team und die Menschen, mit denen es arbeitet, verkörpert werden, werden die empirischen Scrum‐Säulen Transparenz, Überprüfung und Anpassung lebendig und bauen Vertrauen auf. Scrum Team Der zentrale Bestandteil von Scrum ist ein kleines Team von Menschen, ein Scrum Team. Das Scrum Team besteht aus einem:einer Scrum Master:in, einem:einer Product Owner:in und Developer:innen. Innerhalb eines Scrum Teams gibt es keine Teilteams oder Hierarchien. Es handelt sich um eine geschlossene Einheit von Fachleuten, die sich auf ein Ziel konzentrieren, das Produkt‐Ziel. Scrum Teams sind interdisziplinär, d.h. die Mitglieder verfügen über alle Fähigkeiten, die erforderlich sind, um in jedem Sprint Wert zu schaffen. Sie managen sich außerdem selbst, d.h. sie entscheiden intern, wer was wann und wie macht. Das Scrum Team ist klein genug, um flink zu bleiben und groß genug, um innerhalb eines Sprints bedeutsame Arbeit fertigzustellen, üblicherweise 10 oder weniger Personen. Im Allgemeinen haben wir festgestellt, dass kleinere Teams besser kommunizieren und produktiver sind. Wenn Scrum Teams zu groß werden, sollten sie in Erwägung ziehen, sich in mehrere zusammengehörende Scrum Teams zu reorganisieren, die sich alle auf dasselbe Produkt konzentrieren. Daher sollten sie Produkt‐Ziel, Product Backlog und Product Owner:in teilen.   Das Scrum Team ist umsetzungsverantwortlich (responsible) für alle produktbezogenen Aktivitäten: Zusammenarbeit mit den Stakeholder:innen, Verifikation, Wartung, Betrieb, Experimente, Forschung und Entwicklung und alles, was sonst noch erforderlich sein könnte. Es ist von der Organisation so aufgebaut und befähigt, dass es seine Arbeit selbst steuert. Das Arbeiten in Sprints mit einer nachhaltigen Geschwindigkeit verbessert den Fokus und die Kontinuität des Scrum Teams.   Das gesamte Scrum Team ist ergebnisverantwortlich (accountable), in jedem Sprint ein wertvolles, nützliches Increment zu schaffen. Scrum definiert drei spezifische Ergebnisverantwortlichkeiten innerhalb des Scrum Teams:  Developer:innen, Product Owner:in und Scrum Master:in 6 Developer:innen Developer:innen sind jene Personen im Scrum Team, die sich der Aufgabe verschrieben haben, jeden Sprint jeden Aspekt eines nutzbaren Increments zu schaffen. Die spezifischen Fähigkeiten, die von den Developer:innen benötigt werden, sind oft breit gefächert und variieren je nach Arbeitskontext. Die Developer:innen sind jedoch immer ergebnisverantwortlich dafür, ● einen Plan für den Sprint zu erstellen, das Sprint Backlog; ● Qualität durch die Einhaltung einer Definition of Done einzubringen; ● täglich ihren Plan zur Erreichung des Sprint‐Ziels anzupassen; und ● sich wechselseitig als Expert:innen zur Verantwortung zu ziehen. Product Owner:in Der:die Product Owner:in ist ergebnisverantwortlich für die Maximierung des Wertes des Produkts, der sich aus der Arbeit des Scrum Teams ergibt. Wie dies geschieht, kann je nach Organisation, Scrum Team und Individuum sehr unterschiedlich sein.    Der:die Product Owner:in ist auch für ein effektives Product‐Backlog‐Management ergebnisverantwortlich, das Folgendes umfasst: ● das Produkt‐Ziel zu entwickeln und explizit zu kommunizieren; ● die Product‐Backlog‐Einträge zu erstellen und klar zu kommunizieren; ● die Reihenfolge der Product‐Backlog‐Einträge festzulegen; und ● sicherzustellen, dass das Product Backlog transparent, sichtbar und verstanden ist. Der:die Product Owner:in kann die oben genannten Arbeiten selbst durchführen oder die Umsetzungsverantwortung an andere delegieren. Unabhängig davon bleibt der:die Product Owner:in ergebnisverantwortlich.    Damit der:die Product Owner:in Erfolg haben kann, muss die gesamte Organisation seine:ihre Entscheidungen respektieren. Diese Entscheidungen sind im Inhalt und in der Reihenfolge des Product Backlogs sowie durch das überprüfbare Increment beim Sprint Review, sichtbar.    Der:die Product Owner:in ist eine Person, kein Gremium. Der:die Product Owner:in kann die Bedürfnisse vieler Stakeholder:innen im Product Backlog berücksichtigen. Diejenigen, die das Product Backlog ändern möchten, können dies tun, indem sie versuchen, den:die Product Owner:in zu überzeugen. 7 Scrum Master:in Der:die Scrum Master:in ist ergebnisverantwortlich für die Einführung von Scrum, wie es im Scrum Guide definiert ist. Er:sie tut dies, indem er:sie allen dabei hilft, die Scrum‐Theorie und ‐Praxis zu verstehen, sowohl innerhalb des Scrum Teams als auch in der Organisation.    Der:die Scrum Master:in ist ergebnisverantwortlich für die Effektivität des Scrum Teams. Er:sie tut dies, indem er:sie das Scrum Team in die Lage versetzt, seine Praktiken innerhalb des Scrum‐Rahmenwerks zu verbessern.    Scrum Master:innen sind echte Führungskräfte, die dem Scrum Team und der Gesamtorganisation dienen. Der:die Scrum Master:in dient dem Scrum Team auf unterschiedliche Weise, unter anderem dadurch, ● die Teammitglieder in Selbstmanagement und interdisziplinärer Zusammenarbeit zu coachen; ● das Scrum Team bei der Fokussierung auf die Schaffung von hochwertigen Increments zu unterstützen, die der Definition of Done entsprechen; ● die Beseitigung von Hindernissen (impediments) für den Fortschritt des Scrum Teams zu bewirken; und ● sicherzustellen, dass alle Events von Scrum stattfinden, positiv und produktiv sind und innerhalb der Timebox bleiben. Der:die Scrum Master:in dient dem:der Product Owner:in auf unterschiedliche Weise, unter anderem dadurch, ● bei der Suche nach Techniken zur effektiven Definition des Produkt‐Ziels und zum Product‐ Backlog‐Management zu helfen; ● dem Scrum Team dabei zu helfen, die Notwendigkeit klarer und präziser Product‐Backlog‐ Einträge zu verstehen; ● bei der Etablierung einer empirischen Produktplanung für ein komplexes Umfeld zu helfen; und ● die Zusammenarbeit mit Stakeholder:innen nach Wunsch oder Bedarf zu fördern (facilitate). Der:die Scrum Master:in dient der Organisation auf unterschiedliche Weise, unter anderem dadurch,   ● die Organisation bei der Einführung von Scrum zu führen, zu schulen und zu coachen; ● Einführungen von Scrum in der Organisation zu planen und zu empfehlen; ● Mitarbeitende und Stakeholder:innen beim Verständnis und bei der Umsetzung eines empirischen Ansatzes für komplexe Arbeit zu unterstützen; und ● Barrieren zwischen Stakeholder:innen und Scrum Teams zu beseitigen. 8 Scrum Events Der Sprint ist ein Container für alle anderen Events. Jedes Event in Scrum ist eine formelle Gelegenheit, Scrum‐Artefakte zu überprüfen und anzupassen. Diese Events sind speziell darauf ausgelegt, die erforderliche Transparenz zu ermöglichen. Wenn ein Event nicht wie vorgeschrieben durchgeführt wird, verpasst man die Gelegenheit, zu überprüfen und anzupassen. Events werden in Scrum verwendet, um Regelmäßigkeit zu schaffen und die Notwendigkeit von Meetings, die in Scrum nicht definiert sind, zu minimieren. Optimalerweise werden alle Events zur selben Zeit und am selben Ort abgehalten, um die Komplexität zu reduzieren. Der Sprint Sprints sind der Herzschlag von Scrum, wo Ideen in Wert umgewandelt werden.    Es sind Events mit fester Länge von einem Monat oder weniger, um Konsistenz zu schaffen. Ein neuer Sprint beginnt unmittelbar nach dem Abschluss des vorherigen Sprints.    Alle Arbeiten, die notwendig sind, um das Produkt‐Ziel zu erreichen, einschließlich Sprint Planning, Daily Scrums, Sprint Review und Sprint Retrospective, finden innerhalb der Sprints statt.   Während des Sprints    ● werden keine Änderungen vorgenommen, die das Sprint‐Ziel gefährden würden; ● nimmt die Qualität nicht ab; ● wird das Product Backlog nach Bedarf verfeinert; und ● kann der Scope (Inhalt und Umfang) geklärt und mit dem:der Product Owner:in neu vereinbart werden, sobald mehr Erkenntnisse vorliegen. Sprints ermöglichen Vorhersagbarkeit, indem sie mindestens jeden Kalendermonat eine Überprüfung und Anpassung der Fortschritte in Richtung eines Produkt‐Ziels gewährleisten. Wenn der Horizont eines Sprints zu lang ist, kann das Sprint‐Ziel hinfällig werden, die Komplexität kann steigen und das Risiko kann zunehmen. Kürzere Sprints können eingesetzt werden, um mehr Lernzyklen zu generieren und das Risiko von Kosten und Aufwand auf einen kleineren Zeitrahmen zu begrenzen. Jeder Sprint kann als ein kurzes Projekt betrachtet werden. Es gibt verschiedene Vorgehensweisen, um den Fortschritt vorherzusagen, wie Burn‐Down‐Charts, Burn‐ Up‐Charts  oder Cumulative‐Flow‐Diagramme. Diese haben sich zwar als nützlich erwiesen, ersetzen jedoch nicht die Bedeutung der Empirie. In komplexen Umgebungen ist unbekannt, was passieren wird. Nur was bereits geschehen ist, kann für eine vorausschauende Entscheidungsfindung genutzt werden.   Ein Sprint könnte abgebrochen werden, wenn das Sprint‐Ziel obsolet wird. Nur der:die Product Owner:in hat die Befugnis, den Sprint abzubrechen. 9 Sprint Planning Das Sprint Planning initiiert den Sprint, indem es die für den Sprint auszuführenden Arbeiten darlegt. Dieser resultierende Plan wird durch die gemeinschaftliche Arbeit des gesamten Scrum Teams erstellt.    Der:die Product Owner:in stellt sicher, dass die Teilnehmenden vorbereitet sind, die wichtigsten Product‐Backlog‐Einträge zu besprechen, und wie sie dem Produkt‐Ziel zuzuordnen sind. Das Scrum Team kann zu Beratungszwecken auch andere Personen zur Teilnahme am Sprint Planning einladen.    Das Sprint Planning behandelt die folgenden Themen: Thema Eins: Warum ist dieser Sprint wertvoll?   Der:die Product Owner:in schlägt vor, wie das Produkt im aktuellen Sprint seinen Wert und Nutzen steigern könnte. Das gesamte Scrum Team arbeitet dann zusammen, um ein Sprint‐Ziel zu definieren, das verdeutlicht, warum der Sprint für die Stakeholder:innen wertvoll ist. Das Sprint‐Ziel muss vor dem Ende des Sprint Plannings finalisiert sein. Thema Zwei: Was kann in diesem Sprint abgeschlossen (Done) werden?   Im Gespräch mit dem:der Product Owner:in wählen die Developer:innen Einträge aus dem Product Backlog aus, die in den aktuellen Sprint aufgenommen werden sollen. Das Scrum Team kann diese Einträge während dieses Prozesses verfeinern, was Verständnis und Vertrauen erhöht. Die Auswahl, wie viel innerhalb eines Sprints abgeschlossen werden kann, kann eine Herausforderung darstellen. Je mehr die Developer:innen jedoch über ihre bisherige Leistung, ihre zukünftige Kapazität und ihre Definition of Done wissen, desto sicherer werden sie in ihren Sprint‐Vorhersagen sein. Thema Drei: Wie wird die ausgewählte Arbeit erledigt?   Für jeden ausgewählten Product‐Backlog‐Eintrag planen die Developer:innen die notwendige Arbeit, um ein Increment zu erstellen, das der Definition of Done entspricht. Dies geschieht oft durch Zerlegung von Product‐Backlog‐Einträgen in kleinere Arbeitseinheiten von einem Tag oder weniger. Wie dies geschieht, liegt im alleinigen Ermessen der Developer:innen. Niemand sonst sagt ihnen, wie sie Product‐Backlog‐ Einträge in Increments von Wert umwandeln sollen. Das Sprint‐Ziel, die für den Sprint ausgewählten Product‐Backlog‐Einträge und der Plan für deren Lieferung werden zusammenfassend als Sprint Backlog bezeichnet.    Das Sprint Planning ist zeitlich beschränkt auf maximal acht Stunden für einen einmonatigen Sprint. Bei kürzeren Sprints ist das Event in der Regel kürzer. 10 Daily Scrum Der Zweck des Daily Scrums besteht darin, den Fortschritt in Richtung des Sprint‐Ziels zu überprüfen und das Sprint Backlog bei Bedarf anzupassen, um die bevorstehende geplante Arbeit zu justieren.    Das Daily Scrum ist ein 15‐minütiges Event für die Developer:innen des Scrum Teams. Um die Komplexität zu reduzieren, wird es an jedem Arbeitstag des Sprints zur gleichen Zeit und am gleichen Ort abgehalten. Falls der:die Product Owner:in oder der:die Scrum Master:in aktiv an Einträgen des Sprint Backlogs arbeitet, nimmt er:sie als Developer:in teil. Die Developer:innen können Struktur und Techniken beliebig wählen, solange ihr Daily Scrum sich auf den Fortschritt in Richtung des Sprint‐Ziels fokussiert und einen umsetzbaren Plan für den nächsten Arbeitstag erstellt. Das schafft Fokus und fördert Selbstmanagement. Daily Scrums verbessern die Kommunikation, identifizieren Hindernisse, fördern die schnelle Entscheidungsfindung und eliminieren konsequent die Notwendigkeit für andere Meetings.      Das Daily Scrum ist nicht die einzige Gelegenheit, bei der die Developer:innen ihren Plan anpassen dürfen. Sie treffen sich oftmals während des Tages für detailliertere Diskussionen zur Anpassung oder Neuplanung der restlichen Arbeit des Sprints. Sprint Review Zweck des Sprint Reviews ist es, das Ergebnis des Sprints zu überprüfen und künftige Anpassungen festzulegen. Das Scrum Team stellt die Ergebnisse seiner Arbeit den wichtigsten Stakeholder:innen vor, und die Fortschritte in Richtung des Produkt‐Ziels werden diskutiert.    Während des Events überprüfen das Scrum Team und die Stakeholder:innen, was im Sprint erreicht wurde und was sich in ihrem Umfeld verändert hat. Auf der Grundlage dieser Informationen arbeiten die Teilnehmenden gemeinsam daran, was als Nächstes zu tun ist. Auch kann das Product Backlog angepasst werden, um neue Möglichkeiten wahrzunehmen. Das Sprint Review ist ein Arbeitstermin, und das Scrum Team sollte vermeiden, es auf eine Präsentation zu beschränken. Das Sprint Review ist das vorletzte Event des Sprints und ist für einen einmonatigen Sprint auf maximal vier Stunden zeitlich beschränkt. Bei kürzeren Sprints ist das Event in der Regel kürzer. Sprint Retrospective Der Zweck der Sprint Retrospective ist es, Wege zur Steigerung von Qualität und Effektivität zu planen. 11 Das Scrum Team überprüft, wie der letzte Sprint in Bezug auf Individuen, Interaktionen, Prozesse, Werkzeuge und seine Definition of Done verlief. Die überprüften Elemente variieren oft je nach Arbeitsdomäne. Annahmen, die das Team in die Irre geführt haben, werden identifiziert und ihre Ursprünge erforscht. Das Scrum Team bespricht, was während des Sprints gut gelaufen ist, auf welche Probleme es gestoßen ist und wie diese Probleme gelöst wurden (oder auch nicht). Das Scrum Team identifiziert die hilfreichsten Änderungen, um seine Effektivität zu verbessern. Die wirkungsvollsten Verbesserungen werden so schnell wie möglich in Angriff genommen. Sie können sogar in das Sprint Backlog für den nächsten Sprint aufgenommen werden.    Die Sprint Retrospective schließt den Sprint ab. Sie ist für einen einmonatigen Sprint auf maximal drei Stunden beschränkt. Bei kürzeren Sprints ist das Event in der Regel kürzer. Scrum‐Artefakte Die Artefakte von Scrum repräsentieren Arbeit oder Wert.  Sie sind dafür ausgelegt, die Transparenz von Schlüsselinformationen zu maximieren. So haben alle, die sie überprüfen, die gleiche Grundlage für Anpassungen. Jedes Artefakt beinhaltet ein Commitment, um sicherzustellen, dass Informationen bereitgestellt werden, welche Transparenz und Fokus verbessern, um den Fortschritt messbar zu machen: ● Für das Product Backlog ist es das Produkt‐Ziel. ● Für das Sprint Backlog ist es das Sprint‐Ziel. ● Für das Increment ist es die Definition of Done. Diese Commitments dienen dazu, Empirie und die Scrum‐Werte für das Scrum Team und seine Stakeholder:innen zu verstärken. Product Backlog Das Product Backlog ist eine emergente, geordnete Liste der Dinge, die zur Produktverbesserung benötigt werden. Es ist die einzige Quelle von Arbeit, die durch das Scrum Team erledigt wird. Product‐Backlog‐Einträge, die durch das Scrum Team innerhalb eines Sprints abgeschlossen (Done) werden können, gelten als bereit für die Auswahl in einem Sprint‐Planning‐Event. Diesen Transparenzgrad erlangen sie in der Regel durch Refinement‐Aktivitäten. Das Refinement des Product Backlogs ist der Vorgang, durch den Product‐Backlog‐Einträge in kleinere, präzisere Elemente zerlegt und weiter definiert werden. Dies ist eine kontinuierliche Aktivität, wodurch weitere Details wie Beschreibung, Reihenfolge und Größe ergänzt werden. Die Attribute variieren oft je nach Arbeitsumfeld. 12 Die Developer:innen, die die Arbeit erledigen werden, sind für die Größenbestimmung umsetzungsverantwortlich. Der:die Product Owner:in kann die Developer:innen beeinflussen, indem er:sie dabei unterstützt, die Product‐Backlog‐Einträge zu verstehen und Kompromisse einzugehen. Commitment: Produkt‐Ziel Das Produkt‐Ziel beschreibt einen zukünftigen Zustand des Produkts, welches dem Scrum Team als Planungsziel dienen kann. Das Produkt‐Ziel befindet sich im Product Backlog. Der Rest des Product Backlogs entsteht, um zu definieren, „was“ das Produkt‐Ziel erfüllt. Ein Produkt ist ein Instrument, um Wert zu liefern. Es hat klare Grenzen, bekannte Stakeholder:innen, eindeutig definierte Benutzer:innen oder Kund:innen. Ein Produkt kann eine Dienstleistung, ein physisches Produkt oder etwas Abstrakteres sein. Das Produkt‐Ziel ist das langfristige Ziel für das Scrum Team. Das Scrum Team muss eine Zielvorgabe erfüllen (oder aufgeben), bevor es die nächste angeht. Sprint Backlog   Das Sprint Backlog besteht aus dem Sprint‐Ziel (Wofür), den für den Sprint ausgewählten Product‐ Backlog‐Einträgen (Was) sowie einem umsetzbaren Plan für die Lieferung des Increments (Wie). Das Sprint Backlog ist ein Plan von und für die Developer:innen. Es ist ein deutlich sichtbares Echtzeitbild der Arbeit, welche die Developer:innen während des Sprints zur Erreichung des Sprint‐Ziels ausführen wollen. Folglich wird das Sprint Backlog während des gesamten Sprints immer dann aktualisiert, wenn mehr gelernt wurde. Es sollte genügend Details beinhalten, damit sie ihren Fortschritt im Daily Scrum überprüfen können. Commitment: Sprint‐Ziel Das Sprint‐Ziel ist die einzige Zielsetzung für den Sprint. Obwohl das Sprint‐Ziel ein Commitment der Developer:innen ist, bietet es Flexibilität in Bezug auf die genaue Arbeit, die erforderlich ist, um es zu erreichen. Das Sprint‐Ziel schafft auch Kohärenz und Fokus und ermutigt somit das Scrum Team, zusammen statt in separaten Initiativen zu arbeiten. Das Sprint‐Ziel wird während des Sprint‐Planning‐Events erstellt und dann zum Sprint Backlog hinzugefügt. Während die Developer:innen  innerhalb des Sprints arbeiten, behalten sie das Sprint‐Ziel im Gedächtnis. Wenn sich herausstellt, dass die Arbeit von ihren Erwartungen abweicht, arbeiten sie mit dem:der Product Owner:in zusammen, um den Umfang des Sprint Backlogs innerhalb des Sprints zu verhandeln, ohne das Sprint‐Ziel zu beeinflussen. 13 Increment Ein Increment ist ein konkreter Schritt in Richtung des Produkt‐Ziels. Jedes Increment ist additiv zu allen vorherigen Increments und gründlich geprüft, um sicherzustellen, dass sie alle zusammen funktionieren. Um einen Mehrwert zu erzielen, muss das Increment verwendbar sein. Innerhalb eines Sprints kann mehr als ein Increment erstellt werden. Deren Summe wird im Sprint Review vorgestellt, womit Empirie unterstützt wird. Ein Increment könnte jedoch auch schon vor Ende des Sprints an die Stakeholder:innen geliefert werden. Das Sprint Review sollte niemals als Barriere zur Lieferung von Wert angesehen werden. Arbeit kann nicht als Teil eines Increments betrachtet werden, solange sie nicht der Definition of Done entspricht. Commitment: Definition of Done Die Definition of Done ist eine formale Beschreibung des Zustands des Increments, wenn es die für das Produkt erforderlichen Qualitätsmaßnahmen erfüllt.    In dem Moment, in dem ein Product‐Backlog‐Eintrag die Definition of Done erfüllt, wird ein Increment geboren. Die Definition of Done schafft Transparenz, indem sie allen ein gemeinsames Verständnis darüber vermittelt, welche Arbeiten als Teil des Increments abgeschlossen wurden. Wenn ein Product‐Backlog‐ Eintrag nicht der Definition of Done entspricht, kann es weder released noch beim Sprint Review präsentiert werden. Stattdessen wandert es zur zukünftigen Berücksichtigung in das Product Backlog zurück. Wenn die Definition of Done für ein Increment Teil der Standards der Organisation ist, müssen alle Scrum Teams diese als Mindestmaß befolgen. Wenn sie kein Organisationsstandard ist, muss das Scrum Team eine für das Produkt geeignete Definition of Done erstellen. Die Developer:innen müssen sich an die Definition of Done halten. Wenn mehrere Scrum Teams an einem Produkt zusammenarbeiten, müssen sie eine gemeinsame Definition of Done definieren und sich alle daran halten.     14 Schlussbemerkung Scrum ist kostenlos und wird in diesem Guide angeboten. Das Scrum‐Rahmenwerk, wie es hier beschrieben wird, ist unveränderlich. Es ist zwar möglich, nur Teile von Scrum zu implementieren, aber das Ergebnis ist nicht Scrum. Scrum existiert nur in seiner Gesamtheit und funktioniert gut als Container für andere Techniken, Methodiken und Praktiken.

 

 

Scrum By The Book? Was Ebay’s ehemaliger CTO Joseph Pelrine dazu sagt.

Joseph Pelrine – der ruhige und zurückhaltende Forscher und Praktiker – gilt unter Kennern als einer der Pioniere und Top-Experten für agile Methoden. Er hat über 25 Jahre damit verbracht, Prozesse zu definieren und zu verfeinern, um einigen der bekanntesten Unternehmen der Welt zu helfen, ihre Fähigkeit zu verbessern, die Bedürfnisse ihrer Kunden zu erfüllen. 


Als Psychologe liegt sein Fokus auf den Menschen. Seine Erfahrung in der Anwendung von Spitzentechniken aus sozialer Komplexitätstheorie, der Psychologie und der Prozessoptimierung, gehen weit über den Bereich der Softwareentwicklung hinaus und erstreckt sich auf die gesamte Organisation. 


Obwohl Joseph Pelrine oft als Berater oder Interimsmanager arbeitet, gibt er sein Wissen am liebsten weiter, indem er Einzelpersonen und Organisationen berät, oft in der Rolle eines CTO/CIO/CDO „Flüsterers“. Er forscht an neuartigen Anwendungen der Psychologie auf agile Prozesse und ist außerdem Doktorand in Psychologie und Psycholinguistik.

Sprecher

Herzlich Willkommen zum Agile Growth Podcast, dem Podcast für alle Agile Interessierten mit hilfreichen Ideen und erprobten Werkzeugen, die dich weiterbringen von und mit den Two Agilists.

 

Kai

Herzlich willkommen zum Agil Growth Cast schön, dass du wieder zuschaust. Es ist mal wieder ein Freitag um 11 Uhr und wir haben wieder einen ganz, ganz spannenden Gast heute hier. Und ja, wenn du uns öfter siehst, dann vermisst du vielleicht gerade jemanden neben mir. Und ja, manchmal kommt das vor. Wir hatten eine ziemlich intensive Woche und Jasmine ist gerade ein bisschen dabei, sich zu erholen und sich eben ihre Augen geguckt habe, da sie wirklich ein bisschen müde und abgeschlagen aus.

 

Kai

Und so mussten wir für heute darauf setzen, dass ich heute unser Gastgeber bin. Ich freue mich darüber sehr, denn es gibt immer mal wieder Premieren im Leben und Jasmine stand tatsächlich auch schon mit unserem Gast, den wir heute dabei haben, sehr, sehr oft zusammen auf einer Bühne hat Kinos gegeben. Insofern ist das vielleicht auch nur die faire Rückrunde dafür, dass ich entsprechend heute mit Josef Paul Ryan sprechen darf. Und mit Joseph verbindet mich eine ganze Menge.

 

Kai

Denn nicht nur, dass wir schon in seinem hervorragenden, eingerichteten Küche zusammen kochen durften, sondern auch, dass wir zusammen auf meiner Reise zum Scrum Trainer zusammengearbeitet haben und ich Joseph war, über die Schulter gucken durfte, wie man entsprechend hervorragende Scrum Trainings gibt. Und dort ist schon unglaublich lange dabei. Deswegen freue ich mich sehr auf dieses Gespräch. Und wenn du Fragen konkret hast zu dem, was wir hier besprechen, dann darf sie gerne wie gewohnt hier rein entsprechend denkt oder YouTube, so dass wir dann auch darauf eingehen können.

 

Kai

Insofern freue ich mich sehr, Joseph, dass du da bist und die Zeit nimmst für unseren Growth Cast. Herzlich willkommen!

 

Speaker 3

Agil Guten Morgen!

 

Kai

Ja. Du bist ja unglaublich lange schon mit dem Thema Scrum verbandelt. Ich habe ja 2007 meinen Anfang gemacht und da warst du schon eine Weile mit dem ganzen Agilem Zeug irgendwie unterwegs und hast Projekte gemacht. Und ich würde gern ein bisschen mit dir eintauchen in diese Anfangszeit. Wie kam das eigentlich dazu, dass du mit Agilität in Kontakt gekommen bist?

 

Speaker 3

Das ist eine ganz lange Geschichte. Wie viel Zeit haben wir dann über dein. Ich habe Ende der 80er Jahren angefangen, bei einer Versicherung zu arbeiten, die jemand gesucht hat, der Psychologie studiert hat, aber sich mit Computern auskannte, um im Bereich künstliche Intelligenz zu forschen. Damals war man darunter, eigentlich Experten, Systeme. Das war der Anfang von Neuronale Netzwerke und und so weiter. Und eine der populärsten und bekanntesten Programmiersprachen für Kai damals war Smalltalk und Small Talk ist eine ganz tolle Programmiersprache für ich immer noch sehr viel Community damals war eigentlich nicht sehr groß.

 

Speaker 3

Und dann bin ich irgendwie durch Zufall mit eine Dame namens Rebecca Brock in Kontakt gekommen, die als irgendwie ganz oben ist bei der Agile Values. Rebecca ist eine ganz tolle Frau, leitete ein Team damals bei Technics und zwei Leute in einem Team, mit denen ich mich mal angefreundet haben wollen. Ward, Cunningham und Kernberg kennen Leute zu wenig Leute, war das auch ein bisschen ein Vorbild von jemand, der einfach mal ruhig und zurückhaltend ist, aber ein Genie ist?

 

Speaker 3

A Wort hat die erste Wicki erfunden.

 

Kai

Ich glaube, hat auch diesen pragmatischen Programmierer mit als Autor verfasst. Mit Andrew Hunt zusammen habe ich das richtig im Kopf klingelt.

 

Speaker 3

Das ist echt famos. Das ist eine von den Dave Thomas ist. Das ist Pragmatiker. Dave Das ist nicht Big Dave, der der Chef von Ottawa war, die Ozeane hat. Ja, wir können vielleicht später zum Urteil kommen, am Ort kennenlernten, Kai kennengelernt und sehr viel mit ihnen dann mal zusammen ausgetauscht. Über Senioren und meine Arbeit in Small Talk ging dann mehr in Richtung Entwicklungs Werkzeuge. Ich habe eine Zeit lang auch für dich viel mit Digitalkameras arbeitet, die auch mal Small-Talk Version auf den Markt hatten.

 

Speaker 3

Und da gab es eben von OTA eine die erste integrierte Umgebungen für Versions Verwaltung. Es nannte sich Envy Developer und ich war dann relativ schnell bekannt als eine der Experten in Genf, eine der wenigen, die nicht bei Otto Kai gearbeitet haben. Und damals hat mich Kent Ende 1995 mal angefragt. Ich sage Du, wir machen jetzt mal ein neues Projekt, etwas ganz Verrücktes und wir versuchen auf ganz andere Art zu programmieren. Und wir arbeiten mit Andy. Kannst du uns helfen, Autos entwickeln?

 

Speaker 3

Also ich habe. Anpassungen für Entwickler machte mir jedes Mal, wenn Code eingecheckt wird, das Tests automatisch laufen und dann hat kein Gesamtaufwand den Test schon automatisch laufen können. Kannst du nicht schauen, dass die ganze Prozess automatisiert wird? Jasmine Woher das alles dann kommt, ist es heute wohl seine Fragestellung.

 

Kai

So habe ich das gar nicht. Verstand. Du hast damals schon Psychologie studiert.

 

Speaker 3

Ich habe Psychologie studiert in den späten 70er Jahren in Wien. Unter anderem habe ich die Ehre gehabt, unter Viktor Frankl zu studieren, was wirklich lebensverändernde Ereignis war für mich und ich.

 

Kai

Ich muss sagen, ich interessiere mich ja. Vielleicht liegt das auch daran, dass mit der Psychologe verheiratet bin. Ich interessiere mich auch viel für die psychologischen Themen und da war so ein ganz kleinen Lob aufzumachen, bevor ich das Agil zurückkommen kann. Was war das, was du von Viktor Frankl mitgenommen hast?

 

Speaker 3

Bescheidenheit. Je mehr derselbe gegen ehrlich zu sein. Er hat mal gesagt Du kannst seine seine berühmte Zitate immer die Kai zwischen den Ressorts. Ist die Zeit, wo wir handeln können, und das ist das, was uns zu Menschen macht. Er hat auch mal gesagt Vergiss nie das Auge, kann sich selber nie anschauen. Das Auge kann sich selber nicht anschauen. Brauchst immer ein Blick aus einer anderen Perspektive.

 

Kai

Ich war mir sicher, die Flasche Rotwein, die wir heute nicht haben.

 

Speaker 3

Es ist zu früh am Morgen. Übrigens, das ist bis Kai und Kai Rotwein im Garten.

 

Kai

Okay. Dem wir im Spiegel des anderen, um wachsen zu können. Ja, die Reflektion des anderen. Die Schatten, die man im anderen erkennt und die man integrieren kann.

 

Speaker 3

Ja also zurückzukommen, denke ich, habe mir dann immer wieder interessante Fragen gestellt aus seiner Sicht und andere interessante Sachen wurden sind und. Er hat gesagt Extreme Programming ist eine Ansammlung von Techniken, um aus normal begabten Programmierern Weltklasse Ergebnisse zu bekommen und eine untere, manchmal sogar passable Work. Und da hat er dann mal angefangen, die Fragen zu stellen Ja, wie können wir das ganze was wir machen dann managen? Und wir sind dann mal auf die Idee gekommen. Ein 19 95 Obstler Orbital Working Group Paper von Kai Representative Scrum haben wir mal gesagt okay, klauen wir ein paar Sachen daraus, außer in extreme Programmieren sei Customer The Product Owner und sind Planning Game.

 

Speaker 3

Ist halt mal das Brett Planning Meeting und so weiter. Und dann habe ich schreibe glaube 96 dabei kennengelernt. Ich war in diesem Workshop 95 nicht und ja, ich habe dann angefangen, mehr und mehr mit Kern zusammen zu machen. Nach dem Projekt war es ein Projekt bei Chrysler. Das Projekt die erste Projekt in der Welt ist, kennt dann nachher noch Europa gekommen und ich habe als sein Assistent gearbeitet. Was ich da bemerkt habe, was wir bemerkt haben, ist, dass Smalltalk irgendwie vom Markt verdrängt wurde durch Java.

 

Speaker 3

Und es ist sehr schwer mit Programmiersprachen und ist alles wirklich mal state of the art zu bleiben. Was ich gemerkt habe ist, dass nicht Prozess mehr interessiert hat. Und dann. Es war im Juni 2002 wollen kann schreibe und ich zusammen auf XP 2002 in Oliveira und wir waren im gleichen Hotel ein bisschen außerhalb Val Konferenzsaal vorbei, wo wir angefangen haben zu reden über Scrum und er sagte der Markt Agil Scrum in der Welt einmal rausbringen, ob ich Ihnen helfen würde und gesagt Ja, gerne Kern haben wir damals auch Aufträge gegeben, aber viele ORSC Coaching Aufträge Consulting Aufträge, die, wo er angefragt wurde, die er nicht machen wollte, was sie in Europa oder anderswo waren harte an mich weitergegeben.

 

Speaker 3

Das war ein großer Vertrauensvorschuss. Was ich sehr beeindruckend fand, war die Tatsache, dass ich habe ihn gefragt Du, was wirst du für Provision? Findest du nicht? Ich will, dass du gute Arbeit machst, dass ich stolz darauf bin. Und er hat das Gleiche gesagt, was Kant gesagt hat. Ich will nicht. Ich will, dass das an die nächste Generation weiter gibst. Und das ist das, was mich in meine Arbeit treibt die beste Arbeit zu machen, die ich machen kann.

 

Speaker 3

Und das war nach der ersten Generation.

 

Kai

Jetzt sitzen wir hier zusammen, als sich als Stellvertreter für die nächste Generation zu tragen. Und wir geben was weiter von den Geschichten. Und ich habe letztens hatten wir Jutta Eckstein mal hier ganz früh im Growth Cast und da habe ich noch mal den Hinweis bekommen, es gibt ja so eine Verbindung, die ist glaub ich sehr wenigen Leuten so richtig bekannt hier im europäischen Raum zwischen dieser Scrum Spiel. Ob also dieser Patterns Language Geschichte und der Konferenz, die sich da trifft, ja eher so eine Muster Sammlung erstellt haben, was eine gute Produktentwicklung oder gute Teamarbeit ausgeht.

 

Kai

Und Scrum wie weit hast du da einen Einblick drin gehabt? Weil das hat ja auch irgendwie auch so Small Talk Roots gehabt, habe ich verstanden an der Stelle also eine ganze Geschichte über über Patterns stammte auch von Kanban von ein paar Artikeln damals in. YouTube, the Journal of Objektorientierte Programming und Small Talk Report, wo er dann mal Christopher Alexander Design Paddeln Book gelesen hatten, gesagt hat Okay, wie passt das mal für uns in Softwareentwicklung? Und das sind sehr viele Leute auf dem auf den Zug aufgesprungen.

 

Kai

Mit den 90er Jahren gab es da kaum Vorburg raus. Plus noch oh, ich wollte es nicht aus dem Flow raus reißen. Genau so was baut sich auf mein erster persönlicher Kontakt zu einem der Scrum vor und irgendwann Anfang der 2000er bei einem Trainer in Karlsruhe. Long. Ja schön sowas. Das ist dann ja tatsächlich.

 

Speaker 3

Also. Ich würd lieber ein bisschen wegkommen von der Sonne. Aber zurück zum Kern habe ich mal gefragt Kannst du dann mal? Kannst du mir helfen? Ich merke auch, dass du von den ersten trainiert bist und so weiter. Ich weiß nicht, wen er sonst noch gefragt hat. Vor der Zeit, ich nehme an Erster und Mike und was. Aber er wollte sich dann erst in Europa und bis der Zeit, wo er dann in Europa Kurse unterrichten konnte, wo das mit seinen Reiseplan einrichten konnte.

 

Speaker 3

Und was hat er mir seine Unterlagen gegeben? Und ich hab dann tatsächlich angefangen. Anfang der 2000er Jahren war er und Rainer in Karlsruhe. Wir haben einfach ganz günstig auf ein paar Hundert Euro einen Nachmittag Einführung in Scrum und da habe ich Leute getroffen wie Mentors und wie Christian und dann die haben angefangen, das auch dann weiter zu verbreiten in Deutschland. Ich habe dann auch mit die Leute von Trainer. Es gab ja alles. Zwei neun neun zwei null null null.

 

Speaker 3

Die erste Expedia in London. Und dann habe ich mal dort ein. Zuerst war es nur über Extreme Programming, dann kam noch Scrum und dann kam Exp dei Backlogs und Exp dei wollte liegt anderswo und ich habe dann mal mit André zusammen, dann Exp dei Germany gegründet und unser 6 PD Germany war wahrscheinlich auch 2003 und wir hatten dann aber so war auch dabei Frank Westphal und ich, ich kling wirklich wie ein Ortegas nachgeht, nachgedacht. Ja, damals war es alles besser.

 

Speaker 3

Aber so so so lief es dann. Und ja, dann habe keine Schulden in Europa und ich war dann dabei, dann zertifizierte Trainer und dann hatte mich nach Australien geschickt, wo ich mal das erste Training in Australien gemacht habe, darunter auch bei Atlas. Die haben damals ganz schnuckelige Produkt gehabt namens auf. Haben nicht weiter darauf ein, was aus dir geworden ist. Aber damals habe ich auch Roland Boning kennengelernt und ausgebildet. Und worüber ich mich auch jetzt freue als als Trainer bin ich eine der ersten Trainer Europas.

 

Speaker 3

Eine erste Tranche der Trainees ausgebildet haben, die inzwischen auch andere Two Agilists ausgebildet haben.

 

Kai

Ja, so und so gibst du das vor. Das ist ja auch das, was sich geändert hat im Laufe der Zeit. Denn es würde mich auch noch interessieren Ich habe 2007 ein Zertifikat Scrum Master damals gemacht und auch in diesen 14 Jahren hat sich die Welt ja schon wahnsinnig verändert. Agilität und Scrum betrifft, wenn du mal so vergleichst mit diesen ersten Sessions, wo man dafür 100 Euro in unserem Scrum Workshop drin gesessen hat. Und du hast ja vor kurzem noch mal einen Product Owner Training gegeben.

 

Kai

Was hat sich an der Art der Fragestellung in der Welt verändert? Wenn du mal so vergleichst, was waren die anfangs Fragen, die Leute beschäftigt haben, was waren die? Vielleicht Feindbilder und Gegner, gegen die sich Agilität damals abgrenzen abgegrenzt hat? Und was ist es heute geworden?

 

Speaker 3

Ja, ich um das ist ganz, ganz einfach. Jeffrey Morcerf oder The Early in early Adopters. Wo stecken wir jetzt? Aber ich gehöre da ganz am Anfang und man sagt, es gibt ein Kasim zwischen Early Adopters und Early mit Shorty. Nur Produkte, die es in den Mainstream schaffen, sind überlebensfähig. Einige alte Knacker, so wie ich glauben. Es gibt grade bezüglich Agilität und zweiten Chancen, der es zwischen den majority late majority und nachher kommst du nicht weiter und so was.

 

Kai

Du darfst das sagen bei der Schweiz.

 

Speaker 3

Ja und das ist tatsächlich mal der Sport zwischen Firmen, die. Sowas Agilem machen was sie wollen und Firmen, die das machen was sie müssen und wir sind ganz eindeutig auf der Seite von den Firmen, die wir jetzt machen, machen das was sie müssen. Sie wollen es nett. Also was Sie suchen, ist eine Möglichkeit. Ich nenne das Hashtag metoo Agil. Wir wollen auch sagen, dass wir auch Agil sind, obwohl sie organisationalen Antikörpern, organisationalen Rheuma sich wirklich mal dagegen sträubt.

 

Speaker 3

Wir sehen das auch in Methoden, die jetzt mal. Angeboten werden extreme Programme hat sich nie so aus dem Nischendasein raus geschafft hat nie den Sprung über den ersten Kasim in Trinken finden kann, was ist geschafft hat, weil XP eine Mischung von verschiedene Praktiken war. Einige von diesen Praktiken haben es geschafft, dass es hier entwickelt haben. Ich schaue mir jedes Mal, wenn man Code checkt, dass das System läuft, dass wir es dann bauen können, Continuous Integration, dann Continuous Delivery und jetzt Def Orbs.

 

Speaker 3

Wir haben eine Product Owner ohne Training. Wirklich interessante Diskussion zu. Was bedeutet Begriff Release Planning, wenn eine Firma wie Facebook Changes alle elf komma sieben Sekunden auf den Server pusht? Ist das sind die Sachen, die sich ändern. Also einige Sachen, die sich. Aus den Anfang in welchem geschafft haben wurde Projektmanagement Talk vom Extreme Programming, sprich Scrum war EXP kennt, nannte das AA Disziplin Development Du brauchst verdammt viel Disziplin um EXP zu machen. Wir haben damals ein paar Programme, nur weil exp so schwer ist es keine.

 

Speaker 3

Das war Leidenschaft diesen Disziplin durchzuhalten. Aber es zeigt einfach mal wieder Wenn die Scrum richtig machst, zeigt es, dass du EXP brauchst. Du brauchst es in technischen Praktiken Agil, aber es kommt. Stellte auch mal ein Spiegel, wo im Gesicht jeder sagt, was an Organisation nicht stimmt. Schwabe hat mal gesagt Scrum Scrum ist wie deine Schwiegermutter, die glaubt, dass du nicht gut genug bist für ihre Tochter. Und sie wohnt bei euch. Man sitzt in der Küche, jedes Mal, wenn du da reingehst und die Flasche Bier zu holen, erinnert sie dich daran, dass du nicht gut genug bist.

 

Speaker 3

Ja, okay, so für MeToo das. Das ist einfach zu viel, weil die Leute sich Agil nicht ändern wollen. Also was gibt es für Möglichkeiten zu sagen wir sind auch Agil. Ganz einfach maximal eine Wand stärkst einfach mal ein paar postet dran aber Jane zu viel, dann brauchst du eine gute Methode, nämlich Kanban, nur um zu beweisen Ja, wir sind auch Agile und daraus entwickeln sich auch noch andere Methoden, die wirklich. Sorry, Safe ist perfektes Beispiel dafür.

 

Speaker 3

Safe ist ein persistente Framework für non Agil job description. Aber es verkauft sich vielleicht gut, weil ich mich gar nicht verändern muss. Reden wir lieber über etwas anderes, ist es.

 

Kai

Ich mag, dass wir diese provokativ diese Thesen in den Raum stellst. Ich habe auch gehört, dass der Tresor, dem man Scrum, eingesperrt hat. So, und das ist, wie das da unten in der Ecke irgendwo noch so ein bisschen Scrum ist und der Kunde, wo man da oben war, ich weiß, die Safe Leute Riesenthema, die Grabenkämpfe, die es hier gibt an der Stelle. Ich bin ja auch eher so auf dem Scrum Framework als was deutlich näher dran ist an dem Kanban mit Scrum hinwollen.

 

Kai

Und jetzt hast du ja angesprochen. Ich nenne das manchmal blutleere Scrum, also das, wo du so Cargo Cult mäßig halt in Sachen kopierst, aber den Kern oder die Essenz und die Werte nicht mitgegeben werden muss.

 

Speaker 3

Das ist ja, was ich unterrichte ist, wenn du Agil Bookmarks. Weil es nur ein Buch ist, bist du nicht Agil. Du folgst einer Religion, nur hast du halt eine andere Bibel. Das ist das, was für mich immer so eine Herausforderung war, Leute das beizubringen beibringen. Nein, hatte ich nicht, es sei halt nicht an und Scrum Kai. Die Frage ist lustig machen oder wirst du ein Produkt auf den Markt bringen, der eine Folge ist der den Konkurrenten den Arschtritt.

 

Speaker 3

Du kriegst, du kriegst, es ist nicht die Schule, wo du mal den dann bekommst, wenn du alle Meetings machst. Es geht immer darum du musst Agil sein. Auch auf prozeß ebene. Also ich habe jetzt wahrscheinlich verloren. Aber das ist so. ich glaube das. Was du da ansprichst ist für mich so ein bisschen der Weg. Als ich ganz neu angefangen habe mit Scrum, habe ich mich krampfhaft an der Checkliste und dieser Scrum Kai festgehalten, weil ich so unsicher war in mir selbst, wie man überhaupt Agil vorgehen kann und fand das sehr hilfreich total by the book zu sein, weil mir das ganz viel Klarheit und Sicherheit gegeben hat.

 

Speaker 3

Und umso länger ich das praktiziert habe, umso mehr habe ich die Intentionen der Muster verstanden, die da drinstecken und konnte auf dieser Ebene der Intention und der Muster auf ein Unternehmen oder den Kontext schauen. Um herauszufinden, erreichen die das Ziel, eine Idee bis zum Markt innerhalb von einer kurzen Zeit zu bekommen. Ja, und das ist vielleicht diese das, was du gerade meinst mit vergiss dieses. Also verstehe ich das zumindest dieses eine vergisst, das den Scrum gibt, weil schlussendlich geht es ja darum, die Intentionen zu caption und diese Intentionen umzusetzen in der Kanban.

 

Speaker 3

Ja, ich glaube, wo ich in Technik wie Scrum sehr oft einsetze, ist es auf eine Metaebene, um zu entdecken, was der beste Prozess ist und aus dem Korb sehr oft ein Lean optimiert Pipeline also was also in dem Sinn von A mit Scrum fahren beide Burg, um zu entdecken, was funktioniert und was nicht funktioniert und dann ab zwei Inspektoren da. Auch im Sinne von Ich schau mal, was für euch funktioniert. Aber wichtig ist, dass wenn man etwas zuerst mit Kai Strabo und ich sagt früher immer ins Bett, ohne da das Programm mit den darbt.

 

Speaker 3

Sehr viele Firmen haben einfach das Buch geholt. Rosinenpicken gemacht, die haben die coole Sachen raus, aber nichts, was sie aus ihrem Kopf bringen würden. Dann haben sie gefragt, wieso es nicht funktioniert. Oh ja, okay, danke. Ja, dieser Appell nicht stehen zu bleiben, sondern Inspektion und Adoption auch auf der Ebene zu betreiben. Was ich auch immer wieder höre von Unternehmen, die das längerfristig tun, die dann einfach mehr des Werts Stroms optimieren wollen und die sagen was weiß ich, wir haben Portfolio.

 

Speaker 3

Kanban braucht noch drum herum, was die gesamte Unternehmung besser abbildet. Und diese Zeiten da hinzukommen. Okay, und jetzt sind wir ja auch im Agile Growth Cast immer dran interessiert an. Dem Menschen hinter dem Fachlichen und du hast jetzt ja auch eine ganze Strecke in deinem Leben gemacht, wo du mit Agilität gearbeitet hast. Was waren so die Dinge, die du in deinem eigenen Wachstum gelernt hast, die dich inspiriert haben, wo du selber daran gewachsen bist? Wenn du mal so zurückschaue auf diese ganze Strecke Wohn und Agilität gearbeitet hast, was waren Skills, die du in dir selber entdecken durftest und musstest, um das zu machen?

 

Speaker 3

Hast du da?

 

Speaker 3

Da gibt es einige, aber ich glaube, es ist einschneidendste. Für mich war ich vorher eine Zeit lang CTO bei Ebay. Ihr kennt vielleicht Ebay, dass es diesen Verein online gebraucht waren laden und in der Zeit sieht Jehova dort ist ein Vulkan in Island hochgegangen und hat innert 24 Stunden. Das ganze Reiseverkehr in Europa um ein Jahrhundert zurückgesetzt.

 

Kai

Ich erinnere mich.

 

Speaker 3

Für mich war es nicht so schlimm, dass Europa mein Office ist in Amsterdam. Ich habe nicht dorthin können. Ich habe von zu Hause aus arbeiten müssen. Meine erste Erfahrungen mit Homeoffice schlimme war es für Leute in meinen Augen, für mein Team. Sie waren auf eine Außenstelle in Review in die Ukraine. Sie konnten nicht zurückkommen. Sie haben 48 Stunden Zugreise über Moskau müssen, damit sie nach Hause kann. Mann, ich habe eine Bekannte von mir gehabt, war Pilot für Swissair, der war gestrandet, eine Hochzeit verpasst.

 

Speaker 3

Inzwischen ist alles gut. Diese verheiratet haben Kinder. Was aber das? Hab mich zum Denken gebracht, dass es Vulkane gibt, Vulkane sind Ereignisse, die drei Eigenschaften haben. Erstens die kann sie nicht vorhersagen. Zweitens Du kannst sie nicht beeinflussen. Drittens Du musst reagieren. Für dich als Vater. Das Schlimmste, was passieren kann, ist, wenn die Notaufnahme im Spital anruft und sagt Deine Tochter ist da und man kann es nicht vorhersehen. Du kannst es nicht vermeiden.

 

Speaker 3

Du kannst deine Töchter nicht einsperren, aber du musst darauf reagieren. Wenn In Business haben wir drei Vulkane. Der erste Vulkan sind unsere Kunden. Du kannst sagen, du kannst modisch sehr oft nicht vorhersehen, was die Kunden sich wünschen. Kannst du das beeinflussen? Sehr schwer. Die Leute, die Mode beeinflussen können. Gerade im technischen Bereich sind sehr, sehr dünn gesät. Steve Jobs wollte auch darüber reden, inwieweit Elon Musk so eine von denen ist. Also du kannst Shantanu sind, Fashion nicht vorhersehen kann sich schwer beeinflussen muss, aber darauf reagieren muss.

 

Speaker 3

Sonst gehen deine Kunden wohin. Zweite Vulcan in Konkurrenz. Du weißt nicht, was die Konkurrenz auf den Markt bringt. Dukakis nicht beeinflussen. Das heißt, Firmen, die nicht mehr technologisch innovativ sind, versuchen das zu machen. Wir suchen das machen doch worden. Also Apple gegen Samsung Milliarden Klage über wie gerundet die AEG mobil an Handys sein dürfen. Oder fürchtest Google Millionen Dollar? Denkst wegen Naming Conventions API? Das sind Firmen, die nicht so innovativ sind, wie sie einmal war, die versuchen eine Konkurrenz auszubremsen.

 

Speaker 3

Der dritte Vollkorn sind Sachen in der Welt um uns herum. Wir leben mitten in den dritten Vulcan jetzt. Wir leben mitten in die Agil. Die ersten Crowdworker ankommt. Wir haben es nicht vorhersehen können, aber es nicht beeinflussen können. Wir müssen darauf reagieren. Und jetzt war für mich die Sache. Bei Ebay stelle ich aus CTO, CEO, Entwicklungs Leute vor, eine Firma, wo jede Sekunde offline und ein Verlust von bis zu 10000 Euro pro Sekunde bedeutet.

 

Speaker 3

Warum fängst du an überlegen? Bin ich bereit mein Hintern zu riskieren? Bin ich bereit den Namen Ebay zu riskieren, weil ich etwas sagt? Wir müssen das machen, weil es in Scrum Guide steht. Oh Mann, wir können schon gehen und sagen Hey, daily Scrum Daily Standup. Macht einmal am Tag sehen. Wenn jede Sekunde offline Shantanu einen Verlust bedeutet, dann musst du anfangen überlegen wie kann ich meinen meinen Prozess anpassen? Also das war für mich klar die einschneidendste Erlebnis, der mich wirklich dazu gebracht hat, sehr pragmatisch und sehr realitätsnah mit den ganzen Agilität umzugehen.

 

Speaker 3

Und das ist für mich dann wirklich Agil sein. Jetzt komme ich wieder runter.

 

Kai

Ja, es ist okay, also in den Schuhen gewesen zu sein. Diesen Druck, den man auch auf der Managementebene verspürt, um einfach die Ergebnisse oder die Servicequalität aufrechtzuerhalten, hat er dein Scrum Verständnis ganz stark noch mal beeinflusst. Habe ich grade verspielt. Und jetzt bist du ja. Ich hätte fast gesagt. Ja, du hast eine gewisse Unruhe. Immer noch und forscht auch noch in Bezug auf Psychologie. Wie passt denn das jetzt eigentlich zusammen, was der ganz früh angefangen, also schon bevor du Ärger gemacht hast mit Psychologie.

 

Kai

Und du bist ja noch immer damit beschäftigt, oder? Oder wieder damit beschäftigt, noch mal mehr irgendwie den Menschen oder Teams zu verstehen, wie die hoch performant in dieser Arbeitswelt unterwegs sind. Wie kommt es, dass du da immer noch diesen Drive verspürst, dich da reinzuhängen? Denn so wissenschaftliche Arbeit ist ja auch etwas, was bisschen Durchhaltevermögen braucht und was Konzentration braucht. Was treibt dich also zuerst?

 

Speaker 3

Wie komme ich zurück in die Psychologie? Aber ich bin ebenso weggegangen, habe diese Karriere in Informatik und was macht? Ich habe dann bemerkt, es gibt zwei Arten von Problemen. Es gibt technische Probleme, sind in der Regel Turing komplett. Man findet eine Lösung mit bestimmten Techniken, Problemen mit Menschen. Sie sind faszinierend. Wir haben sie noch nicht gelöst. Also es kommen immer wieder gleiche Probleme. Und was ich dann bemerkt habe. Ist das so viele Leute geraten im Agil Bereich so viel Stuss erzählen.

 

Speaker 3

Die Sie nicht belegen können oder ihr irgendwelche Statistiken, die nicht Hand und Fuß haben. Ja, 70 prozent von den Firmen, die Scrum machen, machen sie richtig. Für mich als Psychologe solltest du weißt von Jasmine als Psychologe wirst du nicht sofort Dr. Freud, du wirst auch kein krimineller Profiler sicher sei. Was du lernst ist Experimente zu entwickeln, die richtige Fragen zu stellen und die Antworten wirklich mal auszuwerten. Also für mich als Statistik, wenn ich 70 prozent höre, will ich erst mal sehen Population Sampling by Sophie Purvis blablabla dies aus und die wiederum sind nur ein inneres Interesse geweckt.

 

Speaker 3

Man habe ich meine jetzige Frau kennengelernt und die ist jetzt grad früh pensioniert, noch keine 30 Jahre als Psychotherapeutin und sie hat mir das unterstellt. Wenn dieses Shantanu wieder eine Uni. Also ich bin wieder an Uni gegangen, habe mein bestes gemacht, habe dann promoviert, Agilität Promotion fertig machen können aus diversen Gründen. Aber was ich bemerkt habe, was ich von und von der Uni mitgenommen habe, ist diesen Drang nach Genauigkeit, Forschungsmethoden, Statistiken wirklich mal Beweise?

 

Speaker 3

Dann wird man wirklich verstehen kann, wie das alles funktioniert und Jasmine weiß auch du wirst nicht mit mir über Studien reden, dass du kennst alle auswendig oder es gibt zu viele Referenzen, dass ich mal beeindruckt, was du da für ein Gedächtnis hast. Und ja, es ist mir schon auch wichtig, finde ich für Menschen, die mit Agilität arbeiten in der Hinsicht. Ich habe ja selber irgendwie im Scrum Training immer mal wieder, das sagt mein Modell irgendwie aufgemalt, weil es so schön einfach musste das sagen.

 

Kai

Und ich, ich weiß, ich weiß, du gehst jetzt wieder steil, aber wenn man mal so hinguckt, ich glaube was. Was war noch mal der Anlass für Tackmann Untersuchung? War das ein Gefängnis, wo irgendwie die Kohorten irgendwie sich angeguckt haben? Oder da gab es so eine ganz persönliche Begegnung, die dahinter steht in eine psychiatrische Abteilung eines Veterans Hasbro. Also so von Militär, Spitäler, wo sie quasi Leute mit posttraumatischen Stress unterstützt haben. Und top.

 

Kai

Man hat einfach nur eine Literatur Analyse gemacht vom vorher, vom Berichte von Therapeuten. Genauer gesagt in diese Berichte von den Therapeuten gibt es gewisse Gemeinsamkeiten, wenn man eine Gruppentherapie macht. Und ich muss sagen hat hab recht. Okay, wenn du Psychologe bist, lernst du auch, wie du diesen Typekit als erstes Paper zu lesen sollten, lernst du wie du Paper richtig liest. Hat dieses Modell nie gesagt. In diesem vor er sagt ganz klar Das passt vielleicht eine psychiatrische Klinik?

 

Kai

Es vielleicht mal Leute mit diesem Stress oder es passt nie. Er würde nie sagen, dass es eine ökologische Validität und Allgemeingültigkeit hat, aber das ist alles. Diese sagen genau wie masslos Pyramide. Die wurde einfach von Menschen mit Beratungsfirmen aufgeschnappt, weil sie einfach zu verkaufen sind.

 

Kai

So einfach. Manchmal sind es die einfachen Dinge, die dann überleben oder das Diagramm, was wir gehen uns ja auch irgendwie so schön unter gerissen haben, weil es eben so schön erklärt, wo sich Scrum eignet. Und wenn dann dem Hans Typekit zuhörst, wer sich davon distanziert hat, denkst du auch Okay, gut.

 

Speaker 3

Ja, ja, ich habe sich ja mit jemandem gesprochen, der gerade dann unter Stacey promoviert hat. Stacey sagte mal im Gespräch. Er hat auch wirklich mal Wut auf die Scrum Leute und sowas wo er wollte das Ding schon mitten 90er Jahre begraben. Also zwischen Version Auflage 2 und 3 für sein Buch ist es verschwunden. Aber es gibt Leute, die immer noch dann darauf aufbauen.

 

Kai

Ja, die Geister, die man rief, da gehen sie nicht mehr weg. Und von dem, was dich gerade beschäftigt, was sind die Herzensthemen? Die, die dich zu einem Talk motivieren oder die dich gerade umtreiben? Deine aktuelle Arbeit. Da würde ich gern so, wenn wir uns langsam der Kurve des Gesprächs nähern, noch mal eintauchen. Was macht was? Was lässt dich morgens aufstehen? Wo steckst du die Nase rein? Was sind die Sachen, die dich inspirieren?

 

Speaker 3

Im Allgemeinen, was mich morgens aufstehen lässt, was mich weiterarbeiten lässt, ist, was ich einfach nicht aufhören kann zu lernen. Und dass ich nicht aufhören kann, mit diesem Bedürfnis das Weite zu geben. Insbesondere ist es meine zum psychologische Sicherheit und Vertrauen. Und tatsächlich ich bin ich zweifle inzwischen an Googles Studie. Es ist interessant, dass physikalische Physical Science, da gibt es tatsächlich mal gewisse Gesetze, Gesetzmäßigkeiten wie Schwerkraft und sowas. Ich kann manchmal auch mal wissenschaftlich beweisen, aber es gibt immer noch Leute, die nicht an globale Erwärmung denken glauben oder die Leute, die glauben, dass Impfstoffe Autismus hervorrufen, sowas aber Kanban.

 

Speaker 3

Wenn man irgendwie die New York Times irgendeinen Artikel veröffentlicht über irgendwas, was nicht in einem Peer Review wissenschaftliche Studie drin ist, einfach war der Name Google draufsteht, glauben alle Leute es muss so sein und es stimmt. Ich glaube, wir müssen uns nur psychologische Sicherheit und das Weite zu erforschen, auf die Instrumente zu entwickeln, um das Testen zu sehen, wie weit ein Unternehmen ist auf unterschiedliche Aspekte, zum Beispiel emotionale Intelligenz, kognitive Diversität und auch Teams können trainieren und ausbilden, dass sie besser werden, da das ist das, was mich treibt.

 

Speaker 3

Kurze Werbespots, weil es sowieso sinnvoll ist, ich halt in ein paar Wochen auch irgendwie ein Tag dort drüben meine neueste Forschung, aber ich glaube, das sind eh keine Plätze mehr frei. Aber könnte man denn dann dann suchen? Ich hoffe, dass sie den Vortrag irgendwann auch mal halte. Aber es geht mir darum, auch wieder mal sagen Hey, überhaupt nicht einfach alles, nur weil ich irgendwo im Forschungsbericht stehe. Wissenschaft ist ein Gespräch und genau wie wir im Gespräch treten, unterschiedliche Ideen, unterschiedliche Ansichten vertreten.

 

Speaker 3

Dass man auch mal aber die Offenheit, die Größe hat zu sagen Hey, wow, das ist cool. Ich muss meine Ansicht jetzt mal überdenken. Das sind das ist meine Einstellung.

 

Kai

Du hast in dem letzten Vortrag auch mal glaube ich, so ein kleines Werkzeug den Leuten an die Hand gegeben, wie man die Situation in Bezug auf Vertrauen in seiner Umgebung verbessern kann. Und wir versuchen ja immer auch wieder gerne, den Leuten, die so als Agile Coaches da draußen arbeiten, an Scrum Master Kleines mitzugeben. Kannst du das noch mal kurz umschreiben, dass man so vielleicht sagen kann, es sein Arbeitsalltag noch mitnehmen kann?

 

Speaker 3

Ja, gerne. Das ist mal Hausaufgabe für Zündschloss, weil psychologische Sicherheit ist eine emergente. Es ist eine abgeleitete Eigenschaft, ist Eigenschaft von Umgebung. Es entsteht durch diese Selbstorganisation. Es entsteht dadurch, dass Menschen miteinander Vertrauen aufbauen. Und der tollste Werkzeuge, die ich verwende, um anzufangen, Vertrauen aufzubauen, habe ich schon einen ganz lieben Freund von mir, Ben Fuchs, Psychotherapeut in London und es ist einfach ein Template. In diesem Kontext oder in dieser Situation kann ich am besten nicht sauber sein, wenn ich.

 

Speaker 3

Etwas machen kann und du oder ohne dass du etwas anders machst. Ich sage es nochmals, wenn ihr postet irgendwas habt sie schreiben. Schreib diesen Template auf. In diese Situation beschreibt die Situation, kann ich am besten mix sein, wenn ich fehlende blicke, ohne dass du oder. Und dass du willentlich überlegt, dass jetzt mords jemand bezüglich jemand zu deinem oder zu der du Vertrauen hast oder zu dem oder zu der du Vertrauen aufbauen willst. Schreib das auf für diesen Template und dann gab das Blatt, diese Person schenke Vertrauen.

 

Kai

Schöne Einladung, kann ich mir gut vorstellen in dem Entwicklungs Workshops auch mit neuen agilen Teams, wo es darum geht, das zu vertiefen und Tobi schreibt uns gerade noch damals war alles besser, sagt der Trainer Generations connected. Der Kommentar ist glaube ich schon ein Weilchen her. Dankeschön. Thomas, ich glaube ihr merkt, dass wir das gerade genießen. Hier unsere Session und ihr zum Abschluss hin. Josef in fünf Jahren. Was ist, wenn ihr euch vorstellen, was was machst du in fünf Jahren werde ich wahrscheinlich nicht.

 

Kai

Ich kann nie aufhören zu arbeiten, aber auch noch ein bisschen Hypothek zu zahlen. Aber ich habe einfach mal diesen Drang weiter zu lernen. Aber was ich mir wünsche ist, dass ich in fünf Jahren viel mehr draußen im Garten spielen kann und meine beiden Töchter spielen kann. Was geht es eigentlich nur über Videokonferenz? Und dass wir solche Sachen dann machen.

 

Kai

Da ist es, das Konferenz Wombat, was entsprechend schon Jasmine immer mal wieder vor ihrem Lampenfieber bewahrt hat. Übrigens wer ein paar von den Vorträgen von Review und Jasmine sehen möchte, der findet ihr auf D Ich habe die da mal alle entsprechend gelistet, die öffentlich im Internet waren und ich möchte dir ganz herzlich danken für das Gespräch, das wir heute hatten.

 

Speaker 3

Bitte! Vielen Dank!

 

Kai

Viele Grüße in die Schweiz und natürlich auch am Ende. Ja und wenn dir die Sache einen Gefallen hat, dann freuen wir uns, wenn du die an entsprechende Leute, die diese Historie vielleicht auch von Agilität interessiert oder die Praxis Tools, die gerade uns mitgegeben hat, noch weiter leitest und dein Netzwerk und wenn du Lust hast Jasmine und mich live im Seminar zu erleben bis dahin ist hoffentlich wieder fit. Dann findest du auf deine Trainings entsprechend unsere Seminare. Herzlichen Dank fürs Zuschauen und bis ganz bald wieder.

 

Wie schreibt man User Stories richtig?

Was ist eine User Story? Was sind die User Story Vorteile?
Es ist immer wieder faszinierend, wie viele Missverständnisse es zu einem eigentlich recht einfachen Konzept geben kann. Die Bedeutung von User Stories ist in agilen Projekten meist überschätzt – und doch kann dieses Format etwas, das hilfreich ist für echte Nutzer-Empathie.
Wir bringen User Story Beispiele und zeigen auch, wie sie in Scrum verwendet werden können.

Kai

User Stories werden oft im gleichen Atemzug genannt mit agilen Methoden und wir kümmern uns heute um ein paar Mythen, denn die werden ganz oft falsch verwendet und du kriegst in diesem Podcast mit. Was ist eine User Story und wie schreibt man die eigentlich richtig? Und wie spart man unglaublich viel Zeit beim User Story schreiben denn falls du da eine riesen lange Liste gerade vor dir hast, die so eine Anforderung ausmacht, dann haben wir da eine kleine Überraschung für dich in petto.

 

Sprecher

Herzlich Willkommen zum Agile Growth Podcast, dem Podcast für alle Agile Interessierten mit hilfreichen Ideen und erprobten Werkzeugen, die dich weiterbringen. Von und mit den Two Agilists.

 

Kai

Herzlich willkommen zum Agile Growth Podcast. Hier sind Jasmine und Kai und wir helfen Menschen dabei, die versprechen Agiler Vorgehensweisen in der Praxis einzulösen, ohne IT WIssen vorauszusetzen.

 

Jasmine

Ganz, ganz oft, wenn wir beim Kunden unterwegs sind – ob jetzt in der IT oder nich, in der IT kriegen wir so was zu hören wie: Ja, wir machen ja jetzt auch dieses Scrum. Wir benutzen Jira und schreiben User Stories. Aha, okay. Und was hat das jetzt konkret mit Scrum zu tun? Grundsätzlich schon mal gar nichts, oder wir kriegen die Fragen. Ja, irgendwie sagt das Management jetzt, wir dürfen nur noch User Stories schreiben, aber ich weiß gar nicht, was das ist.

 

Jasmine

Dieser Begriff User Stories, der geistert so durch die Hallen und Räume, sobald irgendjemand anfängt Agil zu arbeiten oder mit Scrum zu arbeiten. Und wenn du noch nicht so viel damit zu tun hast. Ganz kleiner Disclaimer an der Stelle – Jira ist Ticket Management Tool, das ganz viel kann. Viele Firmen benutzen es. Man muss das nicht benutzen um Scrum zu tun, aber man kann gibt es in gut gibts in nicht so guter Implementierung gibt es in It, gibt es nicht in IT.

 

Jasmine

So, das dürfen wir gerade mal vergessen, weil das hat nichts mit Agilität zu tun. Also welches Werkzeug ich benutze, hat ganz ganz wenig damit zu tun wie Agil ich bin und ob ich User Stories schreibe oder nicht, hat auch ganz wenig damit zu tun wie agil ich bin. Aber die meisten Teams, die Agil eine Produktentwicklung vorantreiben, werden irgendwann mal für sich ein Backlog erstellen. Und ein Backlog ist eine geordnete Liste an Anforderungen an unser Produkt. Und in diesem Backlog sind natürlich Einträge.

 

Jasmine

Und da hilft es mir, eine gewisse Idee davon zu haben, wie ich diese Einträge schreiben kann. Und wenn ich jetzt gucke, was steht denn normalerweise so in den Backlogs, dann sind das nicht nur User Stories, weil das ein sehr spezifisches Format ist, das aber durchaus Sinn macht. Deswegen wollen wir ganz, ganz explizit auf dieses Format eingehen in diesem Podcast. Aber bevor wir da hin kommen, vielleicht noch was kann sonst noch so in dem Backlog drinstehen?

 

Jasmine

Da können zum Beispiel natürlich auch Fehler an unserem Produkt drin stehen. Das werde ich nicht unbedingt in diesem Format User Story machen. Da können System-Anforderungen drinstehen, oder da kann auch technische Schuld drinstehen. Wenn ich schon lange irgendwas an diesem Produkt mache, dann habe ich vielleicht irgendwo Schuld aufgeladen. Das wird auch irgendwie beschrieben sein, aber vielleicht nicht unbedingt in diesem User Story Format. Warum dieses User Story Format aber trotzdem sehr, sehr hilfreich ist, hilft vielleicht, wenn man mal zurück guckt wo kommt Agilität her oder wo kommt Scrum her und es kommt aus der IT und da hat man ein Format gesucht, das den Entwicklern hilft.

 

Jasmine

Im Prinzip Empathie zu entwickeln mit dem Endnutzer.

 

Kai

Wir haben das mittlerweile in unserer Produktentwicklungskultur viel viel mehr drin. Es gibt ja so Leute, die sich darauf spezialisieren, UX genannt, also User Experience, die sich da ganz viel mit beschäftigen. Wie erlebt eigentlich unser Anwender das Produkt oder das System? Und wenn man so ein bisschen zurück guckt, damals gab es das halt nicht in der Form und ich habe ja auch Informatik studiert und bei mir war das am Anfang auch so. Ich als Programmierer habe ganz viel gedacht in so inneren Repräsentationen von meinem Produkt.

 

Kai

Also sprich eher so auf der Ebene von Quellcode und Abstraktionen und Schichten und Datenbank-Layer und all diesen Dingen, die ich als Informatiker eben kann. Damit war ich aber relativ weit weg von dem Problem meines Anforderers, also dem Problem meines Kunden, sondern war eher so in diesem Lösungs-Gebäude drin. Und insofern ist das praktisch für mich, wenn ich als derjenige, der das umsetzen soll, noch mal in den Hautsack des anderen rein schlüpfen kann, desjenigen dessen Probleme lösen will, also unserem Kunden und da mehr verstehe, was will der eigentlich und wieso überhaupt?

 

Kai

Und jetzt haben wir ja auch festgestellt, dass das ganz ganz schwierig ist, in Textform irgendwie Anforderungen aufzuschreiben, also so ein Fein Konzept aufzuschreiben, wo ganz detailliert Details drin stecken, weil das so ein bisschen dieses Flüster-Post Spiel ist, wo man ganz ganz viele Dinge miteinander verzahnt. Und da helfen uns eben User Stories etwas anderes zu tun.

 

Jasmine

Und in meiner Erfahrung ist es eigentlich egal, ob du jetzt in der IT unterwegs bist oder in einer anderen Branche unterwegs bist. Dieses sich in die Schuhe des End-Nutzers zu begeben ist unglaublich schwierig. Also selbst wenn ich jetzt irgendwie im Human Resources unterwegs bin, eine Trainings-Organisation habe, dann hilft es mir einfach durch ein Format gezwungen zu sein vom Endbenutzer her zu denken, weil wie oft kommt das vor? Und das kommt bei mir ganz ehrlich ganz oft vor, dass ich eine geniale Idee habe.

 

Jasmine

Und die ist so genial, dass ich anfange Anforderungen aufzuschreiben. Wie wir diese Idee jetzt umsetzen und in meinem Anforderungen aufschreiben. Wie wir diese Idee umsetzen, vergesse ich komplett zu beachten: für wen ist denn das eigentlich? Und der Punkt von genialen Ideen ist ganz oft – Die entspringen ja aus unseren eigenen Bedürfnissen. Aber mein Bedürfnis ist nicht unbedingt das Bedürfnis meines Nutzers oder meines Kunden. Also wenn ich – und wir geben ja ganz viele Scrum Master Trainings – wenn ich ein Scrum Master Training gebe und ich da eine geniale Idee habe und anfange runter zu schreiben, wie muss ich denn das jetzt genau umsetzen?

 

Jasmine

Was für Material brauche ich und so weiter. Dann kommt Kai ganz oft und sagt mir: Du Jasmine. Was soll denn ein jemand, der neu mit Scrum einsteigt, dabei überhaupt lernen? Da bin ich bisschen sauer auf Kai, aber die Frage ist gut, weil oft ist es ja meinem Bedürfnis entsprungen und viel zu weit weg von dem, was ein Nutzer bräuchte.

 

Kai

Und da hat sich jetzt ne User Story als hilfreich erwiesen. Und machen wir’s mal konkret: Was ist das eigentlich? Wir haben es gerade gehört. Das ist eine Art Empathie-Hilfe, so eine Story. Das ist aber eigentlich ein natürlich-sprachlicher Satz, also ein Stückchen Text, das irgendwie beschreibt: Wer möchte was wozu? Und so nutzen manche auch ein bisschen, wie so die Stützräder am Fahrrad, wenn man Fahrradfahren lernt, eine Zeit lang so ein Format und das nennt sich „als wer möchte ich was um wozu?“ Also zum Beispiel könntest du sagen: Als Agile Growth Podcast Hörer möchte ich verstehen, was eine User Story ist, um

 

Kai

Bald in meinem Arbeitsalltag diese sinnvoller nutzen zu können. Dann hätte ich also festgelegt, wer möchte das haben, nämlich du als unser Hörer? Muss ich vielleicht noch ein Bild innerlich haben – wer bist du als unser Hörer? Also Jasmine ich machen uns so eine Vorstellung davon. Wie siehst du jetzt aus? Wo hörst du uns gerade beim Kochen oder beim Fahrradfahren? Und dann haben wir das „wer“ klar. Und dann das „was“. Was ist eigentlich das, was da gebraucht wird?

 

Kai

Die Funktionalität, das Bedürfnis dahinter? Und wozu? Was ist denn die Absicht? Was möchte derjenige, wenn er dann diese Funktion hat? Und das alles wird eben beschrieben. Und du merkst schon bei diesem Ganzen, wie lange man darüber sprechen kann. Es ist eigentlich ein Satz, der ein Versprechen über ein Gespräch darstellt. Also der ist so unkonkret, dass ohne weitere Unterhaltung darüber,  man das auch gar nicht umsetzen kann.

 

Jasmine

Wobei der aber auch so konkret ist, dass das bei mir schon ganz, ganz viele Ideen triggert, nämlich als Kai gesagt hat: Wer will das, unser Podcast Hörer? Da brauchen wir vielleicht ein inneres Bild von und dann hat Kai schon gesagt: Ja, warum hörst du das? Vielleicht beim Kochen oder beim Fahrradfahren? Ah, spannend. Okay, das heißt, du hast keine Möglichkeit, was aufzuschreiben. Du wirst da nichts neben dir haben. Und stimmt, wir gehen davon aus, dass niemand von euch oder dass du auf jeden Fall nicht an deinem Schreibtisch sitzt und jetzt etwas schreiben möchtest.

 

Jasmine

Das heißt, wir werden die Information so verpacken müssen, damit sie leicht konsumierbar ist – um was geht es wirklich? Um das Verständnis einer User Story. Und dann macht das bei mir auch schon wieder ganz ganz ganz viele Knöpfe auf. Oh, müssen wir dann was zum Backlogs verstehen, was ich vorher schon angedeutet habe, oder? Oder nicht? Oder wo geht das hin? Und der schwierigste Teil ist immer das: Wozu möchtest du das verstehen?

 

Jasmine

Wir haben jetzt angenommen, damit du das besser in deinem Arbeitsalltag umsetzen kannst, das heißt, wir brauchen auch ganz konkrete Umsetzungs-Tipps in dieser Podcastfolge drin. Also, wie du siehst, es ist ein Satz, der aber so viele Informationen enthält, dass es bei mir schon die Kreativität schürt. Das heißt, kann ich das direkt von diesem Satz irgendwie in die Umsetzung gehen? Nein, es ist schwierig, aber ich kann mit Kai drüber anfangen zu reden. Wie muss denn diese Podcastfolge jetzt konkret aussehen, damit sie den Nutzen generiert

 

Jasmine

den wir generieren wollen?

 

Kai

Also das Ding öffnet quasi einen Korridor von Kreativität. Und wenn man dabei natürlich Details herausfindet, dann darf man die auch aufschreiben und dann kann man entsprechend festlegen wann ist denn diese User Story fertig? Und eine ganz nette Merkhilfe sind die drei C dabei. Also das erste C ist Englisch für Card. Also eine User-Story passt auf eine Karteikarte. Das heißt also wirklich, das ist ein kurzer Satz. Das ist nicht eine halbe DIN A4 Seite geschrieben, sondern einfach mal so ein halber Satz

 

Jasmine

Und mit einem dicken Stift.

 

Jasmine

Also nicht eine Karteikarte mit so einem dünnen Bleistift. Es ist eine Karteikarte mit einem dicken Stift.

 

Kai

Das zweite ist in der Story selber steckt ja gar kein „Wie“ drin. Also ich habe da drin. Wer möchte was? Wozu? Ich habe kein Wie drin. Das heißt, dass ganz viel Musik da drin wie die Lösung aussieht. Und das hat Jasmine ja gerade auch schon angesprochen, wie genau das umgesetzt wird, zum Beispiel hier die Podcastfolge ist ja dann etwas, was sich durch den Raum unserer Kreativität füllt. Und dann sind wir beim zweiten C und das steht entsprechend für Conversation.

 

Kai

Also eine User Story führt zu einem Gespräch. Wenn man das jetzt in der Praxis sieht, wie machen das dann Agile Teams? Die haben ein Gespräch im Idealfall zwischen ihrem Anforderer, also dem Kunden und den Entwicklern. Also Fachexperten und Entwickler müssen täglich zusammenarbeiten, steht im agilen Manifest – da trifft das also aufeinander, nicht nur im heterogenen, cross-funktionalen Team, sondern auch mit den direkten Kunden-Dialogen. Also Scrum nennt sowas Backlog Refinement, also Backlogs Verfeinerung. Da, wo wir mehr verstehen, was genau bauen wir denn eigentlich?

 

Kai

Und dieses Gespräch ist eben wichtig. Und das, was wir dabei rausfinden, das halten wir fest im dritten C. Das steht nämlich für Confirmation. Also wie weiß ich eigentlich, dass diese User Story fertig ist? Wann sagt Tante Erna mir – Das ist immer so mein prototypischer Name für den Kunden, für das Gegenüber. Jemanden, der also nicht diese ganze Technologie versteht oft, sondern einfach so eine Fach-Domäne. Wann sagt er, ist das fertig?

 

Kai

Wann akzeptiert das mein Kunde als abgeschlossen? Akzeptanz-Kriterien könnte man das auch nennen. Wann ist diese User Story fertig? War das unsere Podcastfolge fertig? Zum Beispiel wenn du ganz konkretes Wissen bekommen hast und konkrete Tipps, wie du das anwenden kann, bei dir könnte. Bei uns, das Confirmation Kriterium sein.

 

Jasmine

So, jetzt hast du schon gehört, was ist diese User Story? Wie baut sich die auf? Es ist ein Satz, der diese drei Aspekte – wer möchte was und wozu – abdeckt. Und die drei Cs als Merkhilfe: Card, Conversation und Confirmation im Sinne von wie setze ich das um? Oder was ist wichtig dabei, wie wir das jetzt meistens angehen ist – Wir schreiben eine sehr, sehr große User Story. Wir könnten eine User Story für diesen Podcast schreiben. Als Agile Growth Podcast-Hörer möchte ich gerne sehr viel Input zu Agil, damit ich meinem Wachstum begleitet werde.

 

Jasmine

Wäre wahrscheinlich unsere User Story für diesen Podcast und die ist noch relativ schwach, weil dies gerade so aus meinem Kopf entsprungen, die dürften wir jetzt schärfen. Und darunter kann mir natürlich dann ganz viele User Stories für jede einzelne Podcastfolge machen. Und wir könnten sogar noch mehr vertiefen, indem wir ganz viele User Stories für die einzelnen Kapitel einer Podcastfolge machen und somit eine Struktur da reinbringen. Das heißt, ich kann die User Stories auch immer wieder, man nennt das dann splitten, kleiner machen, Teilaspekte davon rausnehmen.

 

Jasmine

Das ist so was, was man zum Beispiel in einem User Story Map machen würde, was wiederum einfach nur eine Empathie-Hilfe ist, um von dem Endnutzer auf das ganze Produkt zu gucken. Und das ist natürlich ein bisschen einfach, wenn ich jetzt ein Softwareprodukte habe, weil ich das einfacher beschreiben kann. Aber ich habe das auch schon bei Lern-Produkten gemacht. Vom Ende User auf die gesamte Lern-Reise zu gucken, die jemand macht, wenn er in ein Training geht oder wenn er in eine ganze Trainings Serie geht.

 

Jasmine

Aber man kann das auch nur mit einem Training machen. Was geschieht vorher? Was geschieht nachher? Von dieser End User Perspektive aus? Und da steckt ganz viel – wir sind dann ganz viele nennen das ein Problem Raum. Wir beschreiben den Problem Raum sehr sehr genau, damit wir kollektiv mit unserer kollektiven Intelligenz als Team in den Lösungsraum gehen. Das heißt wir möchten als Userstory nicht unbedingt haben. Als Nutzer der Software, was sowieso eine sehr sehr sehr schwache Persona wäre, möchte ich, dass dieser Button grün wird, damit ich ihn besser sehe.

 

Jasmine

Das wäre ja schon eine Lösung. Was ich da vielleicht haben könnte ist als Barbara Backoffice möchte ich, dass die Buttons in der Software gut sichtbar sind, weil ich wenig Zeit habe, wenn ich die Software bediene und gleichzeitig am Telefon bin. Das heißt, ich habe da keine Lösung drin. Ich sage nicht, es kann ja sein, dass der Button grün wird, aber ich weiß, warum Barbara Backoffice das will. Ah ja. Barbara Backoffice ist gleichzeitig am Telefon und muss rum tippen und hat wenig Zeit.

 

Jasmine

Und die hat auch nicht Zeit, da drauf zu gucken. Das sag dem oder derjenigen, die dann das Design und in die Lösung geht, so viel mehr aus als „es muss grün sein, damit ich sehen kann.“

 

Kai

Und jetzt gibt es immer wieder diese Frage, die kriegen wir auch in Trainings ganz oft. Wie schreibe ich denn dann jetzt eine gute User Story? Und im Prinzip, wenn du diese Frage hast, könntest du auch sagen – dann gibt es wahrscheinlich ein Problem in der Beziehungsqualität zwischen den Anforderern und deinem Team. Denn eigentlich geht es hier um dialog-basierte Produktentwicklung. Dieser kleine Fetzen Text, der da auf so einer Karte drauf steht, der soll einfach nur zum Dialog anregen. Das heißt, von der Formulierung her ist es eigentlich total egal, wie du so ein Ding aufschreibst.

 

Kai

Und es geht nicht darum, da einen ewig langen Monolog zu machen. Und das sieht man auch manchmal in Teams, die noch neu sind, in Agilität oder wenn wir so reinkommen im Coaching. Die schreiben dann seitenweise Anforderungen in Tickets rein und das sind dann deren User-Stories. Oben steht so ein Satz als soundso und so möchte ich das und das. Und darunter kommt dann Spezifikation nach Spezifikation nach Spezifikation. Und da merkst du, dann fangen die Teams auch an zu chatten über irgendwelche Tickets und schreiben dann da Kommentare rein und so weiter und entgehen dabei dem Dialog und andere Teams, die das sehr Agil tun, die wissen, dass die wichtigste Art der Kommunikation von Angesicht zu Angesicht stattfindet, weil wir eben so viel mehr an Bandbreite haben, an Informationen, die wir im direkten Dialog miteinander haben.

 

Kai

Dass wir die nutzen wollen, um ein möglichst tiefes Verständnis zu haben, um das richtige an Wissen zu produzieren. In unserem Quellcode zum Beispiel. Quellcode ist ja auch so amalgamisiertes Wissen und in unserem Produkt soll die bestmögliche Lösung rein fließen . Und die kriege ich dann hin, wenn die Leute, die das Produkt brauchen, mit denen sprechen, die das bauen und nicht wenn ich eine Abstraktionsschicht habe von Text.

 

Jasmine

Und um das noch mal zusammenzufassen – Es ist nicht schlimm, wenn die Spezifikationen irgendwo stehen. Das Schlimme daran ist, wenn sich das irgendjemand ausgedacht hat und hingeschrieben hat. Das heißt oder das schlimme daran, wenn sie schon in der User Story drin stecken. Die User Story soll der eine Satz sein, der unsere Kreativität anregt. Also als Barbara Backoffice möchte ich gut sichtbare Buttons, weil ich wenig Zeit zur Bedienung habe, wenn ich am Telefon bin. Und da kann das sein, dass wir jetzt in die in die Kommunikation gehen, miteinander, aber vielleicht auch mit prototypisch Barbara Backoffice.

 

Jasmine

Vielleicht fragen wir einfach drei Backoffice Mitarbeiterinnen. Wie sieht denn das aus, wenn du damit arbeitest? Und da sehen wir: Boah, die haben irgendwie sieben Fenster gleichzeitig auf, wenn sie am Telefon sind, müssen alle Programme gleichzeitig bedienen und dann halt unser Programm auch noch. Und dann brauche ich vielleicht eine Telefonansicht. Dann geht es gar nicht darum, dass wir einzelne Buttons umgestalten, sondern es geht darum, dass wir eine Telefon Ansicht des Programms machen oder oder oder oder.

 

Jasmine

Oder es geht einfach darum, dass wir den Button wirklich grün machen. Das würden wir in der Kommunikation mit dem Endkunden rausfinden und in der Kommunikation miteinander. Und wenn wir darüber reden und uns das dann aufschreiben, dann ist das was ganz anderes, als wenn das jemand aufgeschrieben hat, ich das lese. Und das führt oft zu ganz vielen Missverständnissen. Deswegen ist dieser Konversation Part ganz, ganz wichtig in einer empirischen Produktentwicklung. Wir schaffen hundertprozentige Transparenz, damit wir inspizieren und adaptieren können.

 

Jasmine

Das können wir nur zusammen, nicht alleine.

 

Kai

Wir hatten hier mal ein Interview mit Marc Bless, der hat auch mal ein Buch geschrieben über Scrum in der Medizintechnik. Jetzt könnte man ja sagen: Okay, aber wenn jetzt in diesen User Stories nicht so richtig spezifiziert ist, was wir bauen sollen, kann ich das zum Beispiel Medizintechnik Bereich machen, Agil arbeiten oder kann ich das im Luft und Raumfahrt Bereich machen? Wenn ich ganz konkrete Dokumentation brauche, gehört die einfach an eine ganz andere Stelle nämlich, dann verorte ich die in einem Scrum Rahmenwerk in der Definition Of Done, also dem Kriterium, was fertig heißt.

 

Kai

Da kann dann durchaus drinstehen, wir haben irgendeine ISO Norm erfüllt. Und an der Stelle ist vielleicht auch ganz viel textliche Dokumentation entstanden, die das noch mal für die Nachwelt irgendwie verfasst. Es ist aber einfach dann andersherum. Es ist quasi ein Liefer Gegenstand, der nachher aus der Kreativität am Anfang entstanden ist und nicht andersherum. Dass ich mir vorher ein riesen Kopfzerbrechen als ein einzelner Experte, was genau die beste Lösung sein soll. Und danach ein Team, das nur noch umsetzt, sondern eben dieses Führen über die Einladung zum Gespräch.

 

Kai

Insofern kann man auch sagen Agile Teams quatschen viel mehr.

 

Jasmine

Aber dadurch bauen wir das Richtige in der richtigen Qualität und reduzieren sehr, sehr, sehr viel Waste auf dem Weg. Das heißt, das kann sich anfangs uneffizient anfühlen, weil ja, wir gehen viel mehr in den Dialog. Das ist aber hinten raus oder mittelfristig sehr viel effizienter, weil wir den ganzen Quatsch und die ganzen Missverständnisse eben nicht mehr bauen, sondern früher rausfinden. Um das jetzt noch mal so zusammenzufassen. Viele Agile Teams haben ein Backlog, eine geordnete Liste an Anforderungen an das Produkt.

 

Jasmine

Da können ganz viele verschiedene Dinge drinstehen, unter anderem User Stories. Nicht alles was da drinsteht, ist eine User Story, auch wenn Jira das so nennt. Wenn ich zum Beispiel eine System Beschreibung da drin habe, weil das System das einfach braucht, dann bitte nicht als User Story formulieren. Es gibt ganz komische User Stories. Wenn ich aber einen konkreten Umsetzungwunsch ein Feature da drin habe, dann nützt mir die User Story unglaublich. Wenn ich da eine User Story schreibe, ist das nur ein Versprechen für eine Konversation.

 

Jasmine

Das heißt das ist eine Anforderung an unser Produkt. Wirklich aus der Brille des Endkunden raus geschrieben, das uns helfen soll in Konversationen zu gehen und unsere kollektive Intelligenz und Kreativität zu nutzen. Sobald wir in Konversation gegangen sind, können wir natürlich spezifische Anforderungen an diese User Story dran schreiben. Dann werden wir uns auch alle erinnern, was wir uns überlegt haben. Das sind dann die sogenannten Akzeptanz-Kriterien. Also wie teste ich, dass wir fertig sind mit dem was wir denken, dass unser End-User braucht?

 

Jasmine

Eine User Story ist nichts anderes als eine Hypothese und es bleibt eine Hypothese, bis der User das getestet hat und sagt – Jo, das ist das was ich brauche oder noch nicht ganz. Und beides ist okay. Wir sind in einem komplexen Raum, das heißt, wir können nicht immer alles 100 Prozent perfekt haben. Das ist einfach natürlich. Wir müssen vielleicht noch mal zurückgehen ans Reißbrett, noch mal ein bisschen was ändern an unserer Idee schleifen, noch mal ausliefern. Und beim zweiten oder dritten Mal sagt unser End User Genau das habe ich gebraucht.

 

Jasmine

Also Akzeptanzkriterien sind die konkreten Anforderungen, die wir besprochen haben an unsere User Story. Und dann habe ich noch die Definition Of Done, unsere gemeinsame Anforderungen an Qualität für jede einzelne User Story und für jedes einzelne Ticket in unserem Backlog. Das heißt, das gilt über alles hinweg. Alle Anforderungen, die ich habe an Dokumentation, an Qualität etc. steht in unserer Definition Of Done. Da haben wir auch eine Podcastfolge dazu gemacht. Aber jetzt hast du so trennscharf die unterschiedlichen Abgrenzungen.

 

Jasmine

Die sind am Anfang ein bisschen schwierig zu verstehen. Sobald man anfängt, damit zu arbeiten, macht es aber ganz, ganz viel Sinn, warum das getrennt ist und warum wir da sehr trennscharf unterwegs sind.

 

Kai

Diese Themen vertiefen wir natürlich auch in unserem Certified Scrum Master Seminar und auch im Advanced Certified Scrum Master Seminar noch mal, dass du diese gleiche Klarheit und auch noch so das Handwerkszeug dazu lernst, damit du einen Product Owner darin auch unterstützen kannst, das entsprechend zu nutzen. Und wir hoffen, du hast jetzt einen guten Überblick gekriegt über das Thema, denn eigentlich wird das viel zu heiß gekocht, als es gegessen wird. Denn ja, es geht darum, miteinander zu sprechen, das Richtige zu bauen klingt trivial, ist aber in der Praxis ganz oft nicht der Fall.

 

Kai

Insofern die große Einladung zum Gespräch, die wir hier heute aufgemacht haben mit dir. Und wir freuen uns, dass du in dieser Folge wieder zugehört hast beim Agile Growth Podcast.

 

Jasmine

Das war unser kleiner Impuls zum Thema User Stories. Wenn du Leute kennst, die User Stories falsch benutzen oder noch viele Fragen haben zu genau diesem Thema, dann darfst du diesen Podcast natürlich unglaublich gerne weiterempfehlen. Und ich freue mich total, wenn du nächstes Mal wieder mit dabei bist beim Agile Growth Podcast.

 

Wie wird man Scrum Master?

Mehr und mehr Unternehmen suchen Scrum Master und Scrum Masterinnen.


Mit der Corona-Pandemie hat sich die Nachfrage nach dieser Verantwortlichkeit weiter vergrößert, mehr und mehr Teams arbeiten digital und verteilt.

 

Doch wie komme ich eigentlich in diese Rolle rein?

Was ist der Einstiegspunkt und was sind Aspekte, die ich lernen darf, wenn ich diese Rolle auch wirkungsvoll ausfüllen möchte?

Jasmine

Herzlich willkommen zum Agile Growth Podcast! Ich freue mich, dass du mit dabei bist. Die halbe Welt sucht Scrum Master. Aber wenn ich das noch nicht bin oder wenn ich darin wirkungsvoller werden möchte, wie mache ich das denn überhaupt? Das ist unser Thema von diesem Podcast. Wir beleuchten die Scrum Master Rolle von verschiedenen Winkeln. Und ich wünsche dir viel, viel Spaß damit.

 

Sprecher

Herzlich Willkommen zum Agile Growth Podcast, dem Podcast für alle Agile Interessierten mit hilfreichen Ideen und erprobten Werkzeugen, die dich weiterbringen. Von und mit den Two Agilists.

 

Kai

Herzlich willkommen zum Agile Growth Podcast! Wir sind Jasmine und Kai und wir helfen Menschen dabei, die Versprechen agiler Vorgehensweisen in der Praxis einzulösen, ohne IT Wissen vorauszusetzen. Und heute geht es darum, wie man eigentlich Scrum Master wird – eine Rolle oder eine Verantwortung, die immer mehr geworden ist in der Wirtschaft. Das ist unter den Top 20 Zertifizierungen, die es so weltweit gibt, im Bereich Projektmanagement ist der Scrum Master glaube ich auf Position 9 in den USA also schon irgendwie etwas, was viel Sichtbarkeit bekommen hat und im Zuge von Digitalisierung und verteiltem Arbeiten auch immer häufiger angefragt wird.

 

Kai

Das sieht man auch so ein bisschen dran. Ich verfolge seit längerer Zeit die Xing Stellenanzeigen und da kriege ich immer so – wie viele offene Scrum Master Jobs gibt es irgendwie aktuell und das ist immer weiter hochgegangen. Also weiß ich nicht. Früher kriegte ich immer so ja irgendwie 120 130, jetzt sind es 458 oder so  was. Und stagnierte auch gefühlt. Das heißt durch diese ganze vielleicht auch Corona Digitalisierung Welle, die jetzt gekommen ist, hat sich das noch mal intensiviert.

 

Kai

Wie viel Scrum Master so im Land gesucht werden. Und da stellt sich natürlich die Frage: Wenn ich das jetzt nicht selber bin, wie kann ich das dann werden?

 

Jasmine

Eine Frage, die wir vor allem Inhouse Trainings ganz, ganz oft gefragt werden: Wie werde ich denn eigentlich Scrum Master? Und da gilt es zu unterscheiden – Willst du ein Zertifikat? Oder möchtest du die Wirkung des Scrum Master entfalten? Und das sind für mich zwei verwobene, aber auch unterschiedliche Dinge. Wir würden jetzt an der Stelle mal anfangen mit: Willst du das Zertifikat. Weil wenn du einfach den Badge willst, ich bin Scrum Master zertifiziert bei, dann gibt es natürlich Zertifizierungs Organisationen.

 

Jasmine

Es gibt mittlerweile sehr sehr viele und da ist es unserer Meinung nach extrem wichtig, dass du dir Gedanken darüber machst. Was ist mir wichtig an meiner Zertifizierungs Organisation? Wie groß soll die sein und wie viel Reputation soll die denn schon haben? Die zwei größten Zertifizierungs Organisationen sind immer noch die Scrum Alliance und die Scrum.org. Und wenn du uns jetzt schon ein bisschen länger gefolgt bist, dann weißt du wahrscheinlich auch, dass wir für uns als Zertifizierungs Organisation die Scrum Alliance gewählt haben.

 

Kai

Genau das kam eher zufällig tatsächlich. 2007, als ich meinen Certified Scrum Master damals gemacht habe, gab es einfach auf dem deutschen Markt extrem wenig an Angebot. Da war das eh dieses ganze Thema Scrum und Agilität so ein  Nischenthema. Und ja, dann habe ich mich da eine Schulung reingesetzt. Da wusste ich auch nichts irgendwie, welche Allianzen es gibt oder irgendwas, sondern ich wollte einfach eine Scrum Schulung besuchen und das klang irgendwie gut. Und die Scrum Alliance war damals schon aktiv vor den 14 Jahren und die Schulung war gut und so wurde ich dann irgendwie Mitglied und das hat sich dann irgendwie nicht geändert bis heute bzw.

 

Kai

umgekehrt. Ich habe da noch ganz, ganz viele Dinge mit der Scrum Alliance und den Menschen dort gelernt, sodass ich auch froh bin und stolz, mit diesen Menschen zusammenarbeiten zu dürfen. Denn die Scrum Alliance ist so der größte Dachverband weltweit. Also die Scrum Alliance hat mittlerweile 1,4 Millionen Menschen zertifiziert, wenn ich es richtig im Kopf habe. Und insofern hat man da schon auch einfach eine riesen Community und große Haus Konferenzen undsoweiter. Aber ich will jetzt hier nicht den Riesen Scrum Alliance…

 

Jasmine

Das ist ganz spannend. Bei Kai kam das anscheinend zufällig.

 

Jasmine

Wir haben es da gar nicht drüber unterhalten. Bei mir war das wirklich eine bewusste Entscheidung, weil ich habe für mich eine Scrum.org Schulung gemacht als Einstieg. Die war okay, ich hatte aber irgendwie in der Community für mich nicht den Anschluss gefunden. Das mag jetzt anders sein. Zu der Zeit, wo ich die Schulung gemacht habe, war das für mich so und ich habe dann geguckt, wo finde ich denn für mich eine berufliche Heimat? Und damit sind wir vielleicht dann auch schon wieder beim zweiten Punkt.

 

Jasmine

Willst du die Wirkung? Ich habe für mich gemerkt, nach so einer Zertifikats Schulung habe ich viele Fragen gehabt. Unsere Tochter ist ja neun Jahre alt und die liest ganz gerne. Und einer Ihrer Lieblingssätze. Es gibt zwei Lieblingssätze: „Mama, wusstest du?“ Oder „Mama, ich habe Fragen“ und gefühlt ging es mir so nach meiner Schulung. Ich hatte viele Fragen und ich habe irgendwie da in der Community für mich keinen Anschluss gefunden, habe mich dann bewusst für die Scrum Alliance entschieden, weil mir auch die Non-Profit, also das Non-Profit, an der Organisation gefällt.

 

Jasmine

Das ist ein großer Unterschied, die Scrum.org ist For Profit , die Scrum Alliance ist Non-Profit. Mir hat das Non-Profit an der Organisation sehr sehr gefallen und mir hat das Gedankengut dahinter gefallen. Also „we transform the world of work“ – wirklich daran zu arbeiten, dass wir neue Arbeitswelten kreieren, zusammen dafür zu arbeiten. Und da habe ich, so meine Community gefunden und das darfst du für dich entscheiden, egal was du nimmst. Wir würden dir immer ans Herz legen, eine der zwei großen Organisationen zu nehmen und da auch einfach zu gucken welcher Trainer passt zu mir.

 

Jasmine

Beide Organisationen haben natürlich Lernziele hinter den Kursen, die die Kurse erfüllen und jeder Trainer wird diese Lernziele aber ein bisschen anders rüberbringen. Und das ist genau so wie in der Schule. Hattest du einen geilen Geo Lehrer, findest du Geografie cool. Hattest du einen *** Geo-Lehrer oder Lehrerin ist vielleicht Geo nicht dein Lieblingsfach geworden? Zumindest bei mir war das so. Die Fächer hingen partiell von meinen Interessen ab, aber sehr sehr von den Lehrern. Das heißt, sich da mal Gedanken zu machen – bei wem möchte ich lernen, wer möchte, wer darf mein Mentor werden?

 

Jasmine

Weil das einfach zu mir passt, macht für mich total Sinn. So. Und genau – dann gehst du entweder in den Kurs, bei der Scrum Alliance musst du in einen Kurs gehen, sonst kriegst du deinen Stempel nicht und machst danach einen Test. Ich glaube, bei Scrum.org kannst du auch einfach Geld ins Kässle legen und den Test machen. Ich würde dir immer einen Kurs empfehlen, weil das einfach eine Basis ist, die du für dich schaffst. Eine gemeinsame Basis, die auf Lernzielen beruht, die wir als Scrum Master einfach wissen sollten.

 

Kai

Jetzt gibt es natürlich immer wieder die Kritik und die ist auch völlig fein, dass man mit so einem Scrum Master Zertifikat ja gar kein echter Master ist. Also man meistert das ja gar nicht in diesen drei Tagen. Und vielleicht hast du das auch schon mal gehört. Ne Scrum ist einfach zu verstehen, aber schwer zu meistern und das ist natürlich auch genauso. Insofern kannst du sagen, so ein Scrum Master Zertifikat ist jetzt sowas wie ein Führerschein. Also du hast dir mal die Theorie angeguckt, bist auf die Theorie geprüft worden.

 

Kai

Du hast auch ein bisschen was, ein paar Praxis Fahrstunden gehabt, also ein bisschen was gehört und wo macht das Sinn, wo nicht? Und welche Erfahrungen hat der Trainer und andere im Seminar weitergegeben? Aber das Fahren lernt man dann eben doch erst auf der Straße und auf der Straße merkt man dann so Huch! Es gibt ja manchmal Situationen, da ist Aqua Planing und da ist irgendwie Raureif auf der Fahrbahn. Und da habe ich auf einmal eine ganz krasse Steigung irgendwie im Berg und habe aber einen Wohnwagen hintendran.

 

Kai

Und da merkt man dann so – Na, das, was ich jetzt in dieser Basis Schulung gehabt habe, das war gut. Aber vielleicht brauche ich jetzt doch noch das eine oder andere Fahrsicherheitstraining, um entsprechend damit zurechtzukommen. Und da hört man natürlich auch schon raus. Ein wichtiger Teil ist natürlich, einfach Kilometer zu fahren, also Scrum einzusetzen und damit zu arbeiten. Aber vielleicht will man sich unterwegs auch noch ein bisschen mit Facetten beschäftigen, die zum Scrum Master dazugehören.

 

Kai

Und da sollten wir noch mal ein bisschen reingucken, wenn ich jetzt Scrum Master werden will. Okay, ich habe jetzt irgendwie in so zwei, drei Tagen mal verstanden – Was ist denn dieses Scrum? Wie komme ich denn jetzt tiefer in die Rolle rein?

 

Jasmine

Und eins der Punkte, die ich immer sage: Also du, du lernst fahren, indem du Auto fährst, nicht, in dem du darüber nachdenkst, wie Autofahren funktioniert. Das heißt, in die Rolle kommst du vor allem rein, indem du ins Üben gehst und dich in die Rolle rein schmeißt. Wenn du es in deiner aktuellen Organisation nicht kannst, dann hilft es, immer mal wieder zu gucken: Gibt es irgendwo eine Möglichkeit, wo ich mal einem Scrum Master einfach folgen könnte oder wo ich vielleicht so was wie ein Praktikum oder eine Job Rotation oder oder oder machen könnte in meinem Unternehmen, damit ich mein Gespür für diese Rolle bekomme und anfangen kann, diese Rolle zu üben.

 

Jasmine

Es gibt natürlich auch immer wieder die Möglichkeit, dass du bei dir in deinem Umfeld anfängst Scrum zu machen und da in die Scrum Master Rolle reinschlüpfst. Das sind so die zwei Möglichkeiten. Und sonst gibt es ganz, ganz viele offene Jobangebote, die Scrum Master händeringend suchen. Von daher, da gibt es auch immer wieder die Chancen für Neueinsteiger. Besonders wenn du ein bisschen Berufserfahrung hast, ist meine Erfahrung, dass deine Chancen extrem gut stehen, da in eine Rolle reinzukommen.

 

Jasmine

Ansonsten haben beide Organisationen. Wenn du jetzt sagst: Hey, ich bin jetzt unterwegs, ich habe meine ersten Erfahrungen gesammelt und jetzt habe ich Fragen. Gibt es so zwei Möglichkeiten. Das eine ist: Du schließt dich einer Community an, es gibt ganz viele Meet ups, Abendveranstaltungen etcetera. Konferenzen, wo du deine Fragen beantwortet bekommen kannst, wo du in Sparring gehen kannst mit Leuten. Das hat mir sehr geholfen. Und das zweite ist, das haben beide Organisationen, glaube ich.

 

Jasmine

Und jetzt lehne ich mich ein bisschen aus dem Fenster, weil ich kenne natürlich die Scrum Alliance besser als die Scrum.org. Weiterentwicklungsphase für Scrum Master und da wollen wir ein bisschen tiefer reingehen. Nicht unbedingt in den Weiterentwicklungspfad per se. Wir sind auch gerade dran, das Angebot für die Agile Growth zu launchen. Das heißt, falls du Lust hättest, das mit uns zu machen. Und an der Stelle wieder der Aufruf: Der Trainer ist wichtig. Wenn wir zu dir passen, dann freuen wir uns total, wenn du dich mit uns auf einen Entwicklungsweg begehst.

 

Jasmine

Ansonsten gibt es auch andere gute Trainer, die Entwicklungspfade haben. Unser Angebot wird zu Beginn des nächsten Jahres wieder live gehen. Das heißt, wir nehmen kleine Kohorten auf, wo wir in die Entwicklung gehen mit den Menschen. Ich möchte jetzt aber weniger in diesen Entwicklungspfad reingucken als was sind denn die Inhalte des Pfades? Wo schärfen wir denn unsere Fähigkeiten? Wenn wir uns auf einen Pfad begeben, ein wirksamer Scrum Master zu sein. Und ja, nach einem drei Tage Training wirst du vielleicht nicht so wirksam sein, wie du dir das wünscht.

 

Jasmine

Weil in dieser Scrum Master Rolle ist ja schon ganz schön viel drin

 

Kai

Und das ist, finde ich aber auch immer das Reizvolle daran, jetzt nach 14 Jahren – ich lerne immer noch Sachen dazu, die ich brauchen kann. Und das liegt vielleicht so ein bisschen daran. Ich habe ja den Ausdruck ein bisschen von meinem ehemaligen Kollegen Andi geklaut, der IT-Sozialarbeiter – der Scrum Master, also derjenige, wo es einfach menschelt. Und da kann man natürlich ganz, ganz viele Dinge lernen, die einem helfen in der Arbeit mit Menschen.

 

Kai

Und eine Sache zum Beispiel ist der Aspekt von Coaching. Und insofern geht es bei der Entwicklung Scrum Master auch immer darum, mal zu schauen: Was ist denn in dieser kompletten Industrie des Coachings eigentlich entstanden, was ich als Handwerkszeug und Haltung nutzen kann? Und da sprechen wir schon auch davon, dass das auch klassisches Life-Coaching sein kann. Also gar nicht so sehr dieses Performance Coaching, was in dem amerikanischen Scrum Master drin ist, sondern auch die Dinge, die man einfach im guten Kontakt aufbauen, guten Beziehungsaufbau und auch in der Hilfestellung konkret für andere Menschen lernen kann, wie das geht.

 

Kai

Also wirklich Life-Coaching im eigentlichen Sinne, was ja auch sehr, sehr verbreitet ist mittlerweile in der Industrie.

 

Jasmine

Und was in diesem Wort Coaching auch drin ist, ist natürlich, dass ich dem Team und auch der Organisation drumherum, aber insbesondere dem Scrum Team helfe, dass ich das Scrum Team Coach in Richtung Selbstmanagement und Cross Funktionalität. Das sind zwei Dinge, die sagen wir so leicht – ja ein Scrum Team ist selbst gemanagt. Und das ist Cross-Funktional. Aber Holy Cow, das ist hart und da stoß auch ich immer mal wieder noch an meine Grenzen und an meine ursprünglichen Prägungen.

 

Jasmine

Wo ich was sehe, es mich fuchst und das Gefühl habe: So, jetzt hau ich mal mit der Faust auf dem Tisch und ich sag den Leuten einfach, wo es langgeht. Ja, dann tue ich das und dann bekomme ich ganz viel Gegenwind. Es ist immer schön. Es ist eine gute Lehre vom Leben. Also man kriegt immer die Wachstums Container, die man braucht. Aber Selbstmanagement ist meiner Meinung nach uns so aberzogen worden, dass das ganz schön schwierig ist, wieder da reinzukommen.

 

Jasmine

Dass es ganz schön schwierig ist als Einzelperson in die Verantwortung zu kommen und dann auch als Team in die Verantwortung zu kommen. Und wenn ich ein Team in Richtung Selbstmanagement coachen möchte, dann muss ich erst mal mich lernen zu coachen in die Richtung volle Verantwortung. Und dann kann ich auch das Team dabei unterstützen und dabei zu verstehen, dass Selbstmanagement nicht heißt: Ich lasse jetzt einfach die Zügel los und die können machen, was ihr wollt. Sondern Selbstmanagement heißt meistens, einen ganz expliziten Rahmen aufzubauen, worin sich das Team entwickeln kann.

 

Jasmine

Und das ist bei jedem Team sehr unterschiedlich, wie eng oder wie groß ich diesen Rahmen gestalten kann. Aber Selbstmanagement wird nicht passieren, wenn wir sagen: Ja, hier ist jetzt Anarchie. Jeder darf sagen, was er will, jeder darf machen, was er will und wir machen jetzt alles. Sondern wir sind jetzt sehr fokussiert auf ein Ziel, das wir erreichen wollen. Und das darf ich als Scrum Master zu unterstützen lernen und auch zu coachen lernen. Also diese zwei Aspekte von Coaching, das eine geht eher in Life Coaching, das andere geht in Coaching das Selbstmanagements und der Cross Funktionalität. In der Cross Funktionalität steckt ja drin, dass ich mich anfangen muss zu unterhalten mit Menschen, wo ich mich vorher gar nicht unterhalten hätte.

 

Jasmine

Und das ist auch nicht ganz so einfach.

 

Kai

Und wenn wir gerade über diese Coachende Funktion des Scrum Master sprechen und über selbst gemanagte Teams, dann kommt man vielleicht auch auf den Gedanken, wenn das Team doch jetzt selbst gemanagt ist, was macht denn dann der Manager, der vorher dieses Team gemanagt hat? Und das ist natürlich auch ein Teil dessen, was man als Scrum Master mit begleiten darf, nämlich mit dem Management zu arbeiten. In einem neuen Rollenbild, in einem neuen Führungs Verständnis, das ganz oft beinhaltet, dem Team zu vertrauen und loszulassen und einen Rahmen drumherum zu stecken und das große Spielfeld zu beschreiben, aber eben nicht rein zu grätschen in das, was ein Product Owner innerhalb des Teams und den Leuten selber an Verantwortung gehört.

 

Kai

Und da ist also auch noch mal so ein verstecktes Coaching Mandat, für das man vielleicht auch noch mal eine eigene Entwicklung nehmen möchte. Denn die Sprache und ich bin jetzt ja schon lange in der Entrepreneurs Organisation, wo wo es darum geht, wie man so als Unternehmer irgendwie denkt und handelt. Das ist schon auch ein bisschen anderes Jargon. Das ist schon auch ein bisschen andere Flughöhe oder Blickwinkel, eher so strategisch auf Dinge. Und den hatte ich früher definitiv nicht und hatte auch Schwierigkeiten, mich auf dem Feld zu bewegen

 

Kai

als junger Scrum Master, also wie komme ich eigentlich in einen guten Kontakt und kann auch relevante Dinge beantworten? Warum machen wir in Sachen Agilität eigentlich bestimmte Dinge so und nicht anders? Und wie nützt einem das eigentlich? Denn schlussendlich hat der Manager ja auch eine Verantwortung in diesem Unternehmen, dass da irgendwas passiert oder irgendein Budget, das an ihn delegiert worden ist, sinnvoll genutzt wird und so weiter. Und der braucht dann entsprechend Lösungen in diesem Kontext von Agilität und dem ist das vielleicht gar nicht so wichtig, was da im Einzelnen Detail im Team passiert.

 

Kai

Aber der muss natürlich schon auch verstehen und auch vertrauen können darin, dass diese Initiative A nicht seinen Stuhl kostet und B irgendwie sinnvoll ist für ihn.

 

Jasmine

Um da so ein ganz praktisches Failbeispiel aus meiner Karriere zu geben. Also für mich hat das lange gedauert, bis ich verstanden habe oder bis ich, bis ich mich in die Schuhe der anderen Leute stellen konnte und gucken konnte: aus welchem Blickwinkel guckt dieser Mensch denn auf unsere Produktentwicklung und was genau muss der wissen? Und welche Sicherheit braucht dieser Mensch, damit er loslassen kann und vertrauen kann? Und wenn ich zurückblicke und das erfüllt mich immer noch mit einem bisschen Scham, wie viele Male ich mit CEOs, aber auch mit anderen Führungskräften in die Mechanik von Scrum rein geguckt habe und da missionarisch unterwegs war und das Gefühl hatte: Und guck, wir machen das jetzt genau so und du musst jetzt an der Stelle das und das machen und da lässt du am besten ganz die Finger weg, aber nicht verstanden habe.

 

Jasmine

Was genau interessiert denn der Mensch? Weil zum Beispiel ein CEO oder ein Manager, der mehrere Teams unter sich hat, den interessiert die Mechanik von Scrum herzlich wenig an den meisten Stellen, sondern warum tun wir Scrum? Warum ist es das Richtige, hier zu tun? Und was kann ich tun, um die Teams zu unterstützen, damit das auch gut gelingt? Also – oder vielleicht muss ich auch  meine Führungs Haltung ändern an der Stelle und wie begrenzen wir Risiken?

 

Jasmine

Und in all diese Themen rein zu gehen und auch die finanziellen Themen. Was bringt es mir finanziell am Ende des Tages, wenn wir das tun? Das war für mich ganz, ganz ein wichtiger Schritt, ein schmerzhafter Schritt. Und genau da. Da darf man als Scrum Master ganz viel dazulernen. Das ist etwas, was zum Beispiel jetzt auf diesem Pfad zum Certified Scrum Professional in der Scrum Alliance definitiv angesprochen wird mit verschiedensten Lernzielen.

 

Kai

So, jetzt haben wir über Coaching gesprochen als Aspekt. Dann gibt es noch etwas und das sehen auch sehr viele Leute im Scrum Master von außen. Im Deutschen sagen wir Moderation. Das trifft’s aber eigentlich nicht ganz, weil die Engländer sagen Facilitation. Und da steckt noch ein Aspekt drin. Also ja, wir sprechen auch über Moderation, Moderations-Fähigkeiten, Gesprächs- und Gruppen-Moderation. Aber in Facilitation steckt auch noch was Vereinfachendes drin, also etwas in Fluss zu bringen mit einer Gruppe von Leuten im Raum.

 

Kai

Und das ist auch so ein Handwerkszeug und auch eine Haltung, die man einfach nicht automatisch mitkriegt, sondern wo man sich auch ein bisschen reinknien darf. Wie geht das denn eigentlich, dass ich einer Gruppe helfe? Mit Vereinfachung durch gute Moderation, durch Metaphern. Dadurch, dass ich einen psychologischen Raum gestalte. Wir haben hier schon über Team Vereinbarungen gesprochen und all das, was hilft, dass Menschen, die zusammenkommen, gemeinschaftlich ein Ziel erreichen oder ein Moderatorions-Ergebnis erreichen.

 

Kai

Was natürlich immer passiert in den Scrum Ereignissen. Dass ich da immer ein klares Ziel habe und das auch erreichen möchte mit den Menschen. Das kann ich eben entweder eleganter erreichen oder auch total hölzrig und schwierig. Und da eine Kunstfertigkeit drin zu entwickeln, dass ist auch was, was zu diesem Pfadtraining dazugehört, nämlich dass ich nicht einfach nur irgendwie das Ereignis mit dem Ziel abhake, sondern dass die Menschen auch den Eindruck haben, ich habe da meine Zeit gut genutzt. Denn ansonsten passiert ganz oft, dass die Leute sagen: Boah Scrum, das hat so viele Meetings, oh schon wieder, ich will doch einfach nur programmieren, oder ich will doch einfach nur meine Arbeit machen.

 

Kai

Müssen wir schon wieder miteinander reden? Weil das dann eben, wenn das so harzig ist, auch keiner Bock drauf hat. Natürlich hat da dann keiner Bock drauf. Ich kenne diesen Impuls von mir selbst, wenn es schlecht läuft oder ein Elternabend in der Schule – ein klassisches Beispiel. Die sind ja auch meistens ganz unterirdisch moderiert und dann sitzt du da drin und denkst dir so na ja, ok, ich könnte jetzt nicht mal jemand hier so Führungen und Facilitation und ein bisschen was an Facilitation Material und könnten wir nicht mal irgendein Brainstorming machen, statt das hier irgendwie alles irgendwie miteinander zu diskutieren.

 

Kai

Also da jemand, der darüber nachdenkt wie komme ich einfach an das Ergebnis,  mit Leichtigkeit auch durch schwierige Prozesse, dass es diese Rolle von Facilitation.

 

Jasmine

Und die dürfen wir üben. Also ich würd sagen, weder Kai noch ich waren geborene Facilitatoren am Anfang unserer Scrum Master Karriere. Wir haben da ein paar Kurse besucht, ganz viel geübt und auch ganz viel uns mal andere Menschen in den Raum gesetzt und uns Feedback geben lassen, das ist auch etwas, was ich dir ans Herzen legen kann, wenn du die Möglichkeit hast, dir einen Sparringspartner in deiner Organisation zu suchen, wo ihr euch gegenseitig Feedback gebt.

 

Jasmine

Das ist sehr, sehr gewinnbringend, das zu tun.

 

Kai

Und wir haben natürlich totalen Luxus in dem Sinne, dass wir ganz oft zu zweit in Mandaten drin sind und dann auch Pair Facilitation oder Co Facilitation machen können, wo wir halt abwechselnd Sequenzen moderieren und danach auch uns austauschen können beim Spaziergang, wo wir noch Sachen verbessern können. Also da so ein Sounding Board Sparringpartner ist total gut, wenn man das entsprechend hat und Reflexion kommt. Und natürlich gibt es auch immer noch bei uns Dickschiffe von Moderation, wo wir echt auch tagelang Konzepte wälzen und uns überlegen, wie könnte das dann irgendwie gehen?

 

Kai

Was haben wir in unserem Methoden Werkzeugkasten und welche Haltung wäre gut für diesen Workshop? Und das hört auch nie auf. Und ich finde das auch das Schöne daran, dass das ein konstanter Fluss ist, in dem man sich weiterentwickeln darf.

 

Jasmine

Und da vielleicht einen Daumenregel für dich an der Stelle, wenn dich Moderation interessiert. Was wir für uns festgestellt haben und es kann für jeden unterschiedlich sein, aber die Qualität, die wir in einer Facilitation liefern wollen, kriegen wir bei einer Gruppengröße bis 10 Personen auch alleine hin. Zu zweit ist immer besser, immer. Es ist immer lohnenswert zu zweit zu sein. Aber so bis 10 Personen schaffen wir das auch ganz gut alleine. Ab 10, 11, 12, 13, 14, 15 fängt bei mir an zu grummeln alleine.

 

Jasmine

Nicht, dass ich das nicht schaffen würde. Ich schaffe es. Aber mir entgeht viel mehr und wir versuchen unsere Kunden ganz, ganz aktiv davon zu überzeugen, dass es dann sinnvoll ist, in einen zweiten Facilitatior zu investieren, damit man dieses Sparring hat und damit das für die Gruppe noch effizienter ist. Weil in meiner Erfahrung wir investieren ganz viel, wenn wir 15 oder 20 Leute in einem Raum zusammenkommen lassen, eine ganze Zeit lang da ist eigentlich die Kosten der zweiten Facilitation ein Tropfen auf dem heißen Stein, aber der bringt so viel mehr.

 

Jasmine

Also wenn wir schon so viel investieren, dass wir 15 Leute oder 20 Leute für einen halben Tag zusammenkommen lassen, dann lohnt es sich, einen zweiten Facilitatior mit dazu zu nehmen.

 

Kai

Genau. In ganz vielen Kontexten hast du das natürlich nicht so, weil dein Scrum Team kleiner ist als das. Und dann ist das auch völlig fein, wenn man alleine unterwegs ist, aber einfach so als eine Lernchance, unsere Anregung: Vielleicht kannst du immer wieder in Kontakt gehen mit einem anderen Moderator und gemeinschaftlich was machen, um diesen Facilitation Aspekt entsprechend zu lernen und im Advanced Certified Scrum Master gehen wir auch noch mal tiefer drauf ein.

 

Jasmine

Jetzt, wenn du weiter deine Wirkung als Scrum Master vergrößern möchtest. Wir sind jetzt schon auf zwei Aspekte reingegangen, wo du rein tauchen kannst. Das eine ist Coaching im Sinne von Performance,Coaching im Sinne von Coaching Richtung Selbstorganisation und Cross Funktionalität und in Richtung auch Life Coaching. Das zweite ist Facilitation. Das kann man sehr gut lernen und den Muskel verstärken. Ganz viel üben. Der dritte Punkt wäre Mentoring. Ein Scrum Master ist natürlich auch ein Mentor in verschiedensten Themen und da durfte ich zum Beispiel ganz viel lernen, weil ich habe ja als Psychologin relativ viel davon verstanden, wie Menschen ticken und zusammenzuarbeiten.

 

Jasmine

Aber von den Säulen, wo Scrum drauf fußt, also von Lean, von empirischer Prozess-Kontrolle von Product Ownership oder Product Management, aber auch von XP zum Beispiel hatte ich von Tuten und Blasen keine Ahnung. Und ich werde mich jetzt immer noch nicht anmaßen, einem Entwickler zu sagen: Ich bring jetzt mal bei, wie du testen musst, aber ich kann mittlerweile Dinge hinterfragen oder ich kann einen Vergleich bringen. Andere Teams haben dieses Problem so und so gelöst und dann bin ich eher in einer Mentoring Rolle – in einer Rolle, die schon vieles gesehen hat, die weiß welche Pattern, welche Muster Scrum Teams helfen.

 

Jasmine

In verschiedenen Situationen. Das heißt nicht, dass ich diese Muster auf das Team auf doktriniere. Aber dass ich sie  vorschlagen kann, dass ich den Horizont des Scrum Teams erweitern kann, indem ich da als Mentor auftrete. Da hatte Kai, glaube ich, ein leichteres Spiel, weil das einfach deine Homebase war. Ich erlebe das zumindest so, wenn du mit Teams interagiert.

 

Kai

Genau, ich habe das ja selber gemacht in Teams. Insofern hatte ich da schon ganz viel von diesen Mustern, die ich weitergeben konnte, aus der eigenen Erfahrung heraus. Und wenn du jetzt neue rein startet in so eine Scrum Master Rolle oder dich dafür interessierst, sagst du natürlich zurecht – Okay, wo soll ich das denn jetzt hier haben? Und was ich festgestellt habe ist mir hat da auch immer wieder der Austausch mit der Community geholfen. Also einfach die Geschichten und Erfahrungen von anderen zu hören oder die Geschichten und Erfahrungen von anderen in Seminaren zu hören, weil ich dann mein Handlungs-Repertoire im Bezug auf solche Muster erweitert habe und dann auch sagen konnte: Okay, also was ich letztens noch gehört habe ist – bei Otto

 

Kai

 machen die das so und so und das ist das nicht auch vielleicht was für uns, diesen Ideen Katalog nicht nur aus der eigenen Erfahrung zu generieren, sondern auch aus der Erfahrung von anderen und da sind wir einfach wieder beim uralten Prinzip der Menschheit, dem Geschichtenerzählen und dem Zuhören, was andere für Erfahrungen gemacht haben als ein Weisheitsschatz, den wir da anzapfen können in der Rolle des Mentors als Scrum Master.

 

Jasmine

Eine ganz, ganz wichtige Rolle. Und das kommt glaube ich wirklich einfach einfach drauf an Wo startest du?

 

Jasmine

Wo sind dann deine Punkte, wo du mehr lernen musst oder weniger? Also für mich war Coaching und Facilitation fühlte sich natürlicher an diese Rolle des Mentors. Da habe ich mich langsam, langsam Schrittchen für Schrittchen herangetastet und ich merk auch da, da ist immer noch ein riesen Feld an lernen. Nicht, dass in den anderen beiden Punkten auch nicht noch ein riesen Feld und lernen offen ist. Es gibt immer was zu lernen. Überall. Das ist das Tolle. Aber genau in dieser Mentoring Rolle, die immer wieder für mich zu stärken – mir hilft, dass mir das so vor Augen zu führen.

 

Kai

Dann sind wir beim letzten Punkt, der noch dazugehört, mal abseits von Selbstkenntnis und natürlich Agilität irgendwie mögen haben wir noch die Trainer Facette. Wieso Trainer Facette? Na ja, ich treff meistens als Scrum Master auf ein Umfeld, wo diese Agilität entweder falsch verstanden worden ist oder noch gar nicht verstanden worden ist, also noch gar nicht bekannt ist. Und da ist natürlich das Prinzip irgendwie Wissen weitergeben und auch das Mandat dazu bekommen, Wissen weitergeben zu dürfen. Insofern kriege ich ganz oft kleine Trainings Aufträge.

 

Kai

Also dann sagt mal jemand könnte man nicht mal einen einstündigen Workshop dazu machen, was ist eigentlich Agilität. Und dann hat man eigentlich ein Trainings Mandat gewonnen, nämlich erst mal zu klären okay, reicht uns eine Stunde dafür? Wenn ja, welche Übung? Welche Simulationen nutze ich innerhalb dieser Zeit, um ein paar Prinzipien und Punkte rüber zu bekommen? Und auch welches Wissen möchte ich denn überhaupt weitergeben? Denn es gibt so die Annahme und ich beziehe mich auf das Vorwort von unserem aktuellen Buch Scrum Training, das Jutta Eckstein für uns geschrieben hat.

 

Kai

Und die meint so: Naja, also Wissen über Dinge haben mittlerweile einfach sehr, sehr viele Menschen. Aber was nicht so viele Menschen haben, ist eine Fähigkeit, wie man das auch weitergibt. Denn nur weil ich weiß, wie Dinge sind, heißt das nicht, dass ich die so verpacken kann, dass die bei meinem Gegenüber auch ankommen. Und da spielt eben ganz viel rein, diese Facette des Trainers. Denn du hast schon die Möglichkeit, einfach ein Feuer zu entfachen innerhalb von einer Stunde oder einem Tag oder eben auch nur ein Flämmchen oder dass gar nichts angeht.

 

Kai

Und das hängt natürlich schon davon ab, wie baue ich dann entsprechend solche Lernerfahrungen auf, dass die das Relevante beantworten, eine gewisse Tiefe haben und eben auch dauerhaft hängen bleiben?

 

Jasmine

Und da empfehle ich das Trainersein als extrem bereichernd für meine Coaching Praxis auch, weil also als ich gestartet bin auf meine Trainer reise, da war ich ja sehr selbst überzeugt, so dass bin ich ja schon, das kann ich ja schon alles. Ich kam ganz schnell auf dem Boden der Tatsachen an. Ja, ich weiß ganz viel, aber genau das was Kai gesagt hat, das rüber geben von Wissen, das Lernreise gestalten sei das eine Viertelstunde, eine Stunde oder drei Tage.

 

Jasmine

Das habe ich nicht beherrscht. Mein Training war eher: Komm, ich nehm dich jetzt mal zur Seite und ich erzähl dir mal, wie das geht. Das Problem wenn ich das tue ist das beim Gegenüber wahrscheinlich nicht so viel hängen bleibt. Also wie viel bleibt bei dir hängen, wenn du frontal beschallt wirst? Und da zu lernen an welcher Stelle – wo packe ich Inhalte wie? Und wie schaffe ich geschlossene kleine Module, damit die Menschen das verdauen können hilft.

 

Jasmine

Und der zweite Aspekt, den ich oft in mir selber erkannt habe, aber auch oft bei anderen erkenne, ist: Ich erzähl dir jetzt mal alles, was ich weiß zu einem Thema. Und das ist zwar nett gemeint, weil man ja den anderen ableveln möchte, weil man ja möchte, dass der andere das Gegenüber oder die vielen Gegenüber dann das gleiche wissen wie man selbst. Das Problem da ist aber, wie unser Gehirn beschaffen ist. Wir haben – das nennt man kognitiven Bottleneck oder kognitiven Load Theory.

 

Jasmine

Unser Gehirn kann nur eine gewisse Anzahl an Informationen verarbeiten und wir haben da ein Bottle Neck. Das heißt, wenn ich dir jetzt alles erzähle, was ich schon weiß. Dann wird bei dir am Ende sehr viel weniger übrig bleiben, als wenn ich gezielt auswähle, welche Information muss ich hier an dieser Stelle rüberbringen und wie bring ich sie am besten rüber, damit du dich daran erinnerst? Also diese Trainings Muskel zu stärken, das hilft.

 

Kai

Und das ist was, was bei mir recht spät kam in meiner Laufbahn als Scrum Master. Das ist auch nur punktuell in unserem aktuellen Ausbildungskonzept so drin. Dann kriegt man halt mal ein Thema zugeworfen und darf das vor anderen mal trainieren – so ein 20 Minuten Block und kriegt dann entsprechend Feedback dadrauf, damit man auch sich verorten kann. Wo stehe ich denn da eigentlich und Entwicklungs-Vorschläge, wie man da weiterkommen kann? Das ist aber sicherlich ein Aspekt, der für viele erstmal am Rand steht.

 

Kai

Der ist immer wieder wichtig, weil man als Scrum Master eben auch immer mal wieder so ein Trainings Mandat hat. Aber viele stehen halt nicht irgendwie ständig in Seminarräumen, sondern machen das halt mal nebenbei. Insofern entwickeln das auch viele Scrum Master meistens ein bisschen später in ihrem Weg.

 

Jasmine

Wobei ich letztens gerade einen größeren Auftrag hatte mit einem anderen befreundeten Scrum Master / Agile Coach. Wir waren da unterwegs, waren auch im Tandem unterwegs. Das war unglaublich lehrreich für uns beide. Und nach einer gewissen Zeit meinte der Scrum Master irgendwann mal: Du Jasmine, das ist krass. Ich habe endlich kapiert, was die Wirkung von gutem Trainersein ist, auch im Coaching. Und ich habe da kein einziges Training gegeben. Das war ein Coaching-Auftrag. Aber ich kann natürlich situativ, wenn’s gebraucht wird

 

Jasmine

ein 20 Minuten-Modul einfach aus dem Hut ziehen und da eine ganz kurze Intervention als Training machen. Und das gibt mir zum einen als Scrum Master mehr Standing, weil die Leute verstehen, die weiß, wovon sie redet, aber zum anderen hilft es der Gruppe einfach auch eine gemeinsame Sprache zu entwickeln. Und wir alle wissen dann, wovon wir reden. Und dann können wir weitergehen. Und genau dieser Schritt kam bei vielen Scrum Mastern erst später in der Entwicklung.

 

Jasmine

Wir haben das Buch dazu ja auch geschrieben. Falls du Lust hast, da rein zu gucken, bist du herzlich eingeladen dazu. Wenn das für dich noch nicht ansteht, ist das auch völlig in Ordnung. So, jetzt sind wir so die vier Haltungen, die ich als Scrum Master einnehmen kann und da rfwo ich lernen darf, durchgegangen. In diesen vier Haltungen kann ich meinen Scrum Master Muskel trainieren und wir haben auch immer wieder Beispiele gebracht und als Scrum Master habe ich einen Service an das Team.

 

Jasmine

Ich habe ein Service an den Product Owner und ich habe einen Service an die Organisation. Und je nachdem, wo ich herkomme, fällt mir das eine oder das andere leichter. Ich kam ja früher aus der Organisationsentwicklung. Daher heißt dieser Service an die Organisation. Der fiel mir relativ leicht. Den Service an das Team. Den musste ich erst mal lernen, ging aber noch und den Service an den Product Owner, da lerne ich immer noch. Also gute Product Owner schickt mich Product Owner da aktiv und gut unterstützen kann.

 

Jasmine

Da bin ich täglich noch am Dazulernen, weil das für mich die wenigsten natürlichste das Service war.

 

Kai

All diese Coaching Fähigkeiten nach außen, die der Scrum Master vereint, diffus natürlich auch auf Selbsterkenntnis und Selbsterfahrung. Da kann ich noch mal den Turbo einlegen, wenn ich mich gut kenne in verschiedenen Situationen, wenn ich mich de-triggern kann, also auch aus emotionalen Zuständen wieder bei mir selber ankommen kann, ohne in das Drama einzusteigen in der Organisation. Und wenn ich das so als Schmierstoff noch darunter habe, dann habe ich eine gute Basis. Und dieser Weg braucht natürlich eine gewisse Weile, wenn man den geht und macht mehr Spaß, wenn man mit anderen geht, den für sich selbst.

 

Kai

Also Persönlichkeitsentwicklung nur mit sich selbst zu betreiben und auch neue Methoden kennenzulernen. Ja, ich weiß, ich bin auch ein totaler Autodidakt. Ich habe mir super viele Dinge selber beigebracht, aber mit selber beigebracht. Das hat oft inkludiert, dass ich trotzdem in Kontakt und Beziehung gegangen bin mit anderen, um das zu lernen. Also selber beibringen war auch mal aus dem Buch heraus. Aber ich würde sagen, die wichtigen Erfahrungen, die waren dann alle mit anderen Menschen.

 

Jasmine

Und ich glaube, was wir beide aber sagen können, Kai und ich war wirklich diese Selbsterfahrung, die Selbsterkenntnis da drin. Das war der Turbo in unserer Wirkung als Scrum Master gegen außen. Und natürlich auch mit unserem Job irgendwie gut klar zu kommen. Der ist nicht immer einfach da. Man handelt mit ganz vielen Menschen, mit ganz vielen Organisationen, mit ganz vielen Inpediments. Manchmal ist es zum aus der Haut fahren und da eine gute Balance hinzukriegen, mich auch um mich zu kümmern, mich um andere zu kümmern und wahrnehmen zu können:

 

Jasmine

Wie kann ich andere begleiten und wo kann ich andere begleiten? Ist ganz, ganz wichtig für uns. Also um zum Beispiel ein ganz praktisches Beispiel zu machen. Als Scrum Master werden mir natürlich auch Konflikte über den Weg laufen. Entweder Konflikte, die ich selber mit jemandem oder der Organisation habe, oder Konflikte, die in meinem Team entstehen, oder Konflikte, die mein Team mit jemandem oder der Organisation hat. Und wenn ich in diesen Konflikten agieren möchte, wenn ich an und in diesem Konflikt arbeiten möchte, dann ist es sehr  sehr hilfreich, mir mal Gedanken darüber gemacht zu haben und so gespürt zu haben.

 

Jasmine

Wie bin ich denn im Konflikt? Was habe ich denn über Konflikte gelernt? Wie agiere ich im Konflikt? Also Kai und ich sind sehr, sehr unterschiedlich in Konflikten. Ich geh die Aggression, ich werde laut, ich kann auch mal Türen knallen und nachdem ich das gemacht habe, renne ich weg und dann heule ich für mich alleine in der Ecke und habe dann so das Gefühl – und jetzt kommt mich holen, holt mich bitte hier aus der Hölle raus, ich brauch doch jemanden.

 

Jasmine

Wenns aber ganz schlimm ist komme ich da gar nicht raus für mich. Aber das für mich erlebt und erfahrbar gemacht zu haben, hilft mir in den Konflikten auch professionell agieren zu können. Eben nicht laut zu werden, Türen zu knallen, dann wegzurennen hätte ich beruflich jetzt auch nie gemacht. Man macht das dann nicht so, wie man es vielleicht zu Hause macht, aber subtiler Weise macht man es meistens eben doch.

 

Kai

Und das ist so ein Beispiel für Selbstkenntnis – wenn man da sich selbst erfahren hat, dann kann man in den entsprechenden Situationen halt auch anders umgehen oder diese kleine Austastlücke nutzen zwischen Reiz und Reaktion, wo ich dann entsprechend ja, zum Beispiel auch und da haben wir auch schon öfter drüber gesprochen. Ich meditiere ja regelmäßig mit mit dieser Achtsamkeit auch da hinkommen kann, dass ich merke: Oh, da ist was. Oh, das frisst mich irgendwie an und ich möchte aber anders reagieren, als ich das standardmäßig tun würde, um mich zu detriggern.

 

Kai

Und ja, da ist eine ganze Menge an Entwicklungsweg. Und was ich essenziell fand, und das haben wir eben auch schon erwähnt, ist eben Gemeinschaft. Immer wieder in Gemeinschaft gehen mit Menschen. Denn schlussendlich lernen wir diese Dinge doch am besten miteinander und können das über diesen Raum von Beziehung, Beziehungsqualität und Geist und Intention einfach mitnehmen. Ich weiß, das klingt jetzt ein bisschen Eso – irgendwie ist es aber schon so, dass wir Menschen ja Resonanzwesen sind.

 

Kai

Ich habe ein spannendes Buch dazu gelesen, Mindsight von Daniel Siegel, wo es eben auch darum geht und was ich da mitgenommen habe. Schlussendlich werden wir geboren mit irgendwie einem unfertigen Präfrontalkortex und wir docken uns schon kurz nach der Geburt, vielleicht sogar schon davor entsprechend an und fangen an zu reifen mit anderen und wir sind total darauf ausgelegt. Das kann man jetzt mögen oder nicht, dass das so ist, dass wir so abhängig sind von anderen Menschen.

 

Kai

Es ist aber irgendwie so und da hilft es halt mit anderen in Kontakt zu sein, um solche Entwicklung zu machen und weiter für sich zu reifen.

 

Jasmine

Und diese Community kannst du dir natürlich aussuchen. Da kommt es glaube ich wirklich schwer drauf an wie lernst du? Ich bin ein Gemeinschafts-Lerner. Ich weiß nicht, ob ich jemals hier schon erzählt habe. Ich bin ja selbst an der Uni in keine einzige Vorlesung reingegangen, wo ich nicht zwingend hätte drin sein müssen. Ich war aber in meiner Uni. Ich saß nur im Flur und habe da ein Buch gelesen, Mindmaps gemacht und dann kamen Leute an mir vorbei und ich habe Gespräche mit denen gesucht und so lerne ich.

 

Jasmine

Das heißt, ich bin ein Gemeinschaftslerner und ich bin vor allem ein Erfahrungs-Lerner. Ich muss Erfahrungen machen. Das heißt, weil der Weg, den ich für mich ausgesucht habe. Damals gab es den Path To CSP. Jetzt noch nicht so explizit, aber es gab die Scrum Master Weiterbildung. Ich habe für mich die Scrum Master Weiterbildung ausgesucht, um da in Gemeinschaft und in ganz viel Interaktion mit ganz vielen Übungen und ganz viel Diskussion zu lernen. Das war mein Weg zu lernen und nebenbei habe ich halt noch ganz viel in der Community gemacht.

 

Jasmine

Aber ich brauchte auch dieses formale Lernen. Das ist der zweite Schritt, den ich von mir beim Lernen weiß, sonst schiebe ich das auf die lange Bank. Ich bin kein Mensch, der Bücher für sich selber liest. Ich kann einem Lern-Zirkel oder einem Buch Zirkel beitreten und da drin ein Buch lesen und dann drüber reden. Super, dann lese ich auch Bücher. Noch besser ist es, Kai liest das Buch, erzählt mir darüber, dann weiß ich auch, was da drin steht und ich weiß es dann besser, wenn ich es selber gelesen habe.

 

Jasmine

Aber mich da zu erfahren und zu wissen wie lerne ich am besten, hat mir geholfen in meine Wirkung als Scrum Master rein zu gehen. Und nach der Scrum Master Weiterbildung ging es natürlich weiter, wo ich noch in den Nischen geguckt habe. Wo will ich mich noch weiterentwickeln? Bis hin jetzt, wo ich auf dem Weg zum Scrum Trainer bin, wo ich ja wieder eine Community von Mentoren gesucht habe, die mir helfen mich weiterzuentwickeln. Es kann natürlich auch sein, dass du ein ganz anderer Lern-Typ bist und dieses strukturierte Lernen nicht brauchst und auch das Zertifikat nicht brauchst.

 

Jasmine

Und auch dann kannst du natürlich Scrum Master werden und die Wirkung entfachen als Scrum Master. Ich glaube, die Basis, die wir dir hier gegeben haben, sind diese vier Facetten und die drei Services, wo du dich einfach mal reflektieren kannst. Wo bin ich denn da unterwegs? Das zweite was du dann reflektieren kannst ist welcher Lern Typ bin ich und was brauche ich denn da? Und wie ich schon vorhin gesagt habe, wenn du dir dann ein Angebot aus suchst, suchte das aus wo du merkst ich docke an – also such dir diese Community aus, die wo du dich zu Hause fühlst, wo du dich wohlfühlst, wo du lernen kannst, weil wir lernen, da wo wir uns wohlfühlen.

 

Jasmine

Ja manchmal irgendwie an der Grenze unserer Komfortzone. Aber wir müssen uns in der Situation und im Umfeld wo wir sind in einer Lern Zone befinden. Das heißt, wir müssen uns auch ein bisschen wohlfühlen, damit wir lernen können. Und was ich immer mache ist, ich suche mir die Personen, die schon da sind, wo ich hin möchte als Lehrmeister.

 

Kai

Das ist ein bisschen lustig, weil ich bin ein komplett anderer Lern Typ. Ich grabe mich normalerweise mit einem Sachbuch ein. Also wir waren vorgestern gerade im Urlaub in einer Buchhandlung und ich habe da geguckt und bin dann irgendwie so an den ganzen Roman vorbeigelaufen und so weiter. Und ich finde einfach nichts, was mich interessiert. Ja, ich könnte jetzt schon ein und klar habe ich auch mal eine nette Geschichte gelesen oder ein nettes Buch. Ich habe auch mal ein 600 Seiten Roman gelesen.

 

Kai

Es war alles nett, aber ich kaufe irgendwie immer Sachbücher. Ich kuck dann, was interessiert mich das Thema, wo möchte ich was? Und dann lese ich da irgendwie rein und dann, wenn ich merke, das resoniert irgendwie mit mir, dann kommt bei mir dann der Wunsch. Da würde ich aber gern mal ins Seminar gehen und insofern steht das dann auch, ich bin auch ein totaler Seminarlerner. Ich kann eigentlich über das Buch das gar nicht richtig verinnerlichen. Ich brauche dann schon auch irgendwie die Erfahrung dazu, aber das Buch inspiriert mich schon und hilft mir halt einfach rauszufinden – Passt das?

 

Kai

Klickt das oder klickt das irgendwie nicht und insofern  lernen wir ja ganz anders, aber sind halt irgendwie im Austausch. Meistens lese ich dann halt irgendwie wieder ein Kapitel Buch und gehe dann mit Jasmine spazieren und unterhalte mich darüber, was ich tolles gerade gelernt habe und dann hat Jasmine ja auch mit gelernt. Also das ist auch eine ganz witzige Dynamik. Aber da finde ich klar zu haben – Was für ein Lern-Typ bist du eigentlich? Wie machst du das gerne und was ist dafür hilfreich? Das ist sicherlich wertvoll.

 

Jasmine

Und weil wir beide Seminar-Lerner sind und diese Wachstums-Beziehungen in geschlossenen sicheren Seminarräumen genießen, sind wir auch gerade dabei oder Richtung Ende, die intensivste Agile Coach Ausbildung zu konzipieren, die wir gerne genossen hätten vor 6, 7 Jahren. Wir starten dieses Jahr mit einer ganz kleinen Kohorte, werden nächstes Jahr wahrscheinlich mit zwei Kohorten à zwölf Leuten unterwegs sein, das heißt klein, aber fein, so dass wir ganz, ganz viel begleiten können. Ich freue mich total auf das Lernerlebnis.

 

Jasmine

Bin schon ein bisschen nervös. Falls dich das interessiert, darfst du dich gerne bei uns melden. Es gibt noch keine Ausschreibung, keine Flyer, kein gar nichts. Aber wir haben ganz, ganz gerne ein Gespräch, eins Telefonat mit dir und der Rest wird auch noch folgen. Und wir hoffen, wir konnten dich mit dieser Podcastfolge inspirieren, ins Lernen zu gehen. So wie das für dich passt. Mit den vier Facetten des Scrum Masters und den drei Services. Und wir freuen uns total, wenn du nächstes Mal wieder dabei bist.

 

Kai

Wir wünschen dir auf jeden Fall jetzt schon mal viel Erfolg dabei, Scrum Master zu werden, wenn das eine Rolle ist, die dich interessiert. Falls du da selber noch unklar darüber bist, schau dir Scrum mal ein paar Tage an in einem Seminar danach. Danach weißt du, ist das was für mich oder nicht? Das ist so der erste kritische Schritt. Ich glaube, das hast du mitgekriegt in diesem Podcast. Insofern: Ganz gute Reise, gute Inspiration und bis bald.

 

Die Kunst gelungener Retrospektiven

Agil arbeitende Teams reflektieren häufig, wie sie arbeiten. Sie räumen Konflikte auf und finden regelmäßig zu einem besseren Miteinander, um Produkte zu schaffen, die einen Unterschied machen. 


In dieser Podcastfolge teilen wir unsere Haltung zu Retrospektiven, die Gründe weswegen sie Sinn machen und den grundlegenden Aufbau. 


Weiterführende Hinweise zum Vertiefen machen diese Folge hörenswert für Anfänger sowie erfahrene Scrum Master und Agile Coaches.

Jasmine

 

Ganz herzlich willkommen zum Agile Growth Podcast! Ich freue mich, dass du wieder mit zuhörst, heute geht es um ein absolutes Herzensthema von mir und Kai, nämlich Retrospektiven. Wir gehen so richtig richtig in die Tiefe. Wozu machen wir Retrospektiven überhaupt? Was sind die fünf Phasen der Retrospektive mit konkreten Tipps, Tools, Tricks und aber auch Geschichten aus unserem Leben zu den fünf Phasen. Und was für Tools und Handwerkszeug benutzen wir gerne für gelungene Retrospektiven? Viel Spaß damit!

 

 

 

Sprecher

 

Herzlich Willkommen zum Agile Growth Podcast, dem Podcast für alle Agile Interessierten mit hilfreichen Ideen und erprobten Werkzeugen, die dich weiterbringen. Von und mit den Two Agilists.

 

 

 

 

 

Herzlich willkommen zum Agile Growth Podcast. Hier sind Jasmine und Kai und wir helfen Menschen dabei, die versprechen Agiler Vorgehensweisen in der Praxis einzulösen ohne IT Wissen vorauszusetzen. Und heute ist mal wieder so eine Herzensfolge. Da geht es um ein Thema, das unglaublich wichtig ist, was uns viel Spaß macht und was uns auch schon sehr sehr lange begleitet und mit dem sich jeder der irgendwas im Agilen Feld bewegt auskennen sollte – nämlich der Retrospektive.

 

 

 

Jasmine

 

Wenn du schon ein Scrum Training gemacht hast, dann wird dir die Retrospektive begegnet sein, dass ist der Event in Scrum, wo wir uns begegnen und uns mal nicht um das Produkt per se kümmern, das wir entwickeln, sondern um uns selber als Team.

 

 

 

Jasmine

 

Also wo wir Säge schleifen, wo wir gucken, was können wir verbessern an unserem Prozess? Was können wir verbessern für uns als Team? Was können wir verbessern vielleicht in unserer Definition of Done,  an unseren Team Agreements etc. Und für mich ist es etwas, was wir viel, viel häufiger auch in nicht Scrum Kontexten tun sollten. Wir werden in Trainings ganz oft gefragt – du Jasmine also dieses Scrum, ja, macht alles Sinn. Aber wir machen keine Produktentwicklung.

 

 

 

Jasmine

 

Was soll ich denn da rausnehmen, wo ich sage: Die drei Säulen des Empirismus. Transparenz schaffen, inspizieren und adaptieren. Das können wir immer mitnehmen, überall hin in unser Leben. Und die Retrospektive als Werkzeug macht einfach in den unterschiedlichsten Kontexten total Sinn.

 

 

 

Kai

 

Also das ist so was wie der Kaizen Motor. Vielleicht hast du ja schon mal gehört, dass Agilität auch was mit der Lean Production zu tun hat, also schlanker Produktion damals vom Toyota Produktionssystem herkommt, also dem Autobau. Und dieser Kaizen Gedanke heißt halt eine Verbesserung in kleinen Schritten. Und so ist das so ein bisschen wie so Psychohygiene für Teams, könnte man sagen. Also etwas, wo man regelmäßig einfach hingeht, hinschaut und guckt Wie läuft’s eigentlich? Was müssten wir mal aufräumen und was können wir auch besser machen?

 

 

 

Kai

 

Und das hilft einfach Teams dabei, sich darauf zu fokussieren, Wert zu schaffen im Rahmen von Produktentwicklung und eben auch mehr Menschlichkeit am Arbeitsplatz zu haben. Denn wenn man es da schafft, die Konflikte aufzuräumen, die es so gibt, regelmäßig also Stichwort Psychohygiene, dann geht es eben auch den Menschen einfach besser vor Ort.

 

 

 

Jasmine

 

Und der Gedanke dahinter ist ja das stetige Streben nach Perfektion im Wissen, dass es Perfektion nicht gibt. Wenn wir in eine Retrospektive reingehen uns das noch mal zu vergegenwärtigen: Hey, wir gehen hier rein, wir gehen hier vielleicht sogar hart ins Gericht miteinander und mit uns selbst, also Kai und ich machen ja auch Paar-Retrospektiven. Kai’s Spruch am Ende von der Retrospektive ist immer ja, das war wieder schmerzhaft, aber gut. Also wir gehen teilweise auch echt hart ins Gericht, mit uns selber und mit uns als Team.

 

 

 

Jasmine

 

Wir streben nach Perfektion, wissen aber, dass es sowas wie Perfektion nie geben wird. Das heißt, das einzige, was wir tun können, ist Schrittchen für Schrittchen uns zu verbessern und Schrittchen für Schrittchen mehr in die Verantwortung zu kommen. Und das ist etwas, was ich gelernt habe, was vielen Teams, aber auch Individuen so so gut tut. Weil wir, wenn wir in einem Konzern Umfeld unterwegs sind oder auch bei einem Mittelständler, wenn wir in diesen Organisationskulturen unterwegs sind, dann erlernen wir ganz oft Hilflosigkeit.

 

 

 

Jasmine

 

Ich weiß nicht, ob ihr diese Studie kennt von den Affen, die in der Mitte des Affen Geheges hat’s eine Säule und auf dieser Säule drauf ist eine Banane. Und die Affen versuchen natürlich da hoch zu gehen, diese Banane zu nehmen und dann werden sie immer mit Wasser abgespritzt, wenn die da hoch gehen. Irgendwann mal lassen die das bleiben und die gehen dann nicht mehr hoch, weil sie wissen ich komme da eh nicht hoch. Wird mit Wasser angespritzt, ist doof.

 

 

 

Jasmine

 

Und dann kommen neue Affen ins Gehege. Irgendwann mal sind alle Affen ausgetauscht, das heißt alle Affen, die mit Wasser eingespritzt wurden, die sind gar nicht mehr da. Aber auch die neuen Affen gehen diese Säule nicht mehr hoch und holen die Banane nicht, weil sie haben gelernt über ihre anderen Kollegen, die vorher drin waren, dass das eh nichts bringt. Und so kann man – dieses Experiment hat man auch mit Hunden gemacht, also Hunde, die angeleint sind, ihr Leben lang.

 

 

 

Jasmine

 

Wenn man die von der Leine lässt, dann verlassen sie den Radius der Leine trotzdem nicht, weil sie gelernt haben, das bringt gar nichts. Und diese erlernte Hilflosigkeit, die begegnet mir in Organisationen sehr, sehr oft. Das heißt, die Grenzen, die wir uns selber stecken, die sind oft sehr viel enger, als sie wirklich sind. Und eine Retrospektive kann uns da einfach helfen, diese Grenzen nach und nach auszuweiten, mehr in unsere Verantwortung zu kommen, mehr in die Fülle zu kommen, mehr wirklich in’s schöpfen zu kommen.

 

 

 

Jasmine

 

Alles, was wir zusammen wuppen können. Und dann macht Arbeit einfach auch dreimal mehr Spaß.

 

 

 

Kai

 

Also da kam einer, der wusste das nicht und der hat es dann gemacht. Ist ja auch so ein netter Satz dazu und wir helfen uns eigentlich dabei, selbst in den Retrospektiven, dass wir zu denen werden, die das dann nicht mehr wussten, also vielleicht diese Limitierungen vergessen oder uns den Mut schnappen, darüber hinweg zu gehen. Und insofern kann man auch sagen Retrospektiven sind Räume von radikaler Ehrlichkeit. Wobei die Kunst darin besteht, diese radikale Ehrlichkeit nicht zu Lasten von einzelnen Personen in diesem Termin werden zu lassen.

 

 

 

Kai

 

Denn das ist ja auch oft eine Dynamik, die wir haben, dass wir dann Schuld einfach verschieben und sagen: Ja, das hast du und du falsch gemacht. Und deswegen haben Retrospektiven einen ganz, ganz bestimmten Geist, in dem die passieren, um eben radikal ehrlich zu sein, miteinander, aber nicht verletzend für den Einzelnen. Und da spielt natürlich Moderation eine ganz, ganz große Rolle. Und wenn man jetzt ein bisschen konkreter rein guckt, wie so eine Retrospektive funktioniert, dann kann man sich erst mal festhalten an so einer fünf-schrittigen Abfolge.

 

 

 

Kai

 

Die hat damals Diana Larsen mitgeprägt. In dem ersten Agilem Buch über Retrospektiven.

 

 

 

Kai

 

Und da ist so ein fünf-schrittiges Framework drin beschrieben. Und das ist ganz hilfreich, wenn man wenig Moderationserfahrung hat. Denn das startet erst mal damit, dass man ein „Set The Stage“ macht. Die Bühne bereitet für die Menschen, die dann da sind. Und wenn ich von Menschen, die da sind, spreche, dann geht es in diesem Fall halt um das eigene Team. Da sind auch Gäste im Regelfall nicht dabei, außer das Team will das unbedingt haben, denn da braucht man eben einen sicheren Raum.

 

 

 

Jasmine

 

Und die Bühne zu bereiten heißt halt zum Beispiel auch, diesen sicheren Raum zu schaffen. Mit der „Las Vegas Regel“ sagt man manchmal dazu. Also dieses „What happens in Vegas stays in Vegas“. Also das, was wir hier besprechen, das bleibt im Raum. Einzige Ausnahme sind dann Maßnahmen, die nachher rauskommen. Aber so das, wie wir dahin gekommen sind, das gehört erst mal nur uns. Und diese Haltung, die eben bei radikaler Ehrlichkeit verhindert, dass wir das große Fingerpointing beginnen, die nennt sich zusätzlich noch die primäre Direktive.

 

 

 

Kai

 

Auch das ist immer mal wieder was, was ich gern benutze, um eine Bühne zu bereiten.

 

 

 

Jasmine

 

Und diese primäre Direktive oder auch Goldene Regel manchmal genannt, bedeutet so viel wie: Egal, was wir hier entdecken werden, wir gehen davon aus, dass jedes einzelne Individuum das Beste getan hat, was es, also sie oder er, zu dem Zeitpunkt tun konnte, in den Fähigkeiten, die wir hatten, dem Wissen, das wir hatten, oder in der Umgebung, die wir waren. Das heißt, wir haben Ansatzpunkte, wo wir inspizieren und adaptieren können, nämlich beim Wissen, bei den Fähigkeiten oder bei der Umgebung.

 

 

 

Jasmine

 

Aber was wir nicht tun werden, ist zu sagen: Wenn der Paul nicht so doof wäre, dann wäre das ja alles hier ganz einfach. Also das ist mein Wortlaut von der primären Direktive. Die hat mir immer sehr, sehr geholfen. Dann auch in der Moderation der Retrospektive, wenn wir in dieses Fingerpointing abtauchen. Und wenn, wenn sich jemand von euch mit dem Responsibility Process befasst hat, dann wissen wir, dass Fingerpointing ist ganz natürlich. Ich weiß nicht, ob ihr Kinder beobachtet hat.

 

 

 

Jasmine

 

Wenn die so einer Phase sind von zwei, drei Jahren, dann sind die in einer Phase, wo die das ganz natürlich machen. Irgendetwas passiert. Unsere Tochter war da extrem gut drin, irgendwas ist passiert. Und als allererstes hat sie gesagt: Ich bin nicht schuld, der und der ist schuld. Und für mich hat das erst mal gebraucht zu verstehen, das ist ein natürlicher Mechanismus von uns Menschen, dass wir die Schuld auf ein anderes Individuum verschieben, bevor wir in die Verantwortung kommen können.

 

 

 

Jasmine

 

Das heißt, wenn das passiert in einer Retrospektive, da können wir zu der Goldenen Regel zurückgehen und sagen: Halt mal, wir haben uns darauf geeinigt, dass wir genau das nicht tun wollen, sondern dass wir tiefer gehen wollen, dass wir gucken wollen, egal was ist und was irgendwie ein Individuum falsch gemacht hat oder nicht – an was lag es denn? Was können wir in unserem Umfeld verändern, damit das nicht wieder passiert oder damit es uns leichter fällt?

 

 

 

Jasmine

 

Das ist ein Ansatz, der kommt auch aus der Sozialpsychologie, also wir haben, wenn wir die Psychologie angucken, die Individualpsychologie und die Sozialpsychologie. Die Individualpsychologie guckt eher: Was habe ich für eine Prädisposition als Mensch und was habe ich für Erfahrungen gemacht? Und warum bin ich so, wie ich bin? Und die Sozialpsychologie sagt: Das ist eigentlich ganz wurscht, was für eine Prädisposition wir haben und so weiter, sondern in der gleichen Situation verhalten sich ein großer Prozentsatz der Menschen genau gleich.

 

 

 

Jasmine

 

Und da man viele Experimente gemacht und gezeigt, dass dem wirklich so ist, dass egal ob ich sehr altruistisch eingestellt bin oder nicht, wenn irgendjemand Hilfe braucht und ich gestresst bin, werde ich nicht helfen. Eine Regel, die wir noch hinzufügen und ich mag da das Wort Regel nicht unbedingt, aber etwas, was ich im Set The Stage immer wieder erwähne, was ich sehr, sehr wichtig finde, ist die Freiwilligkeit. Das heißt, ich werde so was sagen in einer Retrospektive wie Wenn du gerade nicht hier sein möchtest, wenn du gerade für dich feststellst, dass du nicht in einem Zustand bist, an dieser Retrospektive teilzunehmen, dann ist es für mich völlig in Ordnung, wenn du dich hier ausklinkst.

 

 

 

Jasmine

 

Und vielleicht ist das auch ein bisschen umstritten. Aber ich werde dann immer gefragt – Was passiert denn, wenn jetzt der Dominik nie kommt? Zur Retrospektive. Ja, dann bin ich ja Scrum Master von diesem Team und dann werde ich mit dem Dominik mal reden und mal nicht reden im Sinne von Dominik Du kommst nie, sondern ich habe festgestellt, dass du nicht an den Retrospektiven teilnimmst oder teilnehmen möchtest. Ich bin neugierig. Können wir da mal ein Gespräch darüber führen?

 

 

 

Jasmine

 

Das kann unzählige Gründe haben, die wir beheben können. Es kann auch sein, dass der Dominik nicht an Retrospektiven glaubt, oder es kann sein, dass er sich nicht wohlfühlt im Team. Oder es kann sein, dass wir das Format ändern müssen, damit er teilnehmen kann. Da hatte ich schon unzählige Beispiele dafür. Oder er hat sehr, sehr schlechte Erfahrungen mit Retrospektiven gemacht. Aber diese Freiwilligkeit führt meistens dazu, dass die Menschen eine bewusste Entscheidung treffen, hier zu sein.

 

 

 

Jasmine

 

Und ich sage das auch nicht so im Sinne von: Wenn du gerade nicht in einem Zustand bist, hier zu sein, dann ist es okay, wenn du gehst. So, jetzt machen wir weiter, sondern ich mache da ganz bewusst eine Pause. Und führe diese Freiwilligkeit ein. Damit jeder einzelne eine bewusste Entscheidung trifft. Ja, ich möchte hier sein. Ja, ich möchte beitragen und ich werde das Beste tun, was ich hier gerade tun kann, damit wir als Team vorankommen.

 

 

 

Kai

 

Und ein Beispiel, was ich erlebt habe mit einer Retrospektive. Da habe ich eine ähnliche Frage gestellt wie Jasmine zu dieser Freiwilligkeit. Da ging es nämlich auch um den Check in in die Retrospektive und da gibt es ein Format, das nennt sich Explorer Shopper Vacationer Prisoner. Und dazu habe ich auf ein Flipchart vier Quadranten drauf gemalt und diese Begriffe drauf geschrieben. Und ein Explorer, der ist in der Retrospektive, um möglichst viele Dinge herauszufinden, ist also richtig neugierig. Der findet das auch geil, dass er da ist und freut sich über den Termin und ist super neugierig, was er heute rausfinden kann.

 

 

 

Kai

 

Und ein Shopper läuft so wie so jemand mit einem Einkaufswagen durch den Supermarkt und legt ab und zu mal eine Idee rein, Erkenntnis rein. Und das passt dann schon auch. Dann gibt es einen Vacationer, der ist einfach nur froh, dass er gerade nicht in den anderen Terminen seines Arbeitsalltags ist, sondern hier mal ein bisschen ausspannen kann in der Retrospektive. Und dann gibt es die Prisoner. Die wollen gar nicht hier sein. Und dann habe ich bei einem Team von zehn Leuten einfach gefragt: Macht mal bitte anonym auf eine Karte, schreibt es mal drauf.

 

 

 

Kai

 

Und dann habe ich die Karten eingesammelt und habe dann Striche überall gemacht, wie es aussah. Und da hatten wir zwei Explorer, einen Shopper, einen Vacationer und der Rest waren Prisoner. Und dann gucke ich auf dieses Flipchart, und denke mir so „Oh shit!“ Und hatte einfach mal die Gruppe gefragt, hab das so nicht kommentiert, sondern so. Was denkt ihr denn, wenn ihr drauf guckt? Ja, wir sollten am besten jetzt den Raum verlassen. Und dann habe ich mal nachgefragt Ja, okay.

 

 

 

Kai

 

Was ist denn los? Und dann ging’s zur Sache, dann kriegte ich so: „Das stimmt nicht, das ist doof, das nervt uns hier irgendwie das ganze Scrum und dieses Sprints und diese Längen und wir haben gar nicht gute Themenbereiche“ und das und das und das. Und dann kamen so 17 Punkte, die alle irgendwie Müll waren und dann konnte man richtig gut einsteigen damit in die Retrospektive. Und das ist so ein Beispiel dafür, wie man das auch sehr explizit machen kann.

 

 

 

Kai

 

Wer warum da ist und was vielleicht dann klemmt, was ein bisschen anders noch funktioniert. Mehr mit der Gruppendynamik, weniger jetzt mit dem Einzelgespräch, wie Jasmine das beschrieben hat. Aber auch das ist eine Möglichkeit zum Einstieg. Und es gibt viele, viele weitere Möglichkeiten für diesen Check in. Schlussendlich geht es darum, dass jeder mal beteiligt worden ist und dass ein gewisser Rahmen aufgebaut worden ist. Vielleicht so ein bisschen wie die Working Agreements, zu denen wir auch schon mal eine Folge gemacht haben.

 

 

 

Jasmine

 

Also zusammengefasst: Wir haben die drei Regeln bzw. die zwei expliziten. Die dritte darfst du mit dazunehmen, wenn sie für dich passt. Die Las Vegas Regel, die goldene Regel und wir nehmen ganz oft noch die Regel der Freiwilligkeit mit dazu. Und dann machen wir noch eine entsprechende Check in Übung, um den Menschen einfach zu helfen anzukommen. Kai hat das mit dem Shopper Explorer  Vacationer Prisoner genommen. Man kann noch was nehmen, was jetzt weniger auf diese Freiwilligkeit abzielt.

 

 

 

Jasmine

 

Wenn ich gar keine Zeit habe, würde ich so was nehmen wie ein One Word Opener. In einem Wort Wie bist du gerade hier? Da habe ich nämlich auch die Möglichkeit, dass sich sogenannte Red Flags zum Beispiel erkennen kann. Wenn jetzt jemand sagt: Ich bin neugierig oder ich bin entspannt oder einfach nur freudig, dann sind es keine Red Flags, müde, angespannt etc. Also all diese Wortech wo ich sage: Oh, das ist jetzt vielleicht auch nicht gerade so dienlich für eine Retrospektive.

 

 

 

Jasmine

 

Da würde ich nachfragen: Können wir was für dich tun, damit es dir besser geht, brauchst du noch eine 5 Minuten Pause um dir einen Espresso zu holen, oder ich hatte auch schon den Fall, dass jemand gesagt hat: Ich habe zwei E-Mails, die müssen unbedingt fertig werden, die belasten mich. Da haben wir gesagt: Kein Thema, wir machen eine Viertelstunde Pause. Jeder macht die E-Mails, die er gerade machen muss. Nach einer Viertelstunde fangen wir an. Es war eine super Retrospektive danach.

 

 

 

Jasmine

 

Also irgendein Check in und das Check in sollte für mich jetzt noch nicht unbedingt in die Reflektion des Sprints einzahlen, weil sonst bin ich direkt im Thema drin, sondern das Check in für mich ist ein Weg anzukommen als Mensch. Und das ist etwas, was ich auch beobachte, was wir in ganz vielen anderen Terminen missachten, dass Menschen Zeit brauchen, um anzukommen. Wir sind jetzt gerade in einem Hotel in Südtirol und gucken raus auf eine unglaublich schöne herbstliche Umgebung und ich reise relativ schnell.

 

 

 

Jasmine

 

Kai reist deutlich langsamer.

 

 

 

Kai

 

Ich bin da, glaube ich, mehr so ein bisschen. Wie war das bei den , haben das die Indianer nicht immer gesagt, dass die Züge immer so komisch fanden, weil deren Seele nicht schnell genug hinterher reisen kann? Also ich brauch meistens so ein Sleep over, dann bin ich irgendwie auch da an dem Ort, an dem ich wirklich bin. Außer wenn ich’s schneller brauche, dann muss ich mich mal hinsetzen und meditieren. Dann komme ich vielleicht auch ein bisschen früher an.

 

 

 

Kai

 

Aber grundsätzlich dieses reinstolpern in Termine, das ist natürlich schon eigentlich so, ich würde fast sagen, es ist eine Zumutung, denn wir Menschen hängen doch immer noch an den Erlebnissen, die wir kurz vorher hatten. Und wenn ich so frage und das mache ich auch ganz oft, zum Beispiel in den Trainings so wie sehr bist du gerade hier auf einer Skala von 1 bis 10 und 10 heißt irgendwie wach, klar, präsent, aufgeräumt. Und eins heißt meine körperliche Hülle ist anwesend.

 

 

 

Kai

 

Dann gibt es ganz, ganz viele Leute, die irgendwie morgens beim Check in um 9 Uhr irgendwie auf einer 6 oder 7 sind, weil sie halt vorher schon gearbeitet haben, weil sie die Kinder gerade irgendwie noch im Kindergarten. Dann gab es das kleine Drama und weil sie noch nicht wirklich ein Kaffee gehabt und sich um sich selbst gekümmert haben, was auch immer das ist. Aber die Annahme, dass Menschen, nur weil sie zum Beispiel jetzt am virtuellen Bildschirm erscheinen, auch da sind, ist erst mal falsch.

 

 

 

Kai

 

Und dafür zu sorgen, dass wir in diesem Moment mit diesen Menschen sind, das ist die Qualität die ein guter Check in liefern sollte. Und dafür braucht es keine Rocket Science. Das ist eigentlich ganz einfach. Sich eine gute Frage nehmen und die Leute damit in den Moment bringen, in die Reflektion, in den Augenblick, also in das Jetzt. Dann ist schon viel gewonnen.

 

 

 

Jasmine

 

Genau. Als letzter Punkt, als Anregung für dich. Was ich auch gerne mache, ist, dass jeder ein Stück Papier kriegt. Und ich sage und schreibe jetzt mal alles auf, was noch bei dir ist, was dich gerade beschäftigt. Schreib mal einfach alles auf und dann falte es zusammen. Und dann, wenn wir vor Ort sind, packen wir es in eine Kiste, machen das zur Tür und dann kann man es am Schluss entscheiden, ob man das denn jetzt nochmal mal mitnehmen möchte oder ob man den Zettel auch einfach da lässt.

 

 

 

Jasmine

 

Das kann auch eine Check in Übung sein. Da würde ich dann immer noch ein verbales Check in hinterherschieben, weil da ja jeder nur geschrieben hat. Aber das hilft. Wenn wir ein Team haben, das gerade sehr abwesend ist, dann kann so ein schöner Link, so ein kurzes Ich schreib mir jetzt einfach mal alles von der  von der Seele oder vom Kopf nieder. Kann einfach helfen, dass man in den Moment kommt. Wenn wir das nämlich nicht tun und wenn wir das auch in anderen Termin nicht tun

 

 

 

Jasmine

 

Dann verlieren wir unglaublich viel an Produktivität. Also wenn Leute 10 15 Minuten nur mit 50 Prozent ihrer Präsenz abhängen in dem Termin, dann können wir uns die ersten 10 15 Minuten auch sparen. Deswegen investiere ich lieber 4 Minuten am Anfang des Termins, als dass wir 15 Minuten lang labern.

 

 

 

Kai

 

Und dazu gehört dann und dann sind wir beim zweiten Schritt von der Retrospektive. Der erste war Check in fünf Schritte gibt es insgesamt. Jetzt sind wir beim zweiten. Da geht es dann natürlich nicht darum, dass man irgendwie als Moderator einen großen Monolog anfängt, sondern jetzt haben wir die Menschen hier gerade aktiv hier in dem Raum. Und dann geht es darum, gemeinschaftlich mit ihnen Fakten zusammenzutragen. Und diese Fakten zusammentragen kann sehr unterschiedlich aussehen, bezieht sich aber ganz oft natürlich auf den gerade erlebten Sprint, auf die Iteration, die wir hinter uns haben und da zu schauen.

 

 

 

Kai

 

So ein ganz einfaches Format zum Beispiel „Mad Sad Glad“, also was hat mich irgendwie wütend gemacht? Was hat mich traurig gemacht und worüber bin ich eigentlich richtig froh und dankbar? Und das einfach mal zu sammeln in einem Brainstorming, entweder im digitalen Raum oder auch einfach klassisch mit Notizzettel. Und darüber hat man schon ganz viele Daten darüber da. Und jetzt könnte man denken. Dieses Format ist irgendwie trivial. Das ist vielleicht auch schon alt und abgelutscht. Meine Wahrnehmung ist, dass es für die Leute, die die Inhalte erlebt haben, ist das gar nicht so, die sind nämlich ganz oft einfach sehr emotional verbunden mit den Dingen, die sie erlebt haben während des Sprints.

 

 

 

Kai

 

Und natürlich gehen Sachen gut und andere Sachen gehen nicht gut. Und da kann man auch zehn, zwölf Retrospektiven dieses einfache Format nehmen. Das hat immer noch Kraft, wenn man denn den Raum vorher aufgemacht hat, dass man über das Wesentliche spricht.

 

 

 

Jasmine

 

Und was ich selten tue, ist wirklich so ein Plus minus Retrospektive, weil uns das sehr in ein eingefahrenes geschachteltes Denken lenkt und zum Beispiel „Mad Sad Glad“, das hat schon drei Kategorien. Das regt schon ein bisschen mehr die Kreativität an. Es gibt auch „Die vier L’s“, Loved, Learnt, Lacked und Longed For ist. Das heißt, es ist dann nicht einfach nur ein Minus und ein Meckern, sondern ich muss mir auch noch wirklich überlegen, was ist denn da dahinter an dem, was nicht so stimmt.

 

 

 

Jasmine

 

Unsere letzte Folge und eine unserer letzten Folgen ging ja um die Burndown Charts. Was man natürlich auch machen kann, ist die Burndown Charts der letzten paar Sprints mitnehmen und die man analysieren als Daten. Das heißt, ich kann auch Daten Punkte wirklich mitnehmen. Wenn ein Team oft sagt irgendwas stimmt nicht und irgendwas ist blöd hier, aber so richtig kommen wir nicht ran. Dann könnten wir auch mal eine Pain Snake machen, über den letzten Sprint hinweg. Das heißt, ich zeichne dann immer ein schönen Schlangenkopf, wenn wir vor Ort sind.

 

 

 

Jasmine

 

Alle zusammen in einem Raum funktionierts am besten. Und jeder, der irgendwie eine Störung erlebt hat, ein das war jetzt echt blöd während dem Sprint, hängt sich da ein Post-It an diese Schlange ran und wir machen unsere Pain Snake über den Sprint und wir nehmen das als Daten mit. Oder wir machen einen Zeitstrahl und gucken uns das an. Also es gibt viele verschiedene Formen um Daten zu sammeln und ich bin aber voll bei Kai. Oftmals ist die einfachste Form, das zu moderieren, die effizienteste, weil die Menschen auch wissen, worauf sie sich einlassen.

 

 

 

Jasmine

 

Weil wir zwar unsere Kreativität fördern, indem wir rausgehen aus diesem Plus Minus, sondern ein bisschen weiter gehen, aber da auch wirklich in die Tiefe schauen können. Wenn ich nämlich mit meinem Gehirn schon zu einem großen Prozentsatz damit beschäftigt bin, das Format zu verstehen, in dem wir gerade Daten sammeln, dann wird mein Gehirn nicht so sehr in die Tiefe gehen können, diese Daten zu generieren. Und wenn wir dann die Daten gesammelt haben, also irgendwie alle Daten gesammelt haben und ich finde, da ist das Wichtige an dem Punkt ist, dass wir zwar alle Daten sammeln, aber sie nicht zerreden.

 

 

 

Jasmine

 

Das heißt das schlimmste oder die schlimmsten Fehler, die mir passiert sind beim Datensammeln ist: Wir machen „Mad Sad Glad“. Jeder schreibt seine Zettel. Wir sind irgendwie acht Leute. Jeder hat so irgendwas zwischen sieben und 15 Zetteln und dann geht jeder nach vorne und liest jeden einzelnen Zettel vor und sagt noch was dazu. Dann ist eine Stunde rum. Und wir haben keine einzige Maßnahme, wir haben nicht verstanden, wie hängen diese Datenpunkte zusammen. Das heißt, das Sharing muss stattfinden, darf stattfinden.

 

 

 

Jasmine

 

In diesem zweiten Teil. Wir dürfen uns als Moderatoren aber auch überlegen: Wie machen wir das kurz und knackig? Wie kommt jeder zu Wort? Aber ohne dass wir alle Daten in die Breite zerreden.

 

 

 

Kai

 

Und eine ganz beliebte Variante, wie ich das mache, ist mit so einer Mehrpunkt-Abfrage. Dann kriegt ihr einen Punkt oder eine digitale Stimme. Und dann frage ich einfach: Was ist ein Thema, wo du denkst, das würde sich wirklich lohnen für uns als Team, dass wir das jetzt vertiefen, wo es Energie dahinter? Was macht Sinn? Und dann markieren es die Menschen und dann kommt ganz klar eine Reihenfolge drauf. Und manchmal variiere ich auch, weil das natürlich immer diesen Mehrheits Effekt hat.

 

 

 

Kai

 

Und das heißt auch, dass so Seiten Themen immer wieder runter fallen bei der Art, dass es nicht immer meine Art. Aber häufig nutze ich das so und dann habe ich etwas, wo auf jeden Fall viele Leute eine gewisse Leidenschaft verspüren, darüber mal zu sprechen und das zu vertiefen. Und dann können wir von der zweiten Stufe des Datensammelns rüber wechseln in die dritte und die heißt dann „Generate Insights“, also Erkenntnisse gewinnen. Und da sind wir also dabei, dass wir dann ein so ein Thema, das wir herausgegriffen haben, sezieren.

 

 

 

Kai

 

Und das zerlegen wir am besten auf kunstvolle Art und Weise miteinander mit dem kollektiven Gehirn, das wir da im Raum haben, so dass wir möglichst viele Aspekte der Herausforderung anschauen. Wo kam das her? Was hat das mit dem Menschen zu tun? Was hat das mit den Maschinen zu tun? Was hat das mit den Methoden zu tun? So ein Fishbone Diagramm kennt vielleicht der eine oder andere aus dem Lean Thinking ist eine ganz nette Art und Weise, einmal so ein Thema auf verschiedenen Achsen zu durchdringen.

 

 

 

Kai

 

Und auch da gibt es ganz, ganz viele Formate. Und ich persönlich muss zugeben, ich verfalle da ganz oft in Freestyle in dieser Phase, weil ich da meiner Intuition traue. Jetzt nach den fast 15 Jahren Agilität und dann schaue, wie ich das genau angehe. Ich habe zwar meistens in meiner Moderations-Agenda da schon ein Tool liegen, aber ganz oft liegt das da nur und ich mache was anderes, wenn ich ehrlich bin, weil dieses Durchdringen und diese Klarheit und das im Raum mit den Leuten verstehen oft was anderes braucht als das, was ich ursprünglich dachte.

 

 

 

Kai

 

Und insofern, wenn du da gerade Neueinsteiger bist, vielleicht die Einladung dazu, einfach mal verschiedene Werkzeuge durch zu probieren, damit du dein Handlungs Repertoire erweiterst und dich aber einfach einfach mal festlegen, dass auch einfach mal durch testen.

 

 

 

Jasmine

 

Was für mich als Moderatorin in der Phase ganz wichtig ist, ist offen zu bleiben, nicht meine Meinung zu haben, was jetzt die Lösung sein könnte. Ich bin jemand, der ist superschnell im Lösungs Raum, sondern offen zu bleiben und Fragen zu stellen. Warum ist denn das so? Zu was führt denn das? Also diese offenen W-Fragen zu stellen? Das kann helfen. Eine Methode, die viele gerne anwenden, ist die „Five Whys“. Das heißt, wir nehmen das Problem und fragen dann fünf oder sieben oder sogar neun Mal hintereinander.

 

 

 

Jasmine

 

Warum? Oder wozu? Je nachdem, in welche Richtung ich fragen will, warum ist eher rückwärts, wozu ist er vorwärts? Und das kann helfen, was ich auch ganz gerne mache, vor allem mit Teams, die sehr analytisch unterwegs sind, sind Loop Diagramme zu zeichnen. Das heißt, das initiale Thema, auf das wir uns beschäftigen müssen, packen wir in die Mitte und dann gucken wir zu was führt denn das und was führte zu dem Thema?

 

 

 

Jasmine

 

Und dann erkennen wir vielleicht Zusammenhänge als ein ganz banales Beispiel. Ich habe mal Loop Diagramme mit jemandem gemalt, der abnehmen wollte, da das Thema Abnehmen für ihn in der Mitte. Und dann haben wir mal geguckt wie wie sieht denn die Essens Struktur über den Tag aus und so weiter und haben festgestellt. Also eigentlich so richtig viel Essen tut dieser Mensch gar nicht. Aber er snackt sehr viel und auch sehr viel Süßes. Und dann haben wir per Loop-Diagramm geguckt.

 

 

 

Jasmine

 

Wie kommt denn das? Und worauf wir gekommen sind war es war nicht mal das Essen das Thema. Der große Gamechanger war das Trinken, weil dieser Mensch morgens gerne Kaffee getrunken hat und nicht gegessen hat. Das heißt, er ist auch um 5 aufgestanden, hat dann mit Kaffee begonnen und hat eigentlich bis 2 Uhr nachmittags so seine 7 bis 10 Tassen Kaffee getrunken, was natürlich dem Körper so ein Gespür gegeben hat von „hier ist es warm und es ist alles fein“. Und um zwei Uhr nachmittags kam aber dann das große „Boah, jetzt brauche ich aber Kalorien“ und kam das große reinessen. Und da dann per Loop Diagramm mal zu gucken. Ah ja, vielleicht hilft es, wenn wir Wasser trinken und auch die Mahlzeiten besser verteilen hat unglaublich geholfen zu verstehen, was ist denn an meinen Essgewohnheiten falsch? Das war jetzt ein sehr privates Beispiel. Aber man kann diese Diagramme auch auf die ganze Organisation beziehen. Also in dem dritten Schritt ist es wichtig, dass wir wirklich Erkenntnisse gewinnen, dass wir über dieses „Hey, wir haben jetzt alle Daten gesammelt und da kleben wir ein Pflaster drauf“ hinweggehen, sondern tiefer kommen im Sinne von „Wo genau liegt das Problem?

 

 

 

Jasmine

 

Was ist die Ursache? Wie können wir die beheben?“ Meistens bei so was wie ein Kausalschlaufen-Diagramm oder eben ganz viele Fragen den five, seven, nine je nachdem wo man es nachliest Whys – egal was du da nimmst – Fishbone Diagramm haben hatten wir auch noch, egal was du da nehmen möchtest als Moderations-Methode oder für dich einfach im Hintergrund hast, dass du es einsetzen kannst. Findest du raus was könnte die Ursache sein? Oder was ist eine der Ursachen, die wir am einfachsten angehen können?

 

 

 

Jasmine

 

Und damit gehen wir direkt in den vierten Schritt, nämlich entscheiden, was wir tun wollen.

 

 

 

Kai

 

Meistens gibt es verschiedene Ansatzpunkte, mit denen die Leute hoch kommen, verschiedene Ideen. Und wir wollen vielleicht sogar forcieren, dass unterschiedliche Kleingruppen oder jeder für sich sich mal überlegt, was jetzt die beste Maßnahme wäre. Und wenn wir über Maßnahmen sprechen, dann gibt es manchmal sehr konkrete Dinge, die getan werden können und manchmal auch einfach Vereinbarungen, die sich ändern. Und wir haben in der Folge hier schon über Team Vereinbarungen gesprochen. Hin und wieder kommen aus einer Retrospektive auch sowas raus.

 

 

 

Kai

 

Wie zum Beispiel ganz viele Missverständnisse gab, habe ich mal beim Team erlebt, dass sie gesagt haben Wir wollen mehr paraphrasieren, also in eigenen Worten wiedergeben, was mein Gegenüber mir gesagt hat. Und das war auch ein verteiltes Team. Und dann war einfach eine Zeit lang oben im Sprint Backlog drin „In Arbeit paraphrasieren“ als eine Merkkarte. Die konnte man natürlich so jetzt nicht so irgendwann fertigstellen. Irgendwann nach drei, vier Sprints haben wir gesagt: Ja, passt jetzt.

 

 

 

Kai

 

Und dann ist die ist ja dann erst fertig geworden. So könnte man das auch in eine Team Vereinbarung entsprechend reinschreiben, dass wir einfach uns regelmäßig paraphrasieren und widerspiegeln, was der andere gesagt hat, um eben zu vermeiden, dass wir so viele Missverständnisse haben. Und das wäre dann eher so was in puncto Vereinbarung viel öfter und viel konkreter sind Maßnahmen und das ist irgendwas, was wirklich im Sprint Backlog danach gehört und umgesetzt werden kann von jemanden oder mehreren. Und dazu gibt es häufig viele verschiedene Vorstellungen, was man tun könnte, um ein Experiment zu starten, um das Problem zu lösen.

 

 

 

Kai

 

Und da geht es jetzt um eine Entscheidungsfindung, dass das Team gemeinsam sagt: Das hat die höchste Chance darauf, dass es das Problem lösen wird und dass wir es auch umsetzen können. Und da wollen wir eben filtern, dass wir aus diesem Wust von Ideen das Ding rausziehen, wo alle oder zumindest die meisten dran glauben, dass es das Problem löst und die anderen wenigstens mitkommen.

 

 

 

Jasmine

 

Dafür hilft es meistens in meiner Erfahrung, das Experiment möglichst konkret zu machen. Also wir sind oft gut darin zu sagen: Das und das wollen wir tun. Aber dann auch zu sagen. Und wir glauben, das hat diesen Effekt. Und daran könnten wir das messen. Das ist sehr viel schwieriger. Und wenn ich Leute beobachte, die Retrospektiven machen, dann lassen sie diesen Schritt meistens weg. Das und das wollen wir tun. Ja, wir haben eine Maßnahme. Geil, yeah, wir gehen raus.

 

 

 

Jasmine

 

Ja, aber woran erkennen wir denn, dass die Maßnahme was gebracht hat? Darüber dürfen wir uns auch Gedanken machen, genauso wie wir uns darüber Gedanken machen, woran erkennen wir, dass dieses Feature, das wir in unserem Produkt einbauen, irgendjemandem was bringt? Das heißt, was genau tun wir? Was denken wir, dass dadurch besser wird? Und woran würden wir das erkennen? Dann kommen nämlich auch nicht so Maßnahmen raus wie: Wir müssen einfach mehr kommunizieren. Wir müssen einfach mehr kommunizieren, das ist ja schön und gut und recht, aber was denn?

 

 

 

Jasmine

 

Wie denn? Wo denn? Warum denn? Also das hätte ich gerne konkreter, das kann zum Beispiel sein. Wir machen One on one Buddies, damit wir mehr kommunizieren, weil wir gemerkt haben, uns fehlt der persönliche Kontakt. Unsere Annahme ist, dass wenn sich zwei Leute über den Sprint hinweg mehrfach zu zweit unterhalten, dass wir mehr persönlichen Kontakt haben, uns wieder näher kommen. Und das würden wir daran feststellen, dass wir im Daily mehr lachen.

 

 

 

Jasmine

 

Das ist natürlich jetzt auch sehr, sehr vage, oder? Das würden wir daran feststellen, dass unser Stimmungsbarometer, dass wir ständig erheben, um einen Punkt höher geht, oder oder. Also nicht so global galaktische Baseball-Schläger Maßnahmen, sondern sehr konkrete Maßnahmen. Was genau machen wir? Warum machen wir das und wie messen wir das, was wir machen können, um diese Maßnahmen noch mal besser zu machen, damit alle dahinterstehen, ist zum Beispiel so was wie das Perfection Game. Das Perfection Game ist vor allem das ist ein Tool, das benutze ich so oft in so vielen verschiedenen Kontexten.

 

 

 

Kai

 

Das kommt eigentlich von McCarthy aus den Core-Protokollen und das ist so. Die Core Protokolle sind so ein bisschen in der Art und Weise, wie man aus einer sehr nerdigen Sichtweise soziale Interaktionen verbessern kann. Was natürlich uns Informatikern – ich darf es ja sagen, ich bin ja ein – auch teilweise echt gut liegt, weil man so ein bisschen soziale Strukturen durch gewisse Befehle in der Kommunikation abbildet. Und da gibt es eben diese Perfection Game. Und das sagt, wie perfekt ist denn zum Beispiel hier in dem Fall diese Maßnahme?

 

 

 

Kai

 

Und wenn ich keinerlei Kritik äußern kann, dann ist es automatisch eine Zehn. Und eins ist der niedrigste Wert und eins oder null. Und wenn ich darunter score, also weniger zahlen, dann muss ich auch erklären, was würde das für mich kosten oder brauchen, damit ich auf eine 10 komme. Also wenn ich jetzt eine 7 gebe, dann müsste ich sagen: Guck mal folgende Sachen müssten wir noch hinzufügen zu dieser Maßnahme, damit das für mich eine 10 ist und das perfekt,

 

 

 

Jasmine

 

Ist lustig, ich mache das anders. Haha.

 

 

 

Kai

 

Okay, wir haben bisschen Research gleich nach dem Podcast

 

 

 

Jasmine

 

Also wie ich das mache ist und ich finde, das nimmt bisschen Druck raus, eben nicht sagen zu müssen Ja, ich bin jetzt bei einer 7, eine volle 10 wäre es für mich, weil oft weiß ich das ja gar nicht. Oft bin ich ja, ich bin bei einer 7 und diese zwei Punkte stören mich. Die müssten wir noch anders machen. Das heißt, was ich oft frage ist Wo bist du?

 

 

 

Jasmine

 

Dann sammle ich das und frage die niedrigste Person, also die Person, die nicht am niedrigsten gescored hat: was bräuchte es denn für dich, um einen Punkt höher zu kommen? Nur einen nicht mehr, wenn du auf ner 6 bist, was brauchst um auf ne 7 zu kommen, da kommt irgendwas. Dann frage ich die nächste Person Du bist auf ner 7, was bräuchtest du denn um auf ne 8 zu kommen? Und so können wir diese Maßnahme iterativ anpassen. Und in meiner Erfahrung, selbst wenn ich nie gefragt habe: Was brauchst du um auf eine 10 zu kommen, sind auf einmal magische Weise dadurch, dass wir diesen Raum öffnen und gemeinsam unsere kollektive Intelligenz drauf schmeißen bei einer acht oder neun.

 

 

 

Jasmine

 

Und wenn wir kollektiv bei einer Acht sind, selbst wenn wir bei einer Sieben sind, ist es für mich good enough. Gut genug, um zu starten, es ist und bleibt ein Experiment. Es ist nicht der goldenen Löffel, den wir da haben, und das ist noch mal wichtig, um aus der Retrospektive rauszugehen. Es ist ein kleines Experiment, um uns zu verbessern.

 

 

 

Kai

 

Ein Beispiel, was ich mal erlebt hab zu dieser vierten Phase „Decide What To Do“, ist, das war ein SAP-Entwicklungsprojekt, mit ganz, ganz vielen Teams. Und ich hatte eine Retrospektive mit den Architekten. Die waren dann noch in einem separaten Thema, nicht eingegliedert in die Teams und auf jeden Fall hatten die ganz viele Verbesserungs-Ideen nach der Retrospektive. Und dann habe ich eine Liste gemacht am Flipchart und habe dann hinter jedem dieser Einträge zwei Spalten gemacht. Und zwar die erste Spalte war Aufwand, den das bei uns verursacht in der Umsetzung und die zweite war Wirkung oder vermuteter Impact, den das hat.

 

 

 

Kai

 

Und dann haben die auch da Punkte hin gemacht. Man konnte dort nachher sehen, was hat den besten Return on Invest. Also wo haben wir eigentlich ein gutes Verhältnis dazu, was relativ wenig Aufwand verursacht und wir erwarten uns davon aber eine hohe Wirkung und das haben wir dann halt genommen. Und das ist auch nur ein Beispiel. Auch da gibt es wieder viele, viele verschiedene Formate, die man nehmen kann, um dann dahin zu kommen, dass man entsprechend einen Ergebnispunkt hat in Form von einer Maßnahme oder eine Vereinbarung bei mir ist das auch oft so, dass die Retrospektiven, die sind ja auch in der Time Box, also die haben eine maximale Dauer von Scrum. Und in dem Moment, wo ich eine Maßnahme rausgezogen habe, die richtig gut ist, hört für mich auch die Retrospektive auf. Ich mache dann meistens den Sack zu, weil die Erfahrung ist, dass wenn wir uns zu viele Dinge vornehmen, dann bringt das nicht so viel, dann zerfasert das nur.

 

 

 

Kai

 

Und man braucht ja auch eine gewisse Weile, um rein zu tauchen. Und meistens sind die Zeit Scheiben. Ich mach meistens so zwei Wochen Sprints mit den Teams. Hängt ein bisschen vom Kontext ab. Da ist so ne Retrospektive 60 oder 90 Minuten lang. Bei 90 Minuten kriegt man das schon mal hin, noch ein zweites Thema anzugucken. Bei 60 im Regelfall nur ein Thema.

 

 

 

Jasmine

 

Ich bin da sehr bei Diana Larsen was Zeit angeht, Diana hat mir mal bei einem Retrospective Facilitator Gathering gesagt, eine Retro unter eineinhalb Stunden mache ich gar nicht. Kommt eh nix bei rum. Bin ich mittlerweile auch dabei. Es kann sein, dass wir mit dem Team bestimmen wir machen eine kurze Retro, eine lange Retro. Das heißt, wir machen eine ganz kurze Retro, halbe Stunde, das eher so ein Pulscheck weg ist. Dafür machen wir einmal im Monat ne zwei Stunden Retro, wo wir wirklich tief abtauchen.

 

 

 

Jasmine

 

Das kann sein, aber so 60 Minuten Retros merke ich einfach. Oder auch ich habe auch schon 75 Minuten Retros. Oft fehlt mir einfach diese letzte Viertelstunde. Das ist meine Erfahrung damit. Da darf jeder seine eigenen Erfahrungen sammeln, wie denn das für mich als Moderator funktioniert, aber auch für uns als Team. Und auch das können wir natürlich anpassen. Per Scrum Guide ist ne Retro drei Stunden lang. Bei kürzeren und Sprints kann es sein, dass sie kürzer ist, aber die Time Box wäre drei Stunden.

 

 

 

Jasmine

 

Und jetzt Hand aufs Herz machen Kai und ich manchmal immer noch Retros ohne Maßnahme? Ja, natürlich. Hat das einen blöden, fahlen Geschmack? Ja, manchmal auch und manchmal ist es genau das, was das Team braucht. Manchmal haben wir als Team einfach mal gebraucht, herz aufs Tisch zu legen und uns drüber zu unterhalten, was gerade ist. Und jedes einzelne Individuum hat so seine eigene kleine Maßnahmen da raus genommen oder auch gar nicht. Also gibt es Retros, wo ich keine Maßnahme finde oder wo ich es nicht schaffe, als Moderator eine Maßnahme rauszuschneiden.

 

 

 

Jasmine

 

Ja, die gibt’s, die gibt’s immer seltener. Die gab es am Anfang noch viel mehr. Gibt es Retros, wo ich mir diesen Druck wegnehme, weil ich einfach merke, dieses Team muss gerade reden? Und wir sind an einem wunderschönen Punkt, wo wir wirklich reden, um Dinge, die wichtig sind. Ja, dann dränge ich nicht auf eine Maßnahme, sondern dann „Go with the flow“. Also geh dahin, wo das Bedürfnis des Teams auch ist, weil dann wird es wertvoll für das Team.

 

 

 

Jasmine

 

Es ist nichts Schlimmeres, als wenn ich das Team in eine Maßnahme rein dränge, die dem Team nichts bringt, weil dann habe ich Dominiks die sagen „Nö, ich komm in keine Retros, es bringt ja eh nichts.“

 

 

 

Kai

 

Ich hatte letztens eine dieser Retrospektiven und da ging es um so einen haarigen Multi Team Konflikt und wir hatten einen 90 minütigen Workshop dazu, vielleicht sogar zwei Stunden mit auch 10 Leuten. Und was ich geschafft habe in dieser Retrospektive ist, dass jeder seine Position einfach mal klar darstellen konnte und wir erkannt haben gemeinschaftlich, dass wir ein Problem teilen. Denn nachdem so das Problem von allen Seiten beschrieben war und auch in den Raum gebracht worden für alle anfassbar und greifbar war, habe ich so die Frage gestellt: Und wenn wir jetzt nichts ändern würden und genau so weiterarbeiten in dieser Multi Team Konstellation, wie wir das bisher getan haben und ihr mal 6 Monate die Zukunft springt oder 9 Monate so Mitte nächsten Jahres.

 

 

 

Kai

 

Was denkt ihr ist dann entstanden? Und dann kamen ganz viele desaströse Aussagen, wo Leute gesagt haben, dann haben wir hier Zeit verschwendet, dann haben wir hier soziales Kapital verloren und so weiter und so weiter. Und allen ist irgendwie klar geworden so geht das gar nicht weiter. Also das Aussitzen tut es nicht und wir haben auch ein gemeinschaftliches Problem. Und dann war aber die Zeit rum und ich bin dann auch mit so ein bisschen so unbefriedigtem Gefühl wie alle anderen auch rausgegangen, dass das Ding irgendwie offen war und dann ist irgendwie einfach von ein paar Menschen getrieben Magie hinter den Kulissen passiert und irgendwann ploppte eine Lösung auf, ohne dass ich noch mal moderiert habe. Also auch das kann sein in diesem Erkenntnisprozess, wenn wir helfen, Sachen vom Unterbewussten ins Bewusste zu heben und auch vom kollektiven Unterbewussten ins Bewusste zu heben, dass dadurch das Problem klar genug wird, dass danach etwas passiert, weil es eben erkannt worden ist. Und insofern haben wir da also auch so ein Erkenntnisprozess laufen, von der zweiten über die dritte, über die vierte Phase einer Retrospektive, wo man sagen könnte wie hieß das im Amerikanischen so schön: „What, so what, now what?“

 

 

 

Kai

 

Also was ist los? Was heißt das für uns? Und was machen wir jetzt? Und da haben wir so eine Erkenntnis Schleife einmal komplett.

 

 

 

Jasmine

 

Und damit gehen wir auch in die fünfte Phase, nämlich den Abschluss. Da darfst du wählen, was auch immer du wählen möchtest. Wenn ihr eine sehr tiefe Retrospektive gehabt hat, ist vielleicht eine Dankbarkeits-Runde angebracht, wo ihr mal Dankbarkeit aussprecht, wofür sie dankbar im Team? Wofür seid ihr dankbar an einander, an diesem Raum, den ihr gerade für die letzte Zeit geteilt habt. Man kann aber auch einfach eine Feedback Door machen. Das wäre dann so die ups,

 

 

 

Jasmine

 

„Wir haben keine Zeit mehr für den Abschluss“-Variante, die ich immer in der Hinterhand habe. Einfach eine Feedback Door dort zu machen, wo man sagt Okay, das ist mein Feedback zu zu der Retro, so gehe ich grad raus oder ein Net-Promoter Score. Da darfst du dir überlegen, was braucht diese Gruppe gerade um hier einen schönen Abschluss hinzubekommen. Und deswegen mach ich das so, dass ich mir ein paar Abschlüsse überlege. 2 3 Natürlich habe ich die jetzt auch in der Hinterhand mit viel Erfahrung, aber

 

 

 

Jasmine

 

In meiner Vorbereitung der Retrospektive lege ich mich da selten fest, weil ich da wirklich ganz intuitiv vorgehe, ganz in mich rein spüre. Was denke ich, braucht diese Gruppe gerade? Und manchmal bin ich egoistisch unterwegs und denke was brauche ich gerade, um hier einen guten Abschluss zu haben? Weil ich bin auch ein Teil der Gruppe. Also wenn man es in dieser ORSC Perspektive sehen würde, die gucken ja ganz viel auf System und System Coaching oder Organisations und Beziehungs Coaching.

 

 

 

Jasmine

 

Und die sagen immer: Jede Stimme ist eine Stimme des Systems und ich bin auch eine Stimme des Systems. So, was brauche ich grade, um hier einen guten Abschluss hinzubekommen. Und das kann mich auch leiten, um einfach nochmal diesen Raum zu schließen.

 

 

 

Kai

 

Jetzt gibt es eine Handvoll an Werkzeugen, die man nutzen kann, wenn du mit Retrospektiven durchstartet. Ein ganz klassisches Werkzeug. Was Corinna Baldauf damals ins Leben gerufen hat, ist der sogenannte Retromat. Da hast du für diese fünf Phasen ganz, ganz viele 140 Aktivitäten aktuell, die man zusammen klicken kann. Die passen natürlich nicht alle vom Ablauf her zueinander. Man muss da auch schon ein bisschen mitdenken und auch ein bisschen mit experimentieren. Aber da hat man ein erstes Werkzeug, oder wir haben ja auch hin und wieder mal Liberating Structures erwähnt, so eine Art Moderation Meta-Baukasten, mit dem man auch Formate zusammenstellen kann, um Menschen zu aktivieren und gemeinschaftlich Ergebnisse zu erzeugen. Wie oft haben wir noch ein paar Bildkarten dabei. Man kann Postkarten einfach sammeln, die man irgendwie da draußen findet, mit schönen Motiven, dass man auch so ein bisschen Bezug nehmen kann zu Bild Metaphern. Also so vom Handwerkszeug. Es gibt unglaublich viele gute Bücher dazu verschiedenster Natur, die sich empfehlen.

 

 

 

Kai

 

Von Judith Andresen. Von Marc Löffler, von.

 

 

 

Jasmine

 

Rolf Tretter. Und wir vergessen hier wahrscheinlich noch einige Autoren, die gute Bücher geschrieben hat. Ach, mir fällt gerade noch ein, Aino Corry ist glaube ich nur auf Englisch erhältlich, aber „Retrospective Antipatterns“ finde ich auch sehr empfehlenswert. Es gibt wirklich super gute Bücher, wo man sich auch Inspiration holen kann. Was Kai und ich beide gemacht haben, unabhängig voneinander ist, dass wir uns irgendwie mal so 5 6. Ich glaube, du hattest sogar mehr Retrospektiven Fahrpläne zurechtgelegt haben, die wir aus der Schublade ziehen konnten für bestimmte Situationen.

 

 

 

Jasmine

 

Das heißt mal geguckt. In was für Situationen komme ich immer wieder? Was für Situationen sind typisch und für diese Situationen mal so ein paar Fahrpläne zurechtgelegt, das hilft am Anfang, um Sicherheit zu bekommen und es hilft auch, um zu üben und da sich hineinzudenken. Weil oft werden wir ja gefragt, was macht denn so ein Scrum Master den ganzen Tag um eine Retrospektive vorzubereiten. Das dauert. Vielleicht mache ich das nicht mal im Stück, sondern das beschäftigt mich oft so zwei, drei Tage vor Sprint Abschluss.

 

 

 

Jasmine

 

Was braucht dieses Team gerade? Wie sollte diese Retrospektive sein? Wie strukturiere ich die? Und sie zusammen zu schreiben ist dann schnell. Aber das beschäftigt mich schon recht lange und da haben wir am Anfang einfach meine strukturierten Pläne geholfen.

 

 

 

Kai

 

Das liegt ein bisschen da dran, weil eine Retrospektive auch so was ist wie vielleicht eine Teamentwicklungs Veranstaltung ohne Kletter Garten. Also sowas, wo man einfach als Agile Coach hoch oder Scrum Master einmal jeden Sprint die Möglichkeit hat einen Impuls zu setzen in eine bestimmte Richtung und dann für sich selber raus zu spielen. Was ist denn der nächst wichtigste Impuls und wie moderiere ich den? Das ist das, was Jasmine gerade beschrieben hat. Das braucht oft Kreativität und ein bisschen Zeit. Und insofern ja, fügt das als Retrospektive und ich glaube, das ist auch der Grund, warum wir so große Fans von Retrospektiven sind eine Form von Fähigkeit hinzu, die man vielleicht so als Einzelmensch kennt.

 

 

 

Kai

 

Meine Mutter schreibt zum Beispiel ich seit Ewigkeiten Tagebuch und beim Tagebuch schreiben reflektiere ich ja auch. Was war heute los? Und vielleicht auch noch mal Was heißt das denn für mich? Und vielleicht ziehe ich sogar noch irgendwelche Konsequenzen daraus? Kann, aber muss nicht. Und das machen wir ja eigentlich bei einer Retrospektive auf einer kollektiven Ebene auch mit den Menschen da. Das heißt, wir heben immer wieder Dinge ins Bewusstsein, um daraus zu lernen. Und das ist vielleicht das, was das Faszinierende ist da dran.

 

 

 

Kai

 

Wenn man sich eine Welt vorstellt, in denen immer mehr Menschen gewohnt sind, auf ihr Handeln zu gucken und kollektiv zu überlegen, was das bedeutet, dann glauben wir daran, dass das eine faire Chance hat, für unsere Welt wirklich einen Unterschied zu machen, der mehr und mehr wichtig ist. Bei den ganzen Problemen, die wir an der Backe haben.

 

 

 

Jasmine

 

Also für uns sind Retrospektiven bewusste Räume, die wir uns schaffen, um uns unseren Mustern, unseren Regeln, unseren Funktionen und Dysfunktionen bewusst zu werden, um die an die Oberfläche zu holen, Dinge, die wir sonst gar keine Zeit haben zu reflektieren und darauf wirklich zu inspizieren und zu adaptieren. Und so können wir den kleinen Kosmos eines Teams verbessern und ausweiten. Aber natürlich global gesehen auch der einer ganzen Firma. Also wenn du diese Methode von Circles And Soup kennst, wo in der Mitte ist, was können wir beeinflussen, was können wir verändern?

 

 

 

Jasmine

 

Dann kommt der nächste Kreis. Was können wir beeinflussen, der äußerste Kreis ist – was ist außerhalb unserer Zone der Beeinflussung? Habe ich die Erfahrung gemacht, wenn ich als Einzelperson anfange, mit Retrospektiven, mit mir selber, mit meinem Partner und oder als Team anfange, dann bin ich am Anfang in einem sehr engen inneren Kreis und ich weite den immer weiter auf und merke, ich kann sehr viel mehr beeinflussen, als ich dachte. Ich kann vielleicht sogar sehr viel mehr selber bestimmen, als ich dachte.

 

 

 

Jasmine

 

Und diese äußere Kreis von das ist überhaupt nicht beeinflussbar für mich, der wird auch immer wieder kleiner. Und ich glaube, so können wir kollektiv einfach viel bessere Organisationen gemeinsam kreieren. Organisationen, die nicht nur dazu dienen, gute Produkte zu liefern, weil dazu dienen sie aber auch dazu dienen uns gute Arbeitsplätze zu liefern. Und das können wir nur im Kollektiv machen.

 

 

 

Kai

 

Und so steigt und steigt mit jeder Retrospektive im Idealfall die Verantwortung, die Menschen übernehmen für ihr eigenes Handeln und das Handeln ihres Teams und ihrer Organisation. Und da liegt ein großes Versprechen drin, das wir auch immer wieder eingelöst gesehen haben über die letzten Jahre. Insofern wünschen wir dir viel Spaß beim Ausprobieren mit Retrospektiven – ein geniales Handwerkszeug. Man braucht eine Weile, um reinzukommen, aber es lohnt sich auch, wenn man damit einmal per Du ist. In diesem Sinne freuen wir uns, wenn du bald wieder zuhörst beim Agile Growth Podcast.

 

 

 

Jasmine

 

Das war eine sehr, sehr tiefe Folge für dich mit ganz vielen Insights, Handwerkszeug und so weiter. Wenn diese Folge dir geholfen hat, dann freuen wir uns total, wenn du den Podcast natürlich weiter empfiehlst an andere Menschen, denen diese Folge dienen könnte und uns ein paar Sternchen in dem

 

 

 

Kai

 

Podcast Client deiner Wahl gibst. Ich glaube, es geht eigentlich nur bei Apple, aber auch da freuen wir uns über auch schriftliche Rezensionen. Und genau wenn wir von dir hören-

 

 

 

Jasmine

 

Und Feedback Feedback ist immer ganz ganz toll.

 

 

 

Jasmine

 

LinkedIn, Twitter wo auch immer. Wir freuen uns auf dich in der nächsten Folge.