Planning

145 Teams in skalierten Umfeldern

Teams in skalierten Umfeldern Heute haben wir ein Thema und wechseln mittendrin noch Richtung uneinig. Wir sind uns heute richtig uneinig. Eigentlich haben wir drei Podcasts in einem aufgenommen. Diese Folge auf YouTube: https://youtu.be/QSzXdukiFVs Agile Master Training: https://znip.academy/agile Das Thema Schon über Skalierung unterhalten und daraus ist irgendwie die Frage entstanden, wie geht’s denn eigentlich den Teams in skalierten Umfeldern? Und schlecht. Schlecht, warum geht’s denen schlecht, es geht den Team immer schlecht. Was? Nein, mein mein Team ist immer wunderbar, also ich weiß nicht, was du mit deinen Teams machst. In Transformation geht’s den Teams immer schlecht. Nein, was genau meinst du? Ich habe mir dann ich weiß nicht mehr ganz, wie diese Frage entstanden ist und ich habe mir dabei eben so gedacht mit na ja Es ist schon eine Sache. Ich habe dieses Scrum oder kann man auf Teamlevel, ich habe meine Rituale eingeschwungen und so weiter und das geht alles. Und jetzt sind da plötzlich noch andere Teams, weil ich einen skalierten Umfeld bin, Dadurch kommt ein bisschen mehr Komplexität dazu und mit der darf ich ja auch irgendwie umgehen. Mhm. Okay, also für mich wäre, Abhängigkeiten so der allererste Punkt oder der allererste Unterschied, der mir auffallen würde, wäre ich bin abhängiger oder weniger also ich bin als Team nicht so frei mir meinen Rhythmus zu wählen. Mhm. Ich bin als Team nicht so frei meinen Backlog zu verhandeln. Mhm. Ich bin als Team nicht so mein Produkt zu gestalten. Also es ist eine ganze Menge weniger Selbstorganisation. Da hast du, glaube ich, schon einen interessanten Punkt genannt, der so eine Rahmenbedingung ist für das, was wir heute betrachten. Wahrscheinlich, dass die Teams am gleichen Produkt arbeiten. [2:21] Im skalierten Umfeld genau. Ich war gerade so was sagen wie auch sonst kenne ich sehr wenig Teams, die tatsächlich so selbst organisierte Reife haben, dass sie sich ihr Produkt auch selbst überlegen können. Ja. Aber zumindest ein paar Eigenschaften davon in skalierten Umfeldern ist das glaube ich alles sehr viel vorgegebener. Welche Eigenschaft ist haben soll, einfach weil das auf einem anderen Level mhm, vorstrukturiert und koordiniert wird. Mhm. Also ne, wenn wir über Flight Level reden, die Strategie und die Koordinative, die ist schon gelaufen. Ja. Bin nur noch die umsetzende Gewalt. Das ist direkt auch schon ein guter Punkt, der mir in allen skalierten Frameworks auffällt. Eine Art koordinative Ebene gibt. Also die scheint wichtig zu sein auch zum Einrichten, damit das alles zusammenspielt. Mhm. Auf dieser Ebene sollten wir uns natürlich auf eine Art wie auch immer gearteten, gleichen Takt einigen, dann vielleicht auch unsere Ziele miteinander abstimmen. Und. Könnte zum Beispiel über einen User Story Mapping passieren oder vielleicht sogar, wenn ich Sprints habe, dass ich als Product-Onerin habe ich dann ein bisschen mehr Aufgabe, mich da zu koordinieren, dass ich dann vielleicht schon die nächsten Sprints grob mit ihren Zielen vielleicht sogar vorplane. Product Ownerin Aber jetzt war ja deine Frage für diesen Podca wie fühlen sich die Teams? Ja, die Product Onnerin gehört zum Team. Und wie fühlt die sich jetzt? Die. Überfahren glaube ich von der Abstimmung, die plötzlich herrscht. Ich meine, das ist ein Overhead für die Product, Weiß ich gar nicht, denn als von einem nicht skalierten Team habe ich auch Abstimmungsbedarf. Mhm. Nur nicht mit anderen Teams oder anderen Productornern oder irgendeiner strategischen Initiative, sondern ich muss mich abstimmen mit, Kunden mhm. Marktrecherchen, User-Experience, Tests, was auch immer alles dazugehört. Und ich glaube, ich, mich so abstimmen und zusätzlich noch mit den anderen Teams, die am gleichen Produkt arbeiten. Ja, viele richten dann so eine Art Chief Product Ownerinnen ein, die das mehr in Richtung, und Stakeholder sich macht und gleichzeitig habe ich das für meinen wahrscheinlich Modul, auch noch. Nee. Nicht? Nee, das ist mehr oder weniger alles schon geklärt. Ach so, ich kriege nur noch so einen Backlog und das muss ich abarbeiten. Mehr oder weniger? Ja dann, dann fühlen sich Teams in skalierten Umfeldern ja noch wohler, weil sie ja weniger Nachdenken brauchen. Teams nee, das glaube ich eben nicht. Also ich kann mir vorstellen, dass dieser höhere Grad an Abhängigkeit, manche Teams auch einfach sehr entlastend ist. Weil es ein reines Abarbeiten, also und das ist gar nicht negativ gemeint, also das es ist einfach auch schön, wenn ich nicht selber. Koordinieren und so weiter und so fort machen muss, sondern wenn das schon erledigt wurde auf ja in einem anderen Fluglevel. Wenn es schon User-Interface-Designs gibt, an die ich mich nur noch halten muss. Ich muss mich nicht entscheiden, wie das Menü aussieht. Das ist schon lange entschieden worden. Trotzdem, dass beides passiert. Also dass ich zum einen die Strategie für das Produkt zu erfüllen habe, auf dem ich mich auf koordinativer Ebene mit den anderen Teams einige und dass ich für die Funktionen, die ich integriere, also mein Team integriert, dass ich mich da auch mit Kundinnen entsprechend unterhalten und einigen darf, wie das aussieht. Auch weil vielleicht auf koordinativer Ebene und, dann höher auf Portfolio oder strategischer Ebene auch nicht alles gesehen wird, denn viele Sachen werden auch, Expertenebene. Beobachte ich anders? Mag sein, dass wir das anders beobachte ich es auch an. Wenn das auf Teamebene erst diskutiert wird. Ja. Dann ist der Rückweg in die anderen Teams zu spät, braucht ja nicht in die anderen Teams nehmen wir mal an ich hätte einen Scrum Framework mit Sprints dann habe ich, Sprints entsprechend auszuplanen, von mir aus mit einem Release-Burndown für die koordinative Ebene, um die Strategieziele zu erfüllen und gleichzeitig werde ich auch, was weiß ich, technische Schulden von dem Modul, was ich, bearbeite eben auch beseitigen dürfen. Genau und diese technischen Schulden haben Auswirkungen auf die anderen Teams. Das muss wieder zurückgespielt werden, Testframework umstelle, weiß ich nicht, Test modular mache oder umstelle von Red Head, eins auf Red Head zwei, dann hat das Auswirkungen auf die anderen Teams. Ich kann diese nicht mehr alleine treffen, Das mag sein und es gibt genug, die kann ich alleine treffen. Also ich würde mich mal aus dem Fenster lehnen und sagen, in einem großen Konzern, mit mittelständischen Unternehmen, kann ich nicht mal als Team das nicht in einem skalierten Umfeld ist, diese Entscheidung treffen, ohne dass andere Teams davon betroffen sind. Von daher würde ich jetzt sagen, das funktioniert vielleicht in einer Startup-Buble. Nicht in Unternehmen, die bisschen größer sind und glaube ich nicht und vielleicht habt ihr da draußen ja eine ganz andere Beobachtung und könnt uns eure Meinung dazu sagen. Team Henry, Systemgrenze Was hast denn du sonst noch so für Beobachtungen und Teams installierten Umfeldern? Ich finde noch so diese Dimension Systemgrenze ganz interessant, also kommen Teams in so eine Art Wettbewerb oder Konkurrenz miteinander. Ich beobachte das manchmal schon innerhalb eines Team, dass Menschen so was wie Userstories reservieren Mhm. Da möchte ich als nächstes dran arbeiten, so Handtuch einmal ausrollen und fertig. Und ich kann mir vorstellen, dass das in skalierten Umfeldern. Auch ein Thema ist, dass sich diese Teams zwar abgrenzen voneinander und als einzelne Einheit sich verstehen im Organisationssystemkontext oben Teambuilding zu betreiben und gleichzeitig aber nicht zu weit diese Grenze fest sein darf, als dass so was wie Kompetenz und Wissen und Austausch von Experten vielleicht, also dass auch ähm einer meines Team wechselt, dass das trotzdem noch passiert mehr als Schwierigkeit vorstellen. Und das würde ich auf die koordinative Ebene auch bringen, also genau dieses Thema. Du willst eine koordinative entscheiden lassen darüber. Wo die Teams sich abgrenzen von anderen Teams. Ich würde das auf jeden Fall beobachten und da drauf gucken, ja? Entsprechend handeln, ja, das funktioniert System theoretisch nicht, weil du kannst nicht beeinflussen, wo das System selbst seine eigene Grenze setzt, Ich kann die Grenze setzen. Nee. Kannst du nicht? Das sind das sind ja keine offiziellen Entscheidungen, sondern das sind inoffizielle, das sind Bauchgefühlgrößen. Du kannst schon häufig in einem Team, Subgruppen nicht wieder auflösen. Also ich bekomme das manchmal nicht hin, dass wenn wirklich ganz starre Subgruppen entstehen und gar keine aufeinanderzugehen und Teambuilding passieren will, aus welchen Gründen auch immer, dann habe ich manchmal schon in einem einem Team so Gruppen. Mhm. Die bestehen dann aus drei, vier Leuten und auf Organisationsebene kann ich vielleicht sagen, dass das Team Tiger und das ist Team Erdmännchen. Aber ob die sich dann auch so voneinander abgrenzen, oder ob die ganz anders zusammenarbeiten, das ist ein Kulturthema, das kann man nicht bestimmen, Ich kann ja aber, wenn ich in meinem Team beim durchaus feststelle, dass ich noch ein Knut brauche. Dann kann ich das ja auf die koordinative Ebene bringen mit hey wir haben im Team Erdmännchen festgestellt. Wir bräuchten noch ein, Genau und wenn Gnus aber Erdmännchen hassen, weil das Unternehmenskultur technisch eine Systemgrenze ist. Ja. Dann bekommt man das nicht so schnell aufgelöst. Das ist das ist dann Thema der Operativen. Okay, da bin ich wieder bei dir. Man kann das nicht bestimmen, wer sich wo zuständig äh oder zugehörig führt. Das müssen die Leute schon selber entwickeln. Man kann den Dialog initiieren. Braucht auch nicht darüber reden, ob Leute sich zu oder nicht entweder das passiert, das ist eine Erfahrung, Gefühl von Zugehörigkeit ist eine Erfahrung. Würdest du also einfach laufen lassen? Na ich würde das schon beeinflussen wollen, dass ich genug bei Erdmännchen eingliedern kann, aber ich kann das nicht bestimmen. Ich dafür ich brauche dafür eine Begleitung auf der operativen. Dieses Anregen, das würde dann einfach, Direkt auf der operativen Ebene passieren, also das, Einen Gnu. Das ist ein Thema für die Kooperative. Aber ob das passiert, das kann die Kooperation das und das ist das sind wir doch aufm gleichen Platz. Das ist das, was ich meine mit, ich kann mir vorstellen, dass in skalierten Umfeldern. Dieses Thema ist Themengrenze, Teamgrenze so fest zu zurrennen, dass Teambuilding und Performing Teams entstehen und gleichzeitig aber so fluide lassen, dass ich in Erdmännchen packen kann. Das ist eine Herausforderung auf Team-Ebene, würde ich sagen. Das fühlt sich, glaube ich, nicht immer leicht. Wenn man dann permanent durcheinander gemixt wird, nur weil irgendjemand, Es braucht jetzt ein Genug. Finde ich von der von der Teamuhr her, also für diese Teamuhr finde ich das auch nicht gut, die Teams ständig durcheinander zu würfeln. Und grade deshalb finde ich es eben auch wichtig, dass auf koordinativer Ebene zu betrachten und, auch ein bisschen Ruhe reinzubringen, die nicht ständig durcheinander zu würfeln. Und ich hatte eben und da scheinen wir uns doch einig zu sein, gedacht, ich habe jetzt eine Aufgabe, die aufm kritischen Pfad meines Projektes ist und stelle halt in einem Team, von mir aus Team Erdmännchen, fest oder ist wohl eine Iteration in die Hose gegangen und wir sind jetzt grade ein bisschen arg an der Kante des kritischen Falles. Wir bräuchten Unterstützung….

