Seminar buchen

Schlagwort: Management

Veröffentlicht am

Burndown Charts verständlich erklärt

Seit langem schon nutzen agil arbeitende Teams spezielle Visualisierungen, um über den Fortschritt ihrer Arbeit Klarheit zu haben. Auch Stakeholder schätzen diese Art und Weise der visuellen Klarheit im Bezug auf den Produktentwicklungsfortschritt. Aber auch im Team und als Coachingwerkzeug eignen sich sogenannte Burndown Charts und Burnup Charts hervorragend. Wir sprechen in dieser Folge über unsere Erfahrungen mit diesen Visualisierungen und wie wir sie in Coachings einsetzen.

Jasmine

 

Schön, dass du wieder dabei bist beim Agile Growth Podcast. Heuete geht es um ein Oldschool visuelles Management Tool, nämlich Burnup und Burndown Charts. Wie können wir die als Agile Coach erfolgreich einsetzen? Welchen Nutzen können wir daraus ziehen? Und wie können sie uns helfen, in die Kommunikation zu kommen?

 

 

 

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. Und heute geht es um grafische Werkzeuge, die einem dabei helfen können, dass man weiß, wo steht man eigentlich in Bezug auf Produktentwicklung, in Bezug auf den Fortschritt eines konkreten Sprints? Da kommt einem vielleicht das Wort Burndown Chart in den Kopf.

 

 

 

Jasmine

 

Und wenn wir an die Empirie denken, dann haben wir die drei Säulen des empirischen Vorgehens, nämlich die Transparenz schaffen, also 100%-ige Transparenz schaffen über alles, was gut läuft und alles, was nicht so gut läuft, damit wir entsprechend inspizieren können. Das heißt, die richtigen Fragen stellen können, damit wir adaptieren können. Das heißt das Richtige anpassen können. Da helfen einem grafische Werkzeuge einfach ungemein. Und da gibt es natürlich auch noch viel mehr als Burndown Charts.

 

 

 

Jasmine

 

Wenn wir jetzt aber den Sprint Fortschritt angucken, wenn wir angucken, wie kann es ein Team denn schaffen, sich wirklich selbst zu managen in Hinblick auf zum Beispiel das Sprint Ziel oder das Ergebnis, was am Ende eines Sprints rauskommen soll? Und wie schafft es auch das gesamte Scrum-Team sich selber zu managen in Hinblick auf Produkt-Ziele? Dann sind unserer Meinung nach BurndownCharts eine große Hilfe. Sie sind kein Muss. Also ganz wichtig, du machst auch Scrum, wenn du keine Burndown oder Burnup oder was auch immer Charts machst.

 

 

 

Jasmine

 

Aber sie helfen manchmal einfach als visueller Marker, den wir zum Beispiel in einem Daily benutzen können.

 

 

 

Kai

 

Ich habe mal Jeff Sutherland reden hören darüber. Der ist ja so einer der geistigen Väter von Scrum und der war Kampfpilot bei den Amerikanern. Und der hatte dann natürlich die Aufgabe, auf so einem Flugzeugträger im Wasser zu landen. Und wenn man das versucht, dann bist du halt irgendwo in der Luft mit einem Flugzeug und muss halt schauen, dass du aufsetzt, quasi zwischen dem Beginn des Flugzeugträgers und dem Ende. Insofern hast du so einen Korridor Fenster, in dem du landen kannst.

 

 

 

Kai

 

Und die gleiche Analogie hat er benutzt, um zu überlegen, okay, eigentlich wollen wir doch so ein Sprint, den wir uns vornehmen an Arbeit, zum Beispiel für vier Wochen wollen wir doch auch in so einem Fenster landen, also das wir möglichst im richtigen Korridor dann da unten ankommen, nämlich was ist mit da unten gemeint? Am Anfang vom Sprint haben wir ganz viele Tätigkeiten, Dinge die in der Sprint Planung identifiziert worden sind und die wir erledigen wollen. Und dann wollen wir die Tätigkeiten Stück für Stück abarbeiten, selbst gemanagt innerhalb unseres agilen Teams, um dann am Ende vom Sprint möglichst bei Null raus zu kommen.

 

 

 

Kai

 

Also dass wir alles gemacht haben, was wir uns vorgenommen haben. Und so eine Grafik nimmt man dann, also da ist die Zeitachse ist dann die x-Achse und auf der y-Achse ist die Anzahl der nicht geschlossenen Tätigkeiten, also der Tasks, die noch offen sind. So ein Ding nennt man dann einen Sprint Task Burndown Chart.

 

 

 

Jasmine

 

Also das was Kai gerade beschrieben hat, da wo wir die Tasks eintragen und dann auch abtragen, wie viel Tasks haben wir fertig? Das Sprint Task Burndown Chart habe ich persönlich noch nie benutzt. Was ich lieber benutze ist das Sprint Product Burndown Chart, nämlich da, wo wir auf die eine Achse eintragen wie viele Backlogs Einträge im Fall wenn ihr User Stories benutzt wie viele User Stories, aber wie viele Backlogs Einträge wir in unserem Sprint haben. Wir könnten auch natürlich, wenn wir so was wie Story Points benutzen, die Story Points eintragen.

 

 

 

Jasmine

 

Sollten wir in Mann-Frau Tagen schätzen, können wir auch das eintragen. Aber oft hilft es mir schon auch einfach nur zu sagen: Okay, wir haben sechs, sieben, acht Product Backlog Einträge in unserem Sprint drin. Die trage ich auf der Achse ein. Und dann jedes Mal, wenn ein Produkt Backlogs Eintrag, also eine User Story oder wie auch immer ihr die formuliert fertig ist, dann tragen wir die ab. Das hat mir bis jetzt in den Team-Kontexten meistens genug Sichtbarkeit darüber gegeben

 

 

 

Jasmine

 

Wie gut sind wir denn unterwegs? Und was ich an der Variante auch immer sehr sehr charmant fand ist, man hat die Team-Zusammenarbeit unglaublich gut gesehen. Oft ist es nämlich so beim Kunden, dass am Anfang des Sprints natürlich irgendwie 8 Einträge offen sind und die sind dann so eineinhalb Wochen offen und nach eineinhalb Wochen gehen mal 5 Einträge zu. Und wir sind ja auch genau 5 Entwickler:innen im Team drin. Ja ist ja logisch. Jeder hat halt in einem anderen Eintrag gearbeitet und dann sind wir fertig und dann fängt das große Gerödel an: Boah, wir haben noch drei, müssen wir irgendwie geschafft kriegen.

 

 

 

Jasmine

 

Dann beginnen drei Leute irgendwie einen neuen Eintrag. Zwei Leute sagen, sie haben nichts mehr zu tun und die drei Einträge werden dann auch nicht fertig. Das heißt, so Sachen kann man daran auch gut ablesen. Manchmal hilft es dann, diese Burndown Charts, egal wie man die macht, mit in die Retrospektive zu nehmen und einfach drüber zu reflektieren: was sagt das über unsere Teamarbeit aus? Sind wir gerade schon ein Team, das wirklich zusammenarbeitet oder sind wir noch eine Gruppe?

 

 

 

Jasmine

 

Verteilen wir die Arbeit auf einzelne Köpfe? Oder sagen wir: Hey, das ist das Wichtigste, was wir diesen Sprint erledigen müssen. Das heißt, wir rücken uns hier zusammen. Das heißt nicht jeder kann alles machen. Überhaupt nicht. Da muss man trotzdem ein bisschen gucken. Aber oft kann man einander aushelfen. Man kann Dinge schon mal vormachen. Irgendjemand, der langsamer ist in etwas. Aber wenn es wichtig ist, kann der jemand trotzdem anfangen.

 

 

 

Jasmine

 

Und der andere, der gerade noch mit was anderem beschäftigt ist, der schneller wäre, kommt danach hinzu. Dann haben wir auch eine gute Wissens-Verteilung. Also solche Dinge kann ich an einem Burndown Chart auch mit ablesen. Zudem dass es im Team einfach ein unglaublich guter Indikator während des Sprints gibt: Ist denn das noch zu schaffen? Wie sind wir denn gerade unterwegs?

 

 

 

Kai

 

Und wenn ich so ganz ehrlich bin, wenn ich zurückschaue, jetzt so über die 14 Jahre Scrum, wie viel Teams habe ich dabei geholfen, so ein Sprint Burndown Chart zu benutzen, egal welche Facette davon? Wenn das elektronische Werkzeug das zufällig ausgespuckt hat, dann haben wir da öfter drauf geguckt. Bei den ersten paar Teams, die ich gecoacht hab, war das auch so, dass ich die Dinger gemalt habe. So am Anfang, das irgendwann dem Team in die Hand gedrückt habe und gesagt habe malt mal selber weiter.

 

 

 

Kai

 

Und in vielen Teams ist das dann irgendwann weggefallen, weil sie den Lernpunkt verstanden hatten. Und dann war das eigentlich genug, auf das Taskboard drauf zu schauen und man sah an dem Sprint Backlog selber dann schon, wie sich die Tätigkeiten entwickeln und ob die das hinkriegen. Insofern habe ich da immer so ein bisschen gemischte Gefühle dazu. Also um ein Ziel zu erreichen im Coaching finde ich das irgendwie ganz nett und ein ganz gutes Werkzeug. Jetzt so für jedes Team bin ich so persönlich.

 

 

 

Kai

 

Also wenn das jetzt nicht so ein Jira irgrendwie ausspuckt. Zum Beispiel habe ich jetzt ein Team, das sehr gerne mit Miro arbeitet im digitalen Raum und da das Task Board drauf hat. Da gibt es natürlich so eine Visualisierung nicht und ich habe die jetzt auch nicht hinzugefügt als Coach. Auf der anderen Seite achte ich auf die ähnlichen Punkte und spreche das auch so ähnlich an. Also zum Beispiel war da das Daily oft am Anfang Personen-orientiert. Also jeder sagt mal, was er so gemacht hat und wo er dran ist.

 

 

 

Kai

 

Und ich habe das jetzt mal umgestellt auf: Lass uns mal entlang des Sprint Backlogs gehen und dann schauen wie sieht es hier aus, wie sieht es hier aus? Und dann gibt es auch so etwas wie ein kleines dann und ein kleines dann heißt so aus Sicht des Entwicklungsteams eigentlich fertig, aber dann müsste noch die Qualitätssicherung und der Product Owner guckt noch mal drauf, dann gibt es das große dann und dann, dann wird das ja auch schon mal genannt. Und das ist eigentlich ein ähnlicher Effekt, den Jasmine gerade beschrieben hat, den man auch über das Coaching mit so einem Sprint Product Burndown Chart erreichen könnte.

 

 

 

Jasmine

 

Ist ganz lustig. Ich habe da ganz andere Erfahrungen gemacht. Also die eine Erfahrung, die ich total teile, ist ja, ich benutze es als Coaching-Werkzeug und die meisten Teams, wenn sie reifer werden, brauchen das einfach nicht mehr, weil sie selber ein Gefühl dafür entwickelt haben, wenn sie auf ihr Task Board gucken. Hey, das reicht im Sprint, das reicht nicht im Sprint. Wir müssen zulegen. Da braucht niemand Unterstützung oder nicht, da reichen Teams im Coaching bei mir.

 

 

 

Jasmine

 

Ich würd über den Daumen gepeilt sagen irgendwas zwischen zwei Monaten und vier Monaten. Und dann haben wir diese Burnout Charts auch schnell mal wieder sein gelassen. Was ich zum Beispiel nie mache ist, wenn Jirar das ausspuckt drauf zu gucken. Ich find das so hässlich auf Jira, dass ich da nicht drauf gucke. Ich bin auch wirklich ein Ästhet, als ich mal das gerne selber. Ich habe das super gerne selber gemalt. Ich habe das jetzt auch mit digitalen Teams gemalt, dann war das bei mir als Kamera Hintergrund.

 

 

 

Jasmine

 

Das hat für uns ganz gut funktioniert. Wenn’s digital ist. Habe ich das oft irgendwie. Darf man niemandem sagen, nicht hingekriegt, oder ich finde es hässlich oder man muss was rumfiddeln und ich fand es anstrengend. Also beide Varianten funktionieren. Ich glaube, da wo wir die Erfahrung teilen ist irgendwann mal braucht es ein Team oft nicht mehr.

 

 

 

Kai

 

Ein anderer Korridor ist natürlich noch, wenn ein Stakeholder wissen will, wie läuft denn die Produktentwicklung generell? Und ja klar, der Product Owner oder die Product Ownerin ist da entsprechend der richtige Ansprechpartner für. Und dann ist es ja schon so, dass man so ein bisschen auch gern das Auge isst mit und was zum visuellen Kommunizieren gut brauchen kann. Und da kommen dann wieder unsere Product Burndown Charts ins Rennen und da habe ich eigentlich die gleiche Betrachtung. Nur dass ich einfach schaue.

 

 

 

Kai

 

Zum Beispiel die Anzahl aller unfertiger Product Backlog Einträge. Das können ja dann doch schon mal, weiß ich nicht. Ich sage mal bis zu 150 Stück sein. Danach finde ich, verliert man total den Überblick. Mehr sollte es nicht sein. Dann muss man eigentlich den Papierkorb aufmachen, das da reinschmeißen. Aber so bis dahin könnte man die Anzahl zählen und dann schaut man entsprechend: Wie viele sind jetzt fertig geworden, sodass man auch darunter brennt. Und da hilft es oft noch eine Linie einzuziehen, wann man ausliefern möchte.

 

 

 

Kai

 

Denn man hat ja nicht vor, das Produkt erst auszuliefern, wenn man alle 150 Einträge umgesetzt hat, sondern sozusagen die Wasserkante, auf der man da landet. Also der Meeresspiegel vom Ozean. Den kann man dann so anpassen, dass der gerade zur nächsten Auslieferung passt. Und weil es eben dieses Phänomen gibt, dass das dann so eine dynamische Linie braucht, auf der man landen möchte, dreht man das Ding auch manchmal um und da macht man Burn Up Chart, wo das entsprechend andersherum funktioniert, dass man entsprechend die Arbeit dann hoch brennt.

 

 

 

Jasmine

 

Genau. Also ich benutze Burn Up Charts in dem Zusammenhang viel, viel lieber, weil da muss ich das ganze Ding nicht ständig anpassen. Das ist mir irgendwie zu anstrengend. Ihr merkt, manchmal bin ich ein bisschen faul. Ähm, ich benutze Burn Up Charts da am liebsten und da kommt auch immer wieder die Frage: Ja, aber das muss doch jetzt genau sein. Und dann brauchen wir genaue Schätzungen und so weiter. Ein guter Freund von uns und mein Co-Speaker Joseph Pelrine sagt immer: Es ist nicht die Schätzung das Problem, sondern die politische Konsequenz der Schätzung.

 

 

 

Jasmine

 

Und so ist das auch beim Burn Up Chart. Es ist nicht das Problem, ob das jetzt genau genug ist oder nicht, sondern welche politische Konsequenz das hat. Es ist und bleibt im komplexen Raum eine Glaskugel-Rechnung. Die kann genauer werden. Aber ganz ehrlich, dann muss ich extrem viel statistisches Voodoo machen. Da ist unser Freund Joseph Pelrine, auch der, den man fragen möchte, wenn man das statistische Voodoo machen will, der ist unglaublich gut da drin.

 

 

 

Jasmine

 

Ich empfinde das ganz oft als viel zu viel Aufwand für das, was rauskommt. Das heißt einfach mal Backlog Einträge zählen und hochrechnen und gucken wie viel schaffen wir denn so im Sprint an Backlog Einträgen normalerweise. Das gibt mir schon mal eine Aussage darüber, wo wir ungefähr landen können. Dann kann ich nämlich sagen: Lieber Stakeholder, wenn die Priorisierung so bleibt, wie sie gerade im Backlog ist und wir drei Monate weiterarbeiten, dann landen wir ungefähr da und das ist ungefähr drin.

 

 

 

Jasmine

 

Und ja, es ist beides ungefähr. Aber es ist eine Aussage, die ich treffen kann und dann gehen die Geister so ein bisschen auseinander. Dann gibt es gewisse Coaches und Agilisten, die sagen: Nee, wir schätzen einfach das gesamte Backlog ein, dann werden wir genauer. Und wenn wir das gesamte Backlog eingeschätzt haben, können wir unsere Velocity nehmen. Haben wir dann auch geschätzt. Dann werden wir da auch genauer, dann können wir eine genauere Aussage treffen.

 

 

 

