Folge 24: DevOps und der agil-industrielle Komplex

https://podcasters.spotify.com/pod/dashboard/episode/e29ihqu

DevOps ist weitverbreitet und somit auch im Blickpunkt wirtschaftlicher Interessen. Mit André Claaßen (Digitale Verwaltung erfolgreich gestalten!) spreche ich über seine Erfahrungen mit agilen Projekten und Unternehmen. Warum DevOps eine Antwort auf den agil-industriellen Komplex ist und warum er persönlich Lean Management und Agilität so gut findet.

In dieser Episode diskutieren Dierk Söllner und sein Gast André Claaßen über die Herausforderungen und Missverständnisse im Zusammenhang mit Agilität und DevOps in der IT-Branche. Sie kritisieren den agil-industriellen Komplex und betonen die Notwendigkeit, Agilität und DevOps nicht als starre Methoden oder Werkzeuge zu sehen, sondern als Ansätze zur Verbesserung von Arbeitsabläufen und Prozessen, um echten Mehrwert für Kunden zu schaffen. Dabei betonen sie die Wichtigkeit von kritischem Denken, Erfahrungslernen, kleinschrittigem Arbeiten und dem Mut, neue Wege zu gehen.

Inhalt

  • Einführung und Vorstellung des Gastes André Claaßen
  • Diskussion über den agil-industriellen Komplex
  • Kritik an der kommerziellen Vermarktung von Agilität und DevOps
  • Die Bedeutung von Scrum und dessen Herausforderungen in der Praxis
  • Extreme Programming und dessen Einfluss auf Agilität
  • Scrum als Tool für das Management und dessen Grenzen
  • Die Rolle von Zertifizierungen und Trainings im agilen Umfeld
  • Vergleich von verschiedenen agilen Methoden und Frameworks
  • DevOps als Antwort auf den agil-industriellen Komplex und die Bedeutung des Wertestroms
  • Kulturelle Aspekte und die Notwendigkeit von Veränderung im Management für erfolgreiche Agile- und DevOps-Umsetzung
  • Abschließende Gedanken zur Agilität und deren Umsetzung

Shownotes

Webseite von Andre Claassen

Transkript (automatisch erstellt, daher keine Gewähr 🙂 )