Read More

131 Fibonacci

Fibonacci Heute wieder eine Solo-Folge von Henry Schneider über die Fibonacci-Folge. Also einer ganz speziellen Zahlenfolge, die wir im Agilen gern verwenden. Diese ist gekoppelt mit Wahrnehmungspsychologie, wozu Janina Kappelhoff noch gesondert berichten wird. Henry hat da nämlich wenig Ahnung von. 😀 Diese Folge auf YouTube: https://youtu.be/r5xlYZPqPcs Fibonacci-Folge Die Fibonacci-Folge wurde von Leonardo Fibonacci 1202…

Read More

129 Flow

Flow Heute geht’s im Flow und die liebe Janina Kappelhoff ist sogar so im Flow, dass wir gar nicht mit Wozu, sondern „Was ist es?“ beginnen. 😀 Diese Folge auf YouTube: https://youtu.be/hUg7UMfuPDc Was meinen wir mit Flow? Wir meinen damit einen Zustand, der heutzutage oft eher mit DeepWork bezeichnet wird. Quasi der Zustand, wo wir…

Read More

120 Agile Master

Agile Master Heute die Folge wo wieder vieles zusammen kommt. Der Agile Master oder die Agile Masterin. Eigentlich handelt der ganze Podcast davon und wir werden hier auch viel referenzieren können. Bestimmt wirst Du heute verstehen warum wir so viele Grundlagen gelegt haben und auch was es denn nun mit der Agile Masterin auf sich…