Jasmine

 

In meiner Erfahrung macht es keinen großen Unterschied, ob ich Backlogs Einträge zähle oder ob ich jetzt Story Points schätze und Velocity noch mit dazu nehme an Story Points oder ob ich als Velocity einfach nehme: normalerweise schaffen wir acht Backlog Einträge. Ich gehe davon aus, wir schaffen immer noch acht Backlogs Einträge. Dann kann ich auch noch eine pessimistische und eine optimistische Schätzung machen. Also viele Leute werden krank sein, was auch immer es wird jetzt Winter. Wir haben Corona.

 

 

 

Jasmine

 

Ich gehe davon aus, wir werden über die Zeit nur noch sechs Einträge schaffen. Das wäre die pessimistische Schätzung. Die optimistische Schätzung ist natürlich: Wir werden besser, weil ist ja unser Ziel, besser zu werden. Das heißt, wir werden über die Zeit elf Einträge schaffen. Dann kann ich zwei Linien ziehen und kann dann immer sagen: Im schlimmsten Fall landen wir da in drei Monaten, im besten Fall landen wir da in drei Monaten. Und dann gibt es auch ein informiertes Gespräch mit meinen Stakeholdern.

 

 

 

Jasmine

 

Wenn die sagen: Ja, aber das brauche ich unbedingt drin. Kann man sagen Ja, das ist gut. Dann lassen Sie uns auch gucken, was wir vorher rausnehmen, damit du das unbedingt drin haben kannst.

 

 

 

Kai

 

So, der Risiken und Beipackzettel, den wir noch dazulegen, ist natürlich dieses ganze Thema: schätzen und Planen ist in Scrum ja gar nicht definiert. Das ist irgendwie dazu gebastelt. Da hat Scrum jetzt per se keine Antwort drauf. Wenn ein Unternehmen gerade das Bedürfnis hat, da mehr Klarheit oder mehr Sicherheit zu haben in Bezug auf dieses komplexe Feld der Produktentwicklung. Da hat Scrum keine Antworten. Das heißt nicht, dass es in der Agilen Welt nicht, wie Jasmine beschrieben hat.

 

 

 

Kai

 

Ideen dazu gibt. Da muss man einfach einen Kontext rausfinden, was funktioniert. Und da gibt es natürlich auch ganz, ganz viele beliebte Dysfunktionen, die man kreieren kann, wenn man anfängt, zum Beispiel den Lieferanten zu bezahlen für die Anzahl der Story Points, die der umsetzt. Und solche Geschichten. Da gibt es doch einiges an Schmerzen. Da haben wir auch immer wieder Diskussionen im Seminarraum zu. Insofern muss man da ein bisschen schauen. Burndown Charts sind prinzipiell ein bisschen weggerückt von der Wichtigkeit, im aktuellen Scrum Guide ist das Wort vielleicht gerade noch vorhanden.

 

 

 

Kai

 

Ich müsste es gerade noch mal nachlesen. Aber das ist, wenn überhaupt, nur noch ein Stichwort. Früher war das mal viel präsenter da drin und mittlerweile ist das nur ein Hilfsmittel, was man neben anderen Graphen und Grafik nehmen kann, wie zum Beispiel einen kumulativen Flow Chart. Was, die Kanban-Leute  ja ganz gern benutzen, wo man dann sieht, an welcher Station der Wertschöpfung man entsprechend wie lange steht und wie lange man braucht in diesem Prozessschritt, um dann den Wert-Strom zu optimieren, was ja so die Grundidee von einem Kanban System ist

 

 

 

Jasmine

 

Für uns Quintessenz von Burn down und Burn Up Charts ist.

 

 

 

Jasmine

 

Sie helfen einem als Mittel dazu, Transparenz zu schaffen, um dann in die Kommunikation einzusteigen, sei es mit dem Team über den Sprint und das Sprint-Ziel oder mit dem Team über das Produkt-Ziel und wie sehr wir das erreichen werden, nicht erreichen werden, was wir verändern können oder auch mit den Stakeholdern. Das heißt immer dann, wenn ich das Chart oder das Hilfsmittel als das Wahrsager-Objekt nehme, wird’s schwierig, weil dann habe ich ganz viele politische Konsequenzen hintendran, da wo ich das Chart nehme als Medium dafür, Transparenz zu kreieren und dann in die Kommunikation einzusteigen, damit wir gemeinsam inspizieren und adaptieren können.

 

 

 

Jasmine

 

Da erfüllt das Tool seinen Zweck. Wir haben dir jetzt hier auch eher die Scrum Master Perspektive auf diese Charts aufgezeigt. Unsere Freunde vom Produktwerker Podcast können dir bestimmt auch noch die Product Owner Perspektive aufzeigen und was man denn da alles auch noch machen kann. Wir hauen sie an für dich.

 

 

 

Kai

 

Genau und insofern viele Grüße ins Rheinland, da komme ich ja auch ursprünglich her. Könnt ihr auch mal reinhören, wär schön. Genau. Wir freuen uns, dass du heute dir einen Überblick verschafft hast zu den Möglichkeiten des visuellen Managements, die einem dabei helfen, im Scrum Team zu arbeiten. Und wir freuen uns, wenn du ganz bald wieder einschaltet beim Agile Growth Podcast.

 

 

 

Jasmine

 

Und wie immer freuen wir uns total auf Feedback und auch so eine Sternchen Bewertung im zum Beispiel Apple-Store, damit unser Podcast noch ein bisschen größer wird, bisschen mehr Reichweite bekommt. Wenn du uns also unterstützen möchtest – wir freuen uns total auf ein paar Sternchen in dem Podcast Service deiner Wahl.

 

 

 

Kai

 

In diesem Sinne bis ganz bald wieder hier im Agile Growth Podcast.

 

 

 

 

Veröffentlicht am

Warum Agilität scheitert

Der Weg zu Agilität ist steinig. Regelmäßig scheitern Unternehmen daran, agile Vorgehensweisen einzuführen. Wir sprechen in dieser Folge über die zehn größten Hemmnisse für Agilität – seien es inkonsistente Prozesse und Praktiken zwischen den Teams, generell einschränkende Organisationskultur, die den agilen Werten widerspricht, fehlendes Wissen und Erfahrung oder auch ein zu geringes Interesse des Managements an echter Veränderung. Wir beleuchten alle Aspekte aus unserer Erfahrung und geben dir Ideen mit an die Hand, was du in deinem Umfeld tun kannst, um diese zu adressieren.

Kai:

Warum Agilität scheitert? Es ist herausfordernd, Agile zu arbeiten. In dieser Folge hörst du die Top 10 Gründe, woran agiles Arbeiten scheitert und was du tun kannst in deinem Team und deinem Umfeld, damit das nicht passiert.

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. Und heute geht es darum, warum Agilität scheitert. Das hat, glaube ich, mittlerweile schon jeder wahrgenommen, dass es auf dem Weg zur Agilität viele, viele Hindernisse gibt und dass das auch in vielen Fällen einfach nicht funktioniert die Arbeitsweise so zu verändern, dass man wirklich zu agilem Arbeiten kommt. Wir schauen uns in dieser Podcastfolge die Top 10 Gründe an, an denen Agile Vorhaben scheitern und was du entsprechend tun kannst, damit das nicht dir auf die Füße fällt.

Jasmine:

Und bevor wir jetzt da reingehen ist mir noch mal so ganz wichtig – ich hatte diese Woche einen Workshop und ich find das so spannend. Der Workshop war wirklich zu Agilität – wie können wir das für uns nutzen? Und ich find es so spannend, wenn ich so Workshops habe, kommt immer als allererstes von mindestens einem Teilnehmer oder einer Teilnehmerin. Ja, Agilität ist ja völlig undefiniert. Das versteht ja jeder so für sich selber, wie er es versteht. Ja, kann ja sein.

Jasmine:

Und ich würde dem vehement widersprechen. Für mich ist Agilität sehr wohl definiert. Wir haben das Agile Manifest und für mich ist ein Ausrichten unserer Arbeitsweise an dem agilen Manifest und den Prinzipien bedeutet für mich Agilität. Und ich glaube, für dich ist es auch so, Kai.

Kai:

Genau da gibt es eine klare Definition. Die besteht aus Werten und Prinzipien. Und wenn man sich die Frage stellt – Arbeiten wir eigentlich agil? Dann ist das das, was bei uns im Hintergrund abläuft. Handeln wir nach den Werte-Betonungen, die da stecken, und setzen wir diese Prinzipien um? Das heißt, dass ist kein beliebiger Begriff. Mein BMW kann auch agil fahren. Nein, das ist es nicht, sondern man kann das wirklich abgrenzen. Und falls dich das interessiert, unsere zweite, dritte, vierte Podcastfolge, müsste man schauen

Kai:

Geht darum Agiles Manifest – was hat das eigentlich so auf sich? Aber darum soll es heute nicht gehen, denn heute gucken wir – Woran scheitert das denn, wenn man dann agil arbeiten möchte?

Jasmine:

Aber an der Stelle für dich zum einordnen, superwichtig: auf was beziehen wir uns, wenn wir von Agilität reden? Das ist für uns nicht undefiniert und schwammig und jeder kann das selber definieren. Der erste Grund:

Kai:

Wir haben vor dem Podcast mal den Fifteenth State of Agile Report uns angeguckt. Das ist ein jedes Jahr raus kommender Report, wo viele Agilisten und auch Unternehmen entsprechend dazu beitragen. -Wie ist denn so die Lage in Bezug auf Agilität? Und da gibt es ein ganzes Listing von noch mehr Gründen, woran Agilität scheitert.

Kai:

Wir gehen jetzt mal nur auf die Top Ten ein, weil die uns auch irgendwie bekannt vorkommen aus den letzten Jahren und unseren Ideen dazu. Und wir starten mit dem ersten. Und das ist nämlich, dass es Inkonsistenzen gibt in den Prozessen und Praktiken zwischen den Teams. So, jetzt denkt man im ersten Moment ja Moment mal Scrum zum Beispiel ist ja ein Rahmenwerk, das darf doch jedes Team extra irgendwie ausfüllen, so wie das es gerne hätte. Das ist damit nicht gemeint an der Stelle, sondern – vielleicht hast du das auch schon mal erlebt.

Kai:

Wenn es dann so richtig durchstartet und die Leute in die Selbstverantwortung kommen, dann haben die auch einen ziemlichen Drive drauf. Und bei einem unserer Kunden war das mal so, dass diese Teams so schnell geworden sind, dass die Product Owner gar nicht hinterher kamen, die Backlogs zu füllen. Also die sind ständig leer gelaufen, weil das Team einfach schneller war als alles drumherum. Und das ist dann eben so eine Inkonsistenz zwischen den Vorgehensweisen. Wenn du so ein Speed Boot, dann hast, um mal in so einer Bild-Metapher zu sprechen und das hat aber noch ein paar Taue zu dem Tanker, der die Restorganisation ist, dann ist das natürlich schwierig.

Kai:

Stichwort Abhängigkeiten irgendwie erfolgreich zu sein mit Agilität oder du hast einen großen klassischen Projekt Überbau, dann hast du da drin irgendwie ein kleines agiles Team – das funktioniert ziemlich schlecht. Deswegen ist das so Top 1 Grund, warum Agilität nicht gut funktioniert in Unternehmen. Und jetzt ist natürlich die Frage was kann man da machen?

Jasmine:

Das ist auch wenn du übergeordnet einen Riesen Wasserfall Prozess hast und da drin versuchst irgendwie Scrum zu machen oder da drin versuchst agil zu agieren,  das fühlt sich immer ein bisschen komisch an und das wird da auch nicht so ganz funktionieren. Und für mich kommt da der Scrum Master als Nummer 1 Person mit ins Spiel. Als Scrum Master haben wir einen Dienst an den  Entwicklern, einen Dienst an dem Product Owner, aber auch an der Organisation. Das heißt, sich da zusammen zu setzen, mit anderen Scrum Mastern zusammenzuschließen und zu gucken – Hey, wie können wir die Prozesse unser Gesamtorganisation ändern, damit auch die einzelnen Teams ihre Agilität voll leben können, ist unglaublich wichtig.

Jasmine:

Und da brauchen wir, glaube ich, ganz, ganz gute Turnschuhe, weil wir laufen da von einem Flur zum anderen. Also das ist wirklich auch so ein bisschen Klinkenputzen, ganz viele Gespräche suchen, gucken, wo finden sich Initiativen, wie wir gemeinsam diese großen riesen Abhängigkeis-Prozesse umgestalten können.

Kai:

Die entstehen manchmal auch daraus. Und darüber haben wir in der Folge über Skalierung auch schon mal gesprochen. Also Skalierung ist ja Agil mit mehreren Teams, dass man einfach sagt hey, ich habe 100 Leute, wie kann ich die agil organisieren? Das ist aber das ist falsche Frage, denn die Frage ist ja, wie viele Leute brauche ich denn, um das Produkt zu bauen? Und das sind vielleicht nur 13 von den 100 und. dann muss ich gar nicht so viel Abhängigkeiten managen, weil dann habe ich irgendwie ein Team, vielleicht zwei Teams, die das Produkt bauen und muss gar nicht so rückwärts denken.

Kai:

Denn das ist natürlich schon ein echtes Hindernis für agie Teams, wenn die harte Abhängigkeiten haben. Und da ist immer die Frage Wie kann ich die reduzieren? Also erst mal erkennen, managen, reduzieren, dass man da hin kommt, dass diese Teams beweglich sind und bleiben. Und da kann man sogar mal verstoßen gegen so Sachen wie – Ich habe beim Informatikstudium gelernt, irgendwie Redundanzen sind des Todes. Also eigentlich willst du gar nichts doppelt haben. Irgenwie, ein Quellcode und so weiter.

Kai:

Das führt natürlich dazu bei der technischen Lösung, dass du dann Sachen raus extrahierst irgendein Rahmen-Framework, dann hast auf einmal zack Abhängigkeiten drin und vielleicht willst du diese sogar zurückbauen. Also und das Thema ist aber so breit, dass wir an der Stelle auch jetzt nicht sagen können Pauschal macht das, sondern die Grundintention ist, Abhängigkeiten erst mal erkennen und dann zu versuchen zu reduzieren. Und dazu gibt es einfach viele, viele Strategien und das ist sehr kontextabhängig von deiner Umgebung, was genau da der nächste Schritt ist, um da weiterzukommen.

Jasmine:

Was mir an der Stelle immer hilft, ist wirklich den Kundenfokus herzustellen. Das ist für mich ein ein Grund-Ding der Agilität, dass wir einen radikalen Kunden Fokus herstellen und vom Kunden her denken um zu gucken was braucht denn der und wie müssen wir unsere Organisation aufstellen, damit unser Kunde möglichst den besten Mehrwert hat? Und da kommen wir vielleicht auch schon zum Zweiten Punkt, der sehr, sehr schwierig ist, wo Agilität oft scheitert, nämlich da, wo die Organisationskultur nicht passt mit den agilen Werten.

Jasmine:

Ich war schon mal unterwegs in einem Kontext, da hatte ich ständig diese Diskussion von „Ja, aber unser Kunde weiß ja gar nicht, was er will. Unser Kunde ist ja blöd. Unser Kunde ja, nee, wir wissen’s ja besser als der Kunde.“ Ja, das ist dann schwierig, weil das führt alles ad absurdum. Dann muss ich auch nicht regelmäßig und schnell liefern, weil wenn ich dem Kunden etwas zeige, regelmäßig und schnell und der sowieso nicht weiß, was er will und sowieso doof ist, dann wird er mir auch kein passendes Feedback geben.

Jasmine:

Das heißt, ich kann da gar nicht iterativ arbeiten. In so Kontexten wird Agilität sehr, sehr schwierig einzuführen sein. Oder wenn wir eben diesen radikalen Kunden Fokus nicht herstellen können, weil wir noch 300 Hierarchieebenen haben, die auch alle wichtig sind und vielleicht sogar wichtiger als unser Kunde.

Kai:

Das war auch ein Umfeld, das ich auch schon mal hatte ein hochpolitisches Unternehmen. Das war also so als wir mit Agilität dann losgelegt haben, hat man einfach sehr klar gesehen, dass so ein Produkt-Backlog nicht sortiert ist nach dem höchsten Wert für den Anwender, sondern nach politischem Gefallen innerhalb der Organisation. Und wenn das ein Entwicklungsteam dann sieht und spürt, dann fassen sich natürlich schon alles ein bisschen an den Kopf und denken so okay, aber das ist doch jetzt nicht Agile.