DevOps. Auf die Ohren und ins Hirn. Ein Podcast rund um DevOps. Von Dierk Söllner.
Herzlich willkommen zu einer neuen Folge des Podcasts DevOps. Auf die Ohren und ins Hirn.
Mein Name ist Dirk Söllner. Ich begleite Unternehmen auf dem Weg zu einer hochperformanten
IT-Organisation. Als Trainer und Coach mache ich Teams und Menschen erfolgreich. DevOps umfasst
für mich kulturelle, organisatorische und technische Aspekte. Diese diskutiere ich in
diesem Podcast mit Experten aus der Praxis. Ich freue mich heute auf das Thema DevOps und
der agil-industrielle Komplex. Zu Gast habe ich André Klaassen. Der aufmerksame Zuhörer wird sich
an die Folge DevOps in der Digitalisierung aus dem Februar 2019 erinnern. Ist also noch gar nicht
lange her.
Dort war ich zu Gast in seinem Podcast und habe diese Folge auch bei mir veröffentlicht. Das heißt
also, das war genau die Februarausgabe bei mir. André ist Experte für agiles Management und
Verwaltungsdigitalisierung. Wir reden heute über eine Problematik, die mir in manchen Kundensituationen,
auch bei Konferenzen oder auch bei Barcamps und häufig eben auch bei Twitter begegnet,
nämlich der agil-industrielle Komplex. Was das genau bedeutet, werden wir im weiteren Verlauf
des Podcasts ausführen.
Also, ich freue mich. Hallo André. Ich habe dich ja schon kurz vorgestellt. Was habe ich vergessen? Was möchtest du ergänzen?
Also erstmal vielen Dank, Dirk, dass ich heute zu Gast bei dir sein darf. Ich freue mich sehr.
Vielleicht kurz ergänzend. Ich bin mittlerweile 53 Jahre alt, Vater von zwei Kindern. Gut, das ist das Private und beschäftige mich eigentlich mit dem Thema IT schon seit frühester Jugend.
Und Schwerpunkte waren lange Zeit Softwareentwicklung, komplexe und große Systeme in der Verwaltungswirtschaft und ich habe mein Portfolio in den letzten Jahren auch ergänzt in Richtung Coaching und Beratung für Digitalisierungsvorhaben in der Verwaltung.
Ja, und ich freue mich heute bei dir zu sein.
Ja, ich finde das interessant von deiner Vorstellung, dass du mit dem Privaten angefangen hast. Das ist immer so, wenn ich an meine Schulungen denke, so ein Punkt, wo ich mich dann immer wundere,
sondern die Leute fragen, gerade in Inhausschulungen, dass sie sich kurz vorstellen. Die kennen sich ja in der Regel eigentlich alle und trotzdem erzählen sie, aus welcher Abteilung sie kommen oder, oder, oder.
Also häufig Dinge, die die meisten anderen wissen. Und ich habe auch schon mal überlegt, ob ich das ein bisschen auflockern kann.
Also insofern fand ich es interessant, dass du jetzt quasi wirklich zuerst deine privaten Dinge vorgestellt hast und ein Vater von zwei Kindern, das ist ja auch eine Leistung an der Stelle.
Gut.
Vielen Dank nochmal für die Vorstellung und ich freue mich.
Ich freue mich auch, dass du da bist, weil ich mich auch auf das Thema freue. Das war ja auch ein bisschen deine Idee mit, dieses Thema hier zu besprechen.
Bevor wir da einsteigen, vielleicht noch der eine Punkt, die aufmerksam Zuhörer werden das eben auch kennen.
Wir sind ja im DevOps-Podcast und da bitte ich meine Gäste ja immer um ihre persönliche Definition von DevOps.
Also André, wie würdest du DevOps definieren?
Also für mich ist DevOps eine Idee, ein Vorgehensmodell, um Produkte,
anhand wirklich von Ende zu Ende optimiert, möglichst automatisiert zu erstellen.
Das ist vielleicht jetzt noch ein bisschen akademisch, aber die Idee kommt oder ich sehe da stark auf das Lean Management.
Wie kann ich also Verschwendung vermeiden und wie kann ich maximal Kundenbedürfnisse und Wertschöpfung in den Vordergrund meines Handelns stellen?
Und für mich ist,
bei DevOps ist sehr, sehr wichtig,
Autonomie und Kompetenz der handelnden Personen.
Das heißt also,
dass die Kompetenzträger diesen Prozess lebendig mitgestalten und auch verantworten.
So, das ist so ein bisschen meine Sicht von DevOps.
Ja, finde ich interessant.
Da kommt ja einiges mit rein, was ich auch sehe.
Also Lean Management, Automation hast du gesagt, eben Kompetenz der Personen, Autonomie.
Ein Wort habe ich bei dir nicht gehört.
Der betrifft das Thema Teams, Teambildung und Organisation.
Aber wie gesagt, das ist ja deine Definition und du hast es ja nicht ausgeschlossen an der Stelle.
Aber insofern, mir persönlich gefällt diese Definition, mir gefällt der Begriff sehr gut.
Jetzt haben wir als Thema agil-industrieller Komplex und ich denke mal, wir sollten einfach mal anfangen,
dass du mal beschreibst, was du oder was man unter dem agil-industriellen Komplex versteht.
Ja.
Ich hole mal ein bisschen weiter aus.
Also ich beobachte und nutze das Thema Agilität eigentlich schon relativ lange.
Gestoßen bin ich auf das Thema im Jahr 2000, als ich ein großes IT-Projekt zu verantworten hatte,
das wirklich in jeder Beziehung außer Plan, außer Time ein Budget war
und das in irgendeiner Form gerettet werden musste.
Und ich habe nach Lösungen geschaut, wie man vielleicht auch mit Arbeitsweisen
oder verändert.
Oder mit bestimmten Vorgehensweisen dieses Projekt auf Kurs bringen konnte und bin damals
auf einen agilen Ansatz gestoßen, der nannte sich Extreme Programming.
Das gibt es auch heute noch und das beinhaltet ganz viele Praktiken aus Gramm, also zum Beispiel
kurze Zyklen, kurze Planungszyklen, testgetriebene Entwicklungen mit, ja, ich sage mal Techniken
der IT.
Und dieses Extreme Programming war für mich eine sehr gute Idee.
Für mich besonders toll, weil es gibt ein tolles Buch von Kent Beck, der auch der Erfinder
der testgetriebenen Entwicklung ist oder Erfinder ist vielleicht zu viel gesagt, aber einer
der großen Leute, die also dieses Thema Unit Testing in den Entwicklerbereich reingebracht
haben.
Kent Beck hat ein Buch dazu geschrieben und das begann mit einem Kapitel über Mut.
Und dieser Begriff Mut, der steht für mich auch ein Stück für das Thema Agilität.
Mut zu haben, die Dinge, die man als richtig erkennt, zu machen und auszuprobieren und
den Mut zu haben, Dinge, die nicht funktionieren, dann auch zu ändern.
Und dieses Thema zieht sich ein Stück weit durch meine Erfahrungswelt, was das Thema
Agilität angeht.
Jetzt zu dem agil-industriellen Komplex.
Im Jahr 2000 sind verschiedene Ideen entwickelt worden, wie man anders IT-Projekte managen
konnte.
Und eine Idee war neben dem Extreme Programming auch die Idee von Scrum.
Es gab auch noch andere Dinge wie Crystal Clear und andere Vorgehensweise.
Aber Scrum war in einer Form brillant, weil im Unterschied zu den anderen Methoden oder
Ideen richtete sich Scrum wirklich an das Management und sagt, ihr Manager, ihr braucht
ein anderes Verständnis von Projekten oder Produktentwicklung.
Ihr könnt eure Vorhaben.
In deutlich kürzerer Zeit, mit deutlich weniger Personal entwickeln, wenn ihr diese
Scrum-Methode, die wir euch hier skizzieren, in euren Projekten einsetzt.
Und damit ist Scrum geboren worden und die Ansprache ans Management, die war auch genau
die richtige, um agile Prozesse sozusagen zu etablieren.
Gleichzeitig zog damit aber auch das Thema Zertifizierung ein.
Das heißt also, die verschiedenen Rollen im Scrum-Prozess werden…
Man zertifiziert, was ja erstmal gar nichts Schlechtes ist, weil man über die Zertifikate
auch erkennt, dass man ein Grundverständnis von den Dingen hat.
Aber nachdem halt Scrum sehr erfolgreich wurde, vor vier bis fünf Jahren begann also sozusagen
dieses Thema abzuheben, haben sich aus meiner Sicht viele Beratungshäuser oder Schulungsanbieter
wirklich auf das Thema gestürzt.
Kann man ja auch nicht verdenken.
Und daraus ist etwas entstanden, dass ich und viele andere auch und auch Menschen, die
sozusagen damals die Grundlagen…
für agiles Arbeiten gelegt haben, den agil-industriellen Komplex nennen.
Agil-industrieller Komplex heißt, dass also das Thema Agilität industriell vermarktet
wird.
Das heißt also, es gibt große Produkte, um agile Methoden zu schulen, zu lehren und
einzusetzen.
Es gibt komplexe Frameworks.
Eins davon ist zum Beispiel Safe.
Und was dabei aus meiner Sicht ein Stück weit aus dem Fokus gerät…
ist, dass Agilität ja angetreten ist, genau diese Frameworks und großen komplexen Prozesse
und Methoden in Frage zu stellen.
Die Grundidee von Agil war eigentlich, arbeitet in kleinen Schritten, lernt, was ihr dort
erfahren habt, achtet auf die Benutzerwünsche und auf die Werte, die er generiert, reflektiert
und nutzt das Gelernte im nächsten Schritt.
Stattdessen wird heute…
Das ist ein bisschen jetzt eine provokante Zuspitzung, sehr stark ausgebildet in, wie
funktioniert ein Sprint-Planning, was ist ein Daily und wie lange ist ein Daily oder
bei Safe wird es ja noch ganz bunter.
Wir sehen die Rollen in komplexen, skalierten Safe-Prozessen, agilen Prozessen aus und
wie spielen die ineinander.
Und was ich dann sehr, sehr spannend finde, also ich schaue jetzt auch mal auf das große
Framework Safe.
Wenn man sich dieses Framework…
anschaut, da gibt es ja eine riesen Übersichtsgrafik mit den ganzen Instrumenten, dann findet man
den Kunden erstmal gar nicht.
Der Kunde steckt irgendwo rechts hinten als kleines Kästchen in der Ecke und das veranschaulicht
aus meiner Sicht ideal, dass man also ganz stark auf die Innensicht schaut und das, was
Agilität ausmacht, was liefere ich an Werten und wie sieht der Kunde die gelieferten Werte
und wie sind meine Bemühungen, kundengerecht zu arbeiten.
Das geht so ein Stück weit verloren.
Okay, dann würde ich jetzt mal ganz kurz mal einhaken, weil du hast schon sehr, sehr viel
erzählt zu dem Thema agil-industrieller Komplex und ein paar Dinge würde ich nochmal rausgreifen,
weil ich ja auch zu dem agil-industriellen Komplex gehöre.
Das wird bestimmt nochmal eine interessante Diskussion, gleich auch.
Aber vielleicht einmal nochmal kurz zurück, auch vielleicht auch ein bisschen zusammenzufassen,
denn ich frage mich manchmal.
Warum sind die anderen agilen Frameworks nicht so erfolgreich oder verbreitet wie Scrum?
Das heißt, wenn ich dich richtig verstanden habe, sagst du, Extreme Programming hat natürlich
viele Parallelen zu Scrum, ist klar, weil sie ja beide auch auf dem agilen Manifeste beruhen.
Also da müssen ja Parallelen da sein.
Du sagst aber, damit hat man das Management nicht angesprochen.
Es war rein eine Entwicklersicht.
Okay, gut.
Ich lerne ja in meinem Podcast auch immer etwas.
Dann habe ich jetzt mal etwas gelernt.
Also Scrum ist unter anderem deswegen erfolgreich, weil es eben…
Managern oder das Management an sich anspricht.
Okay, gut.
Ich habe jetzt ja eben auf das agile Manifest abgehoben und das ist für mich eben ein ganz wichtiger Punkt.
Dann hast du von Save etwas erzählt.
Da würde ich gleich auch nochmal drauf eingehen.
Ich würde aber vorher nochmal auf den agil-industriellen Komplex eingehen.
Ich habe ja gesagt, ich bin auch Bestandteil dieses agil-industriellen Komplexes
und habe auch vor sechs, sieben Jahren damit angefangen, mich damit zu beschäftigen
und gebe heute auch…
Ich bin ja auch Scrum-Trainings und zertifiziere auch und bin aber auch als Coach tätig,
also begleite dann die Unternehmen.
Das, was ich so interessant finde bei dem Thema Scrum, ist, dass ich als Trainer und als Coach
quasi keinerlei Prüfungen machen muss oder nur überschaubare Prüfungen machen muss
und vor allen Dingen kein Geld bezahlen muss dafür, dass ich Scrum-Trainings geben kann.
Das heißt, das Einzige, was geschützt ist, ist ja der Begriff The Scrum.
Der ist ja als Trademark geschützt.
Alles andere ist ja frei verfügbar.
Das heißt, das, finde ich, ist A, wie ich finde, erstmal ein Grund dafür,
wahrscheinlich auch, dass Scrum so erfolgreich ist im Vergleich zu anderen Themen.
Also es ist überschaubar im Einstieg und wie gesagt, den Einstieg, den kann sich jeder selber geben,
indem man sich den Scrum-Rite runterlädt, ein, zwei Bücher kauft, ist also überschaubar, was die Kosten angeht.
Also das finde ich eben einen Riesenunterschied, dass man eben…
quasi dass der Einstieg finanziell gesehen als Trainer beispielsweise überschaubar ist.
Richtig. Jetzt muss man bei Scrum sagen, das ist meine Einschätzung,
es wirkt unheimlich plausibel und einfach, wenn man sich das durchliest.
Also jetzt mal vordergründig ist es ja ein sehr, sehr einfaches Vorgehen-Modell.
Es gibt nur ganz wenige Rollen. Es gibt ganz wenige…
Veranstaltung ist falsch gesagt.
Es gibt nur Termine, die man wahrnehmen muss und es scheint sehr einfach implementierbar zu sein,
wenn man es jetzt naiv betrachtet.
Ich habe es naiv betrachtet und habe es damals autodidaktisch eingeführt und ohne Zertifizierung,
also da auch ohne Schulung. Es gab damals aber auch noch nicht so viele Angebote dazu
und bin da katastrophal gescheitert.
Das ist nachvollziehbar. Also nicht, dass du gescheitert bist, aber dass man diesen Eindruck hat.
Auf der anderen Seite, dann sage ich dann,
würde ich jetzt sagen, genau deswegen, das wäre ja ein Grund für einen agilen industriellen Komplex zu sagen,
wir brauchen erfahrene Leute, wir kommen ja auch auf das Thema Coaches nochmal zu sprechen,
wir beide nachher, wir brauchen erfahrene Leute, die genau die Menschen wie dich begleiten,
die vielleicht eine Schulung machen oder sich vielleicht nur den Scrum Guide durchlesen,
ein Buch durchlesen oder irgendeinen Kurs, einen Videokurs besuchen,
um sie nachher bei der Umsetzung zu begleiten, weil das ist ja etwas, was wir in allen Frameworks haben.
Also wenn ich an unser geliebtes ITIL,
denke, das ist genauso. Natürlich kann ich die Leute auf Schulungen schicken
und trotzdem habe ich nachher die Berater im Haus, die mir die Prozesse designen,
die mir die Fallstricke erklären, damit ich nicht die gleichen Fehler wieder mache,
die eben hunderte Firmen vor mir auch gemacht haben.
Wie gesagt, mit anderen Frameworks.
Erstmal richtig, das auf jeden Fall.
Worauf ich abzielen möchte, jetzt mal, ich habe mal bewusst gesagt,
dass ich gescheitert bin, ist halt, dass das Framework an sich,
eine, und das ist, und das wird ja auch überhaupt nicht in Abrede gestellt,
eine ganz gravierende andere Art des Arbeitens ist.
Und Scrum, was ich sehe in den Unternehmen,
wird aber oft als gekapselte Einheit für die Entwicklung betrachtet.
Und Scrum widerspricht dem ja auch nicht.
Also ich sage mal, wenn ich mir einen Scrum Guide durchlese,
dann wird das mehr oder weniger auch ein Stück weit so bestätigt.
Und das bricht mit so vielen,
ich sage jetzt mal, tradierten Arbeitsweisen in Organisationen und Unternehmen,
dass es also eine deutlich größere Nummer ist.
Und wenn du sagst Coach, dann stimme ich dir absolut zu.
Es reicht eben aus meiner Sicht nicht, nur die Zertifikate zu machen.
Die Zertifikate kratzen, oder kratzen ist jetzt ein falsches Wort,
aber die betrachten nur einen ganz kleinen Ausschnitt der Kompetenzen,
die ich aus meiner Sicht, ich sage jetzt bewusst aus meiner Sicht, brauche,
um diese Vorhaben auch wirklich erfolgreich umzusetzen.
Also für mich ist das Handwerkszeug,
also Handwerkszeug, was ich erstmal erlernen muss.
Das heißt, wenn ich jetzt ein Haus bauen will, kann ich viele tolle Ideen haben.
Ich kann auch den Wunsch nach diesem Haus haben,
aber ich muss trotzdem, wenn ich es selber bauen will,
wissen, wie ich maure, wie ich Elektroleitungen verlege und so weiter.
Das heißt also,
für mich ist das erstmal das Handwerkszeug an der Stelle.
Und ich würde nochmal so ein paar Dinge sozusagen dagegen stellen, aus meiner Sicht.
Ich glaube, das wird wirklich ein toller Podcast hier in der Diskussion.
Wir müssen auch gucken, dass wir auf das Thema DevOps noch kommen,
aber das kriegen wir auch noch hin.
Also für mich ist ein wichtiger Punkt, den ich in meinen Studien auch immer herausarbeite,
ist, Scrum ist 1995 oder 96 vorgestellt worden.
Und erst 15 Jahre später gab es den Scrum Guide.
Das heißt also, es gab eine sehr, sehr lange Zeit,
wo es Scrum quasi gab, also wo Ken und Jeff das schon dargestellt hatten und erläutert hatten,
wo aber nirgendwo nachzulesen war, wie das jetzt genau geht.
Und dann haben die beiden, und das haben sie jetzt vor ein, zwei Jahren
auch nochmal im Webinar nochmal klargemacht, beide,
wo sie dann die Schwierigkeit hatten, ja, was machen wir jetzt?
Wir wollen eben genau nicht alles im Detail beschreiben,
denn das hätte dir ja geholfen, wenn sie dir 2000 Seiten Eitel-Literatur
quasi für Scrum an die Hand gegeben hätten und gesagt hätten,
okay.
Du musst nicht 17 Seiten lesen, du musst 2000 Seiten lesen
und dann weißt du alles.
Also das Ziel von den beiden war ja, einen Rahmen zu schaffen,
einen festen Rahmen zu schaffen, damit nicht jeder irgendwas machen kann
und sagen kann, ich mache Scrum, aber eben trotzdem genug Spielraum zu lassen.
Und dieser Spielraum ist genau eben das Problem oder die Herausforderung,
die ich eben dann sehe.
Und da stimme ich dir zu.
Da gibt es natürlich viele Leute, die daran, ich sage mal, verdienen,
wenn man es negativ sagt, positiv gesprochen, die dort Unterstützung anbieten.
Und da gibt es natürlich keine Qualitätskontrolle.
Also wenn sich jemand heute Coach nennt, egal ob agiler Coach oder wie auch immer,
es gibt ja keine Prüfung und kein feststehendes Institut oder Zertifikat,
was nachweist, hey, das ist ein guter Coach.
Das Einzige ist, dass er vielleicht gute Projekte gemacht hat.
Also das war der eine Punkt, den ich da noch ergänzen wollte.
Und der andere ist, dass, wie ich finde, Scrum manchmal auch ein bisschen überbewertet wird.
Scrum sagt ganz genau.
Klar, wir haben hier beschrieben, wie ein Team arbeiten kann an einem Produkt.
Natürlich kann ich die Scrum-Ansätze oder agile Ansätze nutzen,
um auch das Unternehmen zu übertragen.
Aber das ist nicht der ureigene Anspruch von Scrum.
Natürlich muss ein Scrum-Master auch die Organisation als Servant Leader weiterentwickeln.
Aber eben nochmal, Scrum hat aus meiner Sicht nicht den Anspruch, eine Organisation aufzubauen.
Scrum hat den Anspruch, ein Team zu befähigen, genau das zu tun, was Scrum als Framework will,
nämlich Produkte zu liefern, Werte zu generieren, mit dem Kunden zusammenzuarbeiten.
Und genau das erfordert auch die Betrachtung des Umfeldes aus meiner Sicht, damit das erfolgreich ist.
Das ist auch kein Widerspruch.
Das sehe ich auch genauso wie du.
Ich würde aber jetzt nochmal kurz zwei Punkte zurücksprechen.
Du hast jetzt mehrfach gesagt, ich bin ja auch Teil des agilen industriellen Komplexes.
Der Begriff ist ja nicht scharf.
Mit agil industriell meine ich, dass ganz große Beratungshäuser,
die 2009 noch extreme gegenteilige Positionen zu agilen Entwicklungen propagiert und veröffentlicht
und mit Studien unterlegt haben, dann ab 2011 oder 2013, 2014 jetzt absolute Befürworter sind.
Also das finde ich einerseits ein bisschen unglaubwürdig und schwierig.
Und andererseits wird halt, das ist meine Wahrnehmung,
die Vermittlung von Methodenkenntnissen in den Vordergrund gestellt.
Ja, also wie finden die Scrum-Zeremonien statt und wie funktioniert ein Planning etc. pp.
Das reicht nicht aus meiner Sicht.
Und bei Scrum ein Stück weit, Scrum kommt ja aus der IT-Entwicklungswelt.
Also wenn wir bei Scrum, auch wenn Scrum natürlich einen Anspruch hat,
auf alle Produkte, für alle Produkte zu gelten und das unterstützt sich,
aber ursprünglich erfolgreich eingesetzt wurde es halt für Software-Entwicklungsprojekte.
Und dort brauche ich viel, viel mehr, auch vom Management her,
als das, was ein Scrum-Guide vorgibt.
Das ist so meine Sicht.
Wenn ich nur Scrum mache und blende alles andere aus,
was ich für erfolgreiche Projekte brauche,
dann besteht die Gefahr des Scheiterns.
Nicht nur die Gefahr, dann wird das scheitern.
Da stimme ich dir vollkommen zu.
Und ich stelle fest, es ist ja auch eine schwierige Rolle,
und die Rollen sind sehr, sehr anspruchsvoll, die Scrum definiert.
Insbesondere die Product-Owner-Rolle, die Scrum-Master-Rolle,
aber sogar die Team-Rolle ist extrem anspruchsvoll.
Sie erfordert sehr, sehr andere Verhaltensweisen und Kompetenzen
als klassische tradierte Arbeitsweisen, auch im Projektmanagement.
Was ich sagen will, ist, ich brauche halt weitere,
oder da wiederhole ich mich jetzt, weitere Kompetenzen,
die sind unabdingbar.
Und ich erlebe, dass halt Menschen aus diesen Ausbildungen kommen
und dann in IT-Projekte reingehen
und dann eine Scrum-Master-Rolle übernehmen,
was erstmal nicht schlecht ist und was sehr, sehr viele Dinge abdeckt,
aber was, wo aber auch eine gewisse Blindheit gegenüber
Dingen ist, die man eigentlich mit einem, ich sag jetzt mal,
auch mit einem klassischen IT-Hintergrund
oder einem klassischen Projektmanagement-Hintergrund erkennen könnte.
Ich möchte das jetzt nicht zu weit ausführen,
aber ich habe ein Beispiel erlebt, also von so einem HR-Coach,
der wirklich aus einem komplett fachlich anderen Hintergrund
in ein Software-Projekt reinkam, was wirklich sehr anspruchsvoll war.
Und erste Maßnahme war, dass er das Team mit aller Macht
davon wegbringen wollte, Code-Reviews zu machen.
Weil das steht halt nicht im Scrum-Guide.
Und da sage ich, Achtung, Achtung, man kann sich über Code-Review streiten
oder nicht, aber ganz wichtig ist halt, dass ich das Team sozusagen befähige,
eigene Arbeitsweisen zu entwickeln, die dem Team helfen.
Und wenn das Team erkennt, das hilft uns, dann darf ich nicht intervenieren.
Und ich glaube, dass die Gefahr besteht, wenn ich diese IT-Konferenzen
und diese Kompetenzen nicht habe, dass ich in meiner Unsicherheit
sehr stark auf dieses Scrum-Methodenset zurückspringe
und dann sozusagen ein Stück weit auch ohnmächtig bin.
Das ist jetzt die technisch-praktische Sicht.
Die andere Sicht ist aber viel wichtiger.
Der Scrum-Master ist ein Change-Agent.
Das heißt also, das, was der Scrum-Guide beschreibt
und was auch erfolgreich funktionieren kann,
erfordert starkes Arbeiten mit dem Management außerhalb des Scrum-Teams.
Und diese Kompetenz halte ich noch für viel wichtiger, dass ich die tue.
Und da sind wir vielleicht weniger bei einer Zertifizierung
als auch beim Coaching.
Die Zertifikate suggerieren aber ein Stück weit,
dass ich erst mal genug Kompetenzen habe nach dem Zertifikat,
um Scrum erfolgreich einzuführen.
Und da sage ich nein.
Ich weiß weder, wie IT-Projekte funktionieren,
wenn ich nicht aus diesem Umfeld komme
oder auch aus einer Angelegenheit.
In einer ganz anderen Fachdomäne ist ja egal.
Und zweitens ist, ich weiß nicht, wie ich ein Change durchführe.
Und drittens ist, ich weiß nicht,
wie ich mit einem harten Senior-Management verfahre.
Das Glauben, mit Scrum wird jetzt alles gut,
aber ich muss mich kein Stück ändern.
Ja, okay.
Also da sind wir einer Meinung, da stimme ich dir zu.
Das, wo ich eine andere Sicht habe, ist,
dass wenn ich mache Scrum-Schulungen in der Regel zweitägig,
manchmal sind es auch drei Tage.
Die meisten, die bei mir aus den Schulungen rauskommen,
die nehmen mit, dass sie wissen,
sie haben jetzt quasi einen Einstieg geschaffen.
Das heißt, die kriegen von mir das Handwerkzeug beigebracht,
aber eben auch das Verständnis, so einfach ist es nicht.
Und da habe ich vielleicht eine andere Meinung als du.
Also das ist auch vielleicht nur die Außensicht,
die du vom Management hast.
Die Leute, die, ich denke auch, das machen andere Trainer genauso,
die erklären eben das Handwerkzeug, aber wissen ganz genau,
jetzt weißt du, wie du mit dem Hammer umzugehen hast,
aber wann du ihn benutzen kannst
und wie viele andere Hammer oder Hämmerchen es noch gibt,
das weißt du nicht, da brauchst du Unterstützung.
Also das, glaube ich, das kommt bei einer vernünftigen Scrum-Schulung bei raus.
Und das Beispiel, was du hattest, ich glaube, das ist genau der Punkt,
wenn wir über den agilen industriellen Komplex reden,
dann glaube ich, ist das ein Komplex, der wie alle anderen auch dann entsteht,
wenn da ein Mainstream draus wird, wenn man damit Geld verdienen kann.
Und da muss man wie auch bei allen anderen Sachen unterscheiden,
wenn man da ein Mainstream raus wird, wenn man damit Geld verdienen kann.
Und da muss man wie auch bei allen anderen Sachen unterscheiden,
was ist gut, was ist schlecht.
Also wo ist ein Coach gut und wo ist ein Coach schlecht.
Und den Coach, von dem du erzählt hast, das war aus meiner Sicht auch ein schlechter Coach,
weil er eben die Grundprinzipien nicht verstanden hat.
Nämlich, dass man bei Scrum Dinge ausprobieren muss
und dass das Team letzten Endes quasi für sich entscheiden soll, was hilft ihm.
Das hast du ja auch gesagt.
Also das, finde ich, ist eben der Punkt.
Es spricht erstmal nichts gegen diesen agilen industriellen Komplex,
aber gegen schlechte Mitspieler.
Und das hast du natürlich immer.
Wenn du Mainstream hast, wenn sich da eben Branchen rum aufbilden oder ausbilden,
hast du immer auch schlechte Mitspieler.
Und die kann man natürlich nicht so einfach trennen oder finden.
Ja, also ich glaube, ich bin da auch jetzt nicht ganz klar positioniert.
Also ich möchte mich jetzt nicht 100% gegen das Thema Zertifizierung aussprechen,
weil ich finde es einerseits auch gut, was du sagst,
dass du deinen Schülern mit auf dem Weg gehst.
Ihr wisst jetzt sozusagen, ihr kennt jetzt die Tools,
aber ihr braucht noch Zeit, um die Tools richtig adäquat einzusetzen.
Finde ich auch gut.
Trotzdem sehe ich, wenn ich jetzt mal rein auf die Vermarktungsseite schaue,
ja, wenn ich schaue bei Accenture, wie dort das Thema agil dargestellt wird,
dann sind das immer Lösungsangebote.
Ihr braucht agiles Management, hier ist die Lösung.
Ihr wollt skalieren, Agile, hier ist die Lösung.
Ihr wollt irgendwas machen, hier ist die Lösung.
Und genau das ist falsch, falsch, falsch.
Weil das widerspricht zutiefst der Natur von Agilität.
Und Scrum ist super, aber man darf es nicht mit der Lösung verwechseln.
Weil Scrum ist eine radikale, veränderte Art der Arbeit.
Und was du sagst mit dem Experimentieren, ich muss auch den Mut haben,
da bin ich wieder bei Kent Beck, Mut haben,
die Dinge, die ich als richtig erkenne, zu tun.
Und wenn die Hunde…
100 Mal anders sind, als im Scrum Guide beschrieben.
Egal, es funktioniert und das ist auch richtig.
Und die Lösungsorientierung führt halt aus meiner Sicht vor allen Dingen dazu,
dass man in eine Binnensicht abrutscht.
Das heißt, man schaut bei Agilität nicht mehr,
wir haben ja ursprünglich über DevOps gesprochen,
jetzt kommt der Bogen vielleicht zu DevOps,
nicht mehr, wie generiere ich Werte
und wie akzeptiere ich aber auch das Leistungsvermögen
meines jetzigen Lebens.
Und das ist das, was ich jetzt auch sehr gerne sehe.
Und das ist das, was ich jetzt auch sehr gerne sehe.
Ich bin nicht so ein Verhinderer des jetzigen Systems
und verhindere Überlastung.
Und wie reagieren Kunden auf meine Leistungen?
Sondern ich konzentriere mich bei Lösungen,
Lösungen, Lösungen auf eine Binnensicht.
Wir müssen entwickeln, besser arbeiten.
Wir müssen PO besser entscheiden.
Wir müssen Scrum Master besser coachen.
Und das ist alles nicht agil.
Weil agil ist am Ende des Tages das,
was dazu führt, dass ich in einen Verbesserungsprozess komme,
das mir erlaubt,
mein Team und meine Arbeitsweise immer besser zu machen.
Und da ist also meine große Kraft,
die Kritik, der industriell agile Komplex,
gerade von großen Beratungshäusern,
ich nehme dich da mal aus, Dirk,
sondern wirklich dieses Methoden und Lösungen verkaufen
für Fragen, die jetzt scheinbar angestellt sind,
führt dazu, dass ich den Menschen
Lösungskompetenzen nehme.
Weil ich sage denen,
ihr braucht gar nicht nachdenken,
nehmt doch die Lösung.
Ihr habt ein Problem mit eurer Produktion,
nehmt doch skaliertes Agile
und dann ist alles gut.
Nein, nein, nein.
Also jetzt werde ich ein bisschen emotional bewusst.
Da stimme ich dir auch wiederum zu.
Ja, ne, da stimme ich dir zu,
weil auch das sehe ich so.
Denn du hast ganz viele wichtige und richtige Dinge gesagt
und ein Punkt, der kommt dann genau wiederum auch
in das Negative rein.
Die negative Sicht ist,
die Leute, die Firmen wie Accenture und so weiter,
es gibt ja noch ganz viele andere,
also wir machen jetzt keine Schleichwerbung hier,
wir müssen auch andere Namen nennen.
Also es gibt ja die ganzen Beratungshäuser,
die dann eben nicht nur die Lösung liefern,
sondern die sie auch,
dann die Leute liefern.
Also die dann die Scrum Master liefern
und da stimme ich dir eben zu
und habe das selber auch erlebt.
Dann werden eben junge Absolventen,
die haben vielleicht sogar Soziologie
oder andere nicht wirtschaftsnahe Fächer studiert,
die werden im Crashkurs zum Scrum Master ausgebildet
und dann als Scrum Master auch beim Kunden eingesetzt
und faktoriert.
Die schaffen es natürlich nicht,
den gestandenen Entwicklern klar zu machen,
warum die Entwickler jetzt anders arbeiten sollten.
Das heißt,
die haben gar keine Lebens- und Berufserfahrung
und das habe ich eben auch erlebt
und das, denke ich,
ist der Punkt, den du auch ansprichst.
Es werden nicht nur die Lösungen verkauft,
sondern eben die Leute
und das Geschäftsmodell von diesen großen Beratungshäusern
ist ja genau quasi konträr zu dem Ansatz eines Scrum Masters.
Ich sehe einen Scrum Master oder auch einen agilen Coach,
so wie ich arbeite,
als jemand, der sich eben überflüssig macht.
Ja, sorry,
dann würde ich jetzt als Manager oder Partner
bei so einer Unternehmensberatung sagen,
vergiss es,
du machst die Betriebsarbeit,
das ist schon nicht überflüssig,
du machst dich sowas von unentschuld,
nee,
unüberflüssig,
also nicht ersetzbar,
damit ich dich schön weiter fakturieren kann.
Also jetzt hauen wir beide in die gleiche Kerbe,
aber das ist, glaube ich,
wirklich ein wichtiger Punkt,
wo einfach die Grundidee,
die hinter Scrum steht,
nämlich genau,
dass der Scrum Master sich eben im Prinzip überflüssig macht,
dass er andere stark macht,
dass das mit dem Geschäftsmodell von manchen Firmen
eben nicht übereinstimmt.
Also dann,
da sind wir auch wiederum,
da denke ich,
einer Meinung.
Ja, und es ist so ein bisschen ambivalent.
Also ich tummel mich ja auch
in den Bereich der Verwaltungswirtschaft
und auch da kommt Agilität zum Tragen
oder wird erkannt als Idee,
um Produkte für die öffentliche Verwaltung herzustellen.
Aber da erlebe ich so eine interessante Sicht,
also jetzt aus meiner Branche.
Ich nenne es mal eingebettetes Scrum,
Embedded Scrum.
Also man sieht irgendwie Agiles,
das Arbeiten ist irgendwie wichtig
und muss auch gemacht werden,
allein auch, um attraktiv zu sein als Arbeitgeber.
Aber es ist irgendwie auch gefährlich,
also betten wir das ein.
Das heißt also,
wir nehmen mal eine vorgelagert,
doch mal eine Spezifikationsphase vorweg
und nachgelagert eine klassische Abnahmephase hintendran.
Und dieses Denken in,
ich muss Agile machen,
aber ich muss es irgendwie bändigen,
hat jetzt nichts mit dem Agilindustriellen
zu tun,
hat nichts mit dem Komplex zu tun,
aber hat ein Stück weit mit einer klassischen Management-Sicht
darauf zu tun.
Das erlebe ich sehr, sehr oft.
Ja, man muss ja nur die Frage stellen,
PO, hast du die Kompetenz,
dein Projekt zu stoppen?
Ich würde mal sagen,
90 Prozent der POs sagen nee.
Dann sage ich, ihr seid keine POs,
weil ihr habt nicht die Verantwortung
für euer Handeln, ja?
So, die zweite Frage ist,
du gehst in die Entwicklung rein,
und fragst, wann habt ihr zum letzten Mal
mit Kunden gesprochen?
Haben wir noch nie gemacht.
Macht unser PO, und wenn überhaupt?
Nein, ihr macht kein Scrum.
Ihr kennt euren Kunden überhaupt nicht.
Und das erlebe ich in ganz vielen Organisationen.
Oder DevOps,
wir haben ja eben drüber gesprochen,
was ist die Definition von DevOps?
Ich erlebe oft folgende Definition von DevOps.
DevOps ist ein Betriebler,
der vernünftig mit einem Entwickler sprechen kann.
Macht überhaupt keinen Sinn,
aber das,
das erlebe ich oft.
Das heißt, man fokussiert sich beim Betrieb schon
ein Stück weit auf Automatisierung
und Betrieb und Tools,
aber von gemeinsamer Verantwortung,
vom Kulturwandel,
von Werteströmen,
von kundenorientiertem Denken,
nicht die Spur.
Weil am Ende sollen die Jungs,
die sich DevOps nennen,
immer noch Betrieb machen
und sind weiter getrennt von den Entwicklern.
Dann sage ich, Leute, ihr seid keine DevOps, ja?
Ihr seid ganz normale
und vielleicht auch gute,
gute IT-Betriebler,
aber ihr seid nicht das,
was hinter der Idee des DevOps nennt.
Und ich nenne das ein Stück weit auch,
ich glaube, da werde ich einen Artikel zuschreiben,
der agile Etikettenschwindel.
Das heißt, diese ganzen agilen Rollen,
POs, Scrum Master, DevOps,
die findet man jetzt überall,
aber man kann mit ganz wenigen Fragen entlarven,
dass diese Rollen gar nicht gelebt werden.
Und zwar in ihrer Ernsthaftigkeit,
die damit verbunden ist.
Und die Ernsthaftigkeit heißt
Verantwortungsübernahme.
Also da stimme ich dir auch zu.
Bevor wir vielleicht gleich bei DevOps weitermachen,
noch eine Pointe von mir.
Ich war jetzt gerade vor zwei, drei Wochen
bei einer großen deutschen Behörde
und Scrum-Shootung gemacht.
Da waren dann sogar auch mal Führungskräfte mit dabei,
weil meistens schicken ja die Führungskräfte nur die Mitarbeiter.
Was ich gut finde bei der Gelegenheit.
Super.
Also der war da,
der hat sich auch damit auseinandergesetzt
und der hat es auch verstanden
und hat auch ganz klar gesagt,
so wie ich hier Scrum verstanden habe,
wird das bei uns nichts werden.
Also war ja auch ehrlich.
Worauf ich hinaus wollte ist,
dass die erkannt haben,
wir haben ja gar keinen Scrum-Master.
Also die machen Scrum,
sagen sie, mit ihren Dienstleistern,
also mit den IT-Firmen, die liefern.
Die haben keine eigenen IT-Entwickler,
aber sie haben keine Scrum-Master im Haus.
Und haben dann festgestellt,
da fehlt ja was ganz Wichtiges an der Stelle.
Aber dann lass uns mal zu DevOps rübergehen,
wenn du da jetzt keine Ergänzung mehr hast.
Du hast ja gesagt,
DevOps hast du gesagt,
ist die Idee vom Lean-Management.
Also Lean-Management in abgeschossenen Projekten zu arbeiten,
in Wertströmen zu denken,
produktorientiert zu sein.
Wie sind denn da so deine Sichten jetzt auch vielleicht
in Bezug auf den agil-industriellen Komplex?
Wird das Ganze noch ein bisschen komplizierter an der Stelle
mit einem neuen Begriff,
mit einem neuen Ansatz wie DevOps?
Ich finde, DevOps ist auch ein Stück weit,
so habe ich das verstanden,
eine Antwort auf den agil-industriellen Komplex.
Der zeichnet sich ja aus meiner Sicht dadurch aus,
dass man eben Inseln betrachtet,
also Management, Entwicklung, Produktion
und dort Lösungen verkauft.
Scrum, Save, Kanban oder was auch immer
und sagt, mach das.
Die Idee von DevOps,
ich beziehe mich jetzt auch auf das Buch
Das Phoenix-Projekt,
was ich hier sehr empfehlen kann,
was du ja, glaube ich, auch schon mehrfach empfohlen hast,
ist ja die Idee, dass wenn ich Produkte wirklich erfolgreich,
denken will und produzieren will,
dann muss ich weiterdenken
und ich muss den gesamten Wertestrom betrachten.
Das heißt, ich kann nicht nur ein Stück weit
ein Entwicklungsteam betrachten,
was ja Scrum auch tut,
muss man ja ehrlicherweise sagen,
sondern ich muss ja die vor- und nachgelagerten Prozesse
genauso im Blick halten.
Und insofern macht DevOps für mich,
für mich sage ich jetzt,
das Denken ein wenig einfacher,
weil am Ende des Tages geht es darum,
mal die gesamte Welt zu verändern.
Die gesamte Prozesskette zu sichten, zu erkennen
und dann an der Prozesskette
auch in Form einer neuen Organisation
mit allen Beteiligten diese Prozesskette zu optimieren.
Das klassische deutsche Wort ist ja
der kontinuierliche Verbesserungsprozess.
Der trifft es aber nicht.
Ich schaue auf das Lean-Management.
Da gibt es ja die Kultur der ständigen Verbesserung.
Also das Kaizen ist ja viel mehr als,
der kontinuierliche Verbesserungsprozess.
Und das ist ja die bei allen Menschen im Prozess
verankerte Überzeugung.
Ich kann immer, immer, immer, immer noch ein Stück besser werden
oder es besser machen.
Und DevOps löst mich auch in meiner Denkweise
ein Stück weit von Tools.
Ja, sogar auch von Tools wie Kanban oder Tools wie Scrum.
Ich sage jetzt mal bewusst Scrum als Tool,
als Methodenset.
Sondern geht ein Stück weit eine Ebene höher
und sagt, wenn ich mal alles von Anfang bis Ende betrachte,
wo sind denn da unsere wirklichen Flaschenhälse?
Und wenn ich jetzt, ich war letztens bei einem Unternehmen,
wo ich das sehr, sehr gut beobachten konnte.
Die hatten also wirklich agile Teams.
Das ist alles wunderbar.
Aber die haben nicht den gesamten Wertestrom betrachtet.
Das heißt also, das Management davor
und vor allem die Kunden danach
fühlen sich nicht so gut.
Und das ist das, was wir jetzt machen.
Das ist das, was wir jetzt machen.
Das ist das, was wir jetzt machen.
Das führt sozusagen zu extremer Überlastung
des Produktionsbereiches.
Also wenn also ein Management sehr, sehr viele Dinge annimmt
und das System überlastet
und wenn der Kunde sozusagen auch nicht in der Lage ist,
du hast ja eben über die Verwaltung gesprochen,
an dem Wertestrom mit zu partizipieren,
indem ich halt abnehme,
dann nützt mir nicht die Optimierung einer Produktion
oder Entwicklung mit Scrum,
sondern muss ich an ganz,
ganz anderen Stellen optimieren.
Und da finde ich, macht das Lean Management
und auch das DevOps die Sache einfacher,
weil das nimmt für mich gedanklich ein Stück weit Druck
aus der Produktion raus
und schaut
und setzt
die Optimierungspotenziale
an vielleicht ganz anderen Stellen an,
die viel sinnvoller sind.
Dafür brauche ich aber alle Beteiligten an Bord.
Da habe ich sehr lang monologisiert.
Du musst jetzt eingreifen.
Ich nehme dir das.
Also ich habe mir aufgeschrieben,
DevOps als Antwort auf den agilen industriellen Komplex.
So habe ich das noch gar nicht gesehen.
Für mich ist das Schöne an DevOps,
es ist eben kein Framework.
Scrum ist auch ein Framework,
sagt es ja selber,
17 Seiten überschaubar beschrieben.
DevOps ist für mich eben kein Framework,
es ist ein Ansatz
und ich glaube auch,
das finde ich das Schöne,
es gibt niemand in dem Umfeld,
der diesen Begriff,
der sich irgendwie schützen will
oder der daraus großartig Geld machen will,
dass er da etwas entdeckt oder entwickelt hat.
Dann schau mal auf die,
die, die ich kenne,
aber vielleicht kenne ich die,
die du kennst auch nicht,
weil ich sie nicht kennen möchte.
Also für mich ist das eine Community.
Ja, okay, na gut,
also auch da haben wir ja
einen industriellen Komplex wahrscheinlich,
aber dahinter steckt für mich eben
ein neuer Punkt,
es ist eben dann noch mehr
und wie du auch gesagt hast,
das finde ich,
das Interessante,
es geht nicht darum,
mit irgendeiner Methode zu arbeiten,
es kommt ja im Prinzip ein zweiter dazu.
Also wenn ich jetzt quasi
eine Empfehlung aussprechen würde,
dann würde ich sogar sagen,
als Tool,
wie du es eben genannt hast,
für ein DevOps-Team,
kommt für mich vielleicht sogar eher
kann man in Frage als Scrum.
Auch da lehne ich mich jetzt ja weit aus dem Fenster,
aber auch das wäre für mich eben genau ein Punkt,
dass ich mit der Diskussion,
wir wollen jetzt den Betrieb
mit in die Verantwortung nehmen,
wir wollen den Wertstrom umfassender betrachten,
wenn ich das tue,
dann muss ich auch vielleicht
über die Arbeitsweise nachdenken.
Und über Limitierung, ja,
und Limitierung in Kompetenzen,
Wichten, Menschen, Maschinen, Tools.
Vielleicht nochmal bei DevOps,
was ich so oft sehe,
DevOps hat ja ganz viele Facetten
und eine Facette ist natürlich auch DevOps
in Form einer Kompetenz technisch
in Form einer Kompetenz technisch
das Toolset zu automatisieren,
jetzt gerade mal in der IT und Entwicklung.
Das heißt also, ich kenne mich aus mit
mit Docker, mit Continuous Integration
und Delivery.
All das ist total wichtig.
Aber DevOps braucht genau diesen kulturellen Blick
und den du jetzt auch gerade aufspannst.
Und ob das Scun-Ban oder Scum ist,
in meiner Sicht auch wieder egal.
Ja, am Ende brauche ich eine Prozesskette.
Erstmal, die ich erstmal aufzeichne.
Und da hilft ja Kanban,
weil ich sehr, sehr einfach
den Prozess sichtbar machen kann.
Aber darum geht es halt,
den Wertestrom aufzuzeichnen
und dort zu erkennen,
wo sind denn eigentlich meine Lagerhalden.
Und vielleicht hier auch nochmal ein Literaturtipp,
wo ich ganz viele Aha-Erlebnisse hatte.
Das ist das neue Buch von dem Klaus Leopold,
sehr, sehr zu empfehlen.
Ich habe leider den Titel jetzt vergessen,
aber den kann man vielleicht nochmal
in die Shownotes reinbringen.
Ich packe ihn in die Shownotes, ja.
Warte mal.
Ah ja, hier.
Klaus Leopold.
Absoluter Literaturtipp.
Agilität neu denken.
Warum agile Teams nichts mit Business-Agilität zu tun haben.
Und in dem Buch wird wunderbar aufgezeigt,
dass Agilität,
wenn ich nicht erfolgreich Produkte machen will,
dann muss ich Agilität einfach anders und größer denken.
Und,
äh,
wo ich bei Scrum ein Stück weit halt Bauchschmerzen habe,
es ist ganz oft nicht das Entwicklerteam,
was der wirkliche Flaschenhals ist.
Es ist es nicht.
Es ist ganz oft der vorgelagerte und nachgelagerte Prozess.
Und die Umgebung.
Und die Umgebung, die Anforderungen und so weiter.
Und die Umgebung, ja.
Ich kann programmieren, so schnell und so toll und so effizient ich will,
wenn ich katastrophale Entscheidungen im Vorfeld treffe
oder katastrophale Entscheidungen im Nachhinein.
Und wenn mir das alles nachfällt, nützt mir das alles überhaupt nichts.
Ich optimiere an der falschen Stelle.
Und das merkt man in der Entwicklung.
Das heißt, es führt zu einer Frustration
und Überlastung des Systems.
Und dann besteht die Gefahr, dass sich etwas entwickelt,
was die alten, grummeligen Männer,
die also Agil damals mit auf Podest gehoben haben,
Zombie-Scrum nennen.
Zombie-Scrum ist sozusagen der Endpunkt von Scrum,
wo man also diese ganzen Zeremonien und,
und Dinge praktiziert, aber Sinn entleert dann macht,
weil es einfach nur noch gemacht werden muss.
Und hier, also das, dieses Buch ist, glaube ich, wunderbar.
Vielleicht schon ein guter Gast auch für dich, Dirk.
Ja.
Den Klaus Leopold mal einzuladen.
Der hat sehr viel dazu zu sagen.
Das glaube ich.
Ich werde das in die Show-Notes reinpacken, das Buch.
Das steht bei mir auch auf der Liste hier,
weil ich auch das glaube als eine Möglichkeit,
einzelne Teams auch in eine Skalierung reinzubringen.
Und wir haben jetzt schon ziemlich viel Zeit verbraucht.
Wenn ich auf die Uhr gucke,
sind wir schon locker an diesen 45 Minuten dann dran,
die wir ja, wie ich immer so als Ziel, als Maximum habe.
Deswegen würde ich jetzt nicht auf deine Aussage vorhin eingehen,
safe und agil,
weil der letzte Podcast,
den hast du in deinem Urlaub nicht mitbekommen,
der ging genau um das Thema DevOps und safe.
Da haben wir darüber auch gesprochen,
haben wir auch darüber gesprochen,
ob das A in safe berechnet,
ist oder nicht.
Aber wie gesagt,
dieses Fass sollten wir beide jetzt nicht aufmachen,
weil dann sind wir in den 45 Minuten nicht durch.
Wir könnten zwar noch eine zweite Runde machen,
aber das können wir ja irgendwann ja nochmal aufgreifen.
Man kann ja auch solche Dinge nochmal wiederholen.
Also insofern, Klaus Leopold, packe ich mit rein
und finde ich eben, also in die Show-Notes,
finde ich eben sehr interessant,
weil es eben für mich auch eine Möglichkeit ist,
Skalierung oder Zusammenarbeit an sich herbeizuführen
und dann nicht auf die üblichen,
verdächtigen zu kommen,
die überall gerade genutzt werden.
Gut.
Ich habe zum Abschluss vom Podcast
immer die Frage an meine Gäste,
gibt es noch irgendetwas,
was wir nicht besprochen haben?
Dann gibt es irgendetwas,
was du noch als Abschluss sagen würdest?
Also insofern gehört der letzte bei dir
ein Statement oder noch irgendetwas hinzustellen.
Ja, also trotz,
ich möchte einfach nochmal klarstellen,
ich finde Agilität richtig gut,
richtig, richtig gut
und das ist eine ganz tolle
und auch wichtige
und auch zeitgemäße Form von Arbeit.
Passt für mich wunderbar auch
in den Kontext neuer Arbeit.
Das ist genau das, was wir brauchen
überall im Bereich, wo ich
Wissensarbeit mache. Also ich finde das erstmal
sehr, sehr gut. Noch besser
finde ich die Ideen hinter Agilität,
kritisches Denken,
aus Erfahrung lernen,
kleinschrittig zu arbeiten, reflektieren.
Und ich
zitiere weiter meinen
Kent Beck mit dem Thema Mut.
Habt Mut,
die Dinge, die ihr machen
wollt, auch zu tun.
Steter Tropfen höhlt den Stein.
Ich kriege nicht alles von heute auf morgen
umgesetzt. Aber solange ich
beherzt und vielleicht auch ein Stück weit
tapfer die Dinge, die ich
für richtig finde, mache
und einbringe in mein Team,
in die Organisation,
solange ist eigentlich
alles klar.
Gut.
Das ist ein tolles Schlusswort, oder?
André, dann bedanke ich mich
bei dir für diese kurzweiligen,
interessanten und auch
kritischen 46
Minuten. Insofern
vielen Dank von mir aus und
bis demnächst auch mal in der Realität.
Tschüss André. Dirk, danke dir.
Tschüss.
Musik
Musik
Musik
Musik
Musik
Musik
Musik
Musik
Musik
Musik
Musik
Musik
Musik
Musik
Musik
Musik
Musik
Musik
Musik
Musik
Musik
Musik
Musik
Musik
Musik
Musik
Musik
Musik
Musik
Musik
Musik
Musik
Musik
Musik