Read More

118 Planning 2

Planning 2 In der Planning 1 Folge haben wir bereits angedeutet, dass der aktuelle Scrum Guide nicht mehr zwischen Planning 1 und 2 unterscheidet und wir es, allein schon für die Aufteilung der Folgen, trotzdem für sinnvoll halten. Dies ist also die Anschlussfolge zum Planning 1 und beschreibt das Planning-Event zum Start eines neuen Sprints…

Read More

116 Planning 1

Planning 1 Heute reden wir über das Planning 1. Der aktuelle Scrum Guide kennt nur das Planning und unterscheidet nicht mehr zwischen 1 und 2. Wir halten das dennoch für sinnvoll und teilen die Folge daher nach 1 und 2 auf. Es ist endlich mal wieder eine Folge, die sich gezielt an unsere Product Ownerinnen…

Read More

Folge 110 User Story

User Story Heute geht es auf unserer Reise in die Agilen Welten & Methoden weiter, denn das Thema ist User Story. Heute geht es also um Agiles Anforderungsmanagement. Natürlich geht es auch darum, was sind Dinge, wie wir sehen, die man mit User Stories falsch und auch richtig machen kann? Diese Folge auf YouTube: https://youtu.be/hrPK8VmWEAs…

Read More

Folge 091 Velocity