Kai:

Also wir wollten doch jetzt den idealen Wert liefern hier für unsere Anwender. Und das ist dann auch richtig schmerzhaft und macht den Leuten gar keinen Spaß, weil das natürlich auch irgendwie komplett gegen die Werte und Philosophie dahinter steht. Und was es da gebraucht hätte, wäre die Führungsperson, also der Sponsor, in dem Fall mehr mit Agilität zu konfrontieren. Ich gebe zu, da war ich noch relativ unerfahren, was Agile anging und habe da nicht die Führungskraft genug mitnehmen können in diese Richtung, um einfach diesen Dialog und das Sparring zu haben, weil die Führungsperson da ganz, ganz klar diese Organisationskultur auch mitgeprägt hat.

Kai:

Und ja, das ist vielleicht auch der Teil. Kultur ist natürlich eher so der Schatten der Organisation, die kann man nicht so direkt anpacken und sagen wir drehen jetzt die Kultur irgendwie anders. Aber man kann natürlich mit den Menschen arbeiten, die die Kultur ganz, ganz stark prägen. Und das hat eben auch viel mit dem Führungsverhalten zu tun, was in der Organisation okay ist, geahndet wird, nicht geahndet wird und auch den Märchen und Geschichten, die man sich erzählt von früheren Zeiten in der Organisation.

Jasmine:

Und was mir als Scrum Master da immer hilft, wenn ich in solche Situationen komme, in Umfelder dann reinkomme, ist nicht anfangen zu missionieren und zu sagen Kuck mal, das sind die Agile Values, die müssen wir jetzt leben, weil sonst wird das alles hier den Bach runtergehen, sondern wirklich zuerst mal zu analysieren und zu gucken was haben wir denn für eine Organisationskultur? Ist die eher kompetitiv oder ist die kollaborativ? Ist sie eher Zahlen, Daten, Fakten getrieben? Oder sind wir alle Gefühlsmenschen und so weiter?

Jasmine:

Da kann ich mal einfach reingehen um zu gucken wo stehen wir denn grade in unserer Organisationskultur? Und dann gucke ich mir die agilen Werte an und gucke – Und welcher Wert ist der einfachste zum Erreichen?

Kai:

Und das wird tatsächlich mit der Zeit auch einfacher. Stelle ich fest. Denn wenn man viel in so agilen Umfeldern arbeitet, dann merkt man, wenn das nicht passt, in dem System, wo man beauftragt wird oder auch wenn es dein eigenes Unternehmen ist, wenn du da mal in ein Nachbar-Team reingehen sollst oder so. Dann kriegst du vielleicht so einen Impuls und der heißt renn ja – also versuch irgendwie hier nichts zu machen, weil das passt kulturell irgendwie gar nicht da hin. Mit dem gesagt:

Kai:

Sowas wie Scrum ist natürlich auch ein Kulturwandler. Das heißt auch durch das Tun entstehen andere Werte. Und das ist eben auch dieser große Konfliktpunkt. Dann kommen nämlich die Scrum Werte Mut, Fokus, Offenheit, Commitment, Respekt. Einfach in den Kontrast zu denen, die bisher da sind. Und das kann eben passen oder auch nicht. Also insofern ist auch mit Scrum anfangen eine Möglichkeit, so eine Kultur zu wandeln. Aber da braucht es eben auch dann die Führung mit an Bord.

Kai:

Das funktioniert ja nicht nur im Team, dann eigentlich was zu machen.

Jasmine:

Ich hatte ein total spannendes Gespräch mit einem Teammitglied letztens, mit dem wir schon ein bisschen länger arbeiten mit dem Team mit der Abteilung arbeiten wir schon ein bisschen länger und dieses Teammitglied meinte „Ja, ich war jetzt gerade so in Terminen außerhalb von unserer Abteilung in so Community Runden und die haben da irgendwie alle gemeckert und gelästert und es war irgendwie eher trübe Stimmung. Und ich glaube noch vor einem Jahr hätte ich total verstanden, was die alle sagen und meinen. Und mit der neuen Erfahrung, die ich jetzt gemacht habe, habe ich mir nur so gedacht Jungs, hört auf zu meckern, kann man alles anders machen, kann man alles anders organisieren.“

Jasmine:

Und das ist das, wo ich immer denke, was am meisten hilft ist, wenn man so kleine Kultur Bubbles anfängt zu etablieren, weil die ganze gesamte Organisationskultur auf einmal zu verändern. Das werden wir nicht schaffen, das schaffen vor allem nur durchs Tun. Am Anfang ist meistens das Tun, die neue Beziehungserfahrung, die neue Arbeitserfahrung schaffen und dadurch wird sich die Kultur wandeln. Das werde ich nicht – zack – in der gesamten Organisation hinkriegen. Deswegen ist mein Gedanke ganz oft.

Jasmine:

Den habe ich bei Michael Sahota mir geholt :Lass uns Kultur Bubbles machen, lasst uns gucken, wie wir einzelne Kultur Bubbles machen können in der Organisation, weil die werden sich ausweiten und da drin neue Beziehungserfahrungen, neue Arbeitserfahrungen schaffen, damit wir da drinnen eine neue Kultur erschaffen können, die sich dann meistens auf das Recht des Unternehmens auswirken wird. Und am Anfang kann das sein, dass ich relativ hohe Steuern zahlen muss ins Rest des Unternehmens, weil ich eine andere Kultur erschaffe, mir da drin, weil ich eine neue Arbeitsweise habe.

Jasmine:

Und diese Steuern kann ich dann anfangen zu minimieren, um das mal so bildlich gesprochen zu haben. Und an der Stelle auch zu sagen: Wenn wir den Report angucken, der kommt ja jährlich, diese Komponente „Die Organisationskultur passt nicht zu den agilen Werten. Die war jetzt wirklich top top top of Hindernisse die ganze Zeit. Jetzt ist es schon an zweite Stelle gerückt, sprich: Es ist gar nicht mehr ganz so schlimm.

Kai:

Dann sind wir beim dritten Faktor, nämlich dass eine Organisation generell Widerstand hat gegen Veränderung. Das kennst du vielleicht auch persönlich. Also wenn man jetzt mal Organisation als einen Organismus nimmt und dich selbst als einen Organismus, wie viel Veränderung hast du schon probiert? Wie viel haben geklappt? Und ja, es gibt einfach Leute, die haben mehr Disziplin und Drive, um Veränderungen in ihr Leben reinzubringen. Und ich glaube, für alle ist es hart, wenn man – je nach Treiber, die man so hat für die Veränderung.

Kai:

Manchmal passieren schreckliche Dinge im Leben und man muss dann einfach und dann hat man vielleicht auch den Drive, das durchzuziehen und viele andere Sachen bleiben stecken bei dem frohen Neujahrswünsche, wo man dann denkt, das wäre doch toll, wenn wir das machen könnten und so ist das mit Organisationen nicht anders. Auch da gibt es die Fresszellen, die Killerzellen, die sehen – „Oh, ein Eindringling ist jemand Neues da – den müssen wir vernichten und ausstoßen.“ Und je nachdem, wie eine Organisation da drauf ist und die das eher gewöhnt ist, neue Ideen zu integrieren oder eben neue Ideen auszustoßen.

Kai:

Und da es halt nicht anders als andere Ideen, da ist es erst mal eine Idee und die wird dann eliminiert und rausgeschmissen.

Jasmine:

Und auch das darf eine Organisation üben. Also für mich geht das sehr, sehr stark  Hand in Hand mit: „Die Organisationskultur passt nicht zu den agilen Werten. Natürlich muss ich als Organisation oder darf ich es als Organisation üben, neue Ideen zu akzeptieren in einer komplexen Welt, wo ich nicht weiß, was ich nicht weiß. Da werden immer wieder neue Ideen kommen und diese neuen Ideen werden mir vielleicht nicht immer gefallen, weil Veränderung ist für uns Menschen echt „a bitch“. So mögen wir nicht so ganz so gerne, also auf jeden Fall ich nicht.

Jasmine:

Und ich glaube, ich bin schon ein Mensch, der eigentlich viel Veränderung erträgt, akzeptiert und auch selbst mit initiiert. Und trotzdem fühlt sich das halt immer mal wieder echt doof an. Und das fühlt sich für den Einzelnen doof an. Das fühlt sich dann für die Gruppe doof an. Es fühlt sich für das ganze Organisationssystem doof an. Sprich wir dürfen das an der Stelle lernen, Veränderung mit in unseren Alltag zu integrieren, zu akzeptieren und damit umgehen zu können.

Kai:

Und so ein bisschen der Lackmustest für dich ist, wenn du in Kontakt kommst mit dem System und da reiten jetzt mittlerweile auch viele Agilisten darauf rum. Das machen wir auch so: „Start with the Why“ – Wieso überhaupt Agilität? Denn das ist ja auch irgendwie ein Mittel zum Zweck, hätte ich fast gesagt. Auch wenn es natürlich auch eine Haltung ist, also mehr als nur ein Mittel. Aber es braucht einen Treiber dafür und da kann man halt andocken bei ich sag mal klassisch Freud, Schmerzvermeidung oder Lustgewinn auch für die Organisation und die Leute, die das entsprechend beauftragen und das dann erst mal rauszufinden, um zu gucken „Gibt es hier irgendeine Kraft?

Kai:

Eine Welle, auf der wir so eine Veränderung mit rein tragen können?“ Das ist dann das, was wir ganz, ganz viel tun am Anfang, in der Auftragsklärung. Um das klar zu haben und nicht an dieser generellen Organisationsresistenz einfach abzuperlen.

Jasmine:

Oder wenn wir es mit Virginia Satir sagen, die sagt ja, Leute verändern sich dann, wenn der Schmerz der Veränderung kleiner ist als der Schmerz, den ich gerade ertrage, wo ich stehe. Es gibt auch andere Veränderungs-Theorien, die sagen wir verändern uns auch aus anderen Gründen, aber ich finde das ist immer so ein ganz guter Treiber, mit dem „Why“ zu starten. Was für ein Problem haben wir denn wirklich? Was wollen wir lösen mit Agilität? Und wenn es da keins gibt, dann wird unsere Agile Transition oder wie auch immer wir das nennen wollen wahrscheinlich scheitern.

Jasmine:

Der vierte Punkt auf den größten Hindernissen zum Weg von Agilität ist, dass die Leute zu wenig Skills und Erfahrung mit Agilität haben. Und das ist für mich immer so ein Punkt. Ich bin ja nicht der gute Verkäufer. Nicht unbedingt. Und das fühlt sich dann immer so ein bisschen an, als würde ich jetzt meine Coaching-Fähigkeiten verkaufen. Aber mir hat mal eine Kundin von mir gesagt: „Guck mal, Jasmine, wir haben, bevor du gekommen bist, Bücher gelesen.

Jasmine:

Wir haben unser Wissen aufgestockt. Wir haben Leute in Scrum Master Kurse geschickt. Wir haben alles getan an Wissen aufbauen, was wir konnten, damit wir dieses Agile Scrum Ding irgendwie meistern können. Aber niemand von uns hat das mal gefühlt gehabt vorher. Niemand von uns hat die Erfahrung gemacht, so müsste sich das anfühlen, wenn es mal fluppt oder – So könnte das irgendwie sein. Und dadurch konnten die das für sich gar nicht umsetzen. Weil alles, was wir ja neu lernen, setzen wir in den Referenzrahmen des Lernens, den wir schon jetzt haben.

Jasmine:

Und wenn wir da keine Erlebbarkeit drin haben als Mensch, dann wird das natürlich erheblich schwierig mit einem Buch oder auch mit einem zwei, drei Tage Scrum Master Kurs zurückzugehen und zu sagen: „Wir probieren das jetzt direkt aus.“ Da hilft es wirklich, einen Menschen an der Seite zu haben, der diese Erfahrung schon gemacht hat. Und das kann man auch verschiedene Methoden ja bewerkstelligen. Also man kann sich einen Coach reinholen, der einem oder die einen da begleitet. Ich kann aber auch einen Mitarbeiter von außen rein holen, der oder die schon viel Agilität erlebt hat und mithilft, das in unsere Firma rein zu tragen.

Jasmine:

Ich glaube einfach, wenn ich noch keine Referenz-Erfahrung dafür gemacht habe, wie sich das anfühlt, dann wird es echt schwierig.

Kai:

Fünfter Punkt: Nicht genug Leadership-Partizipation also nicht genug Teilnahme vom Management an dieser ganzen Geschichte, dieses Agile. Wasch mich, aber mach mich nicht nass hier in der Abteilung. Also bitte probiert mal die Probleme meines Teams zu beheben. Das sind dann manchmal die Mandate, die wir bekommen. Wir sagen, dass das nicht immer so direkt aus dem Kopf raus, aber uns natürlich schon. Klar. Das heißt hier, wir müssen auch definitiv mit dem Management arbeiten und wir haben es beim letzten Kunden so ein bisschen übertrieben.

Kai:

Die haben dann gesagt, bitte geht jetzt mal endlich in die Teams, wir haben jetzt irgendwie 3-4 Wochen mit euch „Agile und warum? Und was ist das und wollt ihr das wirklich? Und so weiter. Und fangt doch mal endlich an mit dem Team zu arbeiten“. Weil wir eben ganz, ganz sicher sein wollen, dass die Leute das Mitgehen und dieses Mitgehen vom Management, dieses am eigenen Leib erfahren was das heißt und am besten selber vielleicht in einem Veränderungs-Team so zu arbeiten. Das ist wichtig, denn nur dann kann man auch wirklich mitbekommen.

Kai:

Was heißt das denn als Implikation für meine Teams, für meine Mitarbeiter? Wieso verhalten sie sich jetzt anders? Wieso brauchen die jetzt was anderes und wie lasse ich überhaupt die Kontrolle los, damit die in Selbstverantwortung kommen können?

Jasmine:

Weil es heißt ja dann auch für das Management und mit dem Management meine ich vom Vorstand über Geschäftsführung zu Abteilungsleiter, zu Teamleiter. Also ich meine da alle, ich muss lernen, anders zu führen. Dinge, die ich vorher getan habe, werde ich vielleicht nicht mehr tun. Und ich darf mir auch Gedanken darum machen, wie gehe ich mit dieser Veränderung um? Weil wenn ich vorher sehr, sehr stark fachlich geführt habe und auf einmal einfach nur noch Rahmen hinstelle und sage ja Fachlichkeit mache ich jetzt nicht mehr.

Jasmine:

Ich bin jetzt eine Agile Führungskraft, ich mache ja nur noch Rahmen, dann werden meine Mitarbeiter genauso lost sein, wie wenn ich weiter nur noch fachlich führe und da fest halte und denen eigentlich gar nicht die Freiheit zur Entfaltung gebe. Das heißt, wenn ich da anfange mit Agile oder mittendrin bin, mit Agile, wird das ein kontinuierlicher Prozess sein zu gucken was ist unser Führungsbild, was ist unsere Führungsparadigma und wie darf sich das auch wandeln mit dem Wandel der Teams?

Jasmine:

Und das ist so ein ganz, ganz wichtiger Punkt. Wenn Teams anfangen agil zu arbeiten, dann fangen die an, sich ständig zu hinterfragen, zu reflektieren und ihren eigenen Prozess zu verbessern. Sprich was heute gut war für die, wird in zwei Jahren nicht mehr gut für die sein und vielleicht schon in zwei Monaten nicht. Ich muss als Führungskraft da ja dann mit am Ball bleiben, mich selber hinterfragen und reflektieren und stetig gucken „Und wie darf ich jetzt als Führungskraft sein, damit ich meine Teams optimal unterstütze?“

Jasmine:

Das ist für mich so ein bisschen wie meine Mutterrolle. Also ich weiß, die von euch, die Kinder haben, vielleicht kennt ihr das – man hat immer wieder so Situationen, die sind anstrengend mit den Kindern. Dann denkt man so Boah, warum geht das jetzt nicht mehr? Warum ist es echt so anstrengend hier zu Hause und dann macht es irgendwann mal auf einmal klick und dann läuft’s. Und dann denkt man so, boah, jetzt ist wieder cool! Und die nächste anstrengende Situation, die ist dann einfach nur gleich ums Eck, weil das ja ein konstanter Wandel ist.

Jasmine:

Unsere Kinder wandeln sich konstant, die wachsen konstant und bei den Kindern sagen wir auch das ist völlig normal, die müssen sich ja entwickeln. Irgendwann mal, wenn wir da so erwachsen werden, ist das anscheinend nicht mehr normal, dass wir uns konstant entwickeln, sondern wir wollen, dass die Menschen gleich bleiben. Das ist ein bisschen paradox und widerspricht einfach dem agilen Gedanken. Wir werden uns als Mensch ständig wandeln und weiterentwickeln, als Team ständig wandeln und weiterentwickeln, als Organisation ständig wandeln und weiterentwickeln.

Jasmine:

Und entsprechend darf sich auch das Leadership, das Management auf allen Ebenen ständig wandeln und weiterentwickeln. Wir gehen weg von: „Was Hänschen nicht lernt, lernt Hans nimmermehr“ hin zu: „Was Hänschen nicht lernt, ist eine große Chance für Hans, später Fun zu haben.“

Kai:

Und ich glaube, damit haben wir den sechsten Punkt auch direkt mit erschlagen, nämlich unadäquate Management-Unterstützung und unadäquate Schirmherrschaft. Ja genau, also da muss jemand sein, der will das dann auch wirklich und er weiß auch, warum man das möchte und was das für Konsequenzen hat.

Jasmine:

Was wir ganz oft machen mit unseren Kunden. Also hier noch mal ein Tipp, wie das so funktionieren kann, ist, dass wir wirklich ganz konkret sagen: Okay, wenn wir hier mit einem agilen Vorhaben beginnen, dann bedeutet das für dieses Vorhaben, dass die Mitarbeiter da drin gewisse Freiheiten brauchen im Organisations-Kontext, den sie sonst vielleicht nicht hätten. Dafür brauchen wir die Schirmherrschaft. Dafür brauchen wir einen Menschen, der möglichst irgendwo hoch ist, damit wir Regeln brechen können, weil nur dann können wir als Organisation ja auch lernen.

Jasmine:

Welche Regeln hindern uns und welche Regeln sind gut für uns? Und das ist ein ganz großes Umlernen der Organisation: Wo fesseln wir uns selber oder wo tut uns der Rahmen auch gut? Und dieses Agile Vorhaben darf dann öfters einfach – das hat so ein bisschen Narrenfreiheit. Die dürfen tun und lassen –  nicht was sie wollen –  aber die dürfen sehr viel mehr tun und lassen als andere, dürfen viel mehr Regeln brechen, um genau das rauszufinden. Und es braucht ein großes Augenmerk drauf. Das braucht eine gute Schirmherrschaft drauf und das braucht ein ganz anderes Management-Paradigma dahinter.

Jasmine:

Der nächste Punkt ist unadäquates Training oder Wissen.

Kai:

Ohne ein gemeinsames Bild davon, was überhaupt Agilität ist und wie sich das anfühlt und das mal im geschützten Rahmen zu erleben ist das wirklich schwer, dann auch gemeinschaftlich Energie freizusetzen und in die gleiche Richtung zu gehen. Und ja, natürlich, das ist bei uns immer eine der ersten Maßnahmen, die wir machen, entsprechend ein Training durchzuführen – Scrum Trainings zum Beispiel – falls du dich da weiter vertiefen willst, wir haben auch letztens ein Buch drüber veröffentlicht.

Kai:

Das heißt auch Scrum Training. Und da geht es natürlich schon darum, auch mal das einmal gemeinschaftlich dieses Wissen aufzubauen und die ganzen agilen Mythen mal platt zu klopfen. Denn es gibt ja doch ganz viel mittlerweile dazu, was alles irgendwie Agile sein soll angeblich und was irgendwie Teile von Scrum sind und was man noch an Kanban reingedichtet hat und so weiter und so fort.

Jasmine:

Und wir haben festgestellt, dass es relativ viele Trainings auf dem Markt gibt, die einfach ein riesen Bild machen und das ist manchmal dann sehr, sehr schwierig und viele Trainings sind auch sehr sehr global und behandeln dann gar nicht das Problem, das wir in der Organisation gerade haben. Also ich bin ein totaler Fan von einem Grundlagen-Training, damit wir alle mit der gleichen Basis starten, damit wir eine gemeinsame Sprache sprechen, damit wir alle wissen wohin wir wollen und dann müssen wir und dürfen wir auf dem Weg immer wieder rausfinden.

Jasmine:

Und wo brauchen wir weiteres Wissen und das wird für jede Organisation anders sein. Also wenn ein Kunde auf mich zukommt und es kommen manchmal Kunden, die sagen wir brauchen jetzt hier ein ganzes Education-Konzept. Da kann ich sagen kann ich euch nicht bieten. Das wird für jedes Team bisschen anders sein. Es gibt Teams, wenn die wirklich Softwareentwicklung machen, die merken an einer gewissen Stelle relativ schnell: Oh Mist, wir wissen nicht, wie wir wirklich kontinuierlich integrieren.

Jasmine:

Wir haben zu wenig Ahnung von Testen, damit wir das guten Gewissens machen können. Wir brauchen da Training. Es gibt andere Organisationen, die merken: Wir sind sehr, sehr schwach auf der Brust, was dieses Product Ownership angeht. Wir haben da ganz wenig Ahnung von wie Produktmanagement wirklich geht. Die brauchen da mehr Unterstützung. Oder es gibt Organisationen, die haben diesen ganzen Komplex von menschlicher Arbeit. Wie arbeiten wir als Mensch gut Facilitation Skills, also diese ganze Scrum Master hin zu Agile Coach Geschichte nicht drauf etc.

Jasmine:

Da gibt es ganz, ganz viele Dinge und da können wir nicht so einen Kahlschlag machen. Die meisten agilen Teams, die ich kenne, brauchen irgendwann mal ein erhebliches Budget für Wissensaufbau und auch da darf man als Team wieder in die Kommunikation gehen. Was stimmt denn für uns und was passt für uns? Einige Leute lernen gut, indem sie ein Buch lesen und das anwenden. Andere wie Kai: machen super gerne Online-Kurse. Ich hasse Online-Kurse. Also andere Menschen wie ich gehen auf Konferenzen, trinken da ganz viel Kaffee mit Leuten und bekommen da ihr ganzes Wissen mit.

Jasmine:

Ich gehe auf Konferenzen ja selten in Vorträge rein außer ich halte ihn selber. Da muss ich da sein. Also es gibt so ganz unterschiedliche Lerntypen. Ich sauge mir das Lernen meistens aus Konversation raus. Open Spaces, das perfekte Format für mich zum Lernen. Da dürfen wir uns über das Thema unterhalten. Wie lernt jeder einzelne, was für Skills brauchen wir? Ich liebe es da eine Skill Matrix mit den Teams zu machen, was für Skills brauchen wir die nächsten sechs Monate und welche Lern Formate wenden wir wo an?

Jasmine:

Für wen? Damit wir diese Skills draufhaben?

Kai:

Dann sind wir beim Punkt Nummer 8, nämlich dass sich so traditionelle Entwicklungs-Methoden einfach rein gekrallt haben in die Organisation und da ganz lange geprägt haben, wie man eigentlich entwickelt. Zum Beispiel hatte ich mal ein Unternehmen, die haben auch physikalische Produkte gemacht im Kunststoff Bereich und die waren ganz lange so Stagegate Prozesse gewöhnt, wo es immer so Freigabe Punkte gab, wo es auch eine bestimmte Dokumentation brauchte und so weiter. Und wenn du jetzt damit Agil um die Ecke kommst, dann haben die halt in ihrem mentalen Modell immer gedacht: „Okay, das ist dann was für das machen wir von der Phase 1 bis 2, iterieren wir irgendwie drüber oder so“, aber diese Dinge sind so inkompatibel miteinander, dass das irgendwie gar nicht passt.

Kai:

Also vom Denkrahmen her. Und wenn es dann natürlich viele Menschen gibt, die das bisher gewöhnt waren und das auch nicht loslassen wollen, weil das einfach lange, lange Zeit einen Nutzen hatte oder auch noch kein Nutzen in der Veränderung erkannt worden ist, dann hält man daran fest, wie man das schon immer gemacht hat, weil das bisher natürlich auch der Weg des Erfolgs war.

Jasmine:

Was an der Stelle wiederum hilft, ist wirklich: Problem erkennen, Problem anerkennen, Problem entpersonalifizieren an den meisten Stellen. Wir sind sehr, sehr schnell dabei zu sagen: Ja, aber das ist ja nur der Hans, der nicht mitgehen möchte. Das ist ja nur der hmhmhm, wenn der nicht wäre, dann und so weiter. Also wirklich das Problem entpersonalifizieren und zu gucken: okay, wenn wir so sehr anhaften an irgendwas, dann muss es uns ja auch was geben.

Jasmine:

Eine Sicherheit, irgendein positiverr Benefit muss für uns irgendwann mal dagewesen sein oder ist immer noch da und dann können wir gucken: Und was wäre denn jetzt noch besser? Was gäbe uns noch mehr positiven Benefit? Wir werden uns nicht verändern des Veränderung Willens, sondern die meisten Menschen verändern sich und auch die Systeme verändern sich, weil sie den Drang dazu haben, weil da hinten was besseres wartet. Und dieses Bessere unglaublich gut zu formulieren hilft dann – vorheriger Punkt Wissen rein zu holen, wenn mir denn Wissen fehlt oder eine neue Gewohnheit etablieren, die uns hilft diese neue Entwicklungs-Methode umzusetzen.

Kai:

Eine ganz pragmatische Variante, damit umzugehen mit traditionellen Umfeldern in der Produktentwicklung war für mich auch immer selber Vorreiter zu sein. Also als ich meinem ersten Team Agilität eingeführt habe, habe ich mich selber als Entwickler reingekniet in so Praktiken wie Testgetriebene Entwicklung oder Behavior Driven Development. Und habe da einfach den Vorreiter gemacht und habe die anderen dazu als quasi von innen heraus Teammitglied dazu ermuntert, doch mehr da rein zu investieren in Agile Softwareentwicklung und das Extreme Programming. Diese Techniken, die dahinter stehen.

Kai:

Und wenn man da jemand Gutes finden kann, den man in sein Team reinstafft, dann hat das auch direkt einen Einfluss auf das Team, was dieses Team tut, was das investiert. Also von innen heraus das mitzugestalten durch einen geschickten Recruiting Prozess hätte ich fast gesagt. Das macht auch sehr sehr viel Sinn, wenn man das kann und keine Fähigkeit im Team hat, weil einfach alle gewöhnt sind anders zu arbeiten.

Kai:

So der neunte Punkt, ein fehlendes Geschäftsmodell dahinter oder auch kein Zugriff auf die Kunden oder kein klar umrissenes Produkt.

Kai:

Das klingt ja erst mal total, als ob das wenig Firmen betreffen würde. Aus der Praxis heraus habe ich aber schon den Eindruck, was wir an Visions-Workshops gemacht haben mit Leuten und Visions-Formate irgendwie erklärt und reingebracht, um überhaupt mal zu klären: Was ist denn das Produkt? Was ist denn der Mehrwert dieses Produkts? Was ist das Abgrenzungsmerkmal? Kann ich das schon nachvollziehen, auch der ominöse Kunde, der dann doch teilweise relativ weit weg ist. Also in den letzten Mandaten hatten wir ja bisher Glück.

Kai:

Da konnten wir tatsächlich die Anwender, die das Produkt nutzen, immer wieder in die Sprint Reviews reinholen. Dass da wirklich auch das Entwicklungsteam lernt, was sie an Assumptions, was sie an Hypothesen im Kopf hatten und was davon passt oder nicht.

Jasmine:

Und ich würde sagen, wir hatten kein Glück. Wir haben mittlerweile die Erfahrung gemacht, dass das möglich ist. Und wir sind sehr, sehr, sehr persistent darin, Leute zu nerven, herauszufinden, wie wir das möglich machen. Und bei 100 Prozent – allen Kunden kriegen wir erst mal die Rückmeldung: Das ist bei uns nicht möglich. Immer. Also wenn du da bist und denkst, bei uns ist das aber nicht möglich. Es ist möglich. Also außer du machst

Jasmine:

eine Software für Insolvenz Betreibungen, dass vielleicht der Mensch, der betrieben wird, jetzt nicht unbedingt in deinem Sprint-Review drin ist und gut gelaunt Feedback gibt. Ja, okay.

Kai:

Na gut, du kannst einen Kreis von Insolvenzverwaltern fragen. Also irgendein Feedbackgeber gibt es immer der deine Assumptions irgendwie herausfordern kann.

Jasmine:

Aber an der Stelle, was für die meisten echt echt schwierig ist, ist rauszufinden wer ist wirklich unser Kunde und was ist wirklich unser Produkt? Weil wir unsere Firmen so extrem verzettelt aufgebaut haben und so extrem in die Spezialisierung gegangen sind, dass wir oft einfach unglaublich weit weg sind und nur ein Mini Teilschritt von einem Produkt machen. Sprich wenn wir dann in eine Agile Arbeitsweise gehen, muss uns bewusst sein, dass das bedeutet, dass wir die gesamte Organisation umbauen, nämlich an unserem Kundenstrom entlang.

Jasmine:

Wenn wir das nicht tun. Dann fühlt sich Agilität, also insbesondere Scrum echt dröge an, weil wenn mein Kunde für mein Produkt einfach nur die nächste Abteilung ist oder das nächste Team, dann habe ich kein Produkt. Und das sind so die Gedanken, die wir mit Kunden dann ganz oft machen. Wofür werden wir bezahlt? Wofür kriegst du Kohle? Und dann an dem Punkt anzufangen, also ganz hinten anzufangen, wofür kriegen wir Kohle? Und was ist denn genau das Produkt dann?

Jasmine:

Und das kann sein, dass das mehrere Teams betrifft. Es kann sein, dass das ein Team betrifft, aber da braucht es oft relativ viel Analyse. Und dann auch der Gedanke „Und wie bauen wir jetzt die gesamte Organisation um, damit wir an diesem Wertestrom sind?“

Kai:

Also was kannst du konkret tun: die Menschen, die Kunden reinholen in das Sprint Review, dafür Sorge tragen, dass diese Feedback Schleife geschlossen ist und dafür Sorge tragen, dass das Produkt definiert ist. Dass jemand mal in einem Elevator Pitch sagen kann im Aufzug in 30 Sekunden:  Wir bauen dieses Produkt und das hat diesen Nutzen. Und das ist anders als das andere am Markt, was es auch noch gibt.

Jasmine:

Der letzte Punkt auf unserer Liste für heute ist die fehlende Bereitschaft, Fehler zuzugeben und aus Fehlern aus der Auslieferung zu lernen. Ich habe hier letztens ein Mitglied aus einem größeren Team von einem Kunden von uns so gefeiert, als dieses Mitglied in einem Event gesagt hat: „Leute, ich glaube wir sind viel zu Sicherheitsbedacht hier unterwegs. Wir machen gerade viel zu wenig Fehler.“ Und das fand ich so cool, weil dieses Mitglied einfach meinte: „Hey, wir müssen noch mehr Risiken eingehen, dann kommen wir noch näher an das Kundenbedürfnis ran.

Jasmine:

Und ja, das kann heißen, dass es mal irgendwie kacke läuft. Oder dass wir einen Fehler machen. Aber dann lernen wir daraus, weil Fehler sind Gold wert.“

Kai:

„Wir machen Fehler schneller als alle anderen“ – war mal so ein Leitmotto, ich weiß leider nicht mehr, von welchem Manager, ich müsste das jetzt mal googeln. Aber diese Haltung dahinter. Also „fail early“ und dann aber auch daraus zu lernen – es geht natürlich nicht darum, also der Fehler macht ja keine Freude. Der Fehler ist einfach nur ein Schritt, um mehr zu erkennen, was der Markt will und was die Kunden brauchen. Und deswegen brauchen wir das um uns da ran zu tasten.

Kai:

So ein bisschen wie Autofahren im Nebel. Man fährt immer so ein Stückchen, dann guckt man irgendwie, wo ist da die Kante. Und das will ich mit meinem Produkt auch machen. Das tun ja Startups die ganze Zeit, die pivotieren, die gucken, wo kann ich mich am Markt irgendwie etablieren? Was wird gefragt, was wird gebraucht? Und um da reinzukommen, brauche ich einfach regelmäßig Fehler. Ich fahre ein Stück weit gegen eine Wand oder mit dem Reifen so ein bisschen ab von der Spur und muss dann wieder korrigieren, um entsprechend der Straße weiter folgen zu können, wo ich eigentlich hin möchte.