Velocity Heute wieder ein Henry Schneider Thema: Velocity. Also Geschwindigkeit und irgendwie auch nicht. Jedenfalls geht es wieder ums Messen und Überprüfen. Eine Freude für Projektleiter. Denn heute lernen wir wieder eine Messgröße im Agilen kennen, die uns dabei unterstützt das Projekt zu steuern, Voraussagen zu treffen und vor allem auf das Team zu achten….

Read More

Folge 084 StoryPoints wegstreichen

StoryPoints wegstreichen Heutiges Thema: StoryPoints wegstreichen. Ja, stand eigentlich nicht auf der Liste und ist Henry Schneider im Coaching begegnet. Erste Reaktion war „Nein, nicht machen.“ und dann erinnerte sich Henry, dass er das auch mal vor Jahren gemacht hatte. Die Frage ist also valide und warum macht Henry das heute nicht mehr? Diese Folge…

Read More

Folge 082 Nein

Nein Heute geht es um das richtige Nein sagen. Wieder eine Folge ohne Janinas tolle Stimme und Geschichten, denn sie hat wieder ein Training bei der Teamworks GmbH. Dieses Mal Agiles Teamchoaching kompakt. Nein sagen hatten wir schon ein paar Mal als Thema. Beispielsweise hier. Und ich möchte damit Dir gemeinsam noch einmal etwas mehr…