Jasmine:

Und das braucht natürlich in der gesamten Organisation ein Umdenken, was die Fehlerkultur angeht. Und viele sagen ja dann schon:  „Ne, das ist keine Fehlerkultur, es ist eine Lernkultur. Ja, natürlich ist es eine Lernkultur, aber wenn ich gerade in einer sehr Sicherheitsbedachten Kultur unterwegs bin, dann ist Fehler machen einfach per se mal eine riesen riesen Gefahr. Auch einfach für mein Gehirn. Das ist nicht so einfach das umzudenken und da werden auch „Fuck up Nights“ jetzt nicht helfen, weil was passiert an „Fuck up Nights“ ganz schnell ist:

Jasmine:

Irgendjemand stellt sich auf die Bühne, sagt ich habe hier Scheiße gemacht, aber jetzt bin ich der Held. Das ist dann irgendwie diese Sicherheitskultur nochmal  untermauern. Was ich da gerne mache, ist wirklich im Kleinen anzufangen, im Team anzufangen. Gucken, dass wir Fehler da sicher machen können, die psychologische Sicherheit extrem zu erhöhen. Und wie schon gesagt in der Folge zu Psychologische Sicherheit:  Das kann ich nicht über das ganze Organisation  und Unternehmen machen, sondern das ist ein Team Konstrukt.

Jasmine:

Das muss jedes Team für sich selber machen. Und da zu gucken: „Hey, wie können wir es sicher machen Fehler zu machen und daraus zu lernen?“ Weil das ist der zweite Schritt. Es geht nicht darum Fehler zu machen, einen Schuldigen zu suchen, sondern Fehler zu machen und zu gucken wie können wir gemeinsam lernen. Und das braucht ganz oft sehr, sehr viel Diskurs, sehr viel Diskussion und auch wieder sehr viele Iterationen drüber: Wie ist denn das für uns?

Kai:

Wenn man einen Fehler gemacht hat, dann ist man in seinem Team auch meistens mit Schuld beladen, also man selber es ist einem ja unangenehm. Es ist peinlich. Man will das nicht machen. Da hilft das natürlich nicht auf den drauf zu picken, der jetzt einen Fehler gemacht hat. Der weiß ja eh schon, dem geht es eh schon schlecht und dem tut es eh schon leid. Deswegen gibt es einen kleinen Kulturhack für Teams, den finde ich ganz nett, das mache ich auch öfters mal ein „Failure Bow“, das ist so aus dem Künstlerischen stammend, einfach so eine kurze Verbeugung.

Kai:

„So, ich habe verkackt.“ Und das nimmt einem diesen sozialen Druck des Fehlers weg und dann kann man wieder weiterarbeiten, dann kann man auch gucken, wie kann ich das System so optimieren, dass weniger dieser Fehler passieren? Denn das ist ja der andere Blick, den wir immer wieder haben. „A bad system will beat a good person every time“, hat Deming ja gesagt. Also wie kann ich das System so verändern, dass die Einzelperson weniger in diese Fettnäpfchen rein tritt?

Jasmine:

Und damit sind wir am Ende der 10 Top Gründe, warum Agile schiefgehen kann. Wir hoffen, du hast ganz, ganz viel Spaß mit dieser Folge gehabt. Wir freuen uns unglaublich auf Feedback auf dem Twitter-Kanal und wir freuen uns auch über eine gute Sternchen Bewertung

Kai:

Und wir hören uns ganz bald wieder im Agile Growth Podcast – übrigens Agilität hat auch noch mal einen ganz schönen Aufschwung gekriegt über diese Corona-Zeit habe ich letztens eine Statistik gelesen. Es gibt deutlich mehr Organisationen, die auf Agilität jetzt setzen.

Kai:

Insofern spannende Zeiten in der Welt. Alles bewegt sich ein bisschen schneller. Wir hoffen, dass das bei dir natürlich nicht scheitert, die Agilität, sondern du aus dem Podcast auch mitnehmen kannst, was du tun kannst, damit das bei euch funktioniert. In diesem Sinne bis zum zum nächsten Mal. Wir freuen uns.

Veröffentlicht am

Die Rolle des Managers in Agile

Tobias „Toby“ Baier ist ein leidenschaftlicher Verfechter der kontinuierlichen Verbesserung. Leistungsstarke Teams müssen in der Lage sein, sich schnell an Learnings und veränderte Rahmenbedingungen anzupassen. Den höchsten Wert für Kunden zu liefern, muss nachhaltig sein.

 

Der #AgileGrowthCast ist ein tiefgehendes Interview, dass immer den Anspruch hat, zu inspirieren und mindestens eine spannende hilfreiche Methode oder Idee für Dich als Agilist zu vermitteln. Nimm Freitags um 11:00 Uhr live auf Youtube und LinkedIn an ihm teil und stell uns & unseren Gästen Deine Fragen!

Kai: Herzlich willkommen zum Agile Growth Cast. In unserem wöchentlichen Live-Interview welches wir auf YouTube und LinkedIn führen,

findest du immer spannende Interview Gäste rundum das Thema Agilität. Viel Spaß beim zuhören wenn du das Bild zum Gespräch sehen möchtest findest du auf agilegrowth.de,

und auf unserem YouTube Kanal die entsprechenden Videos,

 

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

 

Kai: Herzlich willkommen beim Agile Growth Cast, schön dass du wieder mit dabei bist und ja

wir sind wieder hier diesmal heute stehen wir mal zur Abwechslung , wir haben unser Studio bisschen umgebaut weil wir gemerkt haben

wir sitzen eh schon die ganze Zeit irgendwie vom Rechner ich weiß nicht wie das hier so gerade geht , jetzt ist mal Zeit ein bisschen was fürn Rücken zu tun hier und ein bisschen mehr Energie vielleicht auch noch in diese Show rein zu bringen damit du hier auch die Sachen mitnehmen kannst die dich interessieren als Agilist und wir haben heute wieder einen unglaublich spannenden Gast da.

 

Jasmine: Genau viele von euch werden die Stimme wahrscheinlich erkennen aus dem YouTube Video Product Owner in a nutshell zumindest ich habe dieses Video schon so oft gesehen weil da sind so viele tolle spannende messages drin auf einer sehr kurzen Zeit ich kuck den auch immer wieder mit Kunden an.

Das ist echt eine eine Perle und unser Gast hat auch ein Podcast nämlich den Einschlaf Podcast.

Nicht sehr agil aber auch super spannend zum ankucken und wir haben im Vorgespräch ein bisschen mit Toby gesprochen und dann meint er ihr habt ja immer so Hardcore Agilisten jetzt bei euch ich weiß doch gar nicht so richtig,

was ich denn so zu diesem zu diesem Format jetzt beitragen kann weil ich sehe mich ja gar nicht so richtig als Agilist,

und ich habe gesagt das ist umso spannender weil Toby ist einer der Menschen der sein Dogfood auf täglicher Basis auch wirklich ist,

also wir als Berater gehen ja oft rein unterstützen helfen begleiten, aber wir sind dann auch mal wieder raus.

Toby ist in der Firma drin angestellt und gestaltet da die Systeme und da möchten wir gerne mit euch ganz tief rein gehen,

wie ist denn das so wenn man eine Firma auch vielleicht auf einer anderen Position als als agiler Coach begleitet.

Ich freue mich total, ganz ganz herzliches willkommen an Toby Baier.

 

Toby: Hallo, moin moin.

 

Kai: Schön, dass du da bist, schön dass wir uns mal wieder sehen ich glaube das ist das muss Jahre her sein ich vielleicht habe ich auch zwischendurch schon Konferenz Blackout gehabt.

Dass wir uns zum letzten Mal irgendwie nebeneinander vielleicht auf ner Couch bei Retrospective Facilitating Gathering, dieser ganz kleinen,

Zusammenkunft von Menschen die für Retrospektiven brennen getroffen haben oder haben wir uns zwischendurch noch mal gesehen ich hatte einfach so ein kleines Loch in meiner Hirnrinde.

 

Toby: Nee haben wir nicht, kennen gelernt haben uns tatsächlich auch beim Retrospective Facilitating Gathering in Portugal.

Das war 2016 glaube ich und ich weiß nicht ob ihr 2017 in den USA dabei war ich glaube nicht oder

 

Jasmine: Nee, wir waren dann noch mal in Holland und ich weiß nicht ob du in Holland warst, doch du warst in Holland oder

Toby: Ja, das war dann 2018, 2019 war ich dann leider nicht dabei.

und RFG ist dann tatsächlich eine der wenigen agilen Konferenzen ist es überhaupt ne Konferen, ich weiß gar nicht an der ich regelmäßig teilgenommen habe und auch gerne wieder teilnehmen werde wenn es sich dann wieder anbietet und wenn es wieder geht.

Ansonsten bin ich gar nicht so viel auf Konferenzen wie du gesagt hast ich sehe mich durchaus als Agilisten aber nicht so als.

Als Lichtgestalt Voran-Prescher und weiß nicht, Promoter.

Hatte ich durchaus mal die Idee dass das werden zu wollen und werden zu können deswegen habe ich auch dieses wunderbare Video von Henrik Nieberg Product Owner in a nutshell synchronisiert, es ist ja nur meine Stimme die Worte und das ganze Video sind ja von Henrik. Ja deswegen freue ich mich immer wenn ich da mal reinluschern darf, in diese Community

Aber so richtig Teil davon habe ich mich nie gefühlt,

 

 

Jasmine: Wenn du es so beschreiben könntest wer ist denn Toby?

 

Toby: Gute Frage also ich erkläre meinen meine agilen Werdegang immer ganz gerne auch mit meinem mit meinem Lebenslauf also ich habe an der Uni Hamburg studiert ich bin ja so einem Nordlicht, ne, ich bin ja südlich von Hamburg aufgewachsen ich habe dann in Hamburg studiert hab 11 Jahre in Hamburg gelebt und bin dann jetzt wieder raus gezogen,

auf das Dorf zwei Dörfer weiter als da wo ich aufgewachsen bin sozusagen und arbeite aber weiter in Hamburg und ich habe auch nirgendwo niemals

woanders gearbeitet, ich bin hier sehr verwurzelt.

Nicht großartig rumgekommen sozusagen, aber auch nie ein Auslandsjahr gemacht nach meinem Studium habe ich noch einen Doktortitel drangehängt das war,

auch in Hamburg, Überraschung und nach dem Doktortitel habe ich dann angefangen Hamburg zu arbeiten zuerst als Softwareentwickler.

In einem Content Management Unternehmen Comedia habe ich sechs Jahre lang gearbeitet als Programmierer, ich habe da auch schon paar andere Rollen übernommen als Projektleiter und hab da schon gemerkt so hm,

Programmierung selbst da bin ich halt einfach nicht der beste, in  der Firma arbeiten einfach fantastische Programmierer und immer ganz viel Ehrfurcht davor gehabt die tolle,

Architekturen da rausfallen und unternimm was die da alles auf die Beine stellen deswegen hab ich mich da halt angefangen um zu orientieren.

Das dort war auch obwohl ichs an der Uni Hamburg schon mitbekommen habe da waren dann ja auch so Leute wie.

Ja Stefan und und und andere die jetzt bei IT (unverständlich) arbeiten und,

und die damals das agile manifest mit ins Deutsche übersetzt haben und so da hatte ich dadurch auch schon mal irgendwie das gesehen aber noch keinen

 echten Kontakt in meiner ersten Firma hatte ich dann im ersten Kontakt da haben wir dann das erste Mal eine agile Schulung bekommen und ich war halt gleich begeistert, genau geil, das ist das richtige Ding, Product Owner,

die Rolle hat mich von Anfang an fasziniert und habe ich gesagt okay,

ich möchte Product Owner werden, wo kann ich das denn, und    innerhalb der Firma konnte ichs leider nicht und dann bin ich zu XING gewechselt, war da zwei Jahre lang Product Owner für den Gruppenbereich super spannende Erfahrung, ich hab da fantastsisch viel lernen können.

Hab die gleiche Rolle dann noch mal bei einer weiteren Firma gehabt bevor ich dann zu Adobe gewechselt bin jetzt arbeite ich seit sechseinhalb Jahren bei Adobe,

war dort erst Agile Coach,

allerdings interner Agile Coach und nicht als externer dazugeheuert habe dort die Aufgabe bekommen einer Gruppe zu helfen sich in Agilität

zu steigern da ging es vor allem um Selbstorganisation da ging’s um organischen anorganisches Wachstum.

Und es ging halt darum dass es eine Gruppe war aus Entwicklern und Product Ownern

bin in einer internen Gruppe, es gab gar keine Scrummastern es gab gar keine Agile Coaches , es gab so ein paar Projektleiter die durchaus mal eine Retrospektive angeboten haben aber,

am das war’s dann so am da habe ich da habe ich dann geholfen bisschen mehr Agilität reinzubringen ja genau und das war,

das war dann mein Einstieg quasi ins Agile Coaching ich bin aber in der gleichen Gruppe auch wieder ausgestiegen nach dreieinhalb Jahren ergab sich dann da die Möglichkeit noch mal sich weiterzuentwickeln da war dann eine Stelle als Engineering Manager offen, und habe ich gedacht okay jetzt war ich Entwickler, jetzt war ich Product Manager jetzt war ich Agile Coach,  jetzt fehlt ja eigentlich noch die Perspektive als Engineering Manager und das mache ich jetzt seidem,

und ich habe noch einmal die Gruppe gewechselt innerhalb der Firma und ich bin jetzt in der Lightroom Gruppe und bin Engineering Manager für die iOS Lightroom Entwicklung.

 

Jasmine: Cool, das nutze ich sogar ab und zu

 

Toby: Ja sehr gut.

 

Ich glaube diese Geschichte erklärt so ein bisschen dann deine Frage wer bin ich dann eigentlich wie seh ich mich denn eigentlich.

Ich sehe mich als jemanden der halt versucht möglich viele Perspektiven einzunehmen und möglichst aus vielen verschiedenen Perspektiven auf das System zu schauen und drauf einzuwirken, ich arbeite sehr sehr gerne

am System, ich arbeite auch gerne im System aber dieses Arbeiten am System wie können wir noch besser werden.

Das hat mich hat mich immer sehr fasziniert und bringt mir sehr viel Spaß.

 

Kai: Das wäre auch eine Facette die ich unglaublich gerne mal vertiefen würde dann,

Ich habe den Eindruck wir hatten jetzt einige ScrumMaster und Agile Coaches schon hier der eine und der andere die aus der Product Owner Brille drauf geschaut hat.

Aber wenn ich mich so ein bisschen zurück erinnere vielleicht so vor der Zeit von Management 3.0 also als das erste größere bekannte Werk überhaupt dazu rauskam,

dass es überhaupt noch Führung und Management braucht in der agilen Welt oder fällt doch Boris Gloger mit Selbstorganisation braucht Führung, da sind ja so ein paar Werke entstanden, die auch dem Management diese Angst  genommen haben dass sie vielleicht jetzt überflüssig werden würden und auf der anderen Seite so das Wissen dass,

Scrum Teams vielleicht aber auch in sich genug sind im bezug auf es gibt es produktorientierte Führung es gibt eine

KVP Führung oder Prozessführung, Scrum-master uns gibt eben das leadership auf seiner technischen Feasibility-Ebene innerhalb des Teams wo sich natürlich schon die Frage aufdrängt was macht denn jetzt MANAGEMENT,

und da würde mich total interessieren was macht denn jetzt MANAGEMENT in einem agilen Umfeld oder was ist so dein

Day Job oder wie weit hast du da Kontakte zur Strategie wie weit beeinflusst du das, du sagst am System arbeiten wie tut man das ohne den Leuten jetzt in ihre Selbstorganisation reinzulatschen, ich glaube das beschäftigt viel im Moment

 

Jasmine: Ich machte dein Lachen gerade.

 

Toby: Ich habe grad ganz kurz überlegt ob ich antworten soll, ach wir legen einfach die Füße hoch und gucken zu nein,

das ist es natürlich nicht ich dachte dass er schon gewechselt bin ist dass ich.

Eine Analogie die ich gefunden hatte als ich ins Engineering Management gewechselt bin ist, dass ich als Agile Coach den Teams zur Seite stand um ihren Weg in die Selbstorganisation besser zu bereiten als Agile Coach hilft man Teams zu erkennen welche Möglichkeiten Sie haben ihre eigenen Abläufe zu verbessern,

Selbstorganisation bedeutet ja auch nicht alleine lassen und dass sie alles alleine machen müssen sondern zur Selbstorganisation eines Teams gehört ja auch dass ich das Team die Hilfe holt die Sie braucht und die Ansprüche stellt,

die sie haben um die bestmöglichen Rahmenbedingungen zu schaffen in denen sie dann arbeiten können.

 Das ist eine Sache die ich auch häufig schon gesehen habe, Selbstorganisation, das bedeutet doch man braucht keine Manager mehr oder überhaupt Leute die irgendwas anderes organisieren das ist natürlich Quatsch,

sondern Selbstorganisation für Teams bedeutet dass das Team entscheidet welche Unterstützung sie dann eigentlich brauchen.

 

Jasmine: Das find ich so schön.

 

Toby:

Dass er das ist eine wahnsinnig schwierige Aufgabe, Selbstorganisation ist nicht leicht dadurch, überhaupt nicht, deswegen braucht es Agile Coaches die den Teams quasi das Aufzeigen zu sagen ja wenn ihr hier immer gegen sie Wand rennt, welche Wand das auch immer ist,

uns fehlt Hardware uns fehlt hier Support, uns fehlt da ne Kommunikationslinie, und so weiter und so fort,

na dann ist das nichts was ihr unbedingt alleine lösen müssen dann können Sie sagen hier Manager kümmer dich mal drum dass diese Kommunikationslinie aufgebaut wird oder kümmer dich mal drum Hardware zu bestellen,

oder kümmer dich drum dass wir Budget haben, dass wir selber Hardware bestellen können, so das ist absolut legitim und das ist kein Widerspruch zur Selbstorganisation wenn selbstorganisierte Teams sich,

Hilfe holen und die Analogie dich dann im Engineering Management für mich entdeckt habe ist, dass ich als Agile Coach die Teams darin unterstützt habe das zu tun und diesen Weg zu finden und als Engineering Manager mein Fokus viel mehr auf den Individuen aber alle Individuen die in meinem Team sind sind ja in Teams.

So das heißt ich kann jetzt den Einzelnen helfen ihren Weg in diesem Team besser zu finden,

weil die einzelnen sind auch manchmal in der Situation wo sie denken ja gut ich habe ja eine Herausforderung aber wir müssen es ja als Team machen und wie kann ich denn jetzt in die innerhalb dieses Teams dafür sorgen dass dieser Weg eingeschlagen wird.

Das heißt da geht’s auch ganz viel um Enablement, um Unterstützung auch der einzelne im Team will ja nicht allein gelassen sein sondern braucht hier und da mal Unterstützung von außerhalb.

 

Und ich glaube an das hat sich bisher ganz gut funktioniert ich glaube aber auch das ist immer sehr auf die Rahmenbedingungen ankommt, also in was für einer Firma bin ich dann und in was für einem Team bin ich denn,

ich habe ja gesagt ich habe einmal innerhalb von Adobe das Team gewechselt und es ist erstaunlich ich meine Adobe, klar, ist ne Riesenfirma wir haben glaube ich 22.000 Mitarbeiter weltweit sehr sehr viele Entwicklungsstandorte, Adobe wächst ja  häufig auch mal durch Akquisitionen, auch der Hamburger Standort ist dazu gekommen durch eine Akquisition,

aber wenn dann das Produkt das da aquiriert worden ist dann vielleicht irgendwann mal woanders weiterentwickelt wird oder gar nicht mehr,

also GoLive, das Produkt was es damals mal gab um Webseiten zu erstellen, was in Hamburg entwickelt worden ist das gibt es nicht mehr,

das heißt der Hamburger Standort bleibt aber bestehen und da werden in andere Produkte weiterentwickelt.

Ja dann hat man halt weltweit verteilte Teams also ich arbeite täglich mit Leuten in den USA zusammen und das ist dann nicht nur am Hauptsitz in San José und in San Francisco sondern auch in Minnesota, auch in Seattle auch in New York.

Und in Bangalore, wir haben euch zwei große Standorte auch, in Indien in Bangalore und in Noida und das sind nicht etwa so Outsourcing oder oder Offshoring Geschichten die wir da machen mit irgendwelchen Auftragsarbeiten sondern das sind Adobe-Mitarbeiter so wie wir alle.

Festangestellte, die ja, es ist einfach egal

ob man jetzt in Indien sitzt oder in Bukarest oder in New York oder in Hamburg oder in San José.

 

Jasmine: Das ist super spannend ich hatte jetzt,

die letzte Zeit auch einen Auftrag bei einem Kunden den ich unterstütz habe wo wir genau das hatten also USA bis Indien ich fand das ja immer schon schwierig eine Zeitzone zu finden wo man alle mal ne Retro machen konnte,

also gefühlt für uns war das ganz okay es war dann immer meistens so 2 Uhr für die andere hieß das aber sie waren schon im Schlafanzug und für die anderen sie waren noch im Schlafanzug.

 

Toby: Kommt alle in euren Schlafanzügen.

 

Jasmine: Genau die Deutschen, zieht auch mal bitte n Schlafanzug an dann haben wir wenigstens Chancengleichheit.

Und was ich hat auch  super spannend fand, weil du auch gesagt hast es kommt noch drauf an in welchem Umfeld unterwegs bist.

Die kulturellen Unterschiede.

Am Anfang haben wir so versucht zu sagen wir sind alle gleich es gibt gar keine. Es gibt halt kulturelle Unterschiede und das ist fein.

Und sobald ich das irgendwie geschafft haben konnten wir teilweise auch zu unserem Vorteil nutzen.

Das fand ich so ganz spannend für uns aber wie gehst du damit um also mit dieser Spannbreite mit den Unterschieden wie schafft ihr da draus ein Team zu machen.

 

Toby: Sehr gute Frage.

Das ist ein kontinuierlicher Prozess also dieses alles über einen Kamm scheren und alle Leute sind gleich und alle Menschen sind gleich das ist ja auf vielen Ebenen ein Problem.

Und wir Mittel und Westeuropäer denken immer,

wir wären den Amerikanern ja so ähnlich weil wir deren Filme gucken deren Hosen tragen und die sehen uns ja so ähnlich tatsächlich,

habe ich festgestellt es gibt viele kulturelle Dinge wo ich meinen indischen Kollegen irgendwie näher bin als den amerikanischen Kollegen also es gibt Elemente in der amerikanischen Kultur mit den ich mich überhaupt nicht identifizieren kann, das Karriere denken z.b. ist in den USA ganz anders als in Europa und Indien und,

okay ich weiß es nicht ob ich das deutsche Karriere empfinden mit dem indischen vergleichen würde wahrscheinlich auch nicht so sehr aber es gibt halt deutliche kulturelle Unterschiede zwischen Deutschland und den USA die einem erst bewusst werden wenn man sich intensiver mit dem Thema beschäftigt nur weil wir immer Hollywood Filme gucken  sind wir noch lange nicht so drauf wie die Menschen dort.

 

Und da gibt’s ja nicht nur Amerika, es wäre ja genauso blöd zu sagen wie es gibt das Afrika obwohl Afrika ein riesen Kontinent mit ganz ganz vielen sehr unterschiedlichen Ländern ist,

viele meiner amerikanischen Kollegen sind aus San José oder San Francisco,

und die sagen immer ich bin Kalifornier weil denen das mit Trump so peinlich war,

ja also das ist das ist ein ständiger interessanter Austausch es ist total hilfreich sich dessen bewusst zu sein dass die Menschen eben unterschiedlich sind unterschiedliche Bedürfnisse haben und unterschiedliche Probleme,

im Moment haben wir so eine

natürlich durch die Corona Pandemie ganz ganz neue interessante Herausforderungen einerseits.

Finde ichs interessant zu sehen, dass

Also wir haben halt drei große Hochhäuser in San José stehen, jetzt wird grade ein viertes dazu gestellt und das ist unser Hauptsitz und da arbeiten die meisten Leute.

Und in San José passieren auch die wichtigsten Dinge da sitzen halt viele der Entscheider und.

Da ist es halt total hilfreich wenn man vor Ort ist und die Leute an der Kaffeemaschine trifft und im Meeting mit denen in einem Raum sitzt.

Und alle anderen also wir Deutschen und die Inder und die in Bukarest und in Paris und wo auch immer wir noch Standorte haben.

Die sind halt nicht regelmäßig da wir fliegen regelmäßig hin um halt Nähe zu erleben um auch mal näher dran zu sein um einfach bessere Meetings haben zu können aber natürlich sind die meisten Interaktionen mit den amerikanischen Kollegen,

Remote. So jetzt,

durch die Pandemie ist halt alles Remote und die Amerikaner lernen kennen wie es dann ist wenn man nicht ständig den Kollegen an der Kaffeemaschine treffen kann sondern in den Meetings sitzt da jeder zu Hause und es gibt nicht mehr den Raum wo alles passiert und ein paar sind Remote

Zugeschaltet,

sondern alle sind Remote, das ist ja auch ein Pattern in Teams also in agilen Retrospektiven, wenn jemand aus dem Team an der Retrospektive    teilnehmen möchte oder soll,

möchte oder soll aber nicht im Raum sein kann dann ist es besser wenn alle nicht im Raum sind von damit man so level-playing-field hat.

Das ist ein gutes Pattern für Retrospektiven und das ist jetzt ein Pattern was wir seit über einem Jahr also Adobe hat sich entschieden schon Anfang März noch bevor es in Deutschland sowas wie einen Lockdown gab

Oder eine Schulschließung seitdem sind wir alle im Homeoffice weltweit und.

Es gibt halt Überlegung wann könnt ihr wieder in die Büros in den USA jetzt da jetzt ein bisschen schneller weil die man impfen weiter sind aber da ist Adobe sehr sehr

Vorsichtig und und das empfinde ich als sehr gut ich meinte müssen nur jetzt tagesaktuel mal nach Indien schauen, unsere Mitarbeiter dort sind natürlich extrem betroffen,

die Coronazahlen in Indien gehen gerade leider durch die Decke es ist ne ganz furchtbare Situation.

Deswegen ist es gut dass die Firma sagt nein wir zwingen niemanden in ein Büro zu gehen, in anderen Firmen ist das ja anders.

Einerseits hilft diese Pandemie das wir alle auf der gleichen Seite sind andere Seite ist die Pfanne nehmen an der Minute ich eine riesen

Belastung und und diese Belastung ist ja sehr unterschiedlich in unterschiedlichen Ländern, nicht nur wegen der Inzidenz Lage sondern auch wegen des unterschiedlichen Umgangs mit der Pandemie in den verschiedenen Ländern also viele meiner amerikanischen,

Kollegen waren halt äußerst besorgt über den Umgang mit der Pandemie durch die vorherige Regierung die die hatten.

Letztes Jahr fühlten  wir uns in Deutschland noch halbwegs gut weil man den Eindruck hatte wir hätten die Pandemie einigermaßen im Griff,

das geht sich jetzt gerade so ein bisschen rum und aus Indien hört man nun diese schrecklichen Nachrichten.

Am Ende hatte das einen riesen Einfluss darauf wie wir wie wir arbeiten und was wir voneinander erwarten.

 

Jasmine: Das find ich auch total schön da auch die Emotionen zuzulassen die da sind also

 

Toby: Absolut und ich bin ich bin so dankbar an einer Firma zu arbeiten die darauf Rücksicht nimmt ganz im Gegenteil, unser LEADERSHIP Vice Präsidentin Maria Yap,

und alle die dort oben Entscheidung treffen sind extrem rücksichtsvoll und.

Gehen einfach ganz ganz wunderbar mit mit der Lage um, also es gibt es gibt ganz ganz, in meiner Wahrnehmung viel viel weniger Druck als das vorher gab, es gibt sehr viel Verständnis es gibt sehr viel Unterstützung wir haben alle drei Wochen also jetzt seit September glaube ich bis jetzt Mitte dieses Jahres gab’s alle drei Wochen einen global,

COVID-Holiday, wo einfach niemand arbeiten sollte, es gibt halt Feiertage wenn wir in Deutschland Feiertag haben

brauchen wir nichts arbeiten aber die Amis arbeiten ja, dann kommen ja trotzdem E-Mails das ist schön dann frei zu haben aber man muss es hinterher wieder aufholen oder währenddessen einfach arbeiten das ist

bei diesen globa verteilten Feiertagen immer schwierig, also hat die Firma gesagt komm, wir machen Global Holidays.

Alle sollen nicht arbeiten und das ist extrem hilfreich.

 

Kai: Wir haben jetzt ein bisschen Einblick bekommen in diese Manager Perspektive – ich glaube.

Es schaut auch hier der ein oder andere mal zu der sich überhaupt noch die Frage stellt dieses Agile Produktmanagement ist das eigentlich was für uns und ich glaube das ist eine Entscheidung die hast du ja dann schon sehr früh getroffen vielleicht hast du schon mehr Agile vergessen als die meisten gelernt haben.

Aber so von der von diesem gedanklichen Prozess, das scheint ja in dem Umfeld wo du bist ja natürlich zu sein so zu arbeiten.

Was ist das was eigentlich das inspirierende oder das antreibende ist,

wie kommt man zu einer Entscheidung agiles Produktmanagement machen zu wollen was sind so die Vorteile die du nach wie vor spürst oder vielleicht auch die Nachteile die du kennengelernt hast um da auch ein differenziertes Bild gerne zu geben.

In dem Rahmen von agilem Produktmanagement.

 

Toby: Was mich von Anfang an begeistert hat an agilen Vorgehensweisen.

Und und das noch mal vorweg, ich setze zwar häufig SCRUM ein und ich mache viel mit SCRUM ich finde Scrum aber komplett unwichtig eigentlich

also ja, Scrum ist manchmal hilfreich aber eigentlich nicht zentralen ich habe zu viele Situationen gesehen wo Leute Scrum eingesetzt haben aber nicht mal wussten, warum.

 

Was mich an an Agilität von Anfang an überzeugt hat ist dieses Eingeständnis oder dieses erkennen dass man eben nicht,

schon vorher weiß was man eigentlich braucht.

Also in der Produktentwicklung passieren häufig Dinge dass jemand meint okay wir wollen ein Produkt bauen und es soll dieses sein,

und jetzt erstelle ich einen ein Pflichtenheft oder Lastenheft und dann wird es runter programmiert.

Am Ende kommt die Qualitätssicherung und guckt drüber und dann ist es fertig und dann verkaufen wir es und diese Vorstellung dass man schon vorher weiß was man eigentlich braucht die ist halt komplett irrsinnig eigentlich also da spielen so ganz viele heroische Annahmen mit rein dass es Leute gibt die glauben es verstanden zu haben oder die glauben den den richtigen Plan zu haben.

Und in der Agilität sich halt dieses Eingeständnis nee wissen wir halt nicht also wir haben eine Idee,

ah jetzt geht’s immer darum diese Idee zu validieren herauszufinden ist das eigentlich richtige oder vielmehr noch die Frage zu stellen wie kann ich diese Idee am schnellsten invalidieren na weil sie ist ja bestimmt falsch, die meisten Ideen sind falsch nicht jeder hat täglich 20.000 Ideen, und die meisten sind falsch.

Es geht da drum, wie kann ich am schnellsten rausfinden welche Ideen eigentlich falsch sind und das hat mich von Anfang an begeistert also,

Da ging es dann relativ schnell habe ich dann auch die LEAN-Startup Szene kennengelernt Ash Maurya und soweiter,

Das hat mich dann als als Produktmanager geprägt dass ich halt irgendwie mit mit schnellen kleinen Experimenten versuche rauszufinden welches eigentlich richtige Weg ist und dann.

mit Anpassung meiner Pläne irgendwie möglichst möglich schnell zu einem Produkt zu kommen was dann halt wirklich erfolgreich sein kann.

 

Das hat sich halt  durchgezogen deswegen bin ich auch so ein großer Fan von RETROSPEKTIVEN dass man halt regelmäßig guckt ok welches nächste kleine Experiment möchte ich denn tun um unser Zusammenarbeiten zu verbessern.