Read More

Folge 075 Sprint Goal

Sprint Goal In der heutigen Folge geht es um das Sprint Goal (deutsch: Sprintziel). Diese Folge ist aufbauend auf die letzte Folge Commitment. Denn es braucht Commitment um sich auf ein begeisterndes Sprintziel im Planning einigen zu können. Warum ist das heute Thema? Henry hat entdeckt, dass er das Thema anders behandelt als Janina und…

Read More

Folge 074 Commitment

Commitment Heute gab es eine Umfrage auf Intagram, und Commitment hat als unser nächstes Thema gewonnen. 🙂 Die Googles Projekt Aristoteles Studie sieht Commitment in Form von Zuverlässigkeit als einen Kernpunkt bei High Performing Teams. Ein weiteres deutsches Synonym für Commitment ist Selbstverpflichtung. Beides trifft das Wort nicht komplett und ist eine gute Annäherung. Es…

Read More

Folge 070 Pull

Pull Heute geht es um das Pull-Prinzip. Warum? Es ist überall in der Agilität und ganz besonders in KanBan. Also heute geht es um das Prinzip des Ziehens. Links Psychologische Sicherheit zyklusbasiert lernen Diese Folge auf YouTube: https://youtu.be/oQ8MxGDrIpU Am Anfang… Für Henry war in der klassischen Projektleitung damals der Umstieg von Push auf Pull eine…

Read More

Folge 063 Ziele

Ziele Das heutige Thema sind Ziele. Darüber haben die liebe Annette und Janina bereits in der Ziele träumen Folge gesprochen und einige Profitipps rausgehauen. Wir möchten heute nochmals die Ziele genauer beleuchten. Also Lebensziele und vor allem auch Projektziele und diese in den Kontext der Agilität bringen. Schließlich haben wir hier ein Sprint Goal und…

Read More

Folge 051 Budgetplanung

Budgetplanung Ich krieg sehr oft von anderen Agilisten zu hören, dass eine Budgetplanung nicht möglich ist. Das ist Unsinn. Das funktioniert. Vor allem wenn Personal die höchsten Kosten sind. Das ist in Entwicklungsteams häufig der Fall. Aber auch Hardware lässt sich schätzen. Also, ich kriege oft zu hören, dass wir Agilisten nie irgendwelche Zahlen nennen…

Read More

Folge 042 OKR

OKR Heutes Themea auf Hörerwunsch, OKR, also Objectives & KeyResults. Hört sich ähnlich an wie KPIs, also Key Performance Indicators und passt auch in diese Ecke. Wörter wie Objectives, also Ziele und KeyResults, also Kernergebnisse oder Messwerte, begnen uns eher im Management Bereich. Bei OKR handelt es sich um ein strategisches Werkzeug. Wir kommen also…

Read More

Folge 028 Routinen und Rituale

Routinen und Rituale Anknüpfend an die letzte Folge beleuchten wir nun die andere Seite von Routinen und Rituale. Hast Du die Folge 026 Rituale und Routinen noch nicht gehört, dann empfehle ich Dir erst einmal dort rein zu hören. Routine ist eine Wegerfahrung. Also eine Erfahrung die wir im Laufe der Zeit machen. Warum funktionieren…

Read More

Folge 026 Rituale und Routinen

Rituale und Routinen Was haben Biberburgen mit Ritualen und Routinen zu tun? Die zwei großen R’s. Auf Janina wirken Rituale eher gläubig. Stimmt das? Sie ist echt dicht dran. Dafür können wir einmal Wikipedia zitieren. Ein Ritual ist eine nach vorgegebenen Regeln ablaufende, meist formelle und oft feierlich-festliche Handlung mit hohem Symbolgehalt. Sie wird häufig…

Read More

Folge 022 Scrum

Was ist denn nun Scrum? Eine Folge, die erfüllt von Flexibilität ist. Denn sowohl Henry als auch Janina haben übersehen, dass das auf dem Redaktionsplan steht. Doch wir beide sind ja Profis und können Dir Scrum auch mal einfach so erklären. Warum das gar nicht so 100%ig leicht ist? Nun Henry wendet dieses Framework in…

Read More