Und danach schaue ich dann was hat denn dieses Experiment eigentlich gebracht hat uns nach vorne gemacht ja oder nein, denn die Maßnahmen die man in RETROSPEKTIVEN beschließt,

das sind ja auch keine Antworten das ist ja auch Versuche, wenn man das Experiment okay wahrscheinlich läufts besser wenn wir mal dass probieren aber man weiß ich ja vorher nicht.

Wir arbeiten an komplexen Systemen und es ist nicht vorhersagbar ob eine Maßnahme, die jemand in einer Retrospektive beschließt tatsächlich hilfreich ist oder nicht.

 

Jasmine: Ja ich finde zwei Sachen total spannend erstens dieses Plädoyer für Retrospektiven aus einer Produktsicht raus auch das höre ich sehr selten.

Gerade wenn ich Leute haben die neu da drin sind dann dann sind ja RETROSPEKTIVEN eher das was uns Zeit kostet.

Wir sind eineinhalb Stunden die wir investieren könnten in Coding. Warum machen wir denn das.

Ich habe das Gefühl das verstehen aber viele Leute relativ auch schnell dass das die uns helfen wenn wir denn RETROSPEKTIVEN gut genug machen und auch mit dieser Demut machen von.

Wir wissen es halt nicht als ich habe gerade überlegtm, ich wieder angefangen zu meditieren.

Und ich habe angefangen also was mir wirklich geholfen hat war mir jetzt zu sagen ich setze mich einmal am Tag auf dieses Kissen,

genauso wie ich mich einmal ein Tag auf die Yogamatte Stelle soll mir auch Jutta erzählt beim Retrospective Facilitating Gathering, das ist der beste Ratschlag ever, stell dich einmal am Tag auf die Yogamatte und guck halt was passiert, wenn du kein Yoga macht das auch fein.

 

Aber die Chance dass ich Yoga mache ist 80% also dadurch mache ich ja täglich Yoga dass ich das nicht täglich auf das Kissen setze,

fange an zu meditieren und mein erstes Experiment war halt ne stille Meditation bis ich gemerkt habe da komme ich nicht rein also mein Tag ist total gut mein Kopf plant dann meinen Tag ich habe doch eine To-Do-Liste danach gemacht so,

ist halt alles andere als meditieren und dann habe ich da angefangen auch irgendwie wieder meine Strategie zu ändern so okay was brauche ich denn jetzt habe ich angefangen mit Atemmeditation das ist schon mal viel besser also ihr Atem Übungen mache und danach noch eine Minute still sitze dann habe ich wenigstens minute wo mein Gehirn bissel weniger redet.

Und da immer kontinuierlich anzupassen ist und nicht so sagen ja ok meditieren und ich habe jetzt einen heiligen Gral und das braucht aber ich finde ich auch eine ganz große

Selbst Verzeihung da drin also mir selber zu verzeihen dass ich nicht immer die Antwort weiß und dann große Demut.

Und ich finde das fand ich so schön dass du diese Demut auch in der Produktdenke rein gebracht hast die meisten Ideen sind falsch.

 

Toby: Das ist als Programmierer so das ist im Team so,

das ist auch als Führungskraft so dass man diese Demut braucht, es gibt ein ganz tolles Buch Leadership Agility, ich habe den Autoren gerade nicht

 

Kai: Will Joiner, ja.

 

 

Toby: Hat mich hat mich total geflasht einfach die sollte der Abstufung zu sehen, heroische Führung im Sinne von ich bin der beste zur Amira also muss ich eure Chef sein und euch sagen die Programmierung geht und ich kann mich dann vielleicht helfen bessere Programmierer zu werden.

Über kollaborative Führung so ja ihr seid auch gute Programmierer, lasst uns das gemeinsam machen hinzu postheroischer Führung dass man zugibt und sagt.

Ich muss gar nicht der beste Programmierer sein ich will doch gar nicht der beste Programmierer sein sondern,

ich will dass ihr die besten Programmierer seid, weil ihr macht die Arbeit ich bin der Meeting Fuzzi, der sich um die Rahmenbedingungen kümmert und der irgendwie Dinge ins Laufen bringt und Sachen organisiert.

Aber.

Es ist natürlich wichtig, dass ich  verstehe was Programmierung ist und ja ich kann programmieren und ja ich bin vielleicht auch nicht das schlechteste Programmierer auf der ganzen Welt aber ich hab überhaupt nicht mehr den Anspruch ein guter Programmierer zu sein ich habe den Anspruch zu verstehen, was meine Jungs machen.

Sind leider nur Jungs.

Und ich will auch die die Komplexität die die beschreiben verstehen und das tue ich auch aber selber mitprogrammieren und irgendwie beste Lösung finden, das ist überhaupt nicht mein Anspruch.

 

Kai:  Das war auch ich habe auch lange Software entwickelt für mich ein ziemlicher Entwicklungsschritt ich würde sagen ich fahre eigentlich viele Jahre meines Lebens ein totaler Einzelkämpfer.

 

Jasmine: Wollte grad sagen, biste nicht mehr?

 

Kai: Wir stehen doch zusammen vor der Kamera hier.

 

Jasmine: Wir arbeiten gut als Team.

 

Kai: Und was für mich ne gute, ne wichtige Lernerfahrung war, war mich dem Schmerz zu stellen, Ideen schlachten zu lassen so nenne ich das immer also so rauszukommen aus dem,

ich weiß das ist der heilige Gral weil das ist meine Überzeugung und wir müssen das jetzt tun,

und dann diese Idee auf die Schlachtbank zu stellen dass es so ein Bild was da für mich sehr resoniert hat weil das immer so anfühlt als ob ich weiß doch ein schon wie es sein muss und jetzt kommen andere und zerstören das irgendwie was ich da in meinen Gedanken habe,

und die Erfahrung zu machen das nach der Zerstörung etwas entstanden ist.

Was wertvoller ist als das was vor der Zerstörung da war und das als ein Ergebnis eines Gruppenprozesses zu sehen und auch zuzulassen.

Ist vielleicht auch was was dann diese Stufen wie du sie beschrieben hast auch mit beeinflusst und das ist für dich ein sehr individueller Lernprozess den einzelne Menschen durchgehen.

 

Wo mir also dieser Titel von einem Buch einfällt, Teamwork ist ein individual skill.

Also das ist irgendwie was was als Entdeckungs oder Kenntnis Reise,

wie jeder selbst durchlaufen darf und wo wir vielleicht durch Metaphern durch Gespräche durch Erfahrung unterstützen können und da werden wir dann wieder bei transformationale Führung die,

die einzelnen Menschen brauchen um in diesem Modus reinzukommen auch diesen Schmerz der Zerstörung der eigenen, b esten Idee vorgeblich besten Idee in Kauf zu nehmen und damit eher statt bei Best Practices bei Good oder Emergent Practices anzukommen also den Sachen die dann halt durch die Resonanz und durch das Feedback tatsächlich funktionieren.

 

Toby:  Also mein erster Coach in der agilen Produktentwicklung war Marty Cagan, Silicon Valley Product Group, war ehemalig Manager bei Netscape, was weiß ich

was er alles gemacht hat eBay, keine Ahnung. Super Typ und ich hatte die große Freude und Ehre das Ding meinen Mann Arbeitgeber damals der mich dann zum Produktmanager ausgebildet hat eine Kooperation mit Marty Cagan hatte und der kam halt alle 4 Wochen für eine Woche zu uns und hat uns gecoacht und wir  haben Schulung von ihm bekommen aber auch direkte Coachings an,

und in seinem Buch inspired ist ja einer der zentralen Sätze „Don’t fall in love with your product“.

Schön dass Du Ideen hast so aber häng nichrt dran das ist schlecht sobald du dran hängst hast du eigentlich verloren.

 

Jasmine: Total schön gibt’s für dich ein, also ich muss anders fragen

wenn wir jetzt Zuschauer haben die Führungskräfte sind die Ideen der Position sind wie du bist gibt’s für dich Tools oder Gedankenmodelle und  oder Modelle die du gerne benutzt oder die dir schon Stütze geben.

Für deine tägliche Arbeit.

Retrospektiven hast du schon genannt für dich schon so ein super gibt’s da noch mehr wo du das sagst hey  das ist etwas damit arbeite ich einfach gerade um am System zur arbeiten.

 

Toby:

Ja gibt’s einiges verschiedenes, ich greif da auf ganz verschiedene Sachen zurück, das prominenteste ist wahrscheinlich das agile Manifest,

das ist witzig, weil das ja  2001 geschrieben worden ist und man denkt irgendwie in den letzten 20 Jahren hätte sich da mal was getan und es gibt ja verschiedene versuche das zu ergänzen und undsoweiterundsofort finde ich auch alles gut wenn ich alles legitim sollte meiner nicht,

stehen bleiben,

trotzdem find ich‘s immer wieder hilfreich auf diese Liste zu schauen nicht nur die vier Wertepaare die da verglichen werden sondern vor allem auch die 12 Prinzipien, da ist jedes einzelne total hilfreich.

 

Da habe ich mir mal eine Retrospektiven-Tätigkeit ausgedacht bei der ein Team sich diese zwölf Prinzipien anschaut,

und  überlegt okay welches dieser zwölf Prinzipien ist für uns,

jetzt gerade das wichtigste wo wir investieren sollten das führt einerseits dazu dass ich das Team mit diesem Prinzip bin auseinandersetzen überlegt was bedeutet es eigentlich für uns als Team, und dann vielleicht dein Ansatzpunkt findet um zu sagen okay.

Das mit dem täglichen Kontakt zu den Wissens Leuten ist vielleicht eine Sache wo wir besser werden sollten, damit wir besser verstehen wofür wir das eigentlich machen.    

Also ist agile Manifest ist für mich immer wieder eine Quelle von Inspiration und Hilfestellung tatsächlich,

um besser voranzukommen,

 

Jasmine: Total spannend wir kommen gerade aus nem Drei-Tage-Workshop wo wir genau das auch gemacht haben. Wir haben die Prinzipien mal genommen, da irgendwie einklassifizieren lassen, ich mach das auch gerne auf den Wertepaaren aber gerne in Richtung Managementworkshops, weil

 

ich finde die Wertepaare sind so für Teams die Arbeiten sind sehr fluffy.

Und an die Prinzipien sind bisschen griffiger und wir haben genau das gleiche gemacht und auch gesagt hey wenn ihr euch hier eins aussucht, lustigerweise haben wir vier Gruppen dann gemacht sucht euch eins aus was am wichtigsten ist und guck mal was sie da machen wollt – drei Gruppen haben das gleiche ausgesucht.

Also wie dann auch so ne, das System zeigt sich immer ich will noch ganz auf ein kommentar hingehen Kerstin

Schreibt, dass sie erst jetzt gerade zugestoßen ist genau nachher auf YouTube verfügbar und wir werden das auch noch als Podcast wirklich im Nachgang ein bisschen später auf unserem Podcast veröffentlichen,

Kerstin du kannst dir das dann irgendwann mal beim Jogging anhören wahrscheinlich eher so in nem Monat, aber

wenn wir da fertig sind ist es auch direkt auf YouTube verfügbar also

man kann das noch ganz lange anhören

 

Kai: Genau, und der Markus schreib noch gehe Ursprung zurück denke bezieht sich auf das Agile Manifest, genau ne also der ganze immer mal wieder die Diskussion ist das Ding jetzt veraltet oder nicht.

Und ich glaube da resonieren wir ziemlich Toby, das ist brandaktuell und in vielen Kulturen noch nicht bei uns angekommen.

Das einzige was schief gegangen ist und wo ich denke, dass es nicht hilfreich ist, ist dieser Focus auf Scrum das habe ich ja schon gesagt ich bin kein ein großartiger Verfechter von SCRUM das ist glaube ich wirklich schief gegangen das halt ganz viele,

Teams Gruppen auch Coaches und Prediger zu viel Fokus auf SCRUM gelegt haben

oder eben auf Kanban oder noch schlimmer auf save oder oder irgendwas auf diesen vorgegebenen

Systemen die man dann einsetzen kann.

Wenn man das nicht mit dem agilen Manifest verheiratet und dieses intentionally incomplete dann auch lebt und sagt okay wir machen daraus jetzt das was uns wirklich hilft und was ist wirklich auf die auf die Spur bringt,

dann kann es halt ganz schnell zu Frustration zu Ablehnung gegenüber

SCRUM führen was dann irgendwie als Ablehnung gegenüber Agile interpretiert wird. Das ist ein ganz wichtiger Punkt.

Der Fokus auf Retrospektiven hat mir immer geholfen, ich mein das ist jetzt auch Agiles Manifest, also man kann das letzte Prinzip aus dem agilen Manifest  dass man sich regelmäßig schaut wo man sich dann verbessern kann als Aufforderung zu agieren Retrospektiven verstehen also, so tue ich das,

trotzdem ist das noch mal ein Punkt für mich der gesondert genannt werden kann es immer eine Hilfestellung die die ich nutze,

wenn man sich nicht agil fühlt kein Bock hat auf Scrum, und wenn man nicht weiß ob dass das Richtige für einen ist,

dann probiert wenigstens Agile Retrospektiven, das kann man auch ohne SCRUM das kann man auch in in irgendeinem anderen Setting machen einfach regelmäßig wenn es nur alle vier Wochen ist ich ne Stunde hinsetzen und reflektieren,

was können wir ausprobieren um besser zurechtzukommen das ist das auf jeden Fall eine meiner Leitlinien.

 Und um die drei Sachen die ich mir überlegt habe auf deine Frage zu antworten komplettieren es gibt.

Ein nicht mehr ganz so neues Modell das nennt sich das Agile Fluency Model von Diana Larsen und James Shore.

Und das ist etwaw wo ich gerade ein bisschen tiefer rein geguckt habe das glaube ich auch extrem hilfreich ist dass man sich einfach,

überlegt okay.

Es gibt so viele verschiedene Dinge in der agilen Welt die man tun sollen könnte, es heißt ja immer du sollst Scrum machen du sollst Pair Programming machen, du sollst,

Continous Deployment machen, du sollst test early machen was auch immer es gibt so viele Sachen die man tun sollen könnte,

welche davon soll ich denn überhaupt machen oder muss ich überhaupt alle machen und die Antwort ist natürlich nein man muss nicht alles machen man kann sich aus diesem,

Toolkit raus sammeln was denn eigentlich für einen gut ist, und das Agile Fluency Modell hilft einen so ein bisschen zu überlegen für welche denn eigentlich was will ich denn eigentlich mit der Agilität erreichen also welche benefits die die Agile Welt so insgesamt verspricht brauche ich denn eigentlich,

vielleicht brauche ich gar nicht alle, und dann quasi zu analysieren okay das ist das was ich eigentlich erreichen will durch meine Bestrebungen in der Agilität.

Und welche Schritte muss ich denn dafür gehen ganz spannendes tolles Modell was die sich da ausgedacht haben.

 

Ja langsam hab ich das Gefühl wir könnten hätten den Workshop jetzt auch zusammen geben könnte ich die letzten drei Tage, weil wir damit tatsächlich auch um die Ecke gekommen sind,

irgendwie dieser Gedanke,

ich glaub Diana hat das mit ihrem Sohn  irgendwie entwickelt William der ja aus der Sprachforschung eigentlich kommt und hat dieser Gedanke Flüssigkeit in der Sprache hast du dann wenn du nachts geweckt wirst und sagen kannst irgendwie nicht mehr auf Englisch anspricht kannst du flüssig antworten,

und Flüssigkeit für die Teams dann als Bedeutung du antwortest auf die Frage wieso wir unser Produkt organisieren mit Produktvision und Product Backlog wenn du nachts geweckt wirst also dieses ne wann ist es in Flüssigkeit Übergang und wie viel plus braucht es auch auf welcher Stufe total.

Schönes Werkzeug und.

Hilfreich absolut hilfreich, mag ich da können wir es damit gut begegnen und weil du grad eben den SCRUM Priester angesprochen hast ich bin ja auch son Scrum Prieste, Certified Scrum Trainer.

Die größten Schmerzen die wir mittlerweile eigentlich unseren Trainings auch haben ist das Menschen natürlich Vorerfahrung gemacht haben mit total verkorkstem SCRUM wo auch viele Dinge einfach wenn du dir die Geschichte dahinter an hörst auch einfach die Hände überm Kopf zusammenschlagen und denkst so,

okay da hätte ich jetzt auch wirklich keinen Bock gehabt so zu arbeiten von dem man sich jetzt verstanden hab und,

diese Wahrnehmung früher war so  der Gegenpart zum agilen Manifest vielleicht so Wasserfall vorgehen und heute ist es halt einfach den das größte Problem für Agilität ist halt Fake Agile, also dieses so 

ich habe nicht drüber nachgedacht warum ich das eigentlich tun möchte sondern ich habe es einmal gemacht weil alle sagen man sollte das machen, und ich habe weder erkannt wieso ich das tun sollte noch welche Problem ich versuche mit diesem Vehikel oder dieser Haltung zu lösen.

 

Um dann auf einem Boden zu treffen der kulturell absolut nicht passt und wo Leute einfach auch nur frustriert sind und auch total nachvollziehbar frustriert sind, das ist was was uns ganz viel beschäftigt.

Um überhaupt dahin zu kommen mit Leuten mal faires Experiment zu starten und zu sagen,

lass uns mal darauf ein dass vielleicht noch ein paar Monate auszuprobieren obwohl wir vielleicht vor vier Jahren in nem Team waren wo wir

irgendwie Story Points in Manntage umgerechnet haben und unser Management dann irgendwie uns unter Druck gesetzt hat damit wir mehr liefern wo du dann einfach so als jemand der lange mit diesem Rahmen Werken arbeitet denkst oh mein Gott was ist denn da falsch abgebogen wo habt ihr denn da die Kulturpassung oder die LEADERSHIP Arbeit verpasst,

die ja dann  auch gut erkennbar ist zum Beispiel in dem Buch von Bill joiner warst du eben genannt hast die da anstehen müsste einfach irgendwie dieses Expert oder heroischen Leadertum drauf getroffen ist, wo es einen ganz großen Clash gab zwischen dem wie man kollaborativ arbeiten wollte innerhalb der Teams und dem was ein MANAGEMENT vielleicht dann erwartet hat.

 

 

Jasmine: Ja oder auch was die Kultur des Teams ist also ein Alien ist.

Ich bin so ein bisschen dagegen dass immer so aufs MANAGEMENT zu  schieben so, wir können nicht agil sein weil das MANAGEMENT ist so böse.

Ich denke ja er hat teilweise was und zum anderen aber auch.

Und Persönlichkeitsentwicklung ist jetzt eine blöder Begriff, aber zum anderen das hat jeder Einzelne muss echt ein paar Hebel im Kopf umlegen.

Ein paar Schritte gehen damit wir zusammen kollaborativ Agil arbeiten müssen und dieses agile Manifest selber leben können,

und ob ich das von unten hoch oder von oben runter mache ist mir eigentlich sowas von Pumpe, es muss halt jeder einzelne in der Organisation zuerst mal sein Hof kehren dann müssen wir zusammen unseren Hof kehren und dann wird’s was also dieser Weg auf allen Ebenen zu tun.

 

 

Toby: Absolut, ich bin ja auch gar kein Gegner von SCRUM überhaupt nicht ich habe es als hilfreich entdeckt wenn man sagt.

Wir gucken erstmal was eigentlich unser Problem ist, unser Ziel.

Und und gucken dann welches Tool dann hilft dieses Ziel zu erreichen und in den Teams,

ist es tatsächlich ein Problem dass es heroische Entwickler gibt die halt alleine eine Aufgabe bekommen Bau dieses Feature und dann ziehen die sich 3 Monate 5 Monate zurück oder nen Jahr und bauen dann dieses Feature,

ja und wenn sie dann fertig sind dann wird es kurz getestet und dann eingebaut zum Release. Und das hat halt dann zur Folge dass man vorher gar nicht weiß ist es überhaupt das Richtige und weiß auch noch nicht wie lange dauert das denn weil,

ob das jetzt ein halbes und ein ganzes Jahr dauert, das lässt sich jetzt vorher nicht wirklich abschätzen.

Und es gibt sind ja nur eine Person die sich mit dem Feature wirklich auskennt. Das sind halt alles Probleme mit denen will man also.

Mit denen wenn man eigentlich als Produktentwickler egal ob jetzt Agile oder nicht mit dem wenn man nicht kämpfen das ist wenn man wenn man diese Probleme nicht hat.

Wenn man dann aus diesem Problembewusstsein heraus irgendwie entscheidet okay, lass uns etwas agiles, es gibt da dieses agile, das scheint genau diese Probleme anzugehen, lass uns da was nehmen wir kannst ja mal mit SCRUM probieren und dann guck.

Hilft dieses Werkzeug denn auch, uns in diesem Problem weiter zu bringen dann kann es was werden aber wenn man einfach nur gesagt bekommt macht SCRUM, probiert es mal aus und sich aber dieses Problems gar nicht bewusst ist dass man lösen möchte dann gehjt’s halt schief.

 

Jasmine: Wir haben einen ähnlichen Kommentar gerade von Stefan gehabt dieses genau also die die die Rahmenwerke können uns helfen.

Und und damit war aber dann auch noch dahinter gucken das findet er es ganz ganz hilfreich und und ich auch also ich habe auch gemerkt vergleiche das immer mit tanzen.

Finde wenn man SCRUM nimmt und und hat einfach diesen SCRUM Tanz tanzt ich meine dann kann man auf unterschiedliche Arten tanzen man kann größtes besseres Wasserfall mit SCRUM machen wenn man möchte.

Wenn man dahinter nicht nicht die Werte legt und ich habe ja mal Tango getanzt und und hat es auch so mechanisch gelernt.

Und das finde ich aber irgendwie nie ganz so gut an es fühlt sich irgendwie weil ich habe dann beherrscht das war okay.

Und dann hatte ich auf einmal so ein argentinischen Tango Lehrer und der hat so in der ersten Stunde gesagt Mädel.

Lern erstmal gehen, wieso ich kann doch gehen, ne kannst du nicht und ein Gefühl für die Musik hast du auch nicht.

 

Sieht ja alles irgendwie hm aus, dann habe ich genau, erst mal so hö?

 

Und dann habe ich ein halbes Jahr rückwärts gehen gelernt zu Musik und wir haben nichts anderes gemacht ich dachte, wann tanzen wir denn endlich.

Aber danach fühlt es sich tanzen wie fliegen an weil ich endlich kapiert weiß dass die denn meine mit diesem Verschmelzen mit den eins werden mit.

Mit dem ganzen und so fühlt sich das für mich manchmal an wenn wir dieses blutleere SCRUM machen, weil wir machen Events  und die Rituale und es ist alles gut.

Wenn es auf einmal mit Leben füllen mit den Werten füllen dann dann macht einmal auf einmal Spaß.

 

Ich glaube Joesph Pelrine hat ja auch mal gesagt, also egal was ihr macht, wenn Kanban und Scrum undsoweiter keinen Bock macht, kein Spaß macht, dann macht ihr’s falsch. Und das finde ich auch immer eine ganz gute Messgröße da drin auch.

 

Toby: Ja Spaß weiß ich also soll natürlich auch immer war Spaß bringen wenn man keinen Spaß an der Arbeit hat gerade in unserer Branche, in der Softwarebranche ist das insgesamt Problem dann läuft irgendwas schief.

Aber natürlich ist Arbeit auch erst mal und unangenehmen wie du sagst, wenn man gesagt bekommt lern erstmal gehen das ist unangenehm und das macht dann erstmal keinen Spaß, das Ergebnis hinterher macht vielleicht Spaß,

aber der Weg dahin ist manchmal schmerzhaft und anstrengend und das ist für mich absolut legitim, das gehört das mit dazu und umso wichtiger ist ist das nicht nur externe Coaches reingeholt werden, die einem sagen,

eine Schulung geben und tolle Worte zum agilen Manifest finden das auch immer jemand ist der das wirklich vertritt und wirklich da hinterher ist das langfristig,

und nachhaltig zu stützen

 

Jasmine: Ich hätte, wir sind jetzt so am Ende wir haben mal wieder die Zeit ein bisschen vergessen aber es hat super viel Spaß gemacht aber.

Ich habe eine Frage noch.

 

Toby: In meinem Podcast muss ich eine Dreiviertelstunde monologisieren,

und mich verzetteln und veraufen, und den Faden wieder aufnehmen damit die Leute gut einschlafen können,

Und wenn man mich reden lässt dann tue ich genau das.

 

Jasmine: Und das war super da waren so viele super spannende Dinge drin ich glaube als Abschlussfrage, ne ich glaube wir haben noch eine Abschlussfrage, die wie immer stellen aber ich hätte eine  die muss ich jetzt noch stellen,

und ich bin mir ganz sicher dass die Leute draußen das auch interessiert also dieses genau das ein dass dieses halbe Jahr rückwärts gehen das war frustrierend.

 

Und ich dachte auch noch so, das war in der Schweiz, hey ich zahl 30 Franken pro Stunde damit ich rückwärts gehe.

Was mach ich hier denn eigentlich? So, es ist verdammt teuer um gehen zu lernen, also das war ein Tal der Tränen wo ich irgendwie durch musste,

ich hatte mein Ziel vor Augen das war mir wichtig und mein Lehrer hat das super geschafft mich da immer wieder zu unterstützen dabei.

Du bist jetzt auch in ner Führungsrolle,

was machst du um diesen Schmerz diesen Frust die Leute dazu unterstützen dabei zu bleiben dran zu bleiben durch dieses Tal der Tränen durchzugehen.

Gibt’s da was was dir hilft?

 

Toby: Da gibt’s kein Allheilmittel da gibt’s nichts von Ratiopharm das ist leider sehr sehr individuell also da hat wirklich jede Person mit der ich gearbeitet habe ein eigenes Bedürfnis, ein eigenes Verlangen das ist ganz ganz wichtig.

Diesen Menschen dann zuzuhören und ihnen den Raum zu geben die Probleme die sie  damit haben die Schmerzen die sie damit haben zu äußern und ich höre mir das alles an und.

Dann geht’s darum, gemeinsam zu überlegen okay ist dieser Schmerz ist diese Unzufriedenheit etwas was tatsächlich darauf hinweist dass hier was schief läuft oder ist es ein Schmerz wie ich muss jetzt gerade rückwärts gehen oder ich muss das gerade, es gibt ja dieses Karate Kid Beispiel mit lern doch erstmal hier polieren und wenn es dann oft genug gemacht hast, dann ist diese Bewegung flüssig, wieder FLUENCY und unseren kannst du es,

dass das sind ja zwei verschiedene Art von Schmerz es gibt ja auch,

Leute die polieren Autos und lernt dadurch nicht Karate, also im übertragenen Sinne Leute die Zahlen 30 Franken oder Euro die Stunde um rückwärts gehen und sind dann keine tollen Tangotänzer, die

gibt’s ja auch so an und das zu identifizieren ist halt eine super individuelle Sache da gibt es einfach keinen generisches Rezept für.

 

Jasmine: Aber ich liebe das eine Tool dass du genannt has, das zuhören.

Das auch etwas wo ich immer wieder merke je länger ich jetzt so arbeite wie ich arbeite am und mit Menschen, zuhören ist es Tool Nummer 1 und es ist nicht einfach.

Man denkt immer das ist mir rückwärts gehen ja rückwärts gehen Easy, nein.

 

Schön so schön.

 

Kai: Gut gehen wir in den Abschluss und oft stelle ich dir die Frage der Toby in fünf Jahren aber ich merke, ne andere Frage beschäftigt mich

 

Toby: Alle die du vor fünf Jahren gefragt hättest lagen auf alle Fälle falsch.

 

Jasmine: Auch du selbst?

 

Toby: Aber hallo wer hat denn vor fünf Jahren gedacht dass wir in so einer Pandemie im Homeoffice sitzen nur noch mit Masken einkaufen und auf eine Impfung hoffen. Wer hat denn vor fünf Jahren damit gerechnet dass irgendwelche Schwurbler nen Sturm auf den Reichstag, also das ist ja

alles kompletter Wahnsinn heutzutage.

Aber fragt bitte.

 

Kai: Also um die fünf-Jahres-Frage nicht zu stellen sondern die andere Frage.

Wenn ich sie jetzt die gute Fee programmiere irgendwie Backend, Frontend.

Von mir aus auch noch irgendne Datenbank dahinter oder irgendwie vielleicht vielleicht zeigen was keine Ahnung, die der Wunsch erfüllen kann in diesem Universum gerade was was wünschst du dir oder was wünscht du uns allen.

 

Toby: Wow. Krasse Frage.

Ich wünsche uns vor allem.

Dass wir wieder auf die Füße kommen, es fühlt sich so an als wäre ziemlich vielen Leuten der Boden unter den Füßen weggezogen worden und das ist natürlich bedingt durch die Pandemie die wir gerade durchleben.

Und in meiner Wahrnehmung führt sie dazu, dass die Gesellschaft gespalten wird und das ist eine Sache, die übt Kräfte auf alle Bereiche auf auf unsere Privatleben aber eben auch ohne professionellsten Leben, also davon ist ja niemand unberührt.

Und wenn ich mir etwas wünschen dürfte dann dass wir in fünf Jahren wieder besser miteinander umgehen dass wieder mehr soziale Interaktion möglich sind und und auf eine sichere Art und Weise und dass wir nicht in so eine.

Seine Spaltung reinrutschen wie es leider in den USA ja auch zu sehen war da gabs ja ne ganz krasse Spaltung, sodass die eine Seite wenn nichts mehr von der anderen Seite geglaubt hat oder hören wollte aber halt kein zuhören mehr  möglich.

Es gibt dann immer Leute die versuchen dann wieder zu einen und diese Schaltung rückgängig zu machen oder zu heilen.

Glaube das ist sehr sehr schwierig wird ich vermute fast fünf Jahre werden gar nicht reichen, aber  reichen, aber wir müssen müssen dringend aufpassen dass uns als globaler Gesellschaft da jetzt nicht  noch mehr Schaden passiert.

Jasmine: Danke vielmals, das waren super schöne Worte es war mir ein Fest ich würde gerne noch Petras  Mitteilungen ganz kurz einblenden so geht’s mir nämlich auch was für eine Bereicherung für mich in diesem im System am System arbeiten Führungsperspektive eintauchen zu können.

Widerspiegelt so mein Gefühl danke viel viel mal das war super bereichernd mit dir zu reden danke dass du dir Zeit genommen hast.

 

Kai: Und ja.

Du hast dir die Zeit genommen hier in den Growth Cast rein zugucken dafür danken dir viel mal wir haben gerade auch so ein bisschen Unterhaltung durchblicken lassen was die Art und Weise wie wir SCRUM vermitteln angeht und Jasmin und ich haben über fast jetzt ein Jahr an einem Buch geschrieben

entsprechend was sich darum dreht wie man gute SCRUM Trainings gibt als agiler Coach um in dieser Perspektive zu wachsen,

und eben auch diese agilen Werte dahinter hat,

wenn dich das Thema interessiert dann kannst du das Buch jetzt vorbestellen und zwar agilegrowth.de/buch oder Amazon oder vielleicht auch wenn sie dann wieder offen haben entsprechend in den Buchläden,

vorbestellbar kaufbar dann bald auch insofern herzlichen Dank wenn dich das interessiert und genau wenn dich, Tobyas,

Stimme in den Schlaf bringen möchte, dann herzliche Empfehlung für den Einschlafen Podcast von Toby und wir freuen uns wenn wir uns ganz bald wiedersehen nächste Woche im Agile Growth Cast.

 

Veröffentlicht am

Scrum by the Book? Was eBay’s ehemaliger CTO Joseph Perline 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.

Veröffentlicht am

Folge #016 – Über Politik und Machtspiele in agilen Transitionen – Dr. Olaf Bublitz im Interview

Wie Olaf als ScrumMaster abgesägt wurde und was er daraus über Politik gelernt hat

Nicht jeder mag Politik in Unternehmen. Und doch: es ist eines der Spiele, die wir Menschen nur allzu gerne spielen. Wer seinen Einfluss dabei nicht geltend macht, dem droht das Game-Over. Wir hören im Interview, welche Lektionen Olaf hier gemacht hat und welche Werkzeuge er heute für Veränderungen gerne einsetzt.

 

Zur Nachlese – Die Shownotes

Olaf’s Unternehmen – ri:level

Play4Agile (Un-)Konferenz – https://play4agile.wordpress.com

Buch von Simon Sinek – Endliche Spiele

Trello – Ein beliebtes kostenfreies digitales Task-Board

Personal Map – Olafs persönliche Visualisierung seines Lebens