Folge 76: Klarheit

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

In dieser Episode des DevOps-Podcasts wird das Thema Klarheit in organisatorischen und technischen Prozessen behandelt. Die Moderatoren Luca Ingianni und Falko Werner diskutieren über die Herausforderungen, denen sie in ihrer Arbeit als DevOps-Trainer und Berater begegnen, insbesondere bezüglich der Unklarheit in Kundenprojekten. Sie betonen die Wichtigkeit von klar definierten Prozessen, gemeinsamen Sprachen und Definitionen sowie die Nutzung von Werkzeugen wie Wertstromanalysen und Visualisierungen, um Klarheit zu schaffen. Die Episode betont, dass Klarheit in allen Unternehmensebenen notwendig ist und dass dies für effektive DevOps-Praktiken und agile Transformationen unerlässlich ist.

Inhalt

  • Einführung und Bedeutung von Klarheit in DevOps
  • Herausforderungen durch Unklarheiten bei Kundenprojekten
  • Bedeutung einer gemeinsamen Sprache und Definitionen
  • Rolle von Werkzeugen wie Wertstromanalysen und Visualisierungen
  • Wichtigkeit von Klarheit auf allen Unternehmensebenen
  • Diskussion über agile Praktiken und ihre Implementierung
  • Einsatz von Planning Poker und anderen Schätzungsmethoden
  • Wirkung von Klarheit auf Effizienz und Transparenz
  • Beispiele aus der Praxis und Erfahrungen der Moderatoren
  • Schlussfolgerungen und Handlungsempfehlungen

Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)

DevOps. Auf die Ohren und ins Hirn.
Ein Podcast rund um DevOps.
Von Dierk Söllner, Falko Werner und Luca Ingianni.
Hallo und herzlich willkommen zu einer neuen Folge des Podcasts DevOps auf die Ohren und ins Hirn.
Gestaltet und produziert von Luca Ingianni und Falko Werner.
Wir sind DevOps-Trainer und Coaches mit langjähriger Erfahrung.
DevOps umfasst für uns kulturelle, organisatorische und technische Aspekte.
Und wo wir gerade über organisatorische Aspekte sprechen, ist vielleicht Aufmerksamhörern aufgefallen, dass ein Name weggefallen ist.
Nämlich Dirk Söllner, der ja vor gefühlt einem Internetjahrhundert diesen Podcast ins Leben gerufen hat,
hat sich aus seiner aktiven Rolle als Mitherausgeber zurückgezogen,
hat den Podcast Falko und mir zum Geschenk gemacht
und ist natürlich weiterhin sowohl uns als auch dem Podcast sehr eng verbunden
und wird bestimmt auch noch als Gast das ein oder andere Mal hier auftreten,
aber gehört eben nicht mehr zum Stammpersonal, sondern ist…
Ich habe den Ausdruck mal in einem anderen Podcast gehört und ich finde den schön.
Er ist ein Freund des Podcasts. Er ist ein Freund von uns.
Insofern begrüße ich jetzt den zweiten Teilnehmer an dem heutigen Podcast, nämlich den Falko.
Hallo Falko, wie geht’s dir heute?
Hallo Luca, schön, dass wir mal wieder zusammensitzen und einen Podcast…
Podcast zu zweit aufzeichnen.
Ich freue mich auf das Thema, das du schon so gut vorbereitet hast, aber das kommt gleich.
An sich, zu deiner Frage, mir geht’s gut.
Ich freue mich auf ein Wochenende demnächst und bin ganz froh, dass die Arbeitswoche so weit rum ist,
bis auf den Podcast, die Podcast-Aufzeichnung jetzt.
Ja, das ist ja keine Arbeit, das ist ja ein Vergnügen.
Sehr schön. Worüber sprechen wir überhaupt dieses Mal?
Ich habe mir da ein Thema überlegt und es ist…
Das Thema heißt einfach Klarheit.
Und dieses Thema ist jetzt natürlich so ein bisschen unscharf, ein bisschen unklar selber.
Das liegt daran, dass ich in den letzten Monaten im Rahmen meiner Arbeit,
Betreuung verschiedener Kunden, immer wieder mit diesem Thema konfrontiert wurde,
dass in verschiedener Hinsicht, aus verschiedenen Perspektiven einfach Unklarheit herrschte
und sowohl mir als Konsultant, als auch meinen Kunden vor allen Dingen,
beträchtliche Schwierigkeiten bereitet hat.
Zum Teil auch Schwierigkeiten, die sich vielleicht gar nicht so richtig bewusst…
Und deswegen habe ich mir gedacht, vielleicht ist es an der Zeit, dass wir das mal hier im Podcast erörtern.
Was fällt dir denn ein zu diesem Begriff Klarheit, Falco?
Das Erste, was mir eingefallen ist, als du den Vorschlag zum Thema gemacht hast,
ist eine Folge, die wir schon hatten, und zwar mit Peter Lange zum Thema gemeinsame Sprache finden.
Das heißt Grundlage gemeinsamer Begriffe, gemeinsames Verständnis von der Situation im Unternehmen,
um dann letztendlich darauf aufbauen zu können.
Und ich denke, das ist eine gute Vertiefung auch zu der Folge jetzt, die wir damals hatten.
Ja, das stimmt. Und es ist spannend, dass wir jetzt an der Stelle einklinken,
weil das ist ja jetzt wirklich was wahnsinnig Grundlegendes,
dass wir sagen, Worte, haben wir überhaupt gemeinsame Worte?
Jetzt mal ganz abgesehen von allem anderen.
Ja, natürlich. Aber wir haben natürlich auch unterschiedliche Sprachen, unterschiedliche Historie.
Ja, die Worte an sich ist ja das eine.
Eine gemeinsame Bedeutung für die Worte zu finden, ist ja quasi der Schritt darauf.
Klar kann man sich immer auf eine Sprache, die in irgendeiner Form definiert ist,
wie Deutsch mit dem Duden oder Englisch mit dem Oxford- oder Merriam-Webster-Dictionary,
wo dann halt viele Begriffe klar definiert sind.
Aber im Geschäftsumfeld gibt es natürlich auch andere Quellen,
die hilfreich sind, so ein gemeinsames Verständnis zu finden.
Zum Beispiel Frameworks, die bestimmte Dinge definieren.
Ich arbeite gerade mit ein paar Kollegen bei der DASA an dem DASA DevOps-Glossar,
wo wir genau das versuchen, für die DevOps-Welt ein Stück zu ermöglichen und zu definieren.
Können uns da natürlich ein bisschen auch abstützen auf bestehenden,
auch mehrsprachigen Glossaren von Save oder von Scrum,
anderen Frameworks und Richtungen.
Die in dem Umfeld IT natürlich ein Stück ergänzend sind zu den Standard-Sprach- und Wort-Definitionen.
Wie siehst du das?
Ja, da sind wir schon mitten im Thema drin eigentlich.
Es erinnert mich vor allen Dingen auch an das, was wir traditionell eingangs dieses Podcasts immer machen.
Nämlich, wenn wir Gäste haben, fragen wir ja immer nach einer persönlichen Definition von DevOps,
weil so einfach ist es halt häufig nicht.
Du kannst nicht einfach den Duden aufschlagen und nachlesen, was heißt denn da DevOps,
sondern das heißt.
Für viele Leute viele Dinge und so ist es auch mit ganz vielen anderen Themen und so ist es
nicht nur auf der Ebene von Worten, sondern
Klarheit ist etwas, was immer wichtig ist, wenn man mit anderen zusammenarbeitet, auf ganz vielen Ebenen.
Ich behaupte, es ist auch sogar wichtig, wenn man nur mit sich selbst zusammenarbeitet, dass man eigentlich weiß, was man möchte, wohin man möchte.
Und es ist mir einfach in den letzten Monaten so aufgefallen bei meinen Kunden, dass
dass ein beträchtlicher Mangel an Klarheit herrscht, der mir natürlich als jemand, der von außen neu zu einer Organisation dazukommt, immer das Leben schwer macht.
Ich muss dann irgendwie versuchen, da rauszufinden, um was es eigentlich geht.
Aber was vor allen Dingen auch für meine Kunden selber das Leben wahnsinnig schwer macht.
Also ich bin gerade irgendwie erinnert an einen Kunden zum Beispiel, den ich in den letzten Monaten hatte, wo einfach überhaupt keine Vorgaben existieren darüber,
in welche Richtung die Organisation sich entwickeln soll.
Also irgendwie so die, die, die wollen halt irgendwas mit Agile machen, so war mal so der Gedanke.
Irgendwas mit ist natürlich ein cooler Anfang, erinnert mich gerade an den Titel von einem Podcast, der jetzt ein halbes Jahr läuft, von von jemand anders im AI Umfeld.
Irgendwas mit AI.
Also letztendlich ist er offenbar neugierig genug, dass ich mir den Titel gemerkt habe und auch die eine oder andere Folge gehört habe.
Und an sich ist das halt so ein Punkt.
Ich sehe es auch, wenn ich in Projektumgebungen reinkomme, dass man dann halt viele neue Begriffe, die unternehmensspezifisch sind, irgendwie sich nahe bringen muss, die man lernen muss.
Je größer das Unternehmen, desto mehr gibt es davon und desto mehr gibt es auch spezielle Abkürzungen und produktspezifische Sichten und anderes,
die dann halt nicht klar und deutlich in einem allgemein definierten Sammelsuchium von Worten wie in Glossar doch,
teilweise schon, teilweise haben Unternehmen sogar Glossare, aber nicht halt in einer Wikipedia, in einem Duden oder in einem Webster nachzulesen sind, weil sie halt doch sehr, sehr unternehmensspezifisch sind.
Genauso ist es mit vielen anderen Aspekten, die ein Unternehmen definieren, zum Beispiel die Art und Weise der Zusammenarbeit, wo du sagst, okay, wir wollen irgendwas mit agil machen.
Und was heißt denn jetzt agil?
Wo wollt ihr hin?
Was ist der Hintergrund?
Wo kommt ihr her?
Was sind eure Werte?
Was sind eure Ziele?
Was sind die laufenden Projekte vielleicht auch?
Oder welche Produkte gibt es im Unternehmen, um einfach als Berater, als Consultant in dem Umfeld dann auch wirken zu können, braucht man halt ein Verständnis.
Und dann muss man halt teilweise recht einfache Fragen stellen und wenn man dann feststellt, es gibt dann keine vernünftigen Antworten, dann wird es natürlich schwierig.
Also ich hatte jetzt letztens eine Schulung im Umfeld von Versicherungen und da ging es um agiles Arbeiten nach Scrum.
Als Framework und Scrum hat ein paar Werte und dann haben wir halt mal gefragt, ja, wie sieht es denn mit Unternehmenswerten aktuell aus?
Gibt es da Überschneidungen?
Gibt es da zu dem Scrum Framework und den Werten vielleicht auch Konflikte, die man dann mal diskutieren musste?
Funktioniert das theoretisch, so ein Framework in dem bestehenden Unternehmensumfeld zu etablieren, schon auf der Ebene der Werte?
Und dann halt der Operator.
Und dann halt die operativen Dinge, Umsetzung der Werte im realen Leben mit, wie werden die Werte dann gelebt, die es aktuell gibt?
Dann stellt man halt fest, ja, es gibt so eine Definition und dann hat jemand drei Werte im Kopf und der Nächste noch drei andere Werte.
Aber wenn man dann fragt, ja, wie werden die gelebt? Wie ist es denn bei euch wirklich in der Realität?
Dann wird es häufig dünn.
Dann merkt man, es hat sich kaum jemand wirklich Gedanken darüber gemacht.
Und genauso mit verschiedenen anderen Dingen, die in einem Unternehmen passieren.
Die nicht so ganz transparent sind.
Also ein Aspekt für Klarheit ist halt auch, dass man darüber redet, sich die Zeit nimmt und versucht, Dinge über verschiedene Köpfe hinweg zu einem gemeinsamen Verständnis zu bringen.
Also Transparenz zu schaffen.
Weiteres Werkzeug, was aus meiner Sicht für Klarheit bricht, ist Visualisierung.
Dass man halt sagt, okay, man redet nicht nur, man nutzt nicht nur Worte, sondern man nutzt auch Bilder.
Man nimmt Zeichnungen, man nimmt Diagramme, man geht an Whiteboard.
Man versucht, auf dem Weg ein gemeinsames Verständnis zu finden.
Und das kann man für verschiedenste Zwecke einsetzen.
Software-Architektur ist ein Beispiel, wo man dann Architektur-Diagramme ableitet, die zur Klarheit beitragen.
Genauso aber auch über Arbeitsabläufe.
Wenn man über Wertstromanalysen nachdenkt, dann sind das ja meist visuell dargestellte Abläufe von Arbeitsprozessen, Prozessschritten, von Abhängigkeiten, die man dann hat, die man dann visualisiert.
Und das hilft aus meiner Sicht auch, Klarheit zu schaffen.
Genauso kann man das auf anderen Ebenen machen.
Zum Beispiel, wenn man ein Produktportfolio versucht zu visualisieren und sagt, okay, wo stehen auf einer Skala, auf einer Sichtbarkeit, auf einer Umsetzbarkeit bestimmte Produkte im Portfolio.
Also auch da hilft aus meiner Sicht Visualisierung sehr gut.
Was muss man bei Klarheit noch bedenken?
Ein lustiger Aspekt ist, dass Klarheit nicht universell ist.
Genau.
Genau.
Genau.
Genau.
Genau.
Genau.
Genau.
Völlig klar sein und dem anderen derselbe Sachverhalt vollkommen unklar sein.
Und im Übrigen auch, dass es natürlich so Dinge gibt wie scheinbare Klarheit.
Als du gesprochen hast, zum Beispiel über Architektur-Diagramme, habe ich mich erinnert an einen mehrfachen Gast dieses Podcasts, den Felix, der mal die interessante Anekdote berichtet hat.
Der war CTO, wenn ich es richtig weiß, eines irgendwie Hosting-Unternehmens.
Und er hat seine Teams mal beauftragt, ihm ein Architektur-Diagramm zu malen.
Ihres Produkts, ihrer Infrastruktur.
Und die waren alle falsch.
Kein Team hat es hingekriegt, ein vollständiges und richtiges Architektur-Diagramm zu malen.
Die hatten alle Lücken, die hatten alle Fehler.
Und insofern, immer wenn ich ein Diagramm sehe, ein Architektur-Diagramm, ein, was weiß ich,
Wettsturm-Diagramm oder sowas, dann muss ich immer an diese Episode zurückdenken und mir
überlegen, das, was ich da sehe, ist das jetzt wirklich die tatsächliche Wahrheit?
Gibt es überhaupt tatsächlich nur eine Wahrheit?
Oder haben da vielleicht zwei verschiedene Leute, wenn du die beauftragst, den Workflow
aufzumalen, malen die dann verschiedene Workflows, weil sie es halt auch echt verschieden machen?
Insofern, auch da können die Dinge nur scheinbar klar sein.
Genau, ja, aber dann hat man zumindest die Möglichkeit, mit mehreren einfacher zusammenzuarbeiten,
um gemeinsam Workflow zu finden.
Und wenn ich mir überlege, wie so ein Wettsturm-Diagramm entsteht, so ein Value-Stream-Workshop
abläuft.
Dann hat halt jemand eine erste Idee, dann bringt er die an die Wand und dann wird sie
halt zerpflückt, diskutiert, ergänzt, erweitert und dann kommen halt andere Sichten dazu.
Dann hat man darüber Klarheit, das ist das eine.
Und das andere ist, man hat die Chance, gemeinsame Sichten zu entwickeln.
Genauso sehe ich das auch, wenn ich jetzt gerade an die Schulung der letzten Woche zurückdenke,
Scrum-Grundlagen, Estimation-Poker, genau das ist Klarheit schaffen.
Klarheit zwischen Anforderung und Umsetzung.
Dass man halt diskutiert, dass man klar macht, sichtbar macht, visualisiert.
Der eine schätzt Aufwand für eine User-Story in acht Story-Punkten, der andere in 21 Story-Punkten
und dann hat man Klarheit darüber, dass man unterschiedliche Sicht auf die Anforderungen
hat und kann dann Klarheit darüber schaffen, wo diese Differenz liegt in der Sicht auf
die Anforderung.
Dann kann man darüber diskutieren, wo diese Differenz herkommt, kann sie auflösen und
im besten Fall schätzt man halt nochmal, hat eine gemeinsame Einschätzung, die gleich
ist, vielleicht ist es bei beiden dann eine 13 oder man hat sich sogar auf eine 5 geeinigt
als Story-Punktgröße für die Anforderung, weil man Klarheit darüber hat, dass bestimmte
Annahmen, die quasi da sind, von unterschiedlichen Sichten heraus vielleicht nicht der Realität
entsprechen und deswegen die Schätzung unterschiedlich ist und deswegen halt es wichtig ist, darüber
zu reden.
Also man kann Klarheit über verschiedene Sichten.
Im besten Fall über Gespräche, über Workshops, über gemeinsame Arbeit an dem Objekt schaffen.
Also zum Beispiel gemeinsame Sicht auf den Quellcode, wenn man nicht genau weiß, was
ist umgesetzt.
Gemeinsame Sicht auf eine Visualisierung, auf eine Dokumentation, die man dann vielleicht
auch noch aktualisiert, wenn man feststellt, das was dort steht, stimmt nicht mit der gemeinsamen,
mit der Sicht der Einzelnen.
Ja, das ist eine berechtigte Frage.
Ich glaube, zumindest der Umstand, dass da…
Ein und dieselbe Architektur verschieden dargestellt wurde, ist ein Signal dafür, dass irgendwo
was im Argen liegt.
Egal, ob es da ein Felixrecht hatte oder vielleicht halt auch nicht oder sowas.
Aber ein Kabel verläuft objektiv entweder da lang oder es verläuft nicht da lang.
An der Realität messen.
Wie klar, wie richtig ist das, was man dort zum Beispiel in einem Modell, in einem Diagramm,
in einer Visualisierung aufgezeichnet hat?
Wie nah ist das an dem Kabelverlauf zum Beispiel?
In dem echten Schrank?
In dem echten…
In dem echten Rechenzentrumsrandabschnitt oder so.
Und da haben wir jetzt ein paar interessante Fragen aufgeworfen.
Zum Beispiel, kann man Klarheit irgendwie messbar machen oder sowas?
Aber ich würde diese Fragen sogar ganz gerne nochmal zurückstellen und erstmal noch ein
bisschen weiter uns an diesem Thema abarbeiten, dass wir sagen, wie kann ich denn jetzt Klarheit
erreichen?
Weil du hast zwar zu Recht gesagt, man könnte zum Beispiel ein Diagramm machen oder sowas.
Man könnte sich verschiedenster Techniken bedienen.
Aber wie wir jetzt gesehen haben, Klarheit oder andersrum, ein Diagramm erzeugt dann
nicht automatisch Klarheit, weil das Diagramm kann ja verkehrt sein.
Insofern, wie können wir denn sowas erzeugen, absichern?
Wie kann man Klarheit erzeugen und wie kann man sicherstellen, dass die erzeugte Klarheit
da ist?
Komme ich zurück auf die Diskussion, auf die gemeinsame Erstellung von einer Dokumentation,
einer Visualisierung im Gespräch von den Beteiligten, die Wissen über die Situation
haben, zur Not an der physisch-realen…
Also dem Quellcode, dem Bit und Byte, das irgendwo steht und geschrieben ist, dass
man halt nachschaut, recherchiert und sich bewusst macht, wie es wirklich ist.
Messen hilft dabei, sicherlich.
Genau, wenn man einen Nachweis hat, wenn man einen physischen Beweis hat, geht da jetzt
eine Stippe lang oder geht da keine Stippe lang, dann kann man es auf diese Weise machen.
Ansonsten kann man das machen.
Was du vorhin ja auch schon angesprochen hast, zum Beispiel Planning Poker, man kann, wenn
man es will, über statistische Methoden, Planning Poker ist, etwas dramatisch gesprochen,
ja einfach nur eine statistische Methode, ich mache die Anzahl groß und schaue dann,
wie groß meine Abweichung ist.
Das heißt, ich kann dafür sorgen, dass Einigkeit besteht oder vielmehr, ich kann überprüfen,
zu welchem Grad Einigkeit besteht, so muss ich sagen.
Das ist, glaube ich, etwas, was ganz wichtig ist und was selten gemacht wird.
Ich meine, bei Planning Poker…
Das ist ziemlich verbreitet, das machen bestimmt viele Leute, auch weil es irgendwie
schön einfach ist und zugänglich ist und nicht viel Mühe macht.
Ob jetzt einer eine Karte hochhält oder zehn, das ist dann auch schon irgendwie wurscht.
Naja, bei einem oder zehn, also bei einem oder mehr als einem mache ich auf jeden Fall
einen Unterschied.
Also wenn ich jetzt für mich eine Karte hochhebe, brauche ich die Karte auch nicht hochheben,
weil ich weiß genau, dass meine Schätzung aus meiner Sicht mit meinem Wissen, mit meinem
Wissensstand…
Ja, ja, klar, aber das ist ja etwas, was ja früher oft gemacht wurde.
Dass einfach ein Chefingenieur oder sowas die Aufwände geschätzt hat.
Der hat das Gesamtwissen, der hat das perfekte Wissen und dann ist das ja auch völlig okay,
wenn man diese Annahme hat und danach arbeitet.
Wenn der Chefingenieur das alles weiß, was notwendig ist und in den Köpfen der anderen
kein zusätzliches Wissen, das notwendig ist, um eine Schätzung abzugeben, besteht,
mag das ja auch völlig okay sein.
Und da bin ich zum Beispiel auch erinnert an etwas, was ich bei einem anderen Kunden vor
nicht allzu langer Zeit gemacht habe.
Nämlich ein, wie nennt ihr das, ein Roll Canvas.
Ich glaube, da hatte ich auch schon mal in einem Podcast darüber gesprochen.
Das war, genau, mein Peter Jetter, glaube ich, der unlängst bei uns zu Gast war.
Und das war ganz interessant, da habe ich mit verschiedenen Teams auf verschiedenen Ebenen,
da ging es irgendwie immer um Antworten.
Da gab es die auf Portfolio-Ebene, die Leute, die da Epics geschrieben haben oder sowas.
Und dann gab es die Leute auf Wertstromebene, die haben vielleicht Features geschrieben.
Und dann gab es die Leute auf Team-Ebene.
Die haben User-Stories geschrieben.
Und mit all diesen Gruppen habe ich jeweils ein Roll Canvas gemacht.
Ich habe die also gefragt, wie versteht ihr eure Rolle?
Was sind eure Eingangsprodukte?
Was sind eure Ausgangsprodukte?
Womit arbeitet ihr?
Was braucht ihr?
Und dann hatte man verschiedene Antworten darüber, wie denn eigentlich dieser Arbeitsfluss aussieht,
diese Verarbeitung von Informationen aussieht.
Und da konnte man eben schon beobachten, an welcher Stelle fehlt was.
Dass die einen sagen, also wir brauchen jetzt, keine Ahnung, eine Roadmap.
Und die anderen Rollen haben aber…
Da hat man einfach keine Roadmap gebaut und da konnte man sagen, an der Stelle hakt es jetzt irgendwie.
Und plötzlich entstand dann eine Klarheit darüber, nicht was machen die einzelnen Leute
oder was sollten sie machen oder so, sondern was braucht eigentlich dieser Prozess als Ganzes.
Und das war für viele Leute eine wahnsinnig lehrreiche Erfahrung,
dass jetzt wirklich mal schwarz auf weiß und ganz deutlich zu sehen,
hier fließt Information und an der Stelle versiegt sie zum Beispiel.
Und das war natürlich eine Menge Arbeit.
Also ich meine, dieser Canvas selber,
der hat irgendwie pro Team, pro Ebene allein die Umsetzung,
ich sage jetzt mal eine Stunde, anderthalb, zwei Stunden gekostet.
Ich hatte Vorbereitungszeit, ich hatte Nachbereitungszeit,
erkleckliche sogar, weil diesen Riesenwust an Informationen dann wirklich mal übereinander zu legen
und auf sich wirken zu lassen und Dinge zu sehen,
vor allen Dingen Dinge, die nicht niedergeschrieben sind, weil sie fehlen.
Das hat schon viel Energie gebunden.
Das war teuer, aber es war, glaube ich, auch wirklich wahnsinnig wertvoll.
Also hast du letztendlich das, was ich vorhin vorgeschlagen habe,
also eine Visualisierung, eine Darstellung aus unterschiedlichen Sichten
in einem Diagramm, in einem Modell zusammengetragen
und damit ein Verständnis für verschiedene andere erhöht.
Also Klarheit geschaffen oder zumindest Klarheit erhöht.
Und deswegen war es mir irgendwie ein Anliegen,
jetzt das zum Thema des Podcasts zu machen,
weil ich das Gefühl habe,
das ist etwas, was so ein bisschen unterbleibt im Alltagsgeschäft.
Man wird immer zerrieben zwischen allen möglichen Dingen,
die fertig werden müssen und die man machen muss und Wertschöpfung und so.
Und diese notwendige Pflege unserer Prozesse,
unseres Verständnisses auf ganz vielen Ebenen kommt da halt irgendwie zu kurz.
Das, glaube ich, habe ich ganz häufig gesehen.
Ich weiß nicht, Falko, siehst du das ähnlich?
Das ist etwas, was mit der Zeit sich entwickelt.
Diese gewachsenen Strukturen in Unternehmen, die halt irgendwo sind,
irgendjemand macht was, irgendwas funktioniert gut,
es wird wiederholt, es wird vielleicht sogar als Prozess definiert,
damit es andere wiederholen können und sich an die Vorgabe halten.
Dann gibt es irgendwo einen Fehler,
dann wird eine Ausnahmeregelung hinzugenommen,
dann wächst letztendlich die Dokumentation, die man dazu braucht.
Dann muss man bestimmt jedes Mal auf diese Ausnahmen achten,
gucken, dass da nicht wieder was an Problemen wächst und entsteht.
Und irgendwann hat man halt einen relativ großen Wust an Dingen,
auf die man achten muss, die man kennen muss,
auf die man sich letztendlich wieder berufen kann und sagen kann,
okay, so haben wir gesagt, wollen wir vorgehen, um das Produkt herzustellen
oder um die Dienstleistung dem Kunden zur Verfügung zu stellen.
Und ja, da bietet es sich halt an, zu schauen, wie viel Bürokratie,
wie viel Aufwand, wie viel nicht wertschöpfende Tätigkeiten sind da dabei
und wie kann man diese vielleicht auch entschlacken, wie kann man Prozess wieder runder,
laufen lassen oder wie kann man es schaffen, dass Wert wieder fließt
und nicht an vielen verschiedenen Liegestellen blockiert ist.
Und ja, dazu, also was Prozesse angeht, denke ich, gibt es gute Werkzeuge,
das zu visualisieren, Wertstromanalyse fällt mir da als erstes ein,
zu schauen, wie wird Wert im Unternehmen geschöpft,
wie kann, was sind die beitragenden Rollen oder Personen im Rahmen der Wertstromanalyse,
die Wertschöpfung, wie arbeiten diese Personen miteinander zusammen
und welche von den Schritten sind halt wirklich für den Nutzer, für den Kunden,
für den Endkunden werthaltig und welche sind halt für das Unternehmen werthaltig,
aber nicht wirklich für den Kunden und was kann man vielleicht auch im Prozess
vereinfachen, verschlanken, vielleicht sogar automatisieren,
um die Wertschöpfung zu beschleunigen.
Genau, also insofern, man hat Werkzeuge, um Kleid herzustellen,
man muss, glaube ich, solche Kleidungskraftwerke,
halt auch verteidigen, also ich glaube, dass, wenn man nicht aktiv gegensteuert,
dann nimmt die Entropie zu, die Unschärfen nehmen zu,
die Dinge gehen irgendwie so halt ihren Gang
und dann ist man irgendwann in so einem Kuddelmuddel drin.
Genau, insofern, Visualisierung hilft, Wertstromanalysen helfen,
Retros helfen, gut gemachte Retros.
Es gibt viele Werkzeuge, wir hatten ja vorhin Planning Poker
bei Anforderungsmanagement, Retrospektiven,
klar, um die Arbeitsprozesse, die man hat, zu optimieren,
sie zu reflektieren, ja, für Retros ganz viele verschiedene Methoden,
die man einsetzen kann, sei es Kommunikationsdiagramme,
mit wem, in welcher Form, über welchen Weg kommuniziert so ein Team,
wo kommen Anforderungen her, mit wem muss man sich abstimmen,
wo gibt es Zulieferungen, sind ja auch Dinge, die man gut in der Retro
mal abfragen oder verarbeiten kann, um zu schauen,
ist es denn allen überhaupt bewusst, gemeinsames Verständnis schaffen
und dann entscheidend ist, dass man sich nicht nur auf die Anforderungen, die man hat, schafft,
und dann entscheidend ist, dass man sich nicht nur auf die Anforderungen, die man hat, schafft,
auch davon abzuleiten, gibt es ja genauso in der Wertstromanalyse,
genauso aus der Analyse der Anforderungsprozesse, die du beschrieben hast,
sind ja dann Maßnahmen abgeleitet worden, um diese Vorgehensweise zu verbessern, zu optimieren,
das kann man in kleinen Schritten iterativ machen,
oder man kann halt wirklich mal einen kompletten Bereich mit Mitarbeitern neu strukturieren,
andere Arbeitsweisen von vornherein ansetzen und dann komplett vorne starten
mit einer Neubesetzung und Zusammensetzung von Teams,
zum Beispiel bei einer agilen Transformation, wenn man von klassischen silo-orientierten Ansätzen kommt
und sagt, okay, wir restrukturieren in eine Richtung, die Agilität fördert,
weil wir irgendwas mit Agilität machen wollen und machen jetzt cross-funktionale Teams,
das heißt, bestehende Teamstrukturen werden komplett aufgelöst,
neue Teams werden durch bestimmte Prozesse zusammengesetzt,
um Ende-zu-Ende-Verantwortung für Produkte, für Wertströme, für Anbieter, für Anbieter, für Anbieter, für Anbieter, für Anbieter,
für Anbieter, für Anbieter, für Anbieter, für Anbieter, für Anbieter, für Anbieter, für Anbieter, für Anbieter,
zu etablieren und so Agilität zu fördern, auch Geschwindigkeit zu erhöhen,
Warteliegezeiten aufzulösen und vielleicht dabei dann auch eine Automatisierung zu fördern,
zumindest eine Standardisierung, dass man halt dann gemeinsam in sowas wie Communities of Practice
oder in Gilden zusammenkommt und teamübergreifend dann,
was früher halt in den Silo-Teams passiert ist, über Standardisierung nachzudenken,
welche Tools, welche Werkzeuge setzten wir teamübergreifend für bestimmte Zwecke ein?
Können wir uns auf eine gemeinsame Versionsverwaltung zum Beispiel einigen?
Können wir uns auf eine gemeinsame Art und Weise, Software zu schreiben mit einer IDI einigen,
die dann die meisten Teams einsetzen? Können wir uns auf ein Continuous-Delivery-Pipeline-Werkzeug,
das dann die Informationen aus der Versionsverwaltung aufnimmt, einigen
und dann
da auch
Klarheit schaffen?
Genau, also es ist einfach, es gibt genug Werkzeuge. Ich glaube, es ist die Zusammenfassung.
Das Wichtige ist, dass man sie auch tatsächlich einsetzt und dass man diese Klarheit verteidigt
und sich vielleicht auch ab und zu mal vergewissert, dass die wirklich noch da ist.
Ich hatte zum Beispiel einen anderen Kunden vor einer Weile, die waren gesegnet mit einer Vielzahl von Mitarbeitern,
die einfach schon ganz lange da waren. Das war, also irgendwie, es war schier keiner kürzer als acht Jahre irgendwie
in diesem Unternehmen und auch in diesem Team, was also natürlich für die spricht als Unternehmen, als Arbeitsumfeld.
Aber die Kehrseite davon war, dass so viel Wissen einfach wahnsinnig implizit war.
Und nicht nur für mich als Berater, der da irgendwie von außen reinkam, sondern auch für Leute, die sie jetzt gerade neu eingestellt hatten.
Die hatten solche Schwierigkeiten, Fuß zu fassen, obwohl alle wahnsinnig freundlich und hilfsbereit waren und einem jede erdenkliche Unterstützung haben zuteilwerden lassen.
Aber ganz viel war einfach nur institutionalisiertes Wissen und keiner konnte dir so richtig sagen, warum das jetzt so gemacht wird
oder wie das jetzt läuft oder es gab keine Liste von, keine Ahnung, von Verantwortlichen beispielsweise.
Sondern das weiß man halt, wen man da anruft.
Dann kann man es lernen und dann kann man es entweder aufschreiben oder eben auch nicht aufschreiben und sich merken.
Ja, genau. Und du hast natürlich immer eine Antwort gekriegt. Also die Leute waren da auch ganz toll.
Die haben dieselbe Frage sich auch zehnmal angehört, ohne mit der Wimper zu zucken.
Aber es war halt einfach so.
Ja, genau. Und du hast natürlich immer eine Antwort gekriegt. Also die Leute waren da auch ganz toll. Die haben dieselbe Frage sich auch zehnmal angehört, ohne mit der Wimper zu zucken. Aber es war halt einfach so.
Ja, genau. Und du hast einfach so.
Einfach echt schwierig.
Es hat so lang gedauert da Fuß zu fassen.
Und ganz ehrlich.
Ich hab da so ein bisschen an mir und meinen Fähigkeiten als Berater gezwipfert und ich hab mir gedacht, das kann doch nicht sein, dass du jetzt so lange brauchst, um da irgendwie einen Dreh daran zu kriegen.
Und erst so im Laufe der Zeit und auch im Gespräch mit eben anderen Leuten, die da neu reinkam, hab ich festgestellt, das liegt vielleicht irgendwie doch nicht an mir, sondern es lag halt extra an der Organisation,
die sich da unsichtbarerweise natürlich auch echt selber an Bein gestellt haben.
Nicht nur in Bezug auf das Onboarding von neuen Leuten, sondern vielleicht dann auch für die tägliche Arbeit.
Ich weiß nicht, wie viel da noch irgendwie schwieriger war, als es hätte sein müssen.
Und was habt ihr dann gemacht an der Stelle?
Also wie seid ihr mit dem impliziten Wissen umgegangen, das halt in den verschiedenen Köpfen verteilt war?
Je nachdem.
Also es gibt so gewisse Sachen, da habe ich einfach gesagt, diesen Kampf, den nehme ich jetzt nicht auf,
sondern das steckt einfach so tief in der Organisation drin, das würde meine Möglichkeiten übersteigen, auch meine zeitlichen Möglichkeiten.
Aber ansonsten habe ich mich halt bemüht, da einfach in dieses Dickicht mal Schneisen reinzuschlagen und zu sagen,
gut, wir fangen mal dort an, wo man vielleicht eine leichte Zugänglichkeit hat.
Zum Beispiel in meinem konkreten Fall war das, ich habe mich sehr stark mit den Anforderungen befasst,
die ja, wie gesagt, auch so ein bisschen undurchsichtig flossen und ein bisschen hemdsärmelig gehandhabt wurden oder sowas.
Und das hat halt den Charme, das hängt an einem vergleichsweise überschaubaren Kreis von Leuten.
Du weißt, du musst mit deinen Product Ownern reden, du musst mit deinen Business Ownern reden, solche Sachen.
Und dann kannst du da Klarheit reinbringen.
So wie es üblich ist, gab es da natürlich auch ein riesen Dickicht von Epics, die 2019 zuletzt aktualisiert wurden,
aber nominell irgendwie halt noch aktiv waren.
Und da bin ich halt einfach einmal durchgegangen und habe gesagt, ja, brauchen wir das noch, brauchen wir das noch, ist das noch aktuell?
Und dann…
ging halt zack, zack, zack, auch eine Menge Storys einfach zu.
Ja, und auf diese Weise konnte man die Klarheit erhöhen, könnte man den Grad an, ich nenne es mal Explizitheit, auch so ein bisschen erhöhen.
Und das hat dann auch den Effekt gehabt, dass Entscheidungsprozesse leichter wurden,
weil man sich wieder darauf verlassen konnte, dass zum Beispiel die Sachen, die im Backlog stehen, auch wirklich mit Recht da drin stehen.
Und dass nicht die wesentlichen Themen von solchen, die vielleicht mal wesentlich gewesen sind, maskiert wurden, verdrängt wurden, sonst irgendwas.
Also, lange Rede, kurzer Sinn, ganz auf den Kopf gestellt habe ich, alleiniger Hansel, diese Organisation natürlich nicht,
aber ich habe schon ein paar Breschen geschlagen, ich habe ein paar Aspekte mir gesucht, wo ich tatsächlich irgendwie wirksam werden konnte
und wo ich für mehr Klarheit gesorgt habe und wo sich dann auch Wirkungen eingestellt haben, was nicht nur mich gefreut hat,
weil natürlich ist es immer schön, Erfolg zu haben, sondern es war auch tatsächlich einfach etwas, wo dann auch die anderen gesagt haben,
ja, das hat uns jetzt echt weitergebracht.
Was sind denn die Wirkungen?
Was sind denn die Wirkungen?
Was sind denn die Wirkungen?
Die Wirkung von Klarheit.
Die Wirkung von Klarheit ist, dass die Arbeit, die man von vorne reingesteckt hat, oder das ist vielleicht das Unmittelbarste,
dass die sich hintenrum wieder auszahlt, so wie meine Mutter immer sagt, keiner hat Zeit, sein Zimmer aufzuräumen, aber jeder hat Zeit, seinen Schlüssel zu suchen.
Entweder du klärst die Anforderungen halt vorher oder du klärst sie hinterher, wenn dann ein Kunde ums Eck kommt und sagt, ja, das war jetzt Mist.
Besser ist es, das vorher zu machen, weil du steigerst die Planbarkeit, du steigerst die Verlässlichkeit, auch im Sinne dessen, dass du in der Lage bist, Zusagen einzuhalten.
Für jene, die auf deinen Arbeitsergebnissen aufbauen.
Ich glaube, das ist ein ganz wesentliches Kriterium dafür, wie viel Klarheit herrscht.
Bin ich denn in der Lage, Zusagen abzugeben und die dann auch hinterher einzuhalten?
Weil das ist ja dann häufig das Allererste, was passiert, dass die Leute sagen, also, da kann ich jetzt gar nicht mich dazu äußern, weil das check ich ja gar nicht, was da alles hintendran hängt.
Oder ich weiß gar nicht, wie unsere Auslastung ist.
Ich weiß nicht, wie viel Arbeitsleistung ich dir überhaupt zusichern kann oder sowas.
Das ist natürlich einerseits roter Alarm, aber andererseits.
Auch eigentlich ganz schön üblich, ne?
Ja, gibt es teilweise.
Ich kann nicht einschätzen, wann ich XY liefere.
Kann natürlich daran liegen, dass die Anforderung unklar ist.
Kann aber auch sein, dass es der Ablauf, der Prozess nicht klar ist.
Oder es kann halt auch sein, dass ich gar nicht weiß, wer alles daran beteiligt ist.
Insofern sind das ja alles Stufen von Klarheit, die man schaffen kann.
Die Beteiligten sichtbar machen, die Abläufe sichtbar machen, die Abhängigkeiten, die dabei entstehen.
Und die.
Nicht entstehen, sondern die halt da sind, die dann sichtbar werden.
Und ja, dann in das Aufräumen gehen.
Und das bietet auf jeden Fall eine gute Grundlage.
Kann man Klarheit dann anhand solcher Aussagen, die Häufigkeit, wie sowas auftritt, wie du gerade gesagt hattest.
Ich weiß gar nicht.
Ich muss erst mal nachfragen oder ich kann gar keine klare Zusage oder keine klare Aussage treffen oder sowas.
Sind das Messgrößen, Indikatoren für Klarheit?
Ein Indikator ist, glaube ich, das richtige Wort, weil da spielt natürlich noch mehr rein als nur Klarheit.
Aber umgekehrt, wenn du keine Klarheit hast, dann wirst du dich häufig schwer tun, deinerseits klare Aussagen zu treffen und deine Zusagen dann auch einzuhalten.
Insofern, ich glaube, zum Teil gibt es eben wirklich direkte Indikatoren, wie wir es schon ein paar Mal erwähnt haben.
Das Planning Poker.
Erstens, wie groß ist die Diskrepanz für eine gegebene Story?
Und zweitens vielleicht auch, wenn man einen Schritt zurückkriegt und sagt, wie oft kommt es eigentlich vor,
dass wir da ganz weit divergierende Schätzungen haben?
Hängt natürlich an verschiedenen Wissensständen von unterschiedlichen Mitarbeitern.
Liegt letztendlich, wie lange so ein Team in welchem Bereich schon zusammenarbeitet und so weiter.
Ist ja auch völlig okay, aber wäre natürlich eine Maßzahl oder ein Indikator für Klarheit.
Genau, oder ein Indikatorchen.
Wie du sagst, da spielen natürlich eine ganze Reihe von Faktoren rein.
Aber man sieht ja schon so.
Man kann Tendenzen ablesen, das bestimmt.
Insofern solche Vergleichswerkzeuge.
Andererseits eben auch als leider ziemlich stark nacheilenden Indikator kann man sagen,
wie verlässlich bin ich denn eigentlich?
Wie gut kann ich denn Zusagen einhalten?
Ich überlege auch gerade, ob es irgendwelche voreilenden Indikatoren gibt, die mir einfallen.
Aber da komme ich jetzt gerade auf nichts wirklich Gewichtiges.
Ja gut, man könnte natürlich all die Dinge, die wir jetzt als hilfreiche Werkzeuge zum Schaffen von Klarheit aufgeführt haben,
aufgeführt haben.
In einem Unternehmen suchen, also zu schauen, gibt es, gibt es so etwas, gibt es Verantwortlichen, gibt es Kontaktlisten, gibt es ein Glossar, gibt es also eine Checkliste, durch die man gehen kann und wird regelmäßig so etwas auch aktualisiert, wäre dann die zweite Stufe.
Also gibt es letztendlich einen aktuellen Stand von all diesen Dokumentationen?
Gibt es ein Onboarding Dokument für Mitarbeiter, das auf dem aktuellen Stand ist?
Gibt es Entwicklerrechte?
Ich denke auch, dass die DORA-Metriken ganz, ganz interessant sind, was auch Klarheit angeht.
Wenn man überlegt, wenn man im DevOps-Umfeld darüber nachdenkt, sowohl Stabilität als auch Geschwindigkeit in Veränderungen zu haben, ist ja DevOps da, Continuous Delivery da.
Und da war ja eine von den Dingen, die auf alle Output-Metriken im System von Softwareentwicklung und Co. Einfluss hatten, ist denn,
alles in der Versionsverwaltung.
Dann ein Single Point of Truth, bei dem letztendlich alle Informationen nachlesbar, schriftlich dokumentiert sind und dann vielleicht auch darauf aufbauend Automatisierungsprozesse und Co. ablaufen können.
Genau, da hast du recht. Also da gibt es eine ganze Reihe von solchen Indikatoren darüber, ob sich überhaupt jemand mal die Mühe gemacht hat.
Ob es solche Informationssammlungen gibt, dann gibt es immer noch diese sekundären Fragen, ist das denn noch alles aktuell, sind die Adresslisten noch korrekt und so weiter und so weiter.
Ja, ja, aber immerhin hat man da schon mal Zeichen.
Genau, also ich würde sagen, ähnlich zur Versionsverwaltung in der Softwareentwicklung und im IT-Betrieb sehe ich, was Wissensmanagement und Kommunikation zwischen Menschen angeht, den Einsatz von einem Wiki in einem Unternehmen.
Hat ein Unternehmen ein Wiki und wird das genutzt und ist es gepflegt. Also eine zentrale Wissensquelle. Das kann jetzt ein Sharepoint sein, wenn das gut genutzt und gepflegt wird.
Das kann ein Wiki sein.
Das kann eine Dateiablage irgendwo sein, wie auch immer es ausgeprägt ist, ist dann wieder die Frage, wie gut ist es anpassbar, editierbar, wird es gepflegt, ist es genutzt und wird es auch regelmäßig aufgeräumt.
Also das, was du gerade gesagt hattest, wo dann die externe Sicht von einem Berater hilfreich ist, zu schauen, okay, lasst uns doch mal wirklich die Zeit nehmen und investieren in, wie läuft denn der Informationsfluss bei der Anforderungserhebung über die verschiedenen Ebenen, Portfolio, Management, Produkt.
Teams und Co. genau ab, wo sind Informationsquellen, wo sind Informationssenken und wo sind zwischendrin irgendwelche Sicherstellen.
Gut und um den Bogen nochmal zurückzuschlagen zu diesem ganzen DevOps-Thema.
Wichtig ist es eben gerade, wenn man in Richtung einer Transformation geht, einer DevOps-Transformation oder sowas, dass man Klarheit hat.
Erstens, wohin man eigentlich will mit so einer Transformation und dass man zweitens sich im Vorfeld oder im Zuge dessen oder wie auch immer,
sich seine Vorgehensweisen, seine Prozesse und so weiter genau anschaut, um zu vermeiden, dass man einen unscharfen Prozess dann irgendwie versucht zu automatisieren,
was entweder ins Auge geht oder, wenn man Pech hat, gelingt es sogar und dann hat man einfach irgendwas Unscharfes in Stein gemeißelt.
Aber dann hat man es zumindest scharf aufgeschrieben. Finde ich gar nicht so schlecht.
Also wenn man es jetzt automatisiert hat, dann steht es schriftlich festgehalten in einer Continuous Delivery Pipeline irgendwo.
Ein Toolkit.
Dann werden die Daten übergeben von X nach Y, auch wenn es nicht optimal ist, dann hat man es zumindest schriftlich und kann darauf aufbauen und eine gute Analyse fahren.
Ein paar Gedanken hatten wir uns noch aufgeschrieben. Feedback. Braucht man Feedback zum Thema Klarheit? Braucht Feedback Klarheit? Braucht Klarheit Feedback?
Naja, also ich glaube, Feedback braucht Klarheit, weil sonst ist es ja unklar, wozu man Feedback gibt und braucht Klarheit.
Feedback, ja, ich glaube, das haben wir auch schon ein paar Mal besprochen im Sinne dessen, es ist möglich und es ist bestimmt auch klug,
sich zu vergegenwärtigen, inwieweit oder wie groß der Grad an Klarheit momentan ist in dem Betrachtungsgegenstand.
Habe ich aktuelle Listen von Zuständigkeiten? Mache ich einen Planning Poker bzw. was beobachte ich in meinem Planning Poker?
Und so fort, dass man rechtzeitig auch gegensteuert, wenn man merkt, dass Prozesse da so ein bisschen ins Unscharfe abgleiten und irgendwelche Diffusionsprozesse einsetzen.
Was mir als Feedback im Rahmen der…
gerade erwähnten Schulung aufkam zum Thema Klarheit und Agilität und Ziele und so weiter, dass das auf allen Ebenen stattfinden muss, also auch Klarheit nicht nur auf der Team-Ebene oder für die einzelnen Individuen, sondern dass das halt in die Abteilungsstrukturen, in der Hierarchie bis nach ganz oben in die Führungsebene des Unternehmens gilt.
Also dass Klarheit auf der Ebene von Geschäftsleitung, Abteilungsleitung notwendig ist, um dann Strukturen darzustellen.
Danach auszurichten, um dann Teams in die richtige Richtung aligned, also auf das gleiche Ziel hin arbeiten, zusammenführen kann.
Ja, da hast du vollkommen recht. Ich glaube, je weiter man nach oben geht, desto wichtiger ist es.
Das habe ich eben gesehen bei einem Kunden von mir, wo von oben runter ein Mangel an Klarheit herrscht.
Wie ich gesagt habe, die machen halt irgendwas mit Agil oder auch nicht oder weiß nicht so genau.
Und entsprechend ist jetzt die ganze Organisation so ein bisschen…
An der Kippe zum Dysfunktionalen, trotz heldenhafter Bemühungen.
Aber es gibt halt einfach keine Klarheit, was wollen wir denn machen?
Wo geht die Reise denn hin? Wer darf denn irgendwas oder auch nicht?
Und das ist eine große Gefahr.
Deswegen bin ich auch immer unglücklich darüber, dass so viele Organisationen eine ganz, ich sage jetzt mal, lieblos gemachte Vision und Mission haben.
Das braucht es halt irgendwie.
Ich möchte, dass das etwas ist, was ich bei jeder Sprintplanung vorne ans Whiteboard schreiben kann, bevor wir in die Sprintplanung reingehen.
Damit ich sagen kann, okay, das, was wir uns jetzt zurechtgelegt haben als nächste Arbeitsschritte, zahlt das auf unser großes Ziel ein.
Wenn das große Ziel natürlich Mumpitz ist, dann mache ich halt irgendwas.
Also insofern sind so eine Zielhierarchien, wie sie ja mit Tractors und Key Results aufgebaut werden, natürlich ganz hilfreich,
wenn man Unternehmensziele hat, die man runterbrechen kann auf die verschiedenen Abteilungen, Teams, Gruppen, wie auch immer das Unternehmen strukturiert ist,
um dann halt zu sehen, dass das einzahlt auf das Unternehmensziel.
Das ist letztendlich hilfreich und wertvoll, ja.
Ja, ich würde sogar noch einen Schritt weiter gehen und sagen, es ist unerlässlich.
Also wenn du da nichts hast und wenn du das nicht wirklich mit deinen Mitarbeitern durchdeklinierst.
Ich finde das immer so ein bisschen schade, wenn ich irgendwo ein Training gebe und dann frage ich die Trainingsteilnehmer,
habt ihr eine Vision oder sowas?
Und dann sagt einer, ja, warte mal, ich glaube, wir hatten da irgendwo eine Präse im Internet, lass dich mich mal raussuchen oder so.
Das muss den Leuten doch bewusst sein.
Warum gehen die denn in dieses blöde Büro?
Oder heutzutage gehen sie nicht mehr ins Büro.
Sondern nur ins Remote-Arbeitszimmer.
Ja, letztendlich kann man das machen.
Dann hat man vielleicht ein erfolgreiches Unternehmen.
Oder man lässt es sein, dann hat man vielleicht trotzdem ein Unternehmen.
Auch wenn das nicht unbedingt zu den Top-10-Unternehmen gehört, die in einer Branche irgendwo Marktführer und so weiter sind.
Für viele funktioniert es ja auch mit Unklarheit.
Ja, das ist ja immer so.
Man bemüht sich ja immer, die Sachen irgendwie möglichst gut zu machen.
Aber wie viele Organisationen gibt es, die einfach…
Die einfach wahnsinnig ungeordnet sind und deswegen überleben, weil das halt irgendwie ganz vielen Organisationen so geht.
Sagen wir mal ehrlich.
Aber nichtsdestotrotz lohnt es sich natürlich, in Richtung Verbesserung zu streben.
Selbst wenn man nur noch einen weiten Weg zurückzulegen hat und vermutlich auch nie erreichen wird.
Gut.
Aber ich glaube, das war ein gutes Wort zum Sonntag.
Wir müssen, glaube ich, schauen, dass wir diese Episode mal in den Kasten kriegen.
Ja, völlig okay.
Passt für mich auch.
Appell an alle, aufräumen.
In eurem…
Prozessen, in euren Datensammlungen, in eurem Verständnis und dann drüber reden und eine gemeinsame, klare Sicht schaffen.
Auf geht’s.
Genau.
Auf geht’s.
Es gibt viel zu tun.
Fangt schon mal an.
Ja, gilt für uns auch.
Wir haben auch ein paar offene To-dos.
Das eine oder andere.
Vielen Dank für das nette Gespräch.
Ich denke, wir haben ganz…
Interessante Beiträge.
Und natürlich auch gespannt, wie das bei unseren Hörern so ankommt, wenn ihr Feedback an uns habt.
Tipps und Tricks zu Klarheit können wir auch gerne in eine Folge aufnehmen mit Gästen oder mit neuem Input.
Weißt du, was ich mir denke, Falko?
Das wäre ein schönes Thema gewesen, auch mal für eine Live-Folge, irgendwie so eine Live-Q&A-Folge.
Das müssen wir mal ins Auge fassen.
Auch das?
Sehr gut.
Sehr schön.
Also, sehr geschätzte Zuhörerinnen und Zuhörer.
Also, vielen Dank, dass ihr auch dieses Mal wieder mit dabei wart.
Ganz vielen Dank auch lieber Falko für diese schöne Episode.
Ich wünsche euch allen eine ganz tolle Zeit.
Macht’s gut.
Ja, vielen Dank.
Ciao.

Folge 75: Toyota Kata

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

In dieser Episode diskutieren die Gastgeber über das Buch „Toyota Kata“ von Mike Rother und seine Bedeutung für die DevOps-Welt. Sie erkunden die Kernkonzepte der Toyota Kata, wie das Improvement Kata und das Coaching Kata, und ziehen Parallelen zu agilen Methoden und DevOps-Prinzipien, insbesondere in Bezug auf kontinuierliche Verbesserung, Prozessfokussierung und die Rolle von Metriken und Feedback. Dabei wird deutlich, dass die Prinzipien von Toyota Kata weit über den Automobilsektor hinausgehen und auch im IT- und Softwareentwicklungsbereich von großer Bedeutung sind.

Inhalt

  • Einführung in das Buch „Toyota Kata“ von Mike Rother
  • Gemeinsamkeiten und Unterschiede zwischen Toyota Kata und DevOps
  • Bedeutung von Improvement Kata und Coaching Kata
  • Vergleich zwischen Toyota Produktionsprozess und IT-Entwicklungsprozessen
  • Fokus auf Prozessverbesserung und Metriken in beiden Bereichen
  • Anwendung der Kata-Prinzipien in der IT und Softwareentwicklung
  • Diskussion über spezifische DevOps-Themen wie Continuous Delivery und Wertstromanalyse
  • Feedback und kontinuierliche Verbesserung als zentrale Elemente

Shownotes

https://websites.umich.edu/~mrother/Homepage.html

https://www.amazon.de/stores/Mike-Rother/author/B002AQBVLE

Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)

DevOps. Auf die Ohren und ins Hirn.
Ein Podcast rund um DevOps.
Von Dierk Söllner, Falko Werner und Luca Ingianni.
Hallo und herzlich willkommen zu einer neuen Folge des Podcasts DevOps auf die Ohren und ins Hirn.
Gestaltet und produziert von Luca Ingianni und Falko Werner.
Wir sind DevOps-Trainer und Coaches mit langjähriger Erfahrung.
Der DevOps umfasst für uns kulturelle, organisatorische und technische Aspekte.
Wir freuen uns heute auf das Thema Toyota Kata.
Zu Gast haben wir, zumindest im Geiste, Mike Rother.
Das ist nämlich der Autor dieses Buchs Toyota Kata.
Und wir haben es jetzt gerade Sommer, die Sommerferien sind gerade zu Ende in Bayern.
Und über die Sommerferien habe ich mir dieses Buch Toyota Kata als Audiobuch angehört.
Und ich fand das sehr interessant und wollte mich mit Falko und auch mit euch,
liebe Hörerinnen und Hörer, so ein bisschen darüber austauschen,
was mir aufgefallen ist an Gemeinsamkeiten.
Vielleicht an Unterschieden und überhaupt, was man halt so daraus mitnehmen kann.
Auch von mir herzlich willkommen und schöne Idee.
Finde ich letztendlich gut.
Du hast dir das Audiobuch angehört, ich noch nicht.
Ich habe so ein bisschen mit Toyota Kata schon Erfahrungen gesammelt in Unternehmensumfeldern,
durch andere Coaches und in verschiedenen Umgebungen.
Nichtsdestotrotz, wenn du sagst, es ist ein Buch von Mike Rother und er ist im Geiste bei uns,
was magst du über Mike irgendetwas sagen, was ist wichtig zu wissen,
was muss man zur Person des Autors des Buches mal gehört haben?
Ja, was gibt es übrigens zu sagen?
Also Mike Rother ist ein Forscher, der ist eigentlich ein Ingenieur, so ähnlich wie wir beide,
der sich fokussiert hat auf diese Themen von Lean Manufacturing, kontinuierlicher Verbesserung
und auf diese Weise, ich glaube, mehr so versehentlich auch Toyota Kata.
Der hat sehr viel gearbeitet im Umfeld der Automobilindustrie.
Nicht nur bei Toyota und Toyotas Zulieferern, sondern auch offensichtlich, das kommt in dem Buch raus,
auch mit deutschen Automobilherstellern.
Ich habe so das Gefühl, der hat beim Daimler was gemacht oder sowas.
Er nennt keine Namen, aber irgendwie klang es immer so nach süddeutschem Raum, wenn ich das gelesen habe.
Na gut, da gibt es ja auch ein paar andere, die nicht nur Daimler heißen oder Mercedes oder was auch immer.
Aber ist ja völlig okay.
Wir müssen ja hier auch keine Namen weiter nennen.
Außer von dem japanischen Automobilhersteller, der im Namen des Titels,
was gibt es noch zu wissen?
Was gibt es noch zu wissen?
Also, der ist, glaube ich, am ehesten berühmt dafür, dass er dieses Buch Toyota Kata geschrieben hat.
Ich muss gerade mal schauen, wann wurde das eigentlich verfasst?
In den 90ern oder so?
Es ist nicht mehr so mega neu.
Er hat aus diesem Buch natürlich sehr viel Kapital geschlagen.
Also, er bietet auch Seminare an.
Er hat als Dozent irgendwie die Ideen darin verbreitet.
Aber er hat auch, also ich meine, er hat das auch wirklich sehr eingehend erforscht
und wahrscheinlich besser erforscht, als es jemand gekonnt hätte,
der einfach ein altgedienter Toyota-Mann ist,
weil er schon auch diese Sicht von außen hat.
Das fand ich auch interessant in dem Buch.
Das hat er immer wieder gesagt.
Manchmal hat er sich mit Leuten bei Toyota unterhalten und die haben ihn überhaupt nicht verstanden.
Und erst Jahre später ist er darauf gekommen,
dass die einfach eine ganz andere Perspektive auf dieselben Fragestellungen hatten als er.
Zum Beispiel, was sind Zielbedingungen?
Was ist eine gut formulierte Zielbedingung?
Und was mache ich, wenn ich die erreiche oder so?
Oder kann ich die überhaupt erreichen?
Und insofern, genau, hat er schon, finde ich, da etwas sehr Richtungsweisendes verfasst.
Ich habe jetzt gerade mal so ein bisschen recherchiert zu dem Thema Buch und Historie und so weiter
und finde da auch viele Neuauflagen, Übersetzungen und anderes.
Insofern gibt es da nicht nur ein Buch,
sondern quasi eine ganze Sammlung von Serien, von Materialien, die hilfreich sind.
Ja, genau.
Mittlerweile gibt es da natürlich einiges mehr zu den Themen,
es gibt Nachfolgebücher, es gibt Arbeitsbücher und alles sowas.
Es gibt, wie gesagt, auch das Hörbuch, das lässt sich gut anhören.
Er hat übrigens auch ein Buch, das wahrscheinlich lesenswert ist, geschrieben über Wertströme,
die ja auch letzten Endes eine Idee waren, die, ich weiß nicht, ob man sagen kann,
Toyota sie erfunden hat, aber die jedenfalls dort sehr viel Interesse genießen, Aufmerksamkeit genießen.
Genau.
Also, lasst uns doch mal kurz darüber reden, um was geht es denn eigentlich in diesem Buch Toyota Kata?
Es geht breit gesprochen darum, wie Toyota, mit welchen Methoden Toyota,
es geschafft hat, zu einem der größten Automobilhersteller der Welt zu werden
und das über Jahrzehnte zu bleiben.
Und was der Mike Rotter beschreibt, ist, dass ganz zentral dafür zwei Praktiken sind,
die auf allen Ebenen bei Toyota angewendet werden, nämlich, und er nennt die Katas.
Er sagt, bei Toyota heißen die gar nicht so, sondern da ist das halt einfach so,
wie man bei Toyota arbeitet, das hat in dem Sinne keinen Namen.
Genau, und Kata für jene, die irgendwie sich mit fernöstlichen Kampfsport,
das ist eine Übung, eine ritualisierte Abfolge von Handlungen, von vielleicht Bewegungen oder sowas,
die dazu dienen, eine Praxis tief zu verankern und deine Fähigkeiten zu verbessern.
Also quasi von dem Gedächtnis und dem aktiven Arbeiten in quasi Muskelgedächtnis zu überführen,
dass man es mehr oder weniger automatisch macht.
Das erinnert mich so ein bisschen an das Thema Scrubbing.
Scrum, das man halt auch in der Softwarewelt sehr häufig findet,
aktives Arbeiten im Team mit bestimmten Regeln, die im Scrum Guide stehen,
die man halt abarbeiten kann, regelmäßig als Event durchlaufen kann,
den Sprint mit den verschiedenen Elementen, unter anderem der Retrospektive.
Und dahinter fragt man ja auch bestimmte Dinge, die Verbesserungen angehen
oder Coaching-Elemente einfließen lassen.
Wo ist denn der Unterschied zwischen einer Kata?
Und solch einem agilen Vorgehen mit bestimmten Ritualen?
Ich glaube, in welcher Sprache der Begriff ausgedrückt wird oder so.
Nee, in der Tat ist es eine Sache, die mir auch viel in einem gewissen Sinne ist,
das Buch fast ein bisschen langweilig zu lesen, weil es irgendwie nichts grundlegend Neues zu bieten scheint.
Da wird dann halt beschrieben, es gibt diese Improvement-Kata, man kann das auch eine Retro nennen.
Es gibt eine Coaching-Kata, es gibt so Sachen wie ein Prozess,
ein Wertfokus, es gibt so Themen wie Visual Management, kann man Bretter und weiß, was weiß ich noch alles,
wo jeder gestandene Agilist halt irgendwie sagt, so, ja, kenne ich alles.
Aber das ist halt ein bisschen so wie, wenn du das Gefühl hast, dass der Goethe ja einfach nur Phrasen gedroschen hat.
Ja, der hat halt diese ganzen ollen Sprüche wieder aufgewärmt, bis du irgendwann darauf kommst,
ach nee, der hat die erfunden und wir wiederholen die jetzt bloß alle.
Keine Ahnung, mit des Pudels Kern oder sowas.
Ja, das ist halt so.
Ja, das ist halt so.
Ja, das ist halt so.
Ja, das ist halt so.
Ja, das ist halt so.
Ja, das ist halt so.
Ja, das ist halt so.
So ist das mit ganz vielen Sachen, die in dem Toyota Kata drinstehen.
Die haben sich zwar mittlerweile verbreitet, aber vielleicht wurden sie ursprünglich wirklich entwickelt,
durchdacht, zur Praxis erhoben, im großen Stil erstmalig bei Toyota.
Das weiß ich offengestanden nicht, das ist vielleicht auch gar nicht erheblich.
Keine großen Unterschiede.
Aber du hast zwei Begriffe gerade genannt, die ich gerne besser verstehen wollte.
Und zwar du hast von Katas, Verbesserungskata und Coachingkata gesprochen.
Was ist der Unterschied?
Genau.
Jetzt habe ich da schon so ein bisschen die Katze aus dem Sack gelassen.
Also, bei Toyota gibt es zwei grundlegende Praktiken.
Diese Verbesserungskata und die Coachingkata.
Diese Verbesserungskata, Improvementkata, ist ein systematischer Ansatz, um Umstände zu verbessern.
Und zwar unter den Einschränkungen von natürlich Unsicherheit, von Unschärfe,
einer komplexen, dynamisch sich verändernden Situation.
Wie kann ich da also meine bestehenden Praktiken weiterentwickeln hin zu etwas,
was hilfreicher, zielführender ist.
Und darüber gelegt, sagen wir mal, ist das Coachingkata,
das ein Ansatz ist, dass Mentoren auf jeglicher Ebene ihren Schützlingen dabei helfen,
dieses Improvementkata richtig anzuwenden.
Das Coachingkata auch sich selbst zu einer Gewohnheit werden zu lassen,
einfach durch Beobachtung.
Das ist halt das, was mein Mentor immer mit mir gemacht hat.
Und dafür zu sorgen, dass also einerseits natürlich Toyota als Organisation sich verbessert,
im Großen oder im Kleinen.
Aber vor allen Dingen, dass dieser Ansatz verbessert, gefestigt und umgesetzt wird.
Das sind die zwei Sachen, die quasi ständig ablaufen.
Und wenn du jetzt sagst, naja, das klingt jetzt natürlich auch wieder sehr nach agilen Vorgehen,
mit Kleinschrittigkeit, mit Feedback und so weiter, dann sage ich, ja, stimmt, genau.
Das ist halt genau das.
Ja, ist auch schön, wenn man die Strukturen an verschiedenen Stellen wiederfindet,
wiederverwendbare Muster hat, die in unterschiedlichen,
unterschiedlichen Unternehmen gut funktionieren und kann man sie auch regelmäßig wieder einsetzen
und weiß, dass sie gut funktionieren, weil sie halt eben nicht aus einem Unternehmen gerade kommen
und nur dort das Nonplusultra sind, sondern sind halt gute oder vielleicht sogar Best Practices.
Genau so ist es.
Und zumindest aus meiner Sicht liegt genau darin, der Wert dieses Buches,
dass es den Blick für uns weitet, die wir vielleicht immer so ein bisschen
in unseren Augen sehen.
Genau so ist es.
Genau so ist es.
Genau so ist es.
Genau so ist es.
Genau so ist es.
Genau so ist es.
Und das für mich ist der große Wert dieses Buchs, dass es wirklich sagt,
nein, das passt nicht nur auf die IT, sondern das passt auf viele Arten von Situationen,
von Aktivitäten, von Organisationen.
Ja, das sieht man ja an verschiedenen anderen Dingen, die in die IT übernommen worden sind,
aus dem Produktionsumfeld.
Da sehe ich Kanban als Signalisierungsmechanismus, Arbeitsweise zum Planen, Strukturieren von
Vorgehen von Arbeit.
von Übergaben und Abhängigkeiten von unterschiedlichen Teams, Teambereichen.
Wir hatten, glaube ich, auch mal für ein skaliertes Umfeld eine frühere Podcast-Folge gehabt zum
Thema Flight Levels, die in dem Umfeld natürlich genauso wiederverwendbar sind, wie das offenbar
bei der kontinuierlichen Verbesserung, die Toyota Kata darstellt.
Sehr gut.
Wollen wir ein Stück weiter in die Tiefe gehen?
Also du sagst, die Coaching Kata baut auf…
…auf der Improvement Kata auf.
Also das Ziel ist quasi die kontinuierliche Verbesserung und das Coaching unterstützt das Ganze.
Also würde ich jetzt sagen, wie läuft dann so ein Improvement Kata ab?
Wer organisiert das?
Wie ist da die Struktur?
Auf was muss man achten?
Gibt es irgendwelche Hilfsmittel?
Also es gibt eine ganze Reihe von Sachen.
Gerade was Hilfsmittel angeht, würde ich sagen, die sind vielleicht tatsächlich ein bisschen
unternehmensspezifischer.
Ob es da vielleicht zum Beispiel…
…Checklisten gibt oder Formulare, dass man sagt, hier ist ein strukturiertes, ein Hilfsmittel,
um dir dabei zu helfen, strukturiert, die gegenwärtige Situation zu durchdenken.
Aber ganz grundsätzlich ist so ein Improvement Kata ja einfach nur ein Ausdruck von einem
klassischen PDCA-Zyklus.
Das ist auch ein Begriff, der in dem Buch vorkommt.
Plan, Do, Check, Act.
Zuerst überlege ich mir die gegenwärtige Situation.
Dann unternehme ich ein Experiment, überprüfe dessen Ergebnis und dann reagiere ich auf
was auch immer das Ergebnis des Experiments war.
Das Interessante daran ist, dass die eben ganz ausdrücklich sagen, man soll sich auf
die Prozessverbesserung, nicht auf die Verbesserung des Outcomes, des Resultats fokussieren.
Will heißen, wenn ich zum Beispiel, angenommen ich habe eine Fertigungslinie und die soll
700 Autos diese Schicht fertigstellen.
Was eben interessant daran ist, ist, dass in diesem Improvement Kata man auch ganz klar
sich auf den Prozess fokussiert und nicht auf das Outcome, auf das Resultat.
Und das heißt, dass das Beispiel, das er in dem Buch bringt, ist zum Beispiel, wenn es
darum geht, ich habe eine Fertigungslinie, die soll in dieser Schicht 700 Autos bauen
oder sowas.
Und sie schafft es nicht.
Irgendwas läuft da schief und es ist absehbar, die kommen ins Rutschen oder sowas.
Dann gibt es jetzt 200.
Dann gibt es zwei Möglichkeiten, wie man vorgeht.
Entweder man sagt, wir müssen jetzt auf 700 Autos kommen, diese Schicht.
Dann wird man da entsprechend irgendwie Prozessänderungen vornehmen, wird, keine Ahnung, ein paar Werker
von woanders abziehen, wird die da schnell noch irgendwie mit dazustecken und schauen,
dass man im Plan bleibt, dass man sein Ziel schafft.
Das wäre vielleicht so die Art und Weise, wie es in vielen Firmen gehandhabt wird.
Und Toyota sagt, nein, das wäre völlig verfehlt, sondern wir nehmen in Kauf, dass
wir jetzt unser Schichtziel verpassen.
Diese Schicht wären es nicht nur 650 Autos, sondern es wären sogar nur 600 Autos, weil
wir machen jetzt nämlich die Pferdescheu und fangen an, Verbesserungen vorzunehmen oder
uns Gedanken zu machen oder sowas, mit dem Ziel, dass in der Zukunft dieses Problem ausgemerzt
ist.
Genau.
Passt also ganz gut zu dem Gedanken des Andern, so des Signals, die Linie zu stoppen, wenn
man ein Problem feststellt, dass man dann sich auch die Zeit nimmt, in die Ursachenanalyse
zu gehen, vielleicht 5Y-Runde durchgeht.
Entsprechend schaut, was ist wirklich die Ursache, vielleicht auch wirklich fünfmal
hintereinander in die Tiefe fragt, was ist der Grund dafür, was ist der Grund dafür,
um dann an dem ursprünglichen Kern des Pudels, von dem du, Gütte, seit ich gerade gesprochen
hast, anzusetzen und wirklich an der Ursache dann auch Veränderungen vorzunehmen und zu
schauen, dass das halt möglichst nicht wieder auftaucht.
Und manchmal sind es ja ziemlich unglaubliche, weit weg.
Von der Wirkung liegende Ursachen, wenn man wirklich in die Analyse reingeht, da zu schauen
und ganz tief zu klicken.
Okay, gut.
Also Fokus auf den Prozess statt auf die Ergebnisse.
Damit man einen stabilen Prozess hat, die Beherrschung des Prozesses quasi steigt, Sicherheit
für die Zukunft, das ist quasi eine Investition in die Zukunft der Produktionslinie und das
kann man natürlich auch auf die IT übertragen.
Das heißt…
Wenn eine Continuous Delivery Pipeline für ein Softwareentwicklungsprojekt Fehler meldet,
dann wirklich halt auch zu schauen, wo ist die Ursache, ist das halt wirklich der Code
Commit, der gerade einen Fehler produziert oder ist vielleicht auch ein Update, eine
Aktualisierung, eine Verbesserung an der Continuous Delivery Pipeline hilfreich, um umzusetzen
und in Zukunft vielleicht weniger Schwierigkeiten zu haben.
Cool.
Genau.
Und dazu muss man aber noch etwas anderes.
Was sehr zentral ist und was auch meiner persönlichen Erfahrung nach häufig sehr schwierig
ist, nämlich man muss die richtige Zielbedingung formulieren.
Target Condition, wie es genannt wird in dem Buch.
Und das ist der Einstieg in so einen Cut-Up-Prozess?
Nicht mal unbedingt ein Einstieg in dem Sinne, weil so eine Zielbedingung kann auch etwas
sehr Großräumiges sein.
Das kann wie eine Vision sein oder sowas.
Es kann kleinräumig sein.
Es kann sein, wir wollen, keine Ahnung, zuverlässig Autos für die Schicht produzieren.
Vielleicht ist das eine Zielbedingung.
Aber es kann auch sein, wir wollen, keine Ahnung, der dominante Autohersteller weltweit sein
oder sowas.
Ach, das ist richtig in Management-Ebenen, in jeder Ebene des Unternehmens einsetzbar,
nicht nur in der Produktionslinie?
Genau.
Aber das Wichtige ist eben, darum, ich habe es ein bisschen zusammengezuckt, als ich gerade
eben das Beispiel mit den 700 Autos gebracht habe, weil es wäre genau eine ganz ungünstige
Zielbedingung, weil damit setzt man einen Anreiz, kurzfristig den Prozess gerade zu
ziehen.
Damit man sein Schichtziel schafft, aber unter vielleicht in Kaufnahme eine Verschlechterung
des allgemeinen Prozesses oder einer Maskierung von Fehlern, was auch aus Toyota-Sicht genauso
schädlich ist.
Was wäre denn ein gutes Beispiel für eine Zielbedingung, wenn das Ziel, 700 Fahrzeuge
pro Schicht herzustellen, eben auf Outcome fokussiert und deswegen eher ungünstig wäre?
Ich versuche mich gerade zu erinnern.
Was?
Was?
Was ist da in dem Buch für Beispiele gebracht worden?
Und mir fällt natürlich jetzt spontan gerade keins ein.
Aber es ging immer darum, dass man im Prinzip in eine ähnliche Richtung denkt, wie im Agilen
dann immer mit dem Wertfokus, dass man also sagt, was ist das dem übergeordnete Ziel?
Zum Beispiel vielleicht für diese Fertigungslinie, wir wollen unsere Zusagen verlässlich einhalten
können.
Nicht 700 Autos, sondern die Linie ist verlässlich.
Ich habe jetzt gerade an Qualität gedacht, also ähnlich wie wir es im DevOps-Umfeld,
häufig mit Prinzipien zu tun haben, Build-Quality-In oder Ende-zu-Ende-Verantwortung auch zu übernehmen.
Halt nicht nur für eine Zahl-Schicht-Ziel oder Produktions-Output, sondern halt eine
Verantwortung auch für andere Dinge, die man aus dem Lean-Umfeld kennt.
Also ein guter, sauberer Arbeitsplatz, verlässliche Abläufe.
Das sind ja auch Dinge, die man mit zum Beispiel Wertstromanalysen oder anderen in dem Umfeld
auch häufiger auftauchen.
Also insofern diese Ende-zu-Ende-Verantwortung finde ich da ganz hilfreich, wo dann Qualität
eben auch mit reinfällt.
Genau, aber was du gerade gesagt hast, auch aus dem DevOps-Kontext, jetzt fällt es mir
nämlich wieder ein, wären dann auch gute Ziele, vielleicht solche Dinge wie Defektraten
oder sowas.
Dass man sagt, wir möchten bitte schön, auch wie man es zum Beispiel von den Dora-Metriken
kennt, mit ihren einander widersprechenden Zielrichtungen, dass man sagt, ich möchte
gerne ein hohes Ziel haben.
Also eine niedrige Produktionsrate haben und eine niedrige Defektrate zum Beispiel.
Also ein mehrdimensionales Ziel, das man dann verfolgt.
Mehrere, keine Ahnung, Messgrößen, die scheinbar widersprechend sind, wo man aber beides trotzdem
anstrebt.
Also letztendlich doch, vielleicht auch eine Steigerung mit der verbesserten Qualität,
eben nicht nur 700 Fahrzeuge zu schaffen, sondern vielleicht konstant regelmäßig 714,
nachdem man die Verbesserung erreicht hat und eine Prozessstabilität.
Und dann halt festgestellt hat, ja, da gab es halt ein Problem.
Das hat auch den Durchsatz, in dem Engpass vielleicht sogar, im besten Fall, den Durchsatz
auch beeinflusst und man kann jetzt auch mehr produzieren, nachdem man weiß, wo die Ursache
liegt.
Was interessanter übrigens auch in dem Buch war, dass Toyota durch Mike Rutter sagt, es
ist in diesem Zusammenhang häufig gar nicht hilfreich, bei der Analyse von Problemen sich
mit den eigentlichen Werkern zu unterhalten und die zu interviewen.
Weil die werden zwar auf jeden Fall eine Antwort haben, werden sie ganz bestimmt, aber sie
werden häufig den Wald vor lauter Bäumen nicht sehen.
Und die werden dir dann sagen, ja, mein Problem ist, dass mir die Schrauben ausgehen.
Wie geht man dann damit um?
Also was ist dann der Ansatz, wenn man eben nicht Go-See machen kann, also sich wirklich
das Thema von der untersten Ebene an betrachtet, sondern wie geht man dann vor?
Das ist genau das, worin die…
Kunst von guten Zielbedingungen liegt.
Dass man sagt, ich gehe nicht auf die unmittelbare Zielbedingung, den Werker dürfen die Schrauben
nicht ausgehen, sondern ich trete einen Schritt zurück und sage, was ist denn das eigentliche
Problem, das ich zu beheben gedenke oder die eigentliche Bedingung, die ich zu verbessern
gedenke.
Insofern wird man natürlich den Prozess beobachten und auch vielleicht die Prozessbeteiligten
mal sprechen, aber nicht in dem Sinne von erzähl mir mal, wo deine Probleme sind und
dann führe ich die einer Lösungsfindung zu, sondern wirklich sich hinstellen und
eigentlich die Probleme zu beheben.
Und dann schauen, was passiert denn da im Prozess eigentlich.
Und übrigens, das fand ich auch ganz spannend, weil das war auch ein neues Learning für
mich eigentlich.
Toyota sagt, häufig ist es klug, eine Prozessanalyse und eine Prozessverbesserung nicht etwa da
zu beginnen, wo man den größten Waste hat, wo man zum Beispiel die größten Digizeiten
hat oder sowas, was ja eigentlich naheliegend wäre, sondern am Ende eines Prozesses, da
wo nämlich der Kunde…
Und das ist ja genau dasselbe übrigens, was wir auch kennen, zum Beispiel aus der Softwareentwicklung,
wenn der Stakeholder ums Eck kommt mit einem ganz eiligen Requirement, das jetzt ganz schnell
umgesetzt werden muss und so und schmeißt mir hier mein ganzes Ding über den Haufen.
Muss ich vielleicht mal Sprint kippen, weil alle meine schönen Planungen sind beim Teufel.
Tut richtig weh und insofern an diesem Ende, wo Bestellungen an den Kunden gehen oder andersrum,
wo der Kunde sich äußert, da Verbesserungspotenziale zu heben, bringt häufig erst überhaupt die
Ruhe und Stabilität in einen Prozess rein, der auf den Schlag den Prozess besser macht,
aber die es einem auch ermöglicht, überhaupt zu verbessern.
Ja, gut, aber das ist ja an sich gar nicht so unintuitiv, wenn man ein Verständnis für
das Pull-System hat.
Also Toyota ist ja einer von den Vorreitern von dem, was man Lean-Management nennt und
sie haben ja bewusst mit Kanban-Karten, Signalsteuerung und Co. die Arbeitsweise am Kunden ausgerichtet,
nach den Kundenbedürfnissen.
Und der Kunde gibt den Takt vor, was letztendlich aber heißt, dass man am Ende des Systems ein
Pull-Prinzip hat und von da an natürlich auch in Verbesserungen gehen sollte, was mir
gerade den Hinweis gibt, wenn ich den nächsten Wertstrom-Workshop mache, dass ich vielleicht
auch bei der Wertstromanalyse bewusst nicht nur nach der Voice of the Customer frage,
also was ist das Ziel oder der Wunsch, Kundenwunsch oder Dankwunsch.
Und dann, wenn man es nochmal hinterfragt, das Kundenbedürfnis, sondern auch, wie endet
der Prozess und die Wertstromanalyse rückwärts vorzunehmen.
Gibt es dazu Aussagen auch in dem Buch, Toyota Kanta?
Nee, darauf geht er nicht ein.
Wertstromanalyse insgesamt kommt nicht wirklich vor in dem Buch, sondern er spricht da wirklich
über Prozessverbesserungen, die vielleicht irgendwie ein Wertstrommodell zugrunde legen,
aber das kommt eigentlich nicht zur Sprache.
Aber was anderes ist auch interessant, weil nämlich…
Also.
Zum einen, ja, Pull-Prinzip und so, aber das, was ich gerade geschildert habe, wenn
die Pulls des Kunden irgendwie zu unrund werden, dann schadet das dem ganzen Prozess.
Mit anderen Worten, einfach nur ein Pull-Prinzip macht diese Sachen ja nicht von alleine auf
einmal irgendwie wunderhübsch.
Und in der Tat, du hast mich gerade daran erinnert, das war eine der Sachen, die ich
auch nicht so ganz erwartet hatte aus dem Buch.
Er hat gesagt, am Anfang seiner Arbeit als Prozessverbesserer ist er auch oft zu forschter
reingegangen, hat gesagt, so, wir machen da jetzt überall irgendwie ein Pull-Prinzip
und kann man Bretter und alles wird wunderhübsch.
Und ist furchtbar auf die Schnauze geflogen, weil der ganze Prozess noch überhaupt nicht
stabil genug war, um sowas einzusetzen.
Sondern dann hattest du auf einmal riesige Unschärfen und Oszillationen und dann kamen
die ganzen Produktionsplaner und haben gesagt, siehste, geht gar nicht.
Wir müssen eine Produktion planen.
Ich hab dir doch gleich gesagt, das geht in die Hose.
Weil die dann, ich sag jetzt mal, das dämpfende Glied waren, dass diese Unsauberkeiten, Unrundheiten
aus dem Prozess so ein bisschen rausgehalten hat.
Mit anderen Worten, einfach nur…
Naiv, ein Pull-Prinzip einzuführen, interessanterweise, macht es schlimmer.
Das Einzige, den Vorteil, den du davon hast, du siehst dann sehr genau, wo es kracht.
An irgendeiner Stelle fliegt dir alles um die Ohren und die ist dann bekannt.
Aber deine Fertigung steht.
Genau, ist schon mal ein großer Wert, aber produziert halt keinen Kundennutzen direkt,
sondern ist ja wie bei der Einführung, wenn man jetzt sagt, agile Transformationen von
einem Unternehmen.
Agilität ist auch ein Werkzeug, das hilft, die Problemstellen…
…sichtbar zu machen, die in einem Unternehmen in der Softwarefertigung auftauchen.
Also auch da ist letztendlich ja nicht Agilität das Allheilmittel für Zusammenarbeit und
die Produkterstellung und Co., sondern ist letztendlich das Ding, das sichtbar macht,
wo die Probleme sind und damit die Chance gibt, sie zu beheben.
Genau, aber trotzdem, da muss man auch aufpassen, weil er hat dann auch gesagt, naja, da hat
er halt auch viel guten Willen verbrannt bei Schichtführern oder Produktionsbüchern,
Planer oder sowas, weil er da halt irgendwie ganz nass vor euch ankam und gesagt hat, so,
jetzt pass mal auf, ich zeige euch jetzt, wie das geht, zack, bumm.
Und es ging natürlich gar nicht.
Ja, auch da, Agilität, kleine Schritte, kontinuierliche Verbesserung, kann man sagen, starte, wo du
bist.
Also im aktuellen System, nicht 25 kann man Boards und komplett Pull-Prinzip von hinten,
sondern in kleinen Schritten schauen, okay, was passiert, wenn wir jetzt am Ende starten
und an einer Stelle den Kunden in den Mittelpunkt stellen.
Dann haben wir natürlich unrunde, vielleicht sogar Jahreszeiten oder anderen Quellen abhängige
Abforderungen im System.
Damit das Pull-Prinzip und Lean funktionieren, gibt es natürlich auch so ein paar Hinweise,
dass man eben bewusst glättet, Anforderungen glättet und einen kontinuierlichen Fluss auch
da produziert.
Also nicht nur, dass das Werkstück oder das Produkt durch die Produktionslinie kontinuierlich
fließt.
Sondern, dass man auch einen möglichst geglätteten Anforderungskanal hat.
Also lineare Auslieferung.
Und übrigens, das ist auch etwas, was Bestandteil von diesem Improvement Cutter ist, such dir
Erprobungsmöglichkeiten mit möglichst kurzen Feedback-Zyklen.
Wenn du die Möglichkeit hast, eine Linie groß umzubauen und der Umbau dauert zwei Wochen
und du hast die Möglichkeit, sie klein umzubauen und der Umbau dauert einen halben Tag, dann
mach das, was einen halben Tag dauert und versetze dich in die Lage zu beobachten.
Kleine Schritte, wie gerade gesagt.
Ja, auch da nochmal konkret.
Das ist der Kern von diesem Improvement Cutter, dass man sagt, auf jeder Ebene, an jeder Stelle
des Prozesses machen wir fortwährend solche Beobachtungen.
Man würde sagen, eine Retro im agilen Sinne.
Wir versuchen, Schwächen zu finden.
Wir versuchen, uns gute Zielbedingungen zu formulieren, die möglichst, ich sage jetzt
mal, ergebnisoffen sind, möglichst zukunftsgewandt und nicht einfach nur, es geht ja nicht um
das Schichtziel zu erreichen, sondern es geht darum, dass Toyota als Ganzes ein kleines
bisschen besser gemacht wird und dann auf dieser Ebene iterieren, Plan-Do-Check-Akt
und so weiter.
Was da noch gar nicht zur Sprache kam, übrigens, sind zwei Sachen, die auch sehr wichtig sind,
nämlich einerseits, dass alle Angestellten daran teilhaben sollen.
Also jeder soll in der Lage sein, Vorschläge zu unterbreiten.
Jeder soll dann auch in der Lage sein, sich zu vermitteln.
Jeder soll in der Lage sein, diese Vorschläge umzusetzen und auszuprobieren.
Es soll keiner eine Scheu haben, auch zum Beispiel eine Andon-Linie zu ziehen und zu
sagen, stopp, hier ist was falsch und wir müssen unsere Aufmerksamkeit darauf lenken.
Und das andere, was ich auch interessant fand, war, dass sie auch gesagt haben, ganz wesentlich
ist, dass man überhaupt einen standardisierten Prozess hat, damit man die nötige Klarheit
hat, damit man etwas hat, was verlässlich genug verstehbar und beschreibbar ist, damit
man es systematisch vermittelt.
Und systematisch verbessern und Verbesserungen beobachten kann, auch ganz im Sinne von so
Dingen wie zum Beispiel im DevOps-Kontext Automatisierung, die natürlich in sich eine
ganz kleine Standardisierung einer Vorgehensweise ist.
Gut, wir haben sehr viel jetzt über Verbesserungen, also Improvement-Kata gesprochen.
Wir haben aber auch gesagt zu Anfang, es gibt eigentlich zwei Typen von Katas.
Ich würde noch ein Stück darauf eingehen wollen, was du aus dem Buch zum Thema Coaching-Kata
sagen kannst.
Also warum gibt es die zweite Form?
Was ist der Mehrwert und wieso wird da unterschieden?
Naja, weil es zwei ganz verschiedene Tätigkeiten sind.
Vielleicht auch ein bisschen auf verschiedenen Ebenen in dem Sinne.
Also jeder soll einen Coach haben, vom Großen bis zum Kleinen sollte jeder irgendwie einen
Coach haben und seinerseits auch gecoacht werden natürlich, damit erwünschte Verhaltensweisen
wirklich durch das ganze Unternehmen verbreitet werden und gefestigt werden.
Und beim Coaching-Kata ist es eigentlich auch wieder nichts Neues, sondern es ist halt einfach
nur der bewährte Ansatz herauszufinden, was braucht denn mein Lerner, mein Schützling,
mein Coachee gerade, was ist ihre Situation, welchen Herausforderungen sehen die sich ausgesetzt
und ihnen dann dabei zu helfen, auch aus eigener Kraft diese Situation durchzuarbeiten und
selbst das Improvement-Kata anzuwenden, das Verbesserungskata anzuwenden und auch die
auf Lösungen zu kommen.
Und der Coach, wie auch in anderen Kontexten, muss sich im Zerfelsfall auch auf die Zunge
beißen und seine eigenen Verbesserungsvorschläge für sich behalten, sondern soll wirklich
nur seinem Coachee zur Seite stehen, während der das Improvement-Kata zur Anwendung bringt.
Gut, also so ein Kata-Coach ist letztendlich vergleichbar zu einem Scrum-Master, der Teams
Arbeitsweisen näherbringt und könnte auch die fünf Coaching-Kata-Fragen einem Software-Entwicklungsteam,
einem DevOps-Team beibringen und das zum Beispiel als Form der Retrospektive nutzen, richtig?
Ja.
Was sind denn die Coaching-Kata-Fragen?
Also wir haben immer von Zielzustand, Target-Konditionierung.
Schon gesprochen, darauf baut sich ja das Ganze auf, dass man Stück für Stück so eine
Struktur hat, der man dann folgen kann, richtig?
Ja, genau.
Also das ist, genauso wie du sagst, der erste Schritt.
Was ist denn mein Zielzustand?
Was ist denn meine Target-Condition, die ich jetzt gerne verfolgen möchte, die ich vertiefen
möchte, die ich verbessern möchte?
Und daran schließt sich fast automatisch die zweite Frage an.
Was ist denn der gegenwärtige Zustand?
In welcher Weise ist mein Prozess, keine Ahnung, nicht verlässlich, nicht…
Nicht robust, was auch immer, ne?
Gibt es einen Grund, warum man zuerst das Ziel und dann die Ist-Situation beschreibt?
Erst wenn ich das Ziel kenne, kann ich den Ist-Zustand ja beschreiben.
Vorher beschreibe ich ja nur irgendwas.
Weiß ich denn, ob ich diesen Zustand, den ich beschreibe, wirklich verbessern will?
Nee, weiß ich nicht.
Erst wenn ich weiß, was das Ziel ist, dann kann ich mir Gedanken machen, wo ich mich
momentan befinde.
Ja und nein.
Man kann natürlich auch sagen, wo stehe ich gerade?
Ist-Situation?
Keine Ahnung.
Das Band läuft unrund und am Ende kommen nicht die 700 Fahrzeuge raus.
Ist natürlich auch eine Beschreibung der Ist-Situation.
Ja, aber die führt uns ja erst noch zu der Zielbedingung.
Nämlich ist das Problem, dass das Band unrund läuft oder ist das einfach nur ein
irgendwie Symptom oder sogar nur ein Bestandteil der Landschaft?
Keine Ahnung.
Oder ist das eigentliche Problem ein Mangel an Verlässlichkeit zum Beispiel?
Und da könnte ich ja sagen, naja.
Unrund oder unrund läuft ist mir zweitrangig, solange ich in der Lage bin, zum Beispiel
verlässliche Zusagen zu machen.
Deswegen, natürlich wird das immer so ein bisschen ein Wechselspiel sein.
Man beschreibt eine Situation und dann überlegt man sich, was steht dahinter im Sinne von,
keine Ahnung, Five Whys oder sowas.
Und wird sagen, okay, jetzt haben wir vielleicht eine neue Zielbedingung erfasst, die auf das
eigentliche Problem abzielt.
Nee, jetzt gehen wir nochmal einen Schritt zurück und überlegen uns, können wir nochmal
eins tiefer einsteigen?
Können wir noch eins grundsätzlicher?
Oder eins ergebnisoffener?
Dass man sagt, vielleicht ist das einfach total egal, wie rund oder unrund das Band ist.
Das Problem liegt ganz woanders.
Vielleicht dürfen wir unseren Kunden einfach nichts versprechen.
Okay, genau.
Also wir haben dann letztendlich so eine Art kleine Feedback-Schleife zwischen Ist-Situation
und Ziel und findet dann letztendlich so ein gemeinsames Verständnis zwischen Coach
und Verbesserer oder Team und sagt, okay, das ist jetzt das, worauf wir uns auch vielleicht
nach einer Fünf-Mal-Warum-Frage.
Frage-Technik-Five-Why einigen.
Das ist unser Ziel.
Und dann gehen wir nochmal konkretisieren die Ist-Situation.
Wie geht es dann weiter?
Dann stellt sich die Frage, was hindert uns daran, unsere Ziel-Situation herzustellen?
Und das kann alles sein.
Das kann Prozess, Arbeitsabläufe, das können Zulieferungen, das können Produkte, Materialien,
Stifte, Platz, Zeit, Geld, irgendwas sein.
Genau, genau.
Und es kann ja durchaus auch, sagen wir mal, vergleichsweise allgemein sein.
Vielleicht ist dann die Antwort auch wieder, was relativ breit ist, das gesagt wird.
Also meine momentane Hürde ist, angenommen, das Problem ist, mir gehen die Schrauben aus.
Ich weiß nicht, wann der Schraubenlieferer mit seinem Flurförderwagelchen vorbeikommt
und mir neue Schrauben bringt oder sowas.
Genau, dann hast du also irgendwie 30, 40 verschiedene Hindernisse, die dir im Weg sind.
Wie entscheidest du, auf welches du dich fokussierst?
Ja, also wiederum.
Das Hindernis kann also vergleichsweise groß und breit sein und, sagen wir mal, ein bisschen unhandlich.
Und insofern stellt sich dann auch wieder die übliche Frage, was ist denn jetzt der nächste Schritt?
Welche Verbesserung wollen wir jetzt als erstes mal ausprobieren?
Okay, also man geht nach gesundem Menschenverstand, überlegt, was ist das, was am erfolgversprechendsten wäre.
Und dann macht man echt einen Test, ein Experiment, so richtig so klassisch, fast wissenschaftlich.
Man misst dann, ist Zustand, verändert es.
Man misst dann den neuen Ist-Zustand, vergleicht, ist es besser geworden, ist es nicht besser geworden.
Und nicht nur das, sondern auch ganz wissenschaftlich, man formuliert eine Hypothese.
Man sagt, mal angenommen, mein Flurförderfritzel mit den Schrauben, der hätte einen Fahrplan,
dann könnte ich meine Pausen entsprechend planen oder sowas und wir hätten die Schrauben nicht mehr ausgehen.
Was weiß ich?
Genau, oder ich kriege die Information, dass nach den letzten 20 Schrauben kann ich demjenigen Bescheid sagen
und der kommt dann vor.
In irgendeiner Art Kommunikation, Kanban, Signalkarte.
Die letzten 20 Schrauben sind im Karton, da ist eine Pappkarte, die nimmst du raus,
geht die Bestellung an denjenigen, der die Schrauben bringt.
Okay, sehr schön.
Genau.
Und dann schlussendlich kommt noch, an welchem Ding, an welcher Metrik, an welcher Begebenheit,
was auch immer, kann ich ableiten oder kann ich Learnings ableiten?
Also das sind jetzt so die sechs Fragen.
Um es nochmal zusammenzufassen.
Was ist meine Zielbedingung?
Da muss man natürlich auch ein bisschen iterieren, haben wir gesagt, bis man die wirklich erfasst hat.
Was ist meine gegenwärtige Situation?
Dann ist die Frage, was ist das Hindernis?
Wie komme ich vom gegenwärtigen Zustand zum Zielzustand?
Dann kommt die Frage, was ist der nächste Schritt?
Was ist meine Erwartung, wenn ich diesen Schritt gemacht habe?
Was glaube ich, was dann passieren wird?
Was wird sich einstellen?
Und dann, woran kann ich beobachten, ob sich diese Erwartung auch tatsächlich bewirkt?
Das sind so die sechs Schritte, die im Rahmen eines Coaching Cutters der Coach seinem Schützling
explizit oder implizit irgendwie durcharbeiten wird.
Und wiederum beim Coaching Cutter ist es ganz wichtig, genauso wie auch beim Improvement Cutter,
nicht zu einer Lösung fürs Jetzt zu kommen.
Es geht überhaupt nicht darum, ob man diese Schicht 700 Autos hinkriegt,
sondern Ziel ist es, dass der Coachee sich weiterentwickelt, Fertigkeiten gewinnt, Sicherheit gewinnt,
im Umgang mit dem Improvement Cutter.
Um das, egal in welchem Zusammenhang, egal auf welcher Unternehmensebene,
zunehmend selbstständig anwenden zu können.
Quasi in den Gehirnmuskel, die Arbeitsweise, die Verbesserungsweise,
die im Coaching Cutter immer wieder geübt wird, dann zu verinnerlichen
und schnell und einfach dieses Denkmuster wiederholen zu können.
Genau, das ist ja auch der Witz, deswegen heißt der Toyota Cutter.
Es ist einfach eine fortwährende Übung.
Ich mache diese Abfolge von Handlungen mit dem Ziel, dass ich eigentlich ganz automatisch
und quasi im Vorbeigehen ständig Verbesserungen im Blick habe.
Insofern ist es wirklich ein spannendes Buch.
Und zwar nicht deswegen, weil es mir etwas Neues gesagt hat,
sondern genau deswegen, weil es laute Dinge wiederholt hat,
die mir aus anderem Kontext schon hinlänglich bekannt sind.
Weil das für mich eine wahnsinnig mächtige Bestätigung dessen ist,
dass wir da irgendwie auf einem richtigen Weg sind.
Und dass wir nicht nur irgendwie in unserer Agilität bleiben,
uns da irgendwie gegenseitig beipflichten und da irgendwelchen Quatsch machen,
sondern nein, das funktioniert.
Und das funktioniert auch nicht nur in irgendwie Software-Architekten-Träumen,
sondern das funktioniert auch ganz klassisch mit gebogenem Blech
und kommt in der Tat sogar von dort her.
Das ist das Wichtige für mich daran, dass das eben eine Bestätigung ist,
eine tiefe Gründung in einem soliden, festen Boden, wo man sagt,
ja, das haben Leute schon jahrzehntelang in verschiedenen Kontexten,
ausprobiert und es war sehr, sehr hilfreich.
Aber ich meine, das hier ist natürlich der DevOps auf die Ohren und ins Hirn Podcast.
Und insofern sollten wir vielleicht nochmal ganz bewusst
als Abschluss dieses Podcasts zusammenfassen.
Wie passt das denn zusammen?
Okay, das heißt, wenn ich jetzt sage,
kontinuierliche Verbesserung ist etwas, was man als DevOps-Prinzip
zum Beispiel von der DASA kennt.
Was sagt Toyota Kata?
Was ist der DevOps-Sicht darauf?
Die stimmen aus meiner Sicht dazu.
Total überein.
Die sagen, kontinuierliche Verbesserung ist das Zentrale.
Wenn du die Wahl hast, zwischen Outcomes zu verbessern und Prozess zu verbessern,
dann entscheide dich für die Prozessverbesserung.
Weil im einen Fall hast du bloß für den einen Tag was besser gemacht
und im anderen Fall hast du für alle Tage was besser gemacht.
Dann weiteres Prinzip aus dem DevOps-Umfeld,
kostfunktionale Teams, Kollaboration, Zusammenarbeit in der Arbeitsweise.
Was gibt es da zu sagen?
Ja, darauf sind wir gar nicht so eingegangen.
Aber das ist natürlich auch,
ein ganz wesentlicher Aspekt von einerseits einem Coaching-Kata
und andererseits auch einem Improvement-Kata.
Es kann ganz natürlich vorkommen,
dass da verschiedene Spezialisierungen ganz eng zusammenarbeiten müssen.
Von mir aus, wie gesagt, die Fertigungsplaner und die Lagerlogistiker
und die Vorarbeiter am Band oder sowas müssen halt gemeinsam irgendwie was auskasperlen,
dass der Prozess als Ganzes, dass die Wertschöpfung als Ganzes erfolgreich verlaufen kann.
Also auch da sehe ich eine völlige Übereinstimmung.
Okay, dann haben wir gesagt, okay, DevOps ist meistens so ein Team-Ding.
Das heißt, den DevOps-Helden können wir mal so ein bisschen außen vor lassen.
Jemand, der wirklich von Anfang bis Ende alles kann.
Du hast kostfunktionale Teams, die Ende-zu-Ende-Verantwortung übernehmen.
Gibt es da aus dem Toyota-Umfeld Unterschiede oder Differenzen zum Thema DevOps?
Auch nicht, sondern ganz im Gegenteil wird sehr darauf gedrungen,
dass man…
Teams, seien es nun irgendwie als Ad-Hoc, einfach Gruppen von Leuten mit gemeinsamen Interessen,
als auch irgendwie fixen Teams, die zum Beispiel für einen bestimmten Bandabschnitt verantwortlich zeichnen oder sowas,
dass die gemeinsam auch in der Lage sind, übrigens auch selbst Entscheidungen zu treffen.
Dass die einfach im Rahmen von so einem Improvement-Cutter sagen,
wir glauben, wir möchten das anders machen und hier sind unsere Kriterien,
um nachzuweisen, dass das tatsächlich funktioniert.
Und dann müssen die keinen…
Manager fragen und sagen, hier, bitte, bitte, dürfen wir, sondern…
Ja, ist der Ding. Sollen die machen?
Wird sich schon zeigen, ob es gelingt oder nicht.
Das ist natürlich schön.
Das heißt, experimentieren ist nicht nur gewünscht, sondern gefordert.
Richtig, genau.
Und alles, was dazugehört.
Auch Toyota-Cutter, genauso wie DevOps, sagt, wir brauchen Rückkopplungsschleifen, ganz ausdrücklich.
Wir brauchen Metriken.
Wir brauchen einen wissenschaftlichen Ansatz mit Hypothesen und allem, was dazugehört.
Das sind…
Das sind also auch wiederum so Gemeinsamkeiten.
Bei Toyota kommen diese Feedbacks dann vielleicht aus dem Prozess raus.
Wenn ich jetzt wieder an mein Band denke, wie viele Autos fallen jetzt runter
oder wie hoch ist meine Defektrate oder sowas.
In einem IT-Umfeld vielleicht genauso.
Da habe ich ja genauso auch eine Defektrate.
Wie viele Failed Deployments habe ich?
Oder wie viele Releases pro Zeiteinheit, pro Sprint, was weiß ich,
was kann ich denn machen, ohne dass ich dabei auf die Schnauze fliege?
Ja, kann ich nach jeder Story einen Release in Produktion bringen?
Oder muss ich bis zum Ende des Sprints oder, keine Ahnung, zu einem anderen längeren Release-Zyklus warten?
Ja, genau.
Ich wollte noch so zwei, drei Dinge abklopfen.
Das eine ist Fokus auf den Prozess.
Ja, also ich glaube, der ist vielleicht bei Toyota sogar noch stärker.
Ich glaube, die sind da noch rigoroser zu sagen, hier ist die Fertigungslinie, so ist unser Ansatz.
Da gibt es ja dann häufig auch Handlungsanweisungen für die Werker, wo dann gesagt wird,
du nimmst bitte…
Eine Schraube Größe 8, tust die in dieses Loch rein, ziehst sie mit 20 Newtonmeter fest und so weiter.
Das kann schon sein, dass es da viel akribischere Anweisungen gibt
und dass dem gegenüber vielleicht in der IT zum Teil das ein bisschen offener gemacht wird,
wo es dann einfach nur heißt, ja, jetzt komm, schreib halt irgendwie Code.
Ja, teils, teils.
Wenn man jetzt überlegt, du hast eine Continuous Delivery Pipeline,
die klar definiert sagt, du nimmst Artefakt, du führst es durch 25 verschiedene Tests.
Am Ende müssen alle Tests erfolgreich abgehen.
Wenn die Tests abgeschlossen sind, dann hast du das Artefakt,
dann kannst du das auf die Testumgebung bringen
und kannst letztendlich verschiedene weitere Teststufen durchlaufen und so weiter.
Das ist ja auch klar und deutlich quasi programmiert.
Aber nicht nur das, sondern auch so Dinge wie eine Definition of Done beispielsweise
oder ein Coding Guidelines oder solche Dinge, wo man schon auch natürlich sagt,
wir wollen da eine gewisse Festschreibung haben und zwar genau zu denselben Zielen,
dass der Prozess irgendwie planbar ist, steuerbar ist, diskutierbar ist.
Aber trotzdem…
Mein Gefühl ist, dass Toyota da noch ein bisschen rigoroser ist,
als ich es häufig wahrnehme, sagen wir mal so.
Na gut, aus meiner Sicht sind wir aber da gerade zwei Dinge,
die miteinander nicht wirklich, also eher Apfel mit Birnen vergleichen.
Der Toyota-Produktionsprozess ist halt der Prozess,
der am Ende die Fertigungslinie abbildet.
Und das ist aus meiner Sicht in der IT eher die Continuous Delivery Pipeline.
Und der Produktentwicklungsprozess wird ja an der Stelle nicht wirklich häufig betrachtet.
Und das ist in der IT…
Das ist in der IT natürlich das, wo Coding, Anforderungsanalyse, Story schreiben,
Code Reviews und anderes alles ablaufen.
Die beiden würde ich ungern mischen.
Aber generell stimme ich natürlich zu.
Genau, da hast du natürlich auch recht.
Also vor allen Dingen, was sie vielleicht gemein haben,
vielleicht sollte man darauf nochmal eingehen,
ist dieser Fokus auf Prozessverbesserung und nicht Verbesserung von Outcomes.
Es ist nicht wichtig, ob du dein Sprintziel schaffst.
Es ist wichtig, dass du dich in die Lage versetzt,
genau, verlässlich in Zukunft dein Sprintziel einzuhalten, zu erreichen.
Genau, dass du lernst, bessere Sprinteinschätzungen zu treffen.
Gute Definition of Readies helfen da und andere Dinge.
Velocity-Ermittlung des Teams, Kapazitätsplanung und ähnliche Aspekte
sind natürlich im Softwareumfeld hilfreich.
Genauso wie Visual Management.
Also Dinge visualisieren.
Wertstromanalyse, Sprint-Backlog in Form von einem Kanban-Board abzubilden
und anderes im IT- und DevOps-Umfeld.
Und so ähnlich geht ja da mit Kanban auch eine Theoretaproduktionslinie vor.
Ja, oder nicht nur Kanban im Sinne von einer Planung oder sowas,
sondern auch Dashboards, wo dann drin steht,
wie viele Autos haben wir denn diese Schicht schon gemacht oder sowas.
Oder wie hoch ist die CPU-Auslastung in meinem Rechenzentrum oder was auch immer.
An vielen Ecken Metriken erfasst.
Und sie möglichst leicht zugänglich, möglichst interpretierbar macht.
Okay.
Gibt es irgendwas, wenn wir jetzt über Toyota Kata sprechen,
was wirklich ein Problem darstellt?
Irgendwas, wo wir sagen, okay, da funktioniert es nicht?
Oder gibt es irgendwo Kritik, die wir an dem Thema Toyota Kata haben
oder generell, die es gibt?
Ja, also es gibt einige Leute, die so ein bisschen an dem Buch rumlörgeln,
wobei ich die nicht so richtig nachvollziehen kann.
Es gibt halt Leute, die sagen, oh, das ist aber so stark auf Toyota fokussiert.
Ach nee.
Also insgesamt, ich finde das Buch gut.
Vielleicht würden sich manche Leute wünschen,
es würde ein bisschen konkretere, ich weiß auch nicht, Kochrezepte anbieten,
wie man zum Beispiel jetzt so ein Improvement Kata macht oder sowas.
Aber ich finde, das Buch bietet da schon ganz schön viel.
Auch im Appendix sind da einige Vorschläge drin,
einige vielleicht Checklisten drin oder sowas, einige Ablaufpläne.
Aber ganz wesentlich ist halt auch, dass man dem Geist dieses Katas genügt
und die konkrete Vorgehensweise anpasst an die Gegebenheiten der eigenen Situation,
des eigenen Produkts, der eigenen Organisation.
Also insgesamt, ich fand das Buch echt toll.
Genau deshalb, weil ich nichts Neues gelernt habe.
Möchten wir noch irgendwas als Schlussbemerkung geben?
Ansonsten hätte ich gesagt, zwei, drei Shownotes und Links.
Michael Rother arbeitet immer noch an der University of Michigan, richtig?
Wenn du das sagst, dann wird das bestimmt stimmen.
Okay, zumindest hatte ich eine Webseite dazu gefunden,
die Toyota-Kata-Website an der University of Michigan-EdU.
Den Link würde ich mit reinhängen und zumindest einen deutschen Link letztendlich,
der so ein bisschen zu dem Thema beschreibt.
Die deutsche Seite von kanbantool.com sind Sachen, die mir auffallen.
Keine Ahnung, vielleicht noch ein Buchlink, ISBN oder irgendwie so ein Thema.
Fände ich ganz sinnvoll und hilfreich.
Genau.
Genau.
Also wir werden sicherlich das Buch selber verlinken.
Auf der Toyota-Kata-Webseite ist das eh drauf.
Das ist mir fast ein bisschen sympathischer, als bei Amazon oder so zu verlinken.
Aber es sei gesagt, es gibt es auch als Hörbuch.
Ich habe bei mir das als Hörbuch angehört.
Mir kam das entgegen.
Ja, ich bin auch ein Hörbuchfreund.
Würde ich mir mal ein paar Gedanken machen.
Bei mir auf der Liste der gerade gelesenen und abgehackten sind schon einige spannende neue Bücher.
Und auch so habe ich ein paar interessante Ideen für die nächsten Podcasts.
Insofern seid gespannt.
Seid aber auch offen für uns zu kontaktieren und als Hörer auch einen Beitrag zu leisten.
Ansonsten vielen Dank fürs Zuhören.
Ja, genau.
Vielen Dank fürs Zuhören, geschätzte Zuhörerinnen und Zuhörer.
Und vielen Dank für die guten Fragen, lieber Falco.
Ja, sehr gern.
Ich freue mich auf unsere nächste Folge.
Geht mir auch so.
Wunderbar.
Also.
Macht’s gut alle zusammen.
Vielen Dank fürs Zuhören und bis zum nächsten Mal.
Ciao.
Ciao.

Folge 74: Peter Jetter zum Defragmentieren von Organisationen

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

In dieser Folge des Podcasts „DevOps – auf die Ohren und ins Hirn“ sprechen Falko, Luca und ihr Gast, der Systembiologe und Berater Peter Jetter, über die Defragmentierung von Organisationen. Sie diskutieren, wie fragmentierte Prozesse, Strukturen und Glaubenssätze die Sicht auf das Gesamtunternehmen erschweren und wie Agilität, Autonomie und eine ganzheitliche Sichtweise helfen können, diese Herausforderungen zu bewältigen. Es wird erörtert, wie verschiedene Methoden wie Scrum, Kanban und DevOps angewendet werden können, um eine effektivere und integrierte Arbeitsweise zu fördern.

Inhalt

  • Einführung und Biografie des Gastes Peter Jetter
  • Definition und Bedeutung von DevOps
  • Die Herausforderung der Defragmentierung von Organisationen
  • Autonomie und Zusammenarbeit in agilen Organisationen
  • Der Einfluss der Industrialisierung und Massenfertigung auf moderne Organisationsstrukturen
  • Vergleich zwischen traditionellen und innovativen Produktionsprozessen (Beispiel: Tesla)
  • Bedeutung von Continuous Integration und Continuous Delivery in der Softwareentwicklung
  • Die Rolle von Kommunikation und Transparenz in Organisationen
  • Anwendung von agilen Praktiken auf Organisationsentwicklung
  • Diskussion über verschiedene agile Frameworks und deren Anwendung

Shownotes

https://www.meetup.com/AgileMunich/

Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)

DevOps – auf die Ohren und ins Hirn
Ein Podcast rund um DevOps
Von Dierk Söllner, Falko Werner und Luca Ingianni
Hallo und herzlich willkommen zu einer neuen Folge des Podcasts DevOps – auf die Ohren und ins Hirn.
Gestaltet und produziert von Luca Ingianni, Dierk Söllner und Falko Werner.
Wir sind DevOps-Trainer und Coaches mit langjähriger Erfahrung.
DevOps umfasst für uns kulturelle, organisatorische und technische Aspekte.
Wir freuen uns heute auf das Thema Defragmentierung von Organisationen.
Zu Gast haben wir Peter Jetter.
Er ist ein ehemaliger Systembiologe, der als Berater, Trainer und Enterprise Coach
seit 20 Jahren Konzerne bei agilen Transformationen unterstützt.
Hallo Peter, schön, dass du da bist.
Hallo, danke für die Einladung.
Was ist denn deiner Biografie noch hinzuzufügen?
Was ist denn eigentlich ein Systembiologe?
Ja, es ist ein ziemlich interessanter,
disziplinäres Feld mit der schönen Abkürzung Eko, Evo, Devo.
Also Ökologie, Evolution und Entwicklungsprozesse.
Wie hängt die Entwicklung des Teils mit der Evolution des Ganzen zusammen?
Wie spielt das Ganze auf das Teil und das Teil auf das Ganze solche Wechselwirkungen?
Und das kannst du auf verschiedenen Skalen machen.
Sprich, wie wirkt eine Zelle und der Gesamtorganismus zusammen?
Oder ganz global galaktisch?
Wie hat der Alten?
Einfluss der Biosphäre auf dem gesamten Planeten, des Ökosystems, auf die einzelnen Lebewesen im
Ökosystem und andersrum, wie vom sozusagen die Teile des Ökosystems auf das Ökosystem und solche
Dinge. Und Systembiologie hat eben auch was mit Systemthinking, Systemmodellierung und
Systemtheorie zu tun. Ich habe eben dann kybernetische Modelle, sprich am Computer,
von verschiedenen komplexadaptiven Systemen gemacht, von Gehirnen, Immunsystemen, Ökosystemen,
pipapo. Und das ist auch was, was mir tatsächlich in meiner Arbeit mit Organisationen, die auch
komplexadaptive Systeme sind, hilft. Sehr spannend. Wir haben in diesem Podcast eine
Tradition, dass wir jeden Gast nach seiner persönlichen Definition von DevOps fragen.
Peter, was ist denn deine? Also aus dem Bauch raus eine Sammlung von
Prinzipien und Praktiken sowie einer Kultur der Zusammenarbeit und Shared Ownership zwischen in
der Regel Softwareproduktentwicklung und IT-Betrieb. Okay, wunderbar. Dankeschön. Und das bringt uns
vielleicht dann auch genau schon in das Thema rein, um das es heute gehen soll. Wir haben sie
genannt Defragmentierung von Organisationen. Was meinen wir denn eigentlich mit der
Fragmentierung von Organisationen? Also wir erleben gemeinsam ja gerade bei
einem Kundenprojekt, dass die Organisation in vielerlei Hinsicht fragmentiert ist. Wir haben
fragmentierte Prozesse, wir haben fragmentierte Strukturen, wir haben fragmentierte mentale Modelle,
wir haben fragmentierte Glaubenssätze und so weiter. Also es hat eine starke Verinselung auf
ganz vielen Ebenen stattgefunden und die erschweren es, eine gemeinsame Sicht des Gesamtunternehmens zu
erzeugen. Das ist eine große Herausforderung. Das ist eine große Herausforderung. Das ist eine große
Herausforderung. Das ist eine große Herausforderung. Das ist eine große Herausforderung. Das ist eine große
Herausforderung. Das ist eine große Herausforderung. Das ist eine große Herausforderung. Das ist eine große Herausforderung.
Wie wenn ich versuche, in einen Spiegel zu schauen, um mich selbst zu erkennen. Der Spiegel ist aber in tausend Teile
zerbrochen. Okay, also ihr seid beide gerade bei einem gemeinsamen Kunden aktiv. Ich bin da jetzt als
Mitco-Host hier in der Runde nicht ganz so drin. Wie lange hat sich das bei dem Kunden so entwickelt und
wo seht ihr den Grund für diese Defragmentierung? Sind das einfach eine Kultur in der Organisation,
die in die Richtung geht, jeder darf machen, was er will? Oder gibt es andere Quellen für diese
Fragmentierung, für diese Aufteilung, diese Inseln? Also ich denke, die Gründe sind vielfältig
natürlich. Aber eine davon ist ganz sicher die Management-Denke der letzten 100 Jahre, die halt
stark aus der Industrialisierung geprägt ist. Und in der Industrialisierung hat man eben stark auf
die Arbeitsheiligkeit geachtet. Und in der Industrialisierung hat man eben stark auf die
Arbeitsheiligkeit gesetzt. Und der Erfolg von Unternehmen in der industriellen Revolution oder im
industriellen Zeitalter, der Inhalt hauptsächlich davon ab, wie effizient kann ich etwas Bekanntes
wiederholen. Also Stichwort Massenfertigung. Da geht es ja nicht darum, innovativ zu sein und jedes Mal
was anderes zu machen, sondern der Geschäftserfolg hängt vornehmlich davon ab, wie gut gelingt es mir,
sehr oft genau das Gleiche zu tun.
Und das kosteneffizient zu machen. Während zum Beispiel heutzutage in einer Wissensgesellschaft
Geschäftserfolg sehr stark an Innovation hängt. Und das heißt letzten Endes jedes Mal was Neues,
anderes machen. Und das ist ein ganz anderer Prozess wie in der industriellen Massenfertigung.
Also die einen reden in der Massenfertigung von einem exploitativen, also einem ausbeutenden Prozess,
immer das Gleiche machen. Und in der Industriellen Revolution, in der Industriellen Revolution,
in der Innovationskultur, Wissensgesellschaft, explorativen Prozess. Also es geht immer um die Entdeckung und Erforschung des Neuen.
Und das sind halt zwei unterschiedliche Paar Stiefel, die auch unterschiedliche Vorgehensmodelle und Strategien benötigen.
Aber an der Stelle möchte ich jetzt ganz gerne nochmal einhaken, weil wir haben ja gerade so ein bisschen begonnen zu lamentieren,
dass eine gewisse Fragmentierung herrscht, dass eine Insularität vielleicht auch herrscht.
Die beobachten wir jetzt gerade bei unserem gemeinsamen Kunden Peter.
Aber das ist ja irgendwie jetzt nichts Außergewöhnliches, sondern das gibt es ja irgendwie eigentlich immer und überall.
Jetzt gibt es aber nur eine Sache, die mich dabei wundert, nämlich reden doch die ganzen Agilisten immer davon,
dass man Autonomie haben müsse. Insofern ist das denn nicht eigentlich genau das Gewünschte, dass man sagt,
jeder macht halt irgendwie sein Ding, solange es für ihn passt, ist doch alles schön.
Wieso ist jetzt einerseits Fragmentierung böse, aber Autonomie gut? Wie geht das zusammen?
In der Architektur haben wir auch so ein Grundprinzip, das heißt,
Loose Coupling, aber High Cohesion. Und die zwei Aspekte der gleichen Münze werden halt leider vergessen,
dass es die gleiche Münze sind und alle auf Loose Coupling gucken, aber das High Cohesion aus den Augen verlieren.
Und eben auch in diesem industriellen Zeitalter mit der Wiederholung des Bekannten ist es natürlich so,
dass zum Beispiel durch das Fließband jegliche,
jegliche Entscheidungen vorweggenommen sind und es sozusagen eigentlich keine Kommunikation mit meinem Upstream- oder Downstream-Prozess stattfinden muss.
Also konkret haben wir so beschrieben, wenn ich den linken Autospiegel hinschraube, dann muss ich nicht mit dem reden,
was macht der im Prozessschritt vor mir und was macht der im Prozessschritt nach mir.
In einer Entwicklungsumgebung wird das so nicht funktionieren.
Na gut, aber machen wir das nicht.
Das ist natürlich auch so in dem Umfeld Softwareentwicklung, wenn wir von Continuous Delivery Pipelines reden und dann halt sagen,
wir bauen alle Prozesse in ein Software-Fließband, in Continuous Delivery Pipeline und bringen das Ganze dann in genau diesen,
man muss nicht mehr miteinander reden, weil am Anfang schüttet der Entwickler ein neues Stück Quellcode in die Pipeline
und am Ende kann der Nutzer ein neues Stück Software nutzen, neue Funktionalität,
neues Feature, ohne dass man da groß drüber reden muss.
Zum Teil, also alles, was sozusagen Regression-Test ist, wo es ja um die Wiederholung des eben bereits Bekannten ist, ja,
aber am Anfang ist ja was anderes, also wenn ich Test-Driven-Development mache, schreibe ich ja jedes Mal einen anderen Test,
einen anderen Code und erst, weil der automatisierte Test dann da ist und zwar ein neuer, den es vorher nicht gab,
kann ich das dann…
…durch die Pipeline bis nach hinten durchschieben.
Also ich verändere ja sozusagen jedes Mal das Produktionsband, das Fließband, indem ich eben die neuen Tests, die den neuen Code abprüfen, hinzufüge.
Das ist auch ganz interessant, wenn man darüber nachdenkt, weil ein Fließband, um diese Metapher zu verwenden,
ist ja dann quasi das Gegenteil dessen, was wir gerne wollen, das ist High Coupling.
Alle Arbeitsstationen sind eng miteinander verknüpft durch dieses gemeinsame Fließband, aber Low Cohesion.
Ich habe keine Veranlassung.
Ich habe keine Veranlassung, auf den rechten Außenspiegelanschrauber einzuwirken, wenn ich der linke Außenspiegelanschrauber bin.
Ich habe aber auch schlicht und ergreifend gar keine Möglichkeit, das Fließband lässt das ja gar nicht zu.
Also selbst wenn ich ganz gerne mit ihm gemeinsam was verändern wollte…
Gut, wenn wir jetzt mal das Thema Fließband und Entwicklung mal ein bisschen weiter betrachten, dann haben wir ja, wenn ich mir irgendein Massenprodukt, nehmen wir mal ein Auto,
da gibt es eine Entwicklungsabteilung in der Organisation, die vielleicht auch agil arbeitet, die auch iterativ arbeitet, neue Varianten entwickelt und Co.
Und dann gibt es irgendwo dieses Fließband, was die Produktion macht, was dann die festgelegten Prozesse umsetzt und was immer mal wieder passiert, sind ja sowas wie Modellupdates, neue Versionen von einem Modell und Co.
Ich sehe aber Köpfe schütteln, die man beim Podcast nicht so wirklich sehen kann. Bin gespannt, wie ihr darauf reagiert.
Das ist für mich genau der Unterschied zwischen dem, was ein Herr macht, bei Tesla macht und was die meisten Deutschen…
Automobilhersteller machen. Das, was ich so wahrnehme und natürlich sehe ich nur einen winzigen Teil und das kann man nicht verallgemeinern, ist, dass im Großen und Ganzen es immer noch einem Wasserfallprozess folgt, im Sinne, ich analysiere alles, ich designe alles und dann entwickle ich alles.
Sprich, ich lege von vornherein fest, wie schaut das neue Auto aus, dann wähle ich mein Fertigungsband entsprechend um und dann habe ich zwar ein anderes Fertigungsband, das kann aber wieder…
Ich kann nur sozusagen 10.000 Euro mal den gleichen Typ herstellen. Also natürlich gibt es gewisse Variationsmöglichkeiten, die sind aber relativ gering. Während das, was ein Herr Maas bei Tesla macht, ist, der kann für jedes einzelne Auto einen anderen Produktionsprozess benutzen und trotzdem ist jedes Fahrzeug, das da durchläuft, auditiert und hat eine Straßenzulassung.
Der kann also bei jedem…
Durchlauf den Prozess und das Fertigungsband verändern und das sehe ich bei anderen Automobilherstellern nicht und das haben die meines Erachtens, glaube ich, so auch noch nicht gar nicht verstanden.
Ja, sehe ich auch so. Normalerweise ist der Ansatz, du hast einen Prozess, der alle bestehenden Kombinationen von Produkten umsetzen kann. Also du kannst halt im besten Fall über einen Fertigungsband den Kleinwagen des SUV in allen Farbvarianten, in allen Ausstattungsvarianten irgendwie…
100 Millionen verschiedene Ausprägungen von Fahrzeug herausbringen, aber du kannst den Prozess dabei nicht ändern. Ja, okay.
Wir sind ja bei Defos, wo es so ganz viel um CICD Continuous geht und das, was ein Herr Maas gegeben hat, ist Continuous Compliance. Das heißt, jedes Mal, wenn er seinen Prozess ändert, wird aber mit jeder Änderung auch gleich die Auditierung und Zertifizierung mit abgefrühstückt.
So dass eben hinten immer ein…
Straßen zugelassenes Auto rauskommt.
Um das auch nochmal zu sagen, ich glaube, das ist eines der großen Probleme in vielen Organisationen, dass man versucht, das gedankliche Modell eines Fließbandes anzuwenden auf Dinge, die überhaupt nicht Fließbandcharakter haben.
Zum Beispiel eine Softwareentwicklung und daraus resultieren dann viele, ich nenne es mal Missverständnisse, Missverhältnisse, Misskonstruktionen vielleicht, die dann ja auch häufig dazu führen, dass auf niedriger Ebene dann versucht wird, irgendwie daran was zu ändern.
Die Leute werden dann in ein Fließband…
Ein Schema gepresst, von dem sie intuitiv oder vielleicht sogar ausdrücklich wahrnehmen, das passt nicht zu der Art, wie ich arbeiten nicht nur möchte, sondern muss, wenn da was Vernünftiges dabei herauskommen soll.
Und dann kommt es halt, dass dann irgendwie sich auf niedriger Ebene Dinge entwickeln.
Da gibt es dann die berühmten U-Boote, irgendwelche neuen Arbeitsweisen werden informell eingeführt, irgendwelche Tools werden informell eingeführt.
Der berühmte Grassroots-Ansatz.
Genau, wir können ja sozusagen das Gegenbeispiel machen.
Also ich habe auch…
Und also stell dir vor, da kommt jetzt einer und sagt, so, ich möchte jetzt in drei Jahren ein Medikament gegen Magenkrebs auf den Markt bringen.
Analysier mir das, design mir die Lösung, mach mir einen Plan, was genau wann zu welchem Zeitpunkt stattfindet, dass ich in drei Jahren dieses Medikament auf den Markt bringen kann.
Das wird nicht funktionieren.
So funktioniert Forschung und Entwicklung.
Das funktioniert Forschung eben nicht, weil ich nicht weiß, was ich alles entdecken werde und was das für Konsequenzen dann nach sich zieht.
Darum heißt es eben genau Forschung und Entdeckung, weil eben die Informationen, die auftauchen, jetzt, heute so nicht vorhersagbar sind.
Ja, also finde ich auf jeden Fall spannend.
Ich fand es ganz nett.
Ich habe jetzt einen Fernsehfilm zum Tunnelbau in der Schweiz, Gotthard Tunnel, letztens gesehen.
Und diejenigen, die das gemacht haben, haben darauf gewettet, dass mit der bestehenden Technik hätten sie es zeitlich nicht im Rahmen des Budgets geschafft, dass die Entwicklung voranschreitet und was dann mit Dynamit auch gut funktioniert hat, dass sie den Vortrieb im Tunnel von zwei Metern am Tag auf vier und dann letztendlich auch auf sechs und mehr schaffen, um in der Zeit, in dem ursprünglichen geplanten Vorgehenszeitraum das Ganze zu schaffen, darauf zu wetten, dass die Entwicklung voranschreitet und was dann mit Dynamit auch gut funktioniert hat, dass sie den Vortrieb im Tunnel von zwei Metern am Tag auf vier und dann letztendlich auch auf sechs und mehr schaffen, um in der Zeit, in dem ursprünglichen geplanten Vorgehenszeitraum das Ganze zu schaffen, darauf zu wetten, dass die Entwicklung voranschreitet und was dann mit Dynamit auch gut funktioniert hat, dass sie den Vortrieb im Tunnel von
Das heißt, da gibt es natürlich eine ganze Menge Risiken, wenn man so vorgeht. Das kann natürlich auch nach hinten losgehen. Neue Techniken bringen halt auch neue Risiken. Wie kann man so etwas in einer Organisation anwenden?
Ich war vor vor 20 Jahren für 15 Jahre in der Telekommunikationsindustrie und die hat auch ziemliche Umbrüche hinter sich, also so vom Staatsmonopol zur Privatisierung von einem Technologiestack, der 20 oder 25 Jahre lang ziemlich stabil war.
Alles dann plötzlich All-IP über den Haufen geworfen, Business-Modelle von ich verdiene mich ziemlich gut mit Long-Distance-Calls und SMSen, fällt alles weg.
Und da war es dann auch so, da waren wir immer auf der Suche nach der nächsten Killer-Applikation, Killer-Anwendung, Killer-Telekommunikationsdienstleistung, die wieder die Cash-Cow wird.
Blöderweise konnte man aber nicht vorhersagen, welche der vielen Ansätze da ertragen kommen. Und letzten Endes ist es dann auch überhaupt keins geworden, sondern eine Mischung aus vielen verschiedenen Dingen.
Und da hat man eine sogenannte Shotgun-Schrotschuss-Strategie gefahren.
Das heißt, ich muss tatsächlich 30 verschiedene Produkte, 30 verschiedene Dienstleistungen, also was weiß ich, Location-Based-Services, Presence, Rich-Communication, blablabla, unterschiedlichste Dinge auf den Markt werfen.
Und mir sind vornherein klar, von diesen 30 Versuchen werden maximal 5 am Markt erfolgreich sein.
Und die müssen so erfolgreich sein, dass sie den Fehlschlag der anderen 25 wirtschaftlichen…
Also ähnlich wie das Venture-Capitalisten machen, die in kleine Firmen investieren, in der Hoffnung, dass halt eine von 10 die Investitionen in die anderen 10 mehr als wettmacht.
Ganz genau. Und letzten Endes ist es so, mit dieser Unsicherheit muss ich eben mit dieser Art von Experimentieren und Unsicherheit leben können.
Und mir muss eben völlig klar sein, ich kann Aussagen machen über so ein Set von Versuchen und Experimenten,
dass, wenn ich das mit 10 oder 20 mache, dass dann die Chance relativ gut ist, damit überlebensfähig zu sein.
Für das einzelne Element innerhalb diesem Set kann ich überhaupt nicht vorhersagen, wird es erfolgreich sein oder nicht.
Wir haben uns so ein bisschen, glaube ich, gedanklich entfernt von dem Aufhänger des Podcasts, nämlich diesem Thema von Defragmentierung.
Insofern würde ich ganz gerne den Podcast selber ein bisschen defragmentieren.
Und vielleicht ist das, was du gesagt hast, Peter, da auch ein ganz guter Aufhänger dafür.
Dass solche Schrott-Schüsse nur dann gut funktionieren, wenn man einerseits den verschiedenen, ich nenne es mal Schrottkugeln,
den verschiedenen Teams oder sowas, ausreichend viel Autonomie zubilligt, dass die da was hinkriegen.
Aber andererseits muss man natürlich auch die Kontrolle behalten über diese Gesamtheit von Einzelelementen, die alle ihre eigene Trajektorie verfolgen.
Und insofern würde ich ganz gerne nochmal eben die Frage stellen, wie sieht das denn in Organisationen typischerweise aus?
Welche Probleme finden wir? Welche Fragestellungen finden wir? Und welche Lösungsansätze haben wir da vielleicht?
Also mir begegnet dieses Thema Fragmentierung seit 20 Jahren bei praktisch allen Kunden.
Eben weil, wie organisiere ich ein großes Unternehmen von genau diesen Gedankenmodellen des industriellen Zeitarters mit der Arbeitsteiligkeit und Pipapo geprägt ist.
Und wenn man sozusagen jetzt auf diese Arbeitsteiligkeit nur den winzigen Teilaspekt der Agilität, Autonomie draufhängt,
dann kann das zur Folge haben, dass sozusagen jeder dieser einzelnen Teile sich losgelöst von den anderen selbstständig macht und wie du gesagt hast, in unterschiedliche Richtungen läuft.
Und das führt zum einen dazu, dass gesamtheitlich relativ wenig hinten rauskommt, obwohl jeder Teil für sich enorm belastet und vor sich hin rödelt und busy ist.
Aber eben sozusagen.
Durch die Reibungsverluste, der Unabgestimmtheit und sozusagen die meiste Wirkung schlichtweg verpufft.
Dann muss man sich eben überlegen, ja, worin besteht denn diese innere Reibung und warum passt das nicht zusammen und wie können wir es denn wieder passend machen, sodass hinten eben wieder was dabei rauskommt.
Und das hat mit allerlei Zielkonflikten, Systembrüchen, Pool-Landschaft, schlechten Interfaces.
Verlustbehafteten, Übergaben und allen möglichen Dingen zu tun.
Und das wird für jedes Unternehmen, wenn die sich das anschauen, werden die da sozusagen andere Muster sehen und die Antwort für das eine Unternehmen, hey, was ist jetzt der erste Schritt, um da ein Stück besser zu werden, wird wahrscheinlich anders ausschauen, als wenn die gleiche Frage in einem anderen Unternehmen gestellt wird.
Das heißt, was dann konkret zu tun ist, wird sich von Unternehmen.
Zu Unternehmen unterscheiden, aber letzten Endes muss es natürlich darauf rauslaufen, diese Fragmentierung so weit zu überwinden, dass wir A in der Lage sind, das Unternehmen als Ganzes, das System als Ganzes wieder sichtbar zu kriegen, weil dann können wir uns einigen, was sehen wir da denn?
Dann kann man sich einigen und was bedeutet das?
Und dann kann man sich einigen, was machen wir jetzt damit?
Also sind für mich sozusagen wieder die Rückführungen.
Auch die drei Säulen von Scrum, Transparency, Inspect and Adapt.
Ich muss erst Sichtbarkeit herstellen, dann kann ich es angucken und bewerten und dann kann ich Adapt, kann ich sagen und was mache ich jetzt damit?
Ja, da sagst du, glaube ich, auch was Wahres.
Insofern, als ich noch sehr lebhaft in Erinnerung habe, ich hatte mal einen Kunden, das war eine kleine Bude.
Also ich glaube nicht, dass die in Entwicklungsabteilung 20 Leute hatte.
Ich habe sie nie gezählt, offen gestanden.
Aber das war also.
Wirklich, die konnten sich auch alle sehen.
Das war noch in seliger Vor-Corona-Zeit.
Die saßen wirklich alle in benachbarten Büros, sogar mit Glastüren und so.
Aber nichtsdestotrotz gab es keine Transparenz und Klarheit darüber, was eigentlich gerade passiert in dieser Entwicklungsabteilung.
Für welchen Kunden machen die gerade was?
In welchem Stand ist es?
Welche Aspekte der Maschine, die dort entwickelt wurde, befinden sich in welchem Zustand?
Also insofern, ich glaube, man muss sich ganz bewusst sein, sowas passiert.
Wahrscheinlich sogar, wenn man nur zu zweit arbeitet.
Und es wird wahrscheinlich nicht besser, je größer die Organisation wird.
Genau.
Also für mich eben immer diese Metapher mit dem zerbrochenen Spiegel.
Die Unternehmen können sich nicht selber erkennen, weil der Spiegel eben zerbrochen ist.
Und dann ist sozusagen die Aufgabe, den Spiegel peu à peu wieder zusammenzusetzen und ein realistisches Selbstbild zu kriegen, um dann beurteilen zu können,
schaut das Bild denn so aus, wie es ausschauen soll?
Und nicht.
Was soll anders sein und was müsste man tun, um es anders zu machen?
Aber dann, also um zum Beispiel das Beispiel zu verwenden des Unternehmens, in dem wir jetzt gerade uns gemeinsam befinden, Peter und ich.
Die einzelnen Bereiche des Unternehmens verwenden von mir das Azure DevOps und andere verwenden bestimmt Jira und noch andere haben einfach nur gute alte Excel-Tabellen.
Auf die Weise, da stimme ich dir zu, kriegt man natürlich keine gemeinsame Sicht hin.
Aber ich stelle mir jetzt die Frage, was macht…
Was mache ich denn da jetzt konkret?
Ich meine, selbst wenn ich jetzt hingehe und sage, Excel-Tabellen sind verboten, dann muss ich ja trotzdem…
Die lösen sich nicht von alleine in Luft auf.
Ich muss eine Alternative schaffen auf Prozessebene, auf technischer Ebene, auf kultureller Ebene vielleicht gleich gar.
Also das…
So schlaue Berater wie McKinsey und so, die haben da natürlich gleich ein Wort dafür gefunden.
Reverse Conway Manoeuvre.
Also sprich, dieses Conway’s Law.
Dass Organisationen sozusagen…
Dazu verdammt sind, ihre Informationsstrukturen dann in ihren technischen Systemen abzubilden und der Weg ist dann sozusagen, das genau andersrum wieder zurückzuführen.
Also indem ich sozusagen die technischen Systeme wieder zusammenschließe zu einem einheitlichen Ganzen, folgt dann sozusagen auch die Information und das Gedankenbild der Organisation.
Und…
Ja, war es eben so, dass genau das passiert ist.
Man hat sich sozusagen auf einer relativ hohen Abstraktionsebene, aber immerhin sozusagen auf einen gemeinsamen Prozess geeinigt, auf gemeinsame…
Wie schaut denn unsere Wertschöpfungskette aus?
Hat es dann runtergebrochen in ein gemeinsames Equirement oder Arbeitsmodell?
Also sprich, ja, wir haben…
Also das ist jetzt Vira oder Ashford DevOps.
Und wir bilden verschiedene Ebenen ab.
Team, Team of Teams, irgendwie größere Einheiten und letzten Endes Gesamtportfolio.
Jeder Ebene gibt sozusagen einen Value Stream, wie Dinge von links nach rechts, von Bedarf erkannt bis zu Bedarf befriedigt, irgendwie fließen.
Und offensichtlich müssen diese Ebenen ja irgendwie zusammenhängen.
Und das ist das, was wir in der agilen Welt, eben was ich sehe, wir als Teams haben Storys als Flow.
Also Items, die fügen sich vielleicht zusammen zu Features, was dann eher so Dinge sind, die auf Teams-Ebene, wo eben mehrere Teams zusammen dran arbeiten, an dem Feature sich zusammentun.
Diese Features zahlen wieder ein auf, was weiß ich, eine Capability einer großen Solution, zahlen wieder ein auf irgendein Unternehmens-Applic.
Und sozusagen diese Kette, sich überhaupt mal darauf zu einigen, dass wir so eine Kette haben wollen, dass klar wird, ich als Mensch im Team,
mache dies, weil zahlt ein auf das, zahlt ein auf das, zahlt ein auf Unternehmens-Ziel.
Und andersrum, genau von oben, kann ich natürlich runterbrechen, hey, um dieses Unternehmens-Ziel zu erreichen, machen wir in der Solution das,
im Value Stream das, im Team das und der einzelne Mensch das.
Und daraus lässt sich dann eben dann sozusagen ein Gesamtbild aller Arbeit und wie die zu dem Gesamtbild,
das das Gesamtziel beiträgt, erzeugen.
Und das ist natürlich aufwendig, das ist viel Arbeit, das herzustellen, aber da kann man sich dann anfangen, sinnvollerweise.
Meiner Erfahrung nach da, wo Leute eben bereit sind, sich auf sowas einzulassen, also dieses Volunteering-Prinzip, die Freiwilligkeit.
Für wen macht das Sinn? Wer will das ausprobieren? Wer macht da mit?
Und dann sucht man sich eben da, versucht da Proof of Concept oder eben…
Sozusagen zu beweisen, dass das tatsächlich besser ist, als das, was man vorher hatte.
Und wenn dem so ist, dann finden sich auch immer wieder neue Menschen, die sagen, hey, ich will auch das Bessere haben, ich will das auch.
Ja, aber trotzdem, wo ich dich so habe, erzählen, hören von wegen, ja, wir haben da sehr viel konsolidiert, wir haben da ganz viele Prozesse zusammengefasst und so.
Also, Hand aufs Herz, das ging doch nicht ohne Streit, oder?
Natürlich nicht. Also dieses Einigen ist Einigungsarbeit und verschiedene Perspektiven.
Perspektiven und Sichtweisen zu einer gemeinsamen Sichtweise zusammenzuführen, ja, ist halt Arbeit.
Und das erfordert einen Diskurs und Debatten und Austausch von Argumenten und zum Beispiel auch sich einigen, wie entscheiden wir denn, wie bewerten wir, ob etwas gut oder schlecht ist.
Also, bevor man sozusagen diese Entscheidungen, das eine ist besser, wie das andere ist, muss man sich erstmal darüber anschauen.
Einigen, wie entscheiden wir denn, ob etwas gut oder schlecht ist und diese Entscheidungskriterien, auf die sich einigen.
Und das ist das, was wir zum Beispiel als Save the Economic Model sagen.
Also, wir brauchen ein gemeinsames Gedankenmodell, nach dem wir Entscheidungen treffen.
Ja, das ist interessant insofern, als ich beobachte, dass dieser erste Schritt häufig nicht gemacht wird.
Man entscheidet sich für Lösungen, ohne dass vorher klar ist, was ist denn eigentlich das Ziel dieser Lösung?
Woran kann ich denn erkennen, dass eine Lösung, die ich jetzt vorstelle, vorteilhaft oder weniger vorteilhaft ist oder inwieweit ich die gewünschten Ziele dann auch tatsächlich erreiche?
Also, ich denke, eigentlich haben wir Agilisten da seit 20 Jahren ein Modell dafür, dieses Validated Learning und genau die Idee von Test First.
Also, ich muss mir eben erst Gedanken machen, wie schaut mein Akzeptanztest aus?
Die Akzeptanzkriterien und dann kann ich was bauen, das meinen Akzeptanztest grün macht.
Das ist in der Softwareentwicklung nicht anders als mit beliebigen anderen Unternehmensentscheidungen.
Oder in der Evolutionsbiologie, wo man bestimmt erst eine Hypothese festlegt, bevor man sein Experiment designt oder durchführt.
Ja, oder anders. In der Evolution, da wird erstmal gemacht und dann geguckt, ob das neue Lebewesen in der Umwelt gut passt.
Ja, da muss ich jetzt ein bisschen gegensteuern, weil Evolution ist eben kein teleologischer Prozess, sprich, der ist nicht zielgerichtet.
Die Evolution hat ja kein Zielbild, da will ich hin, sondern die macht tatsächlich sozusagen diese Schrotstoßstrategie, erzeugt verschiedene Varianten und selektive Prozesse sorgen dann dafür, dass gut nimmt, Töpfchen die schlechten.
Na, kann man dann vernünftig überlegen?
Ja, man kann ja viele Unternehmensziele definieren, die immer sinnvoll sind, an denen man sich orientieren kann.
Immer, hast du ja vorhin das eine Beispiel bei einem Telekommunikationsunternehmen gesagt, auch das geht nicht immer.
Ja, genau. Also nicht umsonst nennt auch Google all seine Initiativen und Projekte Bets, also Wetten, um ganz klar den Charakter herauszustellen.
Ja, das ist eine Wette basierend auf den Anliegen.
Mit den Annahmen, mit den Informationen, die uns jetzt und hier und heute zur Verfügung stellen.
Die Realität wird zeigen, wie gut oder schlecht diese Annahmen waren und sich eben Dinge realisieren oder auch nicht.
Das ist das Nächste, was vielen Unternehmen schwerfällt, ist sowas wie probabilistische Planung.
Also sie kennen immer nur schwarz-weiß, ja, nein, gibt’s oder gibt’s nicht, ist wahr oder ist falsch.
Ja, und so, naja, die Wahrscheinlichkeit, dass sich das als wahre Aussage erweisen wird, ist 60 Prozent.
Damit können die meisten Unternehmen nur sehr schwer umgehen.
Ist ja auch nicht ganz einfach. Was mache ich denn da jetzt draus in Bezug auf eine Budgetentscheidung?
Gebe ich da jetzt nur 60 Prozent des Geldes dafür aus oder was wäre denn meine Reaktion auf Eintreten zur Wahrscheinlichkeit 60 Prozent?
Das ist ja noch der super einfache Fall, den Unternehmen auch seit Jahrhunderten kennen.
Das ist Risikomanagement.
Das Schöne am Risiko.
Das Schöne am Risiko ist ja, es ist ein Known-Unknown.
Und was ist Known beim Risiko? Eintrittswahrscheinlichkeit und Impact.
Und warum geht dann trotzdem so viel in die Hose?
Naja, weil es neben diesen Known-Unknown eben Unknown-Unknown gibt.
Also Dinge, die ich überhaupt nicht auf dem Radar habe, wo ich weder Eintrittswahrscheinlichkeit noch Impact kenne,
noch dass es dieses Risiko oder diese Möglichkeit überhaupt gibt.
Und wenn man sich, es gibt auch Untersuchungen dazu, anguckt, was sind denn die Gründe, warum irgendwie Projekte, Initiativen und sonst was scheitern,
dann fällt fest, ja, unser Risikomanagement hat funktioniert.
Die Risiken, die wir identifiziert haben, die hatten wir auch im großen Teil im Griff.
Was uns das Genick gebrochen hat, waren Sachen, die wir überhaupt nicht auf dem Schirm hatten.
Also diese Überraschungen.
Und dann sind wir wieder da, wo wir vorher waren.
Was sind Vorgehensmodelle oder Strategien für kompliziertes System?
Systeme, die eben ziemlich vorhersagbar sind, wo alle Informationen, die notwendig sind, um sozusagen festzustellen, welches Ergebnis kommt hinten raus,
a priori vorneweg schon bekannt sind.
Und was ist ein komplexes System, das gekennzeichnet ist durch das Phänomen Emergenz?
Also dass eben ständig neue Informationen auftauchen, die aber ziel- und damit handlungsrelevant sind.
Und die ich also fortlaufend in mein Handeln integrieren muss.
Ohne, dass ich weiß.
Was ist es denn, was ich in einem Monat, einem Jahr tun werde oder tun muss, um das Ziel zu erreichen?
Dann sind wir, glaube ich, wieder zurück bei diesem Punkt der Defragmentierung.
Weil ich unterstelle jetzt einfach mal, dass, wenn ich eine zu stark fragmentierte Sicht habe, der von dir angesprochene zerbrochene Spiegel,
dann bin ich ja gar nicht in der Lage, auf unbekannte, auf unknown unknowns zu reagieren.
Die known unknowns, das kann ich mir irgendwie zurechtlegen.
Da kann ich auch in einer hochfragmentierten Organisation, da können die dann wahrscheinlich mit großer Mühe, aber die kriegen das bestimmt hin.
Entsprechende Lösungsverfahren, Reaktionen und so weiter irgendwie mir zurechtdengeln.
Aber was passiert in einer stark fragmentierten Organisation, wenn jetzt irgendein unerwartetes Eintritt, eigenes Eintritt,
dann bin ich ja letzten Endes völlig hilflos, weil ich diese Gesamtsicht gar nicht habe.
Und dann jedes Einzelelement halt für sich irgendwie panisch versucht, was zu zeicheln.
Also ich löse sozusagen lauter lokale Lösungen aus,
die in der Regel sich eben leider nicht magisch zu einer globalen Optimierung zusammenführen,
sondern eben genau im Gegenteil in der Regel sich gegenseitig aufheben und eben massive innere Reibung erzeugen
und am Schluss sozusagen relativ wenig Gesamtwirksamkeit dabei rauskommt.
Also genau das ist das Problem.
Diese lokale Sichten führen zu lokaler Optimierung,
was in der Regel einer globalen Optimierung,
entgegenwirkt.
Also mit einer globalen Sicht bekommen, wie bekommt man die durch ein gesamtes Unternehmen?
Also es fängt an mit einem einheitlichen Denkmodell.
Und auch dieses gemeinsame Denkmodell lässt sich halt nicht mit Flick of a Swip weiter umlegen, erzeugen,
sondern das ist wieder diese Alignment-Arbeit, diese Einigungsarbeit.
Und ich muss halt anfangen, wo sind drei Leute, die sich auf ein gemeinsames Gedankenmodell einigen können,
dann fünf, dann zehn, dann hundert.
Was ist so ein Gedankenmodell?
Sind das die agilen Skalierungs-Frameworks, sind das Produkt- und…
Kann ein Orientierungsrahmen sein, aber eben zum Beispiel ganz konkret eben,
wir haben unterschiedliche Ebenen, Teams, Teams of Teams, was weiß ich, Solutions, Epics,
wir haben Storys, bla bla bla.
Das war ein Aspekt eines gemeinsamen Gedankenmodells.
Und da gibt es noch viele andere und die muss ich halt…
Reihen nach sozusagen beleuchten und beackern.
Und genau wie du sagst, ja, es gibt auch fertige Gedankenmodelle, an denen man sich orientieren kann.
Zum Beispiel agile Frameworks oder diese, auch Kanban hat ja sozusagen Grundprinzipien und Core Practices.
Das sind schon mal so Anhaltspunkte, an denen man sich entlanghandeln kann.
Und auch in Kanban ist natürlich das Erste, was ist wert?
Also die sich darüber einigen, was ist wert?
Und wie entscheiden wir, was ist wertvoller als etwas anderes?
Das ist Punkt Nummer eins.
Und das an sich ist schon ein Gedankenmodell.
Was ist unser gemeinsames Modell für Wert?
Ja, und was mir auch gerade irgendwie sehr in Erinnerung ist,
nicht nur überhaupt dieses gemeinsame Modell zu haben,
oder ja, das ist auch sehr wichtig, vielleicht sogar zentral,
aber das andere ist dann eben auch wirklich Kommunikationsflüsse durch die Organisationen,
die Organisationen sicherzustellen.
Ich hatte das jetzt gerade bei unserem gemeinsamen Kunden Peter,
dass ich mit denen so Rollenworkshops gemacht habe,
mit Leuten, die sich mit Produkt befassen, und zwar auf verschiedenen Ebenen.
Von der Portfolio-Ebene bis runter zu den Product Ownern in den einzelnen Teams.
Und wo wir gesagt haben, okay, was sind denn die Artefakte, die ihr baut?
Was sind denn die Informationen, die ihr von anderswo, in der Regel häufig von Strom auf, bekommt?
Und was sind die Informationen, die ihr nach Strom ab weiterreicht?
Und das war ganz interessant zu beobachten,
dass man dann wirklich sehen konnte, wo sind gewisse Informationsfäden abgerissen.
Die haben es dann geschafft, Ebene 1, Ebene 2, Ebene 3, pang, und dann waren sie weg.
Und in Ebene 4 haben dann die Leute auf einmal die Hände hochgehoben und haben gesagt,
wir haben gar keine Roadmap, die wir gut verwenden können.
Genau. Und das ist für mich ein wichtiger Punkt.
Also das ist immer so dieser Streitpunkt, Huhn-Ei-Diskussion.
Muss erst das Mindset da sein, oder muss sozusagen erst das Verhalten da sein?
Und da gibt es so den Spruch, es ist leichter, sich in eine neue Art des Denkens einzuarbeiten,
als sich in eine neue Art des Arbeitens einzudenken.
Also ich muss sozusagen, wenn ich Strukturen schaffe, die Umgebung verändere,
die ein neues Verhalten ermöglicht, dieses neue Verhalten führt zu neuem inneren Erleben.
Und dieses andere innere Erleben.
Das neue Erleben fängt an, meine inneren Modelle und Glaubenssätze und sonstige Dinge zu verändern.
Es ist meiner Erfahrung nach, wie eher ein Schuh draus wird,
als erst zu versuchen, hier an gemeinsame Gedankenmodelle zu appellieren
und daraus dann ein gemeinsames Verhalten abzuleiten.
Also es ist leichter sozusagen, wie kann man ein unterschiedliches Verhalten ermöglichen,
indem ich die Umgebung verändere, Strukturen.
Strukturen verändere, was zu unterschiedlichen Erleben und Erfahrungen führt
und diese wiederholt unterschiedlichen neuen Erleben und Erfahren.
Die fangen an, meine Haltung, meine Sicht auf die Welt und so weiter zu verändern.
Ja, ich glaube, das ist ganz wesentlich.
Insbesondere, wenn man jetzt wieder Bezug nimmt auf die technologische Unterfütterung vieler Prozesse,
auf Automatisierung oder sowas, die bewirkt für sich erstmal nichts.
Wenn ich jetzt einen schlechten Prozess habe, dann ist das eine gute Idee.
Wenn ich einen guten Prozess automatisiere, dann ist er halt zehnmal so schnell schlecht.
Genau. Aber der Punkt ist, wenn ich zum Beispiel eine Testautomatisierung habe
und eine Continuous Integration, um mal dieses Beispiel zu verwenden,
dann versetze ich mich in die Lage, schnell zu iterieren,
ohne dass es mir besondere Mühen abverlangen würde.
Und das wird natürlich dann auch zu einer Veränderung meines Verhaltens führen
und zu einer Veränderung meiner Denkweisen.
Dann kann ich es mir auf einmal erlauben, vielleicht viel wertorientierter,
viel nutzenorientierter zu arbeiten, weil ich mich einfach ganz schnell an so einen,
Wert vielleicht hin iterieren kann.
Und weil Experimente auf einmal weder teuer noch schmerzhaft sind,
sondern einfach nur die ganz gewöhnliche Art zu arbeiten.
Genau. Also das ist das, was ich vorwiegend funktionieren gesehen habe.
Also eben sozusagen die Möglichkeit für anderes Verhalten schaffen,
das eben dann zu anderen Erfahrungen führt.
Und das dann über die Zeit sozusagen genau wie du sagst,
hey, wenn ich leicht und schnell und billig Experimente machen kann,
dann kann ich auch einmal sozusagen ganz andere Dinge tun und andere Strategien fahren.
Erinnert mich so ein bisschen, es gibt ja von Peter Drucker ein Zitat,
Culture eats strategy for breakfast.
Und dafür gibt es eine Erweiterung von, und zwar aus dem LESS-Framework,
ich glaube Lars Border hatte da mehrere Konzepte zusammengebracht.
Und die Erweiterung lautet, Structure eats culture for breakfast.
Das heißt, wir haben Structure als Grundlage, ähnlich wie du es gerade gesagt hast,
Strukturen schaffen, Kommunikationsstrukturen.
Organisationsstrukturen, die im besten Fall nach Conway’s Law auch gut zusammenpassen.
Dann hat man eine gute Grundlage geschaffen, um die Unternehmenskultur
durch Verhaltensänderungen und Co. zusammenzubringen,
um dann eine Unternehmensstrategie umzusetzen.
Ich glaube, das ist eine ganz gute Grundlage für ein Gedankenmodell,
auch in diesem ganzen Umfeld.
Ja, genau. Jetzt kann ich ein bisschen aus dem Mäh-Täschchen plaudern.
Ich habe gesagt, ich war in der Telekommunikationsindustrie.
Das war nämlich genau da, wo dieses,
das LESS-Framework entstanden ist, NSN 2007.
Und tatsächlich ist das, was ich jetzt da gefasst habe,
in Umgebung verändern, damit sich Verhalten verändert,
dass sich Erleben und Erfahrung verändern,
dass sich dann mentale Modelle und Glaubenssätze verändern.
Das war tatsächlich genau diese praktische Erfahrung zu dieser Zeit dort,
aus der dann sozusagen das LESS-Buch und das LESS-Framework dann auch entstanden ist.
Aber jetzt mal Butter bei die Fische.
Weil wir haben jetzt irgendwie uns,
uns sehr gemütlich ausgebreitet in irgendwelchen hohen philosophischen Sphären.
Aber wie macht man das denn,
dass man eine typische Organisation,
die so eine gewisse Fragmentierung hat, wieder einfängt?
Was sind denn da Werkzeuge,
die ihr als vielleicht besonders wirkungsvoll beobachtet habt?
Das Wichtigste für mich ist,
es gibt kein One-Size-Fits-All.
Also es gibt nicht den universellen Schlüssel,
wenn ich den in das Schloss meiner, in mein Unternehmen stecke und umdrehe,
dann löst sich die Fragmentierung auf.
Also das ist schon mal der erste Zahn, den ich versuche immer zu ziehen.
Sondern ich muss mir halt, also was sind die Fragen?
Was ist eine Herausforderung in meinem Unternehmen?
Was müsste sich ändern, damit es besser wird?
Und dann?
Was muss ich an mir ändern, damit es wahrscheinlicher wird,
dass diese Änderung eintrifft?
Und es sind sozusagen immer die gleichen drei Fragen,
aber die Antwort wird immer eine andere sein in jedem Unternehmen.
Und das ist für mich das Wichtigste,
was die Unternehmen für mich lernen müssen.
Vergesst dieses Blueprints-Zeug
und es gibt die eine Lösung, die immer und überall funktioniert,
sondern was ist so sehr wichtig,
was mir sehr wohlgibt, ist sozusagen dieses Set von sinnvollen Fragen,
die ich mir stellen kann.
Und dann muss ich eben dieses Set von Fragen stellen und gucken,
was kommt bei mir in meinem spezifischen Kontext dabei raus.
Und dann kann ich daraus auch ableiten, hey, was wäre jetzt wohl der erste beste Schritt?
Und natürlich gibt es schon eine Sammlung von Practices oder Dingen,
aber die gibt es in der Agenda nicht.
Das ist eine Agilität seit 20 Jahren und dieses Toolset liegt seit 20 Jahren offen.
Oder länger, wenn man Kanban und Co. auch als Agilität versteht.
Scrum, Lean, Kanban, DevOps, OKRs, Test First,
ist ja alles ein alter Hut.
Wo findet man die Fragen, die man sich stellen muss, gut zusammengefasst?
Gibt es da eine Quelle, die du empfehlen kannst?
Ja, das ist jetzt ziemlich interessant.
Also ich habe mich ja schon geoutet.
Eigentlich komme ich aus der Less-Welt und das erste Less-Book war nichts anderes als ein Fragenkatalog.
If you see this, try that.
If you see this, try that.
Aber Less hat sich nicht durchgesetzt.
Was hat sich stattdessen durchgesetzt?
Save, die genau eben nicht diesen Ansatz gefahren sind,
sondern gesagt haben, wenn du keine Idee hast, probier es mal damit.
Und zwar nicht sozusagen runtergebrochen auf die einzelnen Dinge, die ich da alle sehen kann,
sondern die haben eben sozusagen dir die Mühe erspart,
diese 100 Fragen einzeln zu stellen
und auf 100 Mal eine einzelne kontextsensitive Antwort zu finden,
sondern haben gesagt, hey, wenn du keine Ahnung hast,
dann nimm dir ein Gedankenkonstrukt, an dem du dich orientieren kannst
und dann versuch mal, dem nahe zu kommen und bei dem Weg, dem näher zu kommen.
Da wirst du schon selber merken, dass bestimmte Fragen und Antworten auftauchen,
die dir dann helfen, dich weiterzuentwickeln.
Im besten Fall jedenfalls.
Es kann natürlich auch passieren, dass das so ein bisschen nach hinten losgeht
und dann ist das so wie bei Per Anhalter durch die Galaxis,
wo doch bekanntermaßen die Antwort auf die Frage aller Fragen ist.
Genau, ist 42.
Die Antwort ist 42.
Und in diesem Sinne, die Antwort ist safe, genau.
Egal, was dein Problem ist, wir haben die Lösung.
Das kann passieren.
Natürlich, kluge Leute werden dann dieses Safe Framework auch,
wie du sagst, als Anstoß nehmen, um auf die richtigen Fragen zu kommen
und dann sich für die eigene Organisation, für die eigene Situation,
die richtigen Antworten zu erarbeiten.
Und um das zu sagen, ich bin überzeugt davon, dass man Agilität,
das hast du ja eigentlich auch schon durchklingen lassen,
nur agil umsetzen kann.
Mit anderen Worten, auch all die Mechanismen,
die wir für die Produktentwicklung reklamieren,
die müssen wir natürlich auch auf unsere Organisationsentwicklung anwenden
und sagen, Hypothese bauen, Experiment machen, schauen, ob es funktioniert hat,
genau, und dann gehst du in den nächsten Schritt.
Und deswegen, das ist vielleicht meine Antwort auf, was funktioniert gut,
Sichtbarkeit herstellen.
Also ich bin immer noch unter dem Eindruck von der Wirkmächtigkeit dieses,
Roll Canvas Workshops, den ich eben kürzlich gemacht habe,
wo man dann wirklich quasi nachzeichnen konnte, wenn man genau hingeschaut hat,
wo Informationen versickert sind und wo es dann stromab plötzlich wehgetan hat.
Und wenn man das weiß, dann tut man sich natürlich auch leichter zu sagen,
okay, dann sorgen wir jetzt halt dafür, dass an dieser Stelle die Information durchgängig wird,
dann ist dieses Problem gelöst oder gelindert, dann wird sich natürlich das nächste auftun,
aber mit dem machen wir es dann halt gleichermaßen.
Ich meine, warum ist überhaupt Agilität entstanden?
Also weil halt, sagen wir mal, den Weg, den mir bisher gegangen ist,
schlichtweg nicht mehr funktioniert hat.
Also bei uns da in der Telekommunikationsbranche,
wir haben natürlich auch klassisches Portfolio-Projekt-Programm-Management,
bla, gemacht.
Das Problem war nur, das hat immer weniger funktioniert und zwar so wenig,
dass das existenzgefährdend war.
Und wir mussten schlichtweg lernen, Dinge anders zu machen.
Und das ist eben dieser Unterschied.
Was weiß ich, diese gute Vorhersagbarkeit, kompliziert,
Stacey-Matrix oder Canifin-Framework, komplizierte Systeme, einfache Systeme und komplex.
Und für komplex, da brauche ich eben Annäherungsverfahren.
Iterativ, inkrementell, inspect and adapt.
Und also was kann noch komplexer sein, als eine 50.000-Mann-Organisation zu verändern?
Das liegt in der Natur der Dinge, dass wir da komplex unterwegs sind
und folglich nur iterativ, inkrementell, mit Annäherungsverfahren vorwärtskommen können.
Sehr schön. Peter, vielen Dank, dass du da warst.
Und vielen Dank für die interessanten Gedanken, die du mit uns geteilt hast.
Haben wir noch irgendwas vergessen? Gibt es noch irgendwas, auf das du uns hinweisen möchtest?
Also, ich bin einer der Co-Hosts des Meetups.
Agile Munich.
Das ist ein englischsprachiges Meetup.
Wir sind so 3.000 Mitglieder, versuchen jeden Monat etwa eine Session zu machen,
bei der so 100 Leute sind.
Die Sessions sind mal remote, mal hybrid, mal vor Ort.
Wenn ihr was Spannendes zu erzählen habt, dann meldet euch bei uns
oder guckt mal unter meetup.com, Agile Munich, was da an Sessions schon lief oder ansteht.
Würde mich freuen, wenn wir uns vielleicht treffen.
Und den Link packen wir natürlich in die Show Notes.
Wunderbar. Dann Peter, Falko, vielen Dank.
Auch von mir. Bis bald.
Ja, bis bald. Ciao.
Ciao.

Folge 73: AI in DevOps [EN]

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

In this episode, Luca talks to Amit Eliav of GetAI to get a feel for the kinds of changes that AI may bring to DevOps.

We explore both the technical and the human communication side of applying AI tools as they exist today.

In this episode, the guest, an expert in generative AI, delves into the integration and impact of artificial intelligence in the field of DevOps. The conversation covers various aspects such as the distinction between AI and automation, the history and development of AI, and its practical applications in current DevOps tasks. They discuss the advancements in AI tools like ChatGPT and their potential to automate and enhance various processes in software development and operations, while also addressing the challenges and limitations of AI in this field. The episode concludes with a discussion on future possibilities and the importance of understanding and effectively integrating AI into DevOps practices.

Inhalt

  • The role and evolution of AI in DevOps
  • Defining AI and its distinction from automation and data science
  • Historical perspective on AI development and its mainstream adoption
  • Current applications of AI in DevOps tasks
  • Potential and limitations of AI in automating DevOps processes
  • Future expectations and trends in AI technology
  • Practical steps for integrating AI in organizational processes
  • The importance of validating AI outputs in production

Shownotes

Amit’s website: https//:getai.consulting

Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)

Welcome to a new episode of DevOps auf die Ohren und ins Hirn.
Or in English, DevOps from your ear straight to your brain.
Usually this is a German-language podcast, but we sometimes make exceptions for international guests.
Today is one such exception.
Welcome to the show.
A few years ago, I researched generative AI at the university.
Before it was called generative AI and also built a generative AI venture.
Even before I built a system as a software engineer in the military, AI products for big companies.
So how long is it that big companies have been using AI then?
So back in 2018, I worked for Microsoft.
And I can attest to that.
That I was part of an AI team trying to improve their accommodation system, Xbox.
I’m not sure how long before companies have been using it.
And that was used in production.
So that wasn’t just a research project that Microsoft or something.
Absolutely.
And it was not something new back then in 2018.
That brings me to a question that I’ve been itching to ask.
But I think we’ll take this question second.
And first, we’re going to honor the tradition of this podcast of having every guest.
Give us their own personal definition of DevOps.
So Amit, what’s yours?
So I thought about it.
And my definition of DevOps is doing the hard, back in the shadows, necessary work.
That doesn’t get the praise when it deserves it.
And when everything goes well.
But gets all the spotlight when things go wrong.
So if I’m hearing you say this, it feels like you’re talking very, very specifically about the production side.
Of.
You know, operation side of IT, is that right?
Yes.
Okay.
The question that I’ve been wanting to ask is to maybe actually come similar to the question we just answered, to come up with a definition of AI.
Like, what’s the difference between an AI and an automation?
Like, I suppose we can agree that Jenkins is not an AI, but where does AI begin?
And also where do maybe adjacent approaches live?
You know, what, what’s the difference between an AI and just a heuristic?
Or what’s the difference between AI and just data science?
Because like I, I imagine that what you did for, for this Xbox recommendation engine, you know, might have been just, just a regular statistics engine, right?
You find correlations, And you just spit them out.
Where does AI actually begin?
It began at, at the resistance level very, very long ago, but around 2012 neural nets became more in the mainstream.
Yes, they have become weak.
Not that, but they have become weak because, where does the AI actually begin?
Not really in the mainstream, but they got more powerful together with advances in computations.
I think AI started very long ago, in the 1980s or 1970s.
Yeah, but I didn’t mean when does AI begin in terms of time, but in terms of, I don’t know, complexity or what distinguishes an AI from a statistical model?
That’s a really funny question.
A few years ago, I read a book, Gedela Scherbach, which is a very old book that talks about AI.
And the definition there is very funny, actually.
AI definition changes all the time, because when computers are able to do something we back then thought was impossible, then this becomes AI for a few years.
But then people say, everyone can do that.
That’s not AI.
That’s just a computer vision.
Back then, Alan Turing defined AI, a program that can pass the Turing test, when you talk to a computer.
Arguably, Eliza could do that back in the 60s or 70s, I guess.
Yeah, they passed it long ago.
But in conclusion, AI definition changes all the time as per what’s the new development.
And what differentiates it from just machine learning?
Actually, every machine learning is an AI, but it’s not necessarily the other way around.
You can just write a very complex algorithm, and it can also be AI.
All right.
So what is the answer?
And the answer is, nobody knows?
Is that what it boils down to?
Or is it anything that looks like witchcraft?
It’s a good question.
AI is basically artificial intelligence.
So everything that you’d call that has intelligence and is artificial is AI.
And the definition of what’s really intelligent, it changes all the time.
Okay.
All right.
Another question that I wrote down for you, and which I suppose I can already sense the answer to,
is what’s different about the AI craze that we see today now?
What’s different about it than the first AI craze of the 1970s?
And then the one in the 1980s, and then the one in the 1990s.
I can’t remember one in the 2000s, but that might just be me.
But it feels like everything.
In 10, 15 years, there’s a new AI craze.
So what’s different about the present one?
So about this, I think a few things are different.
The most obvious thing is that now it is very generally available.
The ChatGPT by OpenAI was, I think, the quickest product to get to 100 million users.
So it’s very generally available.
And it is very, very good.
It’s very powerful.
It inhabits knowledge, not like a real human, but close to it.
And you don’t need or have to be a pro data scientist to use it.
So people just started to tell each other, oh, I saw this new product.
It’s ChatGPT.
It helps me do my work better.
And just the word spread like crazy.
So to summarize, you don’t need to be a pro.
You don’t need to be a pro to use it.
Yeah, I think that might be the big difference, right?
I imagine back in the, from what I read back in the 70s, only a handful of people could use it.
And probably it was able to do surprising things even back then.
But it never moved to the mainstream, right?
Because I suppose computers weren’t really mainstream back then.
Yeah, actually, the huge development was even a few years before ChatGPT.
By the model GPT.
But it didn’t really get to the mainstream because of the UI that exposed it.
ChatGPT really resonated with people because it is very intuitive.
It’s just a chat.
Everyone can use, just log in and interact with the language model that it is.
Yeah, that’s interesting, right?
That the power of an AI engine is not just, you know, influenced by the actual power of the neural network or whatever other thing is behind it.
But also.
How, as you said, how approachable it is for regular humans.
And whether you can actually ask it the right questions and then understand its answers.
Yeah, absolutely.
And that’s one of, arguably, one of the biggest little genius of OpenAI.
I’ve never used AI in production.
And I’m really curious to talk through some approaches with you.
And so let’s just try to maybe think about ways in which you could.
Imagine AI might be usable presently in, you know, in DevOps work.
In DevOps work.
So what, maybe you can discuss it a little bit.
What do you think are the biggest pains in the DevOps work currently?
Well, of course, it depends on who you ask and it depends on the specifics.
But, you know, one thing that I find is really difficult to get right is to have a good visual.
And so it’s really a matter of human communication.
And I’m wondering in what ways AI would be helpful there.
Or another thing that I’m seeing is how to ensure continued high quality of our product.
So I’m thinking in terms of, you know, supporting production.
Or I’m thinking in terms of having a solid library of tests.
Or I’m thinking in terms of being able to discover value.
For example.
For our customers.
So it’s, I’m sorry, it’s quite broad.
But there must be something juicy in there where you can say, oh, yeah, this feels like a task that today’s AI could be helpful for, you know, for real cross-functional DevOps teams.
Yeah, absolutely.
So the first thing you said, you could just build all the documentation of the organization.
And that includes even code.
Like real.
Code.
Like Java code.
Python code.
Data about onboarding presentations and history of Slack messages.
And have a bot that is the first responder to questions about the orgs data.
And what it does is just scanning through the orgs data everything.
And comes up with an answer.
If it’s good enough, you can just check that it’s done.
You don’t need a real human doing a machine’s job in that way.
And if it’s not good enough, so a human can step in and provide better support.
And the second thing you said is ensuring the continuous quality of the product, right?
What do you mean?
Like automating tests?
Possibly.
You know, could I use, quite specifically, could I use the AI to derive test cases from like user stories?
Absolutely.
Yeah, you can do that.
Okay.
And could I trust a present AI system to come up with valuable, useful and correct test cases?
Or would a human still need to double check?
In general, when generating code, it’s very recommended to use a human in the loop approach.
Because there will be always small misunderstandings.
And small errors a human would need to check and fix.
But it can definitely do the first go.
And let it do the boring work that’s possible to automate and add real value on top of the AI.
Right.
So I would feed it a user story.
And it would come back to me with a suite of tests that I would, I suppose, still need to fill in a couple of blanks.
Right.
So correct.
A couple of misunderstandings.
Essentially only like a code review, right?
You know, I don’t actually have to write all of this myself.
I can read it through and say, yeah, this looks great.
This looks great.
Ah, you know, there’s something dodgy going on over there.
But only making corrections and not generating the test cases myself.
So I would expect it to generate some good test cases.
Some that would be not good.
And to push to production, like not the real direction at all.
And I’d expect you to generate some tests yourself or ask the ChatGPT to come up with more test cases that fits better what you need.
So I could even iterate with ChatGPT and reference the old test cases that it made and said, well, those are not cutting it.
Make better ones.
Yeah, absolutely.
It’s quite good at that.
Interesting.
And to me, that is something that feels very important to enable ourselves to close those feedback loops quickly.
Because I feel like that is still something that is a struggle for many organizations to really, you know, not just build the forward direction,
but also ensure that tests get created early enough, in high enough volume, that they are run often enough.
So that’s very interesting.
Perhaps even more interesting than doing.
Ah, that’s an interesting idea.
Could you have an AI do an on-call work and have the AI respond if something, you know, if the monitoring fires an alert or something?
Yeah, actually I thought about it a little bit yesterday.
I wouldn’t trust it to be the only on-call guy.
I would currently trust it to ease the work of the…
Maybe surface real insights that says where the problem lies and a suggestion of what to do to fix it.
But I wouldn’t hire an AI and risk all the reputation of a company because maybe there will be a bug and maybe it won’t be 100% accurate.
Sometimes it just makes stuff up.
We all face it, right?
Oh, that’s, that’s interesting.
Talk more about this making stuff up.
Yeah, so how it’s trained is to produce output that looks good, but it does not have to be correct.
It’s really, really good at completing what you ask it to do.
So if you ask it to do something and it doesn’t know how to do it,
it might not tell you and just make stuff up that don’t exist.
Like we just, what we’ve seen, it makes up papers, names in science that don’t exist just to support its cases.
And its output looks good, but sometimes it just looks good and it’s just false.
And wouldn’t there be a way of having the AI be honest and say, well, I don’t know, instead of just making something up?
Yeah, you can ask it.
You can really, really stress.
Stress it to it.
It’s good because it’s really good at the following instructions.
And if you give it the possibility and it’s a good practice to always give it a way out,
like instead of asking it to classify a sentence between true or false,
give it also the neutral option when it’s not sure or tell it if you’re not sure, say, I don’t know.
I wouldn’t currently put an AI to do all the responsibilities.
I would just give it the ability of the on-call and just assist the…
And do you expect that AI will sort of remain in this assistive role or can you, do you expect AI to grow as far as actually replacing, for example, an on-call engineer for the ordinary on-call tasks?
It’s really interesting with the rise of AutoGPT.
I’ll recap quickly what it means.
AutoGPT is just an agent, an AI agent, where you send it to do something.
And give it some tools to do it, like search the web, search Wikipedia, use a calculator and chooses which skills or tools to use and comes back to you with a solution once it has it.
So in the future, I’m guessing yes, because it’s such a pain being on-call, right?
And waking up in the middle of the night, having to understand what’s wrong and saving the infrastructure of the company.
Basically, I think it’s an important enough problem expected to be solved.
One of the things that characterizes technological development is the exponential face of it.
Basically and generally, I think it’s very unintuitive how fast the future technology will pace.
Like we’ve all seen during COVID and understood a little better exponential math.
Now, all this technological advancement only makes…
the pace go faster and faster in a way that’s very unintuitive.
So to recap, yeah, I think in the future, it will be solved, unintuitively and before we know it.
Interesting.
So what I’m getting a sense of is that AIs do better, the better their training data is, the more regular maybe it is.
So I wonder if something like helpdesk work, that should be essentially…
a perfect task for an AI, right?
The typical set of problems is fairly limited.
The resolution is often the same.
There’s hopefully good documentation and so on.
Yeah, yeah, yeah.
That’s a very close problem.
And I think even today you can put an AI and companies are doing it already.
Like putting AI as a first responder, letting a human deal only with the more complicated,
unsupported tasks.
How would I actually do that?
Like, let’s assume that I want to ease the burden of my helpdesk workers by applying an AI in production.
Is that a stage in a Jenkins pipeline?
How do I use an AI in this capacity?
So by helpdesk, what do you mean?
Like general questions about IT and…
Yeah, that sort of thing.
Oh, my printer is not working.
Oh, my password.
Reset.
Oh, okay.
Maybe those are even too simplistic things, because like that that can literally be handled by an FAQ.
But yeah, sort of just your regular helpdesk type conversations.
So the ones that can be handled by an FAQ definitely can be solved today by just giving a summarized answer from the FAQ documentation from the organization.
I guess there are products that do that.
But you can also develop something for free on your data using a Python library called Langchain, which is a new library that takes all the organization knowledge, it can be anything textual, it indexes it in a way that it can query it very, very efficiently.
And once it receives a question from someone seeking support from the help desk, searches for the relevant part of the organization knowledge or documents, and it can just summarize the answer. And it’s really easy to use, very quick.
That brings me to an interesting, different thought. Like, maybe you’re familiar with the idea of the wall of confusion.
Okay, so that is a concept that is often used in DevOps too.
To describe what goes on between, let’s call it a traditional development team and a traditional operations team, where each has their own job, you know, the development team’s job is to write code.
The operations team’s job is it to take this code and have it run in production somehow.
The problem with this separation is that you get conflicts of interest, right?
The developers essentially are only concerned with churning out lots of curly brackets.
That’s a difference.
The operations guys, of course, say, well, we don’t actually care about new stuff.
Our role is it to guarantee stability.
So please don’t change anything.
Please don’t rock the boat.
That way we can guarantee stability.
And the whole premise of DevOps was to remove this conflict of interest.
And in fact, this sort of almost language barrier or certainly barrier of perception by saying, you know what?
You all together are responsible.
You are responsible for continuously delivering value to the customer.
So if, you know, if the system goes down, that’s not just operations problem.
That’s everybody’s problem.
And conversely, if we are too slow at iterating and creating new value, that’s not just developments problem.
That’s everybody’s problem.
And I was long introduction.
My question was, how could maybe AI and chat GPT really help overcome this language barrier?
So I was thinking, you know, could I, as maybe an ops engineer,
use chat GPT to help me figure out where in the code a particular bug might lurk?
So not give definitive answers, but something of the nature of, oh, yeah, look over there.
That’s, you know, that’s a likely candidate.
Is that something that would be doable?
I guess, you know, you could have the AI read the entire code base and then make assumptions about where something happens.
That’s absolutely doable.
I think Copilot X by GitHub.
Is going to do that.
So I don’t suggest implementing it from scratch, but feel free if you want.
You can, you can just ask a GPT or chat GPT to spot a bug in your code.
It comes up with good answers sometimes.
And yeah, it’s, it’s for sure doable, can be done.
It can even ease the burden of a code review and make, you know, linking rules in a code review.
So it can do, instead of just linking rules, it can spot bugs or ask for changes that are sometimes a little awkward to ask.
So you know that, that it’s a little awkward.
So you say, ah, as a code reviewer, I’ll pass that.
I already posted enough comments.
If a bot, just a bot, it doesn’t feel bad.
So it can ensure a better code for everybody.
Even better, better relationships.
Because sometimes.
Sometimes people take it personally.
Yeah, that’s, that’s true.
Right.
Okay.
So how would I, I guess I interrupted you in answering that question before.
How would I actually practically do that?
How would I integrate an AI into my workflow?
Let’s call it AI Linter, just be a pipeline stage.
Sounds like it, doesn’t it?
Yeah, it can be, it can be.
If you, if you want to develop a custom solution, so it will be.
If you.
But I don’t recommend, I just recommend.
If you want to do it for fun, so go ahead.
But I think free, low cost solutions are going to be very high quality.
Do you expect them to stay low cost?
I do.
I do.
Because there is currently a race in the world.
Arguably last week, real AI breakthrough.
Because Google came out with their own good version of AI.
People say the iPhone revolution didn’t happen.
When the iPhone came out, but when Google came out with Android.
So if you can compare the two, right now is the iPhone revolution of AI.
Because now we have competition.
We have competition.
We have all the big companies trying to come out, come up with their own large language models.
And when there is big competitions with a lot of players, economy says,
the prices will go down to the price of the cost to serve those services.
And it will just become commodity.
And you expect that to happen quickly?
I don’t know how quickly, but I expect that to happen.
Yes, it is.
But I wonder if it’s simply cheap to sort of bait people into it and get them used to the idea.
And then eventually everybody will ratchet up the prices to actually be covering their cost.
Because it can’t be cheap to run all of those huge server farms.
I guess.
But I really don’t know.
But, you know, since we are already looking at the crystal ball,
like, what do you expect to become possible in the near future?
And maybe also, what do you expect to never become possible?
I expect writing code will be easier and easier over time.
Right now, it already is quite easy.
People can go inside.
They have a project they’ve never seen before in a language, a code language they don’t know.
It’s possible for them to start delivering quite quickly, even today.
And I think that trend will continue.
I think AI will get into every aspect of our life where it can give us value and where we want it.
But that’s only a guess.
I really don’t stand really behind it.
It’s hard to predict the future.
Fair enough.
Let’s go back to the present.
How would you practically go about building something like a GPT-based app?
If we’d want to build the kind of app that we discussed before with the knowledge base,
it’s really easier to discuss something concrete.
I’d set up, for example, a web page or a Slack bot.
Okay.
If the organization is using Slack.
Serve up a backend using langchain Python.
And index all the organization data.
Let the Slack bot be the first responder to support requests.
And what should I expect in terms of resources that I need to set aside for such an AI?
Do I need my own server farm now?
Your own server for that?
Yeah.
You’d need your own server.
You’d need your own server to serve the backend.
It depends if you’re on a server or the Slack or Teams add-ons.
I don’t know.
But yeah, I’m thinking also in terms of how big of a support system do I need?
Do I need a single machine?
Do I need an entire farm?
Do I need…
Really small machine.
Because if you use, for example, OpenAI’s models as an API,
it doesn’t need to be strong.
You get…
All the embeddings of the knowledge of the organization, also from an API.
If you want to reduce costs a little bit and use open source software,
so you’d need bigger server, maybe with a GPU.
But it really depends on the case.
And then I just, you know, have this chat interface or something
that is included somewhere in my app.
That sounds deceptively easy.
What am I missing?
It really is easy.
But I think, you know, just thinking about this,
I can clearly see how you can be very valuable to companies
because you help me, for one, navigate all of this confusing stuff
and essentially giving me confidence that, yes, you can actually do this
and yes, it’s going to work.
That in itself is already worth a lot.
Yeah, absolutely.
We believe in delivering value and bring this revolution
to the world.
To companies, to get the word out.
Let everyone enjoy this value.
So we talked about before about how to phrase your requests to chat GPT.
And I was wondering if you could maybe expand on that a little bit
and make it even more broad and concrete.
So, for instance, is it better to try to come up with a perfect question
right off the bat?
Or should I just start with something really,
really murky and then refine in conversation?
What’s the better approach?
And do I need to be worried about, like, leading the AI towards an answer
that might sound pleasing but is not actually helpful?
It really depends on the use case.
If you are going to use GPT in production,
you really need to make sure the prompt and the answer is really robust
because the answer that it’s going to give you,
you’re going to have to handle,
you’re going to have to handle every single question.
So, initially, it can give you every string that exists on Earth.
It can return you and quote Shakespeare.
And you have to make sure you can handle each and every possible output.
So, if you just need a yes-no question to be answered,
you have to make sure and test it on a really diverse set of examples.
So, you know…
So, you know what’s expected out of that prompt.
So, really make sure before you deploy.
And even when DevOps podcast,
you need to shift left and test your prompts earlier and often
before you write the code architecture
because it really depends on the outputs and what it can give you.
So, I encourage doing that first.
So, what you’re saying is that before I actually introduce it
or include it in my product,
I should sit down…
I should sit down and just play with the prompt a little bit
and see what kind of requests I ought to be making
and how the responses feel.
Is that what you’re saying?
Even more than that,
I suggest more than just eyeballing a few examples
in the OpenAI playground,
I say run it on hundreds of examples.
And you need to be very damn sure about the robustness of the prompt
before you deploy it into production.
And…
Actually, I built a free tool for that.
You can put it in the comments.
That sounds like I need to actually do rather extensive automated tests
of my AI prompts.
Is that what you’re saying?
Yeah, I say you have to validate.
Could I even automate this?
Because it feels like I can…
Of course, I can replay a natural language prompt,
but how could I even parse the response without actually using my own AI?
So…
So, at this point, I’m back to using a human to validate the AI
so that I can save effort for a human?
Yeah, that’s a good point,
but there actually is a solution to this.
You can use an AI to validate and to…
But the validation is not 100% accurate.
So, for example, the tool I published
lets you see all the outputs of hundreds of examples,
all the outputs from the prompts,
and lets you choose the engine that’s running the outputs.
And it also helps you to validate
that the outputs are correct in natural language.
So, the validation really can be not correct,
but it mostly is because you test it really good
that the validation is correct.
And from now on, you can just play with the prompt
and make sure it’s good.
You can do just a quick check to see validation is good.
The tool…
There are, I guess, other tools out there,
but the tool, it just marks in red
the outputs that are not correct
and in green the ones that are correct.
And it just assists you in the job.
It’s not completely automated.
You need to validate the validator a little bit,
but it really is the job from experience.
Let’s think this through.
If I wanted to concretely add…
AI to, let’s say, to my product development process.
Let’s not even talk about the actual customer-facing product,
but just within something that is a little more controllable,
such as my own organization.
What do I even need and where should I start?
Do I need an account at OpenAI
or do I use a local AI implementation?
What’s the best starting point?
And it sounds like I need a validation tool
like the one you wrote to…
Help me hone.
What else do I need?
What’s sort of the minimal set of things
I should need to download,
create accounts for, and so on and so on?
Yeah, so the minimal is set up an account
in a company that provides a large language model,
such as OpenAI, and get an API key.
You can just use to run your prompts using an API,
provided, of course,
if you want to build a custom software for your organization.
You can…
We all know how to use JGPT’s UI, yeah.
But to use the API, you just need an account.
Okay, and that’s all I need.
I don’t actually need your validation tool then, do I?
Or do I still need it?
It’s not a must.
If you deploy…
If you use it in production,
I really encourage to validate the prompts
because, as I said before,
the range of outputs that comes out
might really influence the architecture of the code.
In the future.
So I encourage to shift left with this.
Is this something that a person can do in a day,
in a week, in a month?
It depends on the quality and all that,
but it can be a few days, a week, two weeks.
Interesting.
Okay, so really all I need is an API key for OpenAI.
Oh, by the way, that means that I give all of my company secrets
to this third party and to this AI,
and I suppose I can’t be sure that the AI,
which doesn’t know any better,
will just regurgitate it to others, will it?
I think there’s a story that Samsung accidentally revealed
a couple of their company secrets
through the use of an OpenAI, I think.
Yeah, I think they used the free version.
You, of course, need to…
This podcast will be here for a while,
so what I say now may change in the future,
so check the privacy in terms of use of each product.
Okay.
Right now, using the API of OpenAI,
it won’t reveal private information,
but if you need to,
if you can’t share customer data outside of your cloud,
it’s also possible to deploy those models in your own cloud.
At the same quality as, say, OpenAI?
Yeah, you can deploy it on Azure,
which is powered by Microsoft,
which has…
49% of OpenAI.
All right.
That was a fascinating trip into a world
that I frankly don’t know very much about yet.
Before we close the podcast,
this is something that I forgot.
This is something that you wish I had asked you.
You wish you had asked me?
I’m not sure.
I can’t think of such a thing.
All right.
I guess that’s a good sign.
I mean, thank you so much for joining this show
and telling us about this fascinating,
new world.
If people want to learn more about you
and maybe make use of your services,
where could people find you?
You can check out our website,
Book an Appointment.
Okay.
Yeah.
What’s the website?
Tell me.
It’s getai.consulting.
That’s actually a pretty cool URL.
getai.consulting.
All right.
I guess we’ll get links to some of the products you mentioned
and stick them in the show notes.
Absolutely.
As well as obviously a link to getai.consulting.
Thank you so much for being here.
This was very fascinating.
I wish you a wonderful day.
Thank you so much.
Bye-bye.

Folge 72: Veit Joseph zu Shift Left

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

Falko und Luca unterhalten sich mit Veit Joseph von der DATEV. Er befaßt sich dort mit der systematischen Umsetzung und Weiterentwicklung von Qualitätssicherung und Teststrategien.

Mit ihm verhandeln wir shift left, was es bedeutet und wie man es umsetzt. Weiter sprechen wir über Testpyramiden und Test-Eistüten, und vor Allem die Wandlung von QS als Abschnitt des Prozesses zu QS als intrinsischer Eigenschaft des Prozesses.

In dieser Podcast-Episode wird der Fokus auf die „Shift Left“-Bewegung in der DevOps-Praxis gelegt, die für eine frühere Einbeziehung der Qualitätssicherung im Entwicklungsprozess steht. Veit Josef, ein Requirements Engineer, erklärt die Notwendigkeit dieser Verschiebung und diskutiert die technischen und organisatorischen Herausforderungen, insbesondere in Bezug auf Teststrategien und Teamdynamiken. Es wird betont, dass erfolgreiche DevOps eine ausgewogene Berücksichtigung von Entwicklung, Betrieb und Qualitätssicherung erfordert, um effiziente und effektive Ergebnisse zu erzielen.

Inhalt

  • Einführung und Hintergrund des Gastes, Veit Josef
  • Persönliche Definition von DevOps durch Veit Josef
  • Diskussion über den Blogpost „Shift Left, nie mehr schlaflos in DevOps“
  • Bedeutung und Umsetzung von „Shift Left“ in der Qualitätssicherung
  • Veränderungen in DevOps durch Cloud-Native-Anwendungen
  • Herausforderungen und Lösungsansätze im Kontext von On-Premise- und Cloud-Anwendungen
  • Bedeutung von DevOps-Praktiken für größere Unternehmen
  • Diskussion über Testing-Strategien, inklusive Testpyramide und Test-Eistüte
  • Integration von Qualitätssicherung in alle Phasen der Softwareentwicklung
  • Rolle von verschiedenen Teammitgliedern im Shift-Left-Prozess
  • Auswirkungen von Shift Left auf Teamstrukturen und -prozesse
  • Diskussion über den Einfluss von Tools und Technologien in DevOps
  • Die Notwendigkeit von Kommunikation und Zusammenarbeit zwischen Entwicklungs- und Betriebsteams

Shownotes

Veits ursprünglicher Artikel

Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)

DevOps. Auf die Ohren und ins Hirn.
Ein Podcast rund um DevOps.
Von Dierk Söllner, Falko Werner und Luca Ingianni.
Hallo und herzlich willkommen zu einer neuen Folge des Podcasts DevOps auf die Ohren und ins Hirn.
Gestaltet und produziert von Luca Ingianni, Dierk Söllner und Falko Werner.
Wir sind DevOps-Trainer und Coaches mit langjähriger Erfahrung.
DevOps umfasst für uns kulturelle, organisatorische und technische Aspekte.
Heute haben wir als Thema, warum die DevOps 8 links beginnen muss.
Also die Unendlichkeit beginnt links, habe ich mir erklären lassen.
Zu Gast dafür, um uns das zu erklären, haben wir Veit Josef, der Requirements Engineer ist bei der Dativ
und sich da allerhand Gedanken zu dieser Art von Topologien gemacht hat.
Veit, willkommen. Schön, dass du da bist.
Ja, schön, dass ich da sein darf. Danke für die nette Anmoderation.
Es stimmt übrigens nur zum Teil.
Ich bin aktuell Requirements Engineer bei der Dativ.
Also ja, da habe ich als Requirements Engineer angefangen.
Ich hatte vorher vor der Dativ noch ein bisschen Background, vielleicht auch als Product Owner oder Application Manager
und bin jetzt mittlerweile aber seit, naja, zwei Jahren folge ich einer neuen Passion, die da heißt
Qualitätssicherung und vor allem Qualitätssicherung von Online- oder von Cloud-Native-Anwendungen.
Und das vielleicht kurz noch zur Einordnung einer zentralen Position bei der Dativ.
Also ich bin nicht direkt in einem der…
Ja, es sind doch irgendwie 250 plus minus x Produkte, die wir so im Portfolio haben.
Nicht in einem dieser Entwicklungsteams, sondern ja, wie gesagt, in einer zentralen Position.
Und wir sehen viele der Produkte und vor allem der neueren Entwicklungen an uns vorbeikommen, zwangsläufig.
Und bei diesem vielen Vorbeikommen kriegt man viel mit und will aber auch viel mitgeben.
Und genau da bewege ich mich gerade ein bisschen.
Sehr schön.
Dann bevor wir uns als eigentliches Thema machen.
Wir haben ja eine Tradition in diesem Podcast, dass wir jeden Tag…
…den Gast nach seiner persönlichen Definition von DevOps fragen.
Und das Schöne daran ist, dass jeder Recht hat.
Insofern, Veit, was ist denn deine persönliche Definition von DevOps?
Ich weiß gar nicht, ob ich jetzt überrascht tun soll oder ob ich eigentlich weiß, dass diese Frage auf mich zukommt.
Also ich würde mich tatsächlich so ein bisschen an der Lexikon oder vielleicht auch an der Wikipedia-Definition halten wollen.
Also ein Team wird durch Nutzung oder gemeinsame Nutzung von Werkzeugen, Entwicklungswerkzeugen im weitesten Sinne und auch Vorgehen,
aber auch die Infrastruktur und Prozesse, die es vielleicht schon gibt, die sie aber dann gemeinsam nutzen, in die Lage versetzt,
Gesamtverantwortung für die Entwicklung und den Betrieb eines Produkts zu übernehmen.
Und neben den Vorteilen, die man sich damit erkauft, also sowas wie, ich kann Software und Produkte kontinuierlicher, schneller und stabiler entwickeln,
werden dabei noch, und das habe ich jetzt ganz oft schon gemerkt, vor allem in so größeren Unternehmen,
wie Data, würde ich jetzt sagen, einfach mal…
Zumindest in die Mitte der Bandbreite einordnen, kann mit so einem Vorgehen oder mit DevOps an sich auch ganz gut so gewachsene Organisationsstrukturen,
man spricht ja da gerne auch von Silos, nicht niederreißen, aber zumindest denen ganz gut begegnen und die Hürden ein bisschen tiefer setzen.
Und auch so, weil ich gerade Prozesse angesprochen habe, so bürokratische Verkrustungen so ein Stück weit auch auflösen.
Auch dabei hilft es.
Sehr schön. Und insofern, wir haben dich eingeladen, weil wir an einem Blogpost von dir vorbeigekommen sind,
den wir recht interessant fanden, der da hieß Shift Left, nie mehr schlaflos in DevOps.
Erzähl doch mal, was war denn dein Witz dabei?
Ja, so witzig ist es vielleicht gar nicht, aber DevOps, zumindest in der Dativ, ist, soweit ich es beurteilen kann,
also es ist, glaube ich, nicht die erste DevOps-Welle, die durch die Dativ gleitet, aber zumindest eine ganz große jetzt.
Und das spielt uns in der zentralen QS auf der einen Seite in die Karte, auf der anderen Seite geht das so ein bisschen vor allem aus unserer zentralen Anspruchshaltung,
muss man schauen, dass man nicht die Ziele, die wir verfolgen, damit irgendwie so ein bisschen dagegen schießt, sage ich mal.
Und bei uns, so meine Beobachtung, war es ganz oft so, dass man sehr gerne neue Wellen ganz oben reitet und sich erst mal darauf konzentriert,
was bringt denn jetzt diese neue Orientierung oder diese zusätzliche Orientierung?
Ich muss vielleicht davor wegschicken noch, die Dativ befindet sich gerade in einem relativ großen Change, sage ich mal.
Was unser Portfolio anbelangt, also diese 250 plus X-Produkte, die ich vorhin mal angesprochen habe,
die sind hauptsächlich On-Premise-Anwendungen, also die bei unseren Kunden und Kundinnen, Kanzleien größtenteils, Steuerberater installiert werden
und die natürlich großen Release-Zügeln unterliegen, da kommt mal da im halben Jahr oder einem Jahr eine CD oder eine DVD raus.
Und jetzt ist man aber der Meinung und der gleichen Meinung bin ich auch, dass wir ganz viele unserer Anwendungen oder Prozesse,
in die Cloud heben müssen, um es jetzt mal ganz einfach zu beschreiben.
Und da ist DevOps natürlich, sage ich mal, bietet ein ganz reichhaltiges Portfolio an Dingen und Methoden und Vorgehensweisen, die das möglichst gut unterstützt auch.
Aber wie ich gesagt habe, Dinge, die ich beobachte, sind, wenn etwas vielleicht neu ist oder man es gerade irgendwie hoch hält und vielleicht auch hoch jubelt,
ich will nicht gegen DevOps schießen, aber das führt oft dazu, dass man sich auf diese neuen Sachen vor allem einschießt.
Okay, was?
Diese schöne neue DevOps-Welt. Jetzt haben wir auch Ops in der Entwicklung mit drin.
Jetzt können wir auch über Dinge reden wie, weiß ich nicht, jetzt schmeiße ich mal ein paar Begriffe um mich,
A-B-Testing, Kern-Release, Blue-Green-Deployment und was mir alles verbindet, vor allem mit der rechten Seite der DevOps 8,
Monitoring as a Service und solche Geschichten.
Und vergiss dabei oftmals, bewusst oder unbewusst, dass wir ja auch, das ist ja eine 8 und ich habe ja nicht umsonst gesagt, die beginnt links,
dass wir halt eine linke Seite auch haben.
Und da vielleicht in der Vergangenheit geprägt durch, wie wir aufgestellt waren mit On-Premise-Anwendungen, Dinge getan haben,
die uns in der neuen Welt, will ich es mal benennen, also in der Online-Welt, so nicht mehr funktionieren und so auch nicht mehr helfen würden.
Und wenn wir uns jetzt nur auf den rechten Teil konzentrieren würden, dann würden wir den linken noch mehr außer Acht lassen und wir würden in eine Schieflage geraten.
Weil ich glaube schon, ich nenne es immer gerne das System DevOps, dass das ein System ist, das nur funktioniert, wenn wir die beiden Seiten irgendwie,
und das hat ganz unterschiedliche…
Die Perspektive, wenn die beiden Seiten möglichst in Balance halten.
Und eine Balance entsteht eben mal nicht, wenn ich mich nur auf eine Seite konzentriere und die andere vielleicht so ein bisschen neben links liegen lasse,
sondern ich muss schon schauen, dass ich da im Gleichschritt marschiere, sozusagen.
Um noch den Bogen zu spannen zu dem Titel.
Ich wollte damit zeigen, ich habe natürlich mich eines besonders schwarzen Szenarios bedient, sage ich mal.
Nämlich, wenn man jetzt irgendwie, okay, jetzt haben wir auch Betrieb, den wir verantworten.
In unserem Produktentwicklung.
Was passiert denn eigentlich, wenn die Hotline klingelt oder wenn irgendwelche Monitoring-Systeme anschlagen, irgendwelche Alerts aufpoppen,
weil wir Dinge detektiert haben, Fehlnutzung oder Fehlersituationen.
Wir müssen ja damit umgehen und im Zweifel, wann passieren die Dinge?
Ja, nicht um Dienstag irgendwie 14 Uhr, wo noch alle in Kraft und Saft sind, sondern im Zweifel am Wochenende.
Und irgendjemand erwischt es, der hat heute das Notfall-Handy irgendwie neben dem Bett liegen und muss reagieren.
Und damit uns solche Situationen nicht passieren oder dass wir eine gute Strategie haben, um mit solchen Situationen, wenn sie denn passieren, umgehen zu können,
wollte ich sagen, lass uns erstmal links auch investieren, damit wir eben das Risiko, dass rechts irgendwas schiefläuft, minimieren können.
Beziehungsweise gute Vorgehensweisen haben, um da rechts auch agieren zu können.
Und so ist es zu dem Titel gekommen.
Aber jetzt müssen wir, ich glaube, jetzt müssen wir nochmal einen Schritt zurück machen und unsere Hörer so ein bisschen einsammeln.
Wovon wir hier eigentlich die ganze Zeit reden, von irgendwelchen Achten mit links und rechts und so.
Es geht natürlich um diese berühmte liegende Acht, dieses Unendlichkeitssymbol, das ganz gerne verwendet wird in der DevOps-Literatur.
Und das hat logischerweise zwei Seiten, eine linke und eine rechte.
Und auf der rechten Seite vor Ort ist DoFight, diese ganzen Dinge, Release, Deployment, Monitoring, Ops.
Also auch das, wenn man…
Wenn man es sich linear vorstellen würde und nicht als liegende Acht, dann würden wir auch sagen, das ist halt so das Strom ab.
Also das Richtige, das Betriebsseitige.
Und auf der linken Seite steht bei dir dann so Dinge wie Code und Plan und Test und Build.
Also die Dinge, die traditionell eher so in Richtung der Entwicklungswelt gehen.
Also vielleicht mit der Grenze da, wo das Produkt zum Kunden übergeht, sage ich mal.
Das ist vielleicht die rechte Seite und davor, das ist die linke Seite, ja.
Genau. Und die Prämisse deines Artikels ist ja wohl die, dass…
erfolgreich sein zu können in einer DevOps-Welt, man seinen Fokus mehr auf diese linke Seite legen muss,
dass man bereits früher in diesem DevOps-Wertstrom auf Qualität achten muss, für Qualität sorgen muss.
Habe ich das so richtig wiedergegeben?
Ja, ist natürlich unfair, weil wir reden ja über eine Acht und dazu sagen, ich muss irgendwie…
Wo ist denn eigentlich der Anfang in der Acht und warum muss ich da denn beginnen?
Aber ja, das ist letztendlich die Aussage.
Vielleicht noch ein bisschen differenzierter, wenn ich nicht ein gutes Level oder eine gute Qualität auf dem Bereich habe,
der eben vor einem Release ist, in der Planungsphase, in der Implementierungsphase, auch in der Testphase,
dann werde ich auf der rechten Seite im Monitoring und im Weitläufigen in der Operations halt meine Probleme bekommen.
Ja, das ist ganz interessant.
Auch insofern, als Falk und ich uns heute Vormittag zusammengesetzt haben, um ein Call for Papers zu beantworten,
der DevOps Enterprise Summit, wo es um genau sowas ging, da haben wir so ein bisschen Rückschau gehalten auf Kunden von uns
und wie deren Erfahrungen so waren und was wir irgendwie als Gemeinsamkeit, egal wie groß oder klein der Kunde ist
oder in welcher Branche er sich bewegt, wenn diese Ausgangs…
Wie soll ich sagen?
Wenn keine Klarheit besteht bereits beim Losmarschieren, dann kommt halt hinten auch nur irgendwas sehr Unscharfes,
im Zweifelsfall sehr Instabiles und womöglich auch nicht besonders Werthaltiges dabei,
weil es ist ja nicht so, dass man sich da so ein bisschen in die Hand nehmen kann,
weil es ist ja nicht so, dass man sich da so ein bisschen in die Hand nehmen kann,
und man muss ganz ehrlich sagen, das ist natürlich jetzt nichts Neues,
das haben die DevOpsler sich jetzt nicht irgendwie ausgedacht oder sowas,
sondern, meine Güte, das ist halt irgendwie so ein Klassiker, das sind halt so Sprüche wie Garbage in, Garbage out,
oder das sind Dinge, die aus Richtung Lean kommen, aus Richtung Toyota Produktionssystem kommen,
wo ja auch schon von vornherein gesagt wurde, daher kommt hier dieser Begriff Shift Left,
je früher man für Qualität sorgen kann, desto mehr wird man Strom ab davon profitieren.
Ja, eine Fehlzeit.
Eine Fehlüberlegung bereits in der Spezifikationsphase aufzudecken und zu sagen,
naja, das war jetzt irgendwie unüberlegt, das zu korrigieren braucht nur einen Federstrich,
dann spezifiziere ich es halt um, zack, bumm, fünf Minuten später ist das Ding erledigt,
während wenn in der Kehrseite das erst auffällt, wenn das Produkt beim Kunden ist und der Kunde sagt,
was soll ich denn damit, ja, dann ist es natürlich irgendwie blöd,
dann habe ich potenziell, so wie du beschrieben hast, viele Monate in den Sand gesetzt,
bis die DVD endlich mal beim Kunden ist und dann bringt sie nichts und dann habe ich keinen Wert geliefert,
und alle haben irgendwie reichlich Torte im Gesicht.
Genau, und vielleicht noch als Ergänzung, du hast ja schon gesagt, das ist alles ein alter Hut,
also da wäre ich keinem mehr hinterm Ofen vorloggen, wenn ich sage,
Dinge, die uns später auffallen, sind teurer.
Wir in der Dativ, also ich will nicht sagen, dass wir irgendwie anfangen, Dinge neu zu erfinden oder so,
das müssen wir nicht tun, also es gibt genügend Standards, Vorgehensweisen, wie meinetwegen Shift Left,
auch wie DevOps, die müssen wir nicht tun.
Das ist eine große Herausforderung.
Aber ich glaube schon, dass wir in der Dativ mittlerweile eine Reife erreicht haben,
die uns nicht nur an den Punkt bringt, solche Dinge nutzen zu können,
sondern auch an den Punkt gebracht hat, zu sagen, okay, und was müssen wir aber aus den Dingen tun,
wie müssen wir sie adaptieren, um sie verwenden zu können,
dass sie in unsere Gegebenheiten, in unsere Anforderungen passt.
Und das ist bei einem Shift Left, den treiben wir vielleicht nicht weiter,
aber wir führen ein paar Perspektiven noch expliziter aus, wenn ich die mal kurz erwähne,
also so Dinge wie, wir sprechen ganz gern auch mal vom Shift Left Left,
also der Shift Left sagt, ja, verlagere die Aktivitäten, die QS-Aktivitäten nach vorne in deinem Zyklus,
entwicklungsbegleitend, aber neben diesem entwicklungsbegleitenden Testen ist es uns noch explizit wichtig,
dass wir auch Dinge in der Planphase QS-Aktivitäten dort ansiedeln,
heißt im Detail, BDD, 3MU-Gespräch sind da so Stichworte, dass eben auch eine QS-Perspektive bei der Definition von Anforderungen,
oder von vor allem testbaren Anforderungen eben auch mit reingebracht wird.
Also das ist uns ganz wichtig, dass wir diese Anspruchshaltung verfolgen,
aber auch so Dinge wie, das schwingt ja auch mit, aber wir sagen es nochmal explizit, Komplexität reduzieren.
Also das frühe entwicklungsbegleitende Testen, vor allem mit isolierten Testobjekten,
das reduziert nun mal die Abhängigkeiten, die man sich bei verteilten Architekturen unweigerlich auflegt.
Und wenn ich da von isolierten Testobjekten spreche,
dann meine ich eben nicht nur irgendwie die isolierte Klasse im Unit-Test,
sondern eben auch das autonome Testen von Microservice in der eigenen Anwendung,
Frontend gegen Backend, das automatisierte Testen von Schnittstellen,
das Testen von Gesamtanwendungen, wo ich dann Zweit- und Drittdienste,
die ich per Abhängigkeit mir angebunden habe, irgendwie durch Service-Virtualisierung isoliere.
Also auch das ist uns ganz wichtig über solche Dinge, die in so einem Shift-Left drinstecken,
aber die wir halt explizit machen.
Und das meine ich mit Adaptieren und auf unsere Gegebenheiten und Anforderungen auch schwingen.
Ein Stück weit anpassen.
Was bedeutet denn Shift-Left für einzelne Teammitglieder?
Also auch noch ein bisschen Kontext.
Der Dativ ist es ja so, dass wir, ich sag mal, Rollen sehr ausgeprägt nutzen in Entwicklungsteams.
Also es gibt eben nicht nur den PO, den Scrum Master, sondern Entwicklungsteams,
sondern es gibt den Test-Ingenieur, es gibt den Security-Ingenieur, es gibt den Architekten,
es gibt den UX-Designer, es gibt den User-Researcher.
Und das ist natürlich kontraproduktiv.
So ein bisschen, wenn wir, Stichwort, wir verteilen QS-Aktivitäten nach vorne im Entwicklungsprozess,
wenn wir diese Aktivitätenverteilung immer nur an einer Person festmachen würden
oder an einer Rolle festmachen würden.
Weil, was wir in der Dativ schon auch propagieren, ist das Stichwort Whole-Team-Quality.
Sprich, es ist nicht mehr eine Person, eine Rolle im Team verantwortlich für QS,
geht jetzt noch weniger als vorher, weil es ist nicht mal, okay, ich warte, bis Entwicklung fertig ist
und dann teste ich.
Sondern es müssen ganz viele Dinge auch vorher und entwicklungsbegleitend passieren.
Sondern ein ganzes Team ist verantwortlich für die Qualität seines Produkts,
für die Qualitätssicherung, fürs Testen des Produkts.
Und das hat natürlich ganz unterschiedliche Auswirkungen für die einzelnen Personen im Team.
Für jemanden, der eher auf der Business-Seite ist, sich um Anforderungen kümmert,
der sollte sich möglichst früh auch in die Position begeben, sich auseinandersetzen zu wollen
mit Programmierung, also mit dem Software-Ingenieur und mit dem Test-Ingenieur,
um eben, wie ich es vorhin beschrieben habe, auch testbare Anforderungen zu haben.
Eben nicht nur seine Anforderungen über den Zaun zu werfen und wird schon sich jemand drum kümmern
und das auch testen, sondern von vornherein sich Gedanken zu machen,
wie wir sie dann auch umsetzen und testen können.
Für einen Software-Ingenieur heißt das natürlich, er ist nicht nur stupide am Programmieren.
Dinge wie TDD sind noch ein Stück weit wichtiger, noch höhere Ansprüche an Entwickler,
auch auf Qualität zu achten.
Und für den Test-Ingenieur heißt es, so ist mein Dafürhalten vor allem in einem moderneren Online-Entwicklungsumfeld,
er wird auch ein Stück weit sich technischer orientieren müssen.
Es geht nicht mehr nur darum, da ist jemand, der spezifiziert Testfälle und hat eine Checkliste und testet manuell,
sondern es geht vor allem darum, Stichwort auch BDD, Stichwort Clue-Code erzeugen,
Stichwort Code-Implementierung, Programmierung, Testfälle auch lesen zu können.
Also, dass auch die Menschen, die in der Disziplin Test-Ingenierung unterwegs sind, ein Stück weit technischer werden.
Also, es hat für jeden auch unterschiedliche Auswirkungen.
Das Mantra, was über allem schweben sollte, ist,
was ich vorhin schon gesagt habe, Whole-Team-Quality.
Also, jeder ist verantwortlich am Ende für die Qualität des Produktes.
Bis hin zum Product-Owner, der sich, und das passiert hier und da doch nochmal,
eben nicht so leicht aus der Verantwortung rauskommt im Sinne von Funktionalität vor Qualität.
Also, auch da muss natürlich ein Stück weit Umdenken stattfinden.
Also, Qualität vor Funktionalität, wenn man den letzten Satz zumindest nochmal aufgreift.
Das können wir uns nicht leisten, Veit.
Nicht schwarz oder weiß.
Leider ist es ja, wie so oft im Leben immer,
die Grautöne, aber das Ganze unterliegt natürlich schon irgendwie einer Kosten-Nutzen-Abwägung.
Aber man muss halt einfach auch feststellen,
dass mit der schönsten Funktionalität,
wenn die nicht mit der entsprechenden Qualität geliefert wird,
dann bringt mir das Ganze nichts.
Also, in mir schlägt ein ganz tiefes Herz für so Dinge wie die ISO 25010,
Softwarequalitäten oder Qualitäten in Softwareprodukten,
Qualitätsanforderungen, Qualitätsszenarien.
Sowas ist mir ganz wichtig.
Und deswegen würde ich immer sagen, ja, ja, Qualität vor Funktionalität,
aber am Ende kauft der Kunde ganz oft eben auch erst,
mal nur Funktionalität und setzt dann schwer drauf,
dass die Qualität auch stimmt.
Stichwort irgendwie Kano-Modell, Basis- und Leistungsmerkmale.
Da erwartet er einfach, dass die in eine entsprechende Qualität kommen.
Aber wenn wir sie nicht liefern können,
dann zerschellen die Erwartungen an der Realität.
Auch schade.
Zumal es da ja auch das zweite Argument gibt,
wenn du entsprechende Qualität entwickelst,
dann kannst du es dir überhaupt erlauben,
in dieser Geschwindigkeit Funktionalität bereitzustellen.
Also wollt ihr jetzt sagen,
wir haben Qualität und Funktionalität und das soll funktionieren?
Hilft ja nix.
Muss es nur gut verkaufen, ne?
Ja, da sagst du was Wahres, glaube ich, Veit,
weil ganz häufig, deswegen habe ich ja vorhin so sarkastisch gesagt,
das können wir uns nicht leisten.
Qualität ist viel zu teuer.
Der Wert von Qualität erschließt sich halt vielleicht nicht auf den ersten Blick.
Ich meine, jeder mag natürlich gerne Produkte, die gut funktionieren,
aber dann ist dir das Hemd doch irgendwie näher als die Hose
und sagst, nee, nee, das Feature muss jetzt noch zur Tür raus.
Das müssen wir jetzt noch in den Sprint reinkriegen irgendwie.
So was kann man schon mal machen, dass man technische Schulden aufbaut,
dass man vielleicht auch organisatorische Schulden oder sowas aufbaut an der Stelle.
Aber man muss halt wissen, was man sich damit so gerade einfängt.
Da führt halt irgendwie kein Weg dran vorbei, ist mein Eindruck.
Ja, und technische Schulden werden nie weggehen.
Es wird nicht ohne gehen.
Aber du musst handlungsfähig bleiben.
Du brauchst Handlungsoptionen, wenn Dinge dir um die Ohren fliegen.
Und diese Handlungsoptionen,
die, um mal wieder irgendwie zum Pudels Kern zurückzukehren,
die muss ich mir auf der linken Seite in der DevOps 8 einfach schaffen.
Durch eine adäquate Qualitätssicherung,
durch Transparenz über die unterschiedlichen Entwicklungsstufen hinweg.
Was wird wo wann getestet?
Wie kann ich isoliert an meine Service, an meine Funktion rankommen?
Weil nur, dass ich am Ende weiß, okay, da ist jetzt was kaputt gegangen.
Wenn ich nicht weiß, wo was kaputt gegangen ist,
und wenn ich nicht weiß, wer, wann, wo was gedreht hat,
dann wird die Fehlerursachenanalyse irgendwelche Logs durchwälzen.
Das wird dich auffressen.
Dann bist du nicht handlungsfähig.
Und dann verschiebt sich alles Weitere auch.
Weil ich meine, du musst erst mal den Fehler beheben,
bevor du das nächste Feature hinterher schieben kannst.
Im Normalfall.
Und allein darum geht’s.
Insofern ist es ja eigentlich bezeichnend.
Falk und ich haben im Zusammenarbeit mit der DASA,
der DevOps Agile Skills Association,
ein Training verfasst,
das heißt DevOps Specify and Verify.
Und das heißt ja nicht zum Spaß so,
sondern das soll wirklich genau das auch ausdrücken,
was du gerade eben vorgetragen hast,
weil dass das zwei Seiten derselben Medaille sind,
dass ich, so wie du es vorher gesagt hast,
dass ich diese sogenannten Three Amigos da haben muss.
Wenn ich also ein neues Feature ausdenke und spezifiziere,
dann muss ich einen Spezifikatör da haben,
wie auch immer du ihn nennst, Product Owner oder sowas.
Ich muss den Entwickler haben,
der gleich mit mir da ist,
der gleich mitredet.
Ich muss einen Tester haben,
der gleich mitredet und jeder bringt seine eigene Perspektive ein,
die notwendig ist,
damit hinterher auch tatsächlich gute Qualität dabei rauskommt.
Und um das gleich vorweg zu sagen,
ich habe auch gar nichts dagegen,
wenn du fünf, drei Amigos einlädst,
wenn das notwendig ist, um da Klarheit zu erschaffen.
Genau, dann kommen wir ja letztendlich auch gleich zum Punkt Wert.
Wenn du Qualität hast und jemanden, der diese nutzt,
dann kannst du natürlich Wertschöpfung betreiben.
Und dann hast du den Kunden,
der auch wirklich zufrieden mit dem Produkt ist,
finde ich letztendlich mal eine ganz nette Folge im Gedanken.
Im Skript habt ihr sowas geschrieben wie die Testpyramide,
eine Geschichte von Bäumen und Eistüten.
Da kenne ich mich mit Testen nicht so sehr aus.
Ich bin ja nur so ein komischer Entwickler und so,
Architekt teilweise noch.
Aber was sind denn so Bäume und Eistüten?
Erzählt mal.
Ja, ich hatte ja eingangs erwähnt,
also man sieht viel in so einer zentralen Position.
Und man sieht vor allem,
und das hat auch,
äh,
erklärbare Hintergründe,
Stichwort On-Premise-Anwendungen,
dass die viel zitierte Testpyramide,
und jetzt bin ich vielleicht erst mal bei der von,
von Cone mit den drei Stufen,
dass die oftmals umgedreht ist und eine Eistüte ist.
Also sprich, ich habe doch viel mehr Aufwände
oder Ressourcen, die ich in die Stufen stecke,
bei denen ich eigentlich möglichst wenig investieren sollte,
weil sie teuer sind, sage ich mal.
Stichwort automatisiertes Testen über die Oberfläche
eines integrierten Systems.
Also mal kurz einen Schritt zurück machen und sagen,
wie schaut denn so eine Testpyramide aus
und wie schaut eine Testeistüte aus?
Möchtest du den Schritt machen oder soll ich den Schritt machen?
Wenn dir das lieber ist, dann mache ich den.
Also passt auf, liebe Hörerinnen und Hörer.
So eine Testpyramide nach Mike Cone,
die stellt da Tests auf verschiedenen Ebenen.
Ganz unten hat man Unit-Tests,
wir alle kennen die, das sind sehr, sehr kleinräumige Tests,
die häufig mit einem sehr hohen Detaillierungsgrad
ganz kleine Elemente eines Produkts abtesten.
Dazwischen habe ich dann Integrationstests,
Servicetests, nenn sie wie du möchtest,
die schon auf etwas größerer Ebene sind,
wo jeder einzelne Test größere Abschnitte des Produkts überstreicht,
bis hin zu Systemtests, Abnahmetests,
funktionellen Tests,
die dann wirklich an der Oberfläche sich befinden
und sehr, sehr große Abschnitte der ganzen Applikation
auf einmal durchtesten.
Und der Mike Cone sagt eben,
du sollst im Vergleich weitaus mehr Unit-Tests haben
als am anderen Ende der Welt.
Am Ende der Pyramide, da wo sie spitz zusammenläuft.
Systemtests, Abnahmetests, funktionale Tests,
einfach weil solche großräumigen Tests viel, viel kostspieliger sind,
tendenziell vielleicht auch ein bisschen instabiler sind.
Wenn irgendwo in dieser langen Funktionskette irgendwas verändert wird,
nicht mal unbedingt kaputt geht, sondern einfach nur anders ist,
dann fliegt dir vielleicht ein Test um die Ohren
und dann bist du eben die ganze Zeit am Hinterherlaufen.
So, das ist jetzt erstmal die Testpyramide.
Vielleicht, Veit, möchtest du weitermachen mit der Test-Eistüte?
Also kann ich gerne auf dem Modell,
was du uns und auch den Zuhörer in den Kopf gesetzt hast.
Wie du schon gesagt hast,
eine Pyramide ist unten am breitesten und oben spitz.
Und die Pyramide sagt nichts anderes als genau das Gegenteil.
Also ich habe wenig Unit-Tests.
Ich habe wenig Tests auf der integrierten Ebene
von zwischen vielleicht Services oder bei Schnittstellen oder Systemen,
sondern ich habe ganz viel meiner Aufwände.
Vor allem, wenn es darum geht, Funktionalität zu testen.
Auf der obersten Ebene, auf Akzeptanz-Test-Ebene,
auf System-Integrations-Test-Ebene und da dann,
und das ist ja immer so die Krux an der ganzen Geschichte,
über die Oberfläche.
Ich meine klar, es gibt Tools, Frameworks,
Oberflächentests auch zu automatisieren.
Aber du hast ja schon angesprochen,
dass es meistens relativ instabil,
weil Änderungen, die tief unten stattfinden,
große Auswirkungen oben zeigen.
Und schon bist du wieder in der Situation,
irgendwie deine Tests wieder neu aufzustellen
oder deine Automatisierung anzupassen.
Und, das ist ja genau das, was wir im Shift-Left propagieren,
wir wollen ja schnelles Feedback.
Wenn du immer erst im integrierten System deine Tests fährst,
dann bist du weit weg vom schnellen Feedback,
weil da bist du relativ nah an, eigentlich wollen wir releasen.
Das, was da jetzt rauskommt,
naja, lass das mal irgendwie ins Backlog packen.
Oder ist das jetzt wirklich so dringend, was da passiert?
Oder ja, ist es? Na gut, dann müssen wir noch mal
die ganze Kette zurückgehen.
Und das ist so was,
was wir uns ja mit der Eistüte vorstellen, sozusagen.
Was nicht gut ist.
Ja, vielleicht sollte man an der Stelle auch erwähnen,
dass zum Beispiel ein Freund von mir,
der sehr viel mit Serverless macht,
der sehr stark die Desintegration von Diensten vorantreibt,
noch weiter als Microservices,
bis hin zu eben wirklich Funktionen,
die einzeln ausgeführt werden.
Und der sagt, lustigerweise, er macht kaum Systemtests
und er macht aber auch kaum Unit-Tests,
sondern er hat einen Test, was denn, Rhombus?
Ich glaube, das ist dann ein Test Rhombus, oder?
Mit ganz, ganz vielen Integrationstests.
Ja, genau.
Also, das ist das, was er macht,
das ist das, was er macht in der Mitte.
Weil er sagt, das ist das,
wo es bei dieser Art von Systemen dann regelmäßig knallt.
Genau, das ist das, was ich dann immer,
was ich dann mir immer so als Baum,
immer so als Bild male.
Ganz unterschiedlich.
Da kann auch mal ein Baum sein,
der in der Mitte irgendwie dicke Äste hat
und oben eher weniger.
Oder er hat einen dicken Stamm und wird oben wieder spitzer,
hat aber in der Mitte, was du gesagt hast,
mit Integrationstests irgendwie eine große Ausprägung.
Genau.
Und so sieht das dann auch auf die Pyramiden, sag ich mal.
Sondern das sieht immer so ein bisschen anders aus.
Ja, kommt auch auf die Architekturen,
die Anforderungen des Produkts dann an.
Ich will noch eine Perspektive mehr dazugeben,
weil das ist bei uns immer ganz interessant.
Wenn wir nämlich Shift Left sagen,
meinen wir damit auch immer,
und das sagen wir dann manchmal auch explizit,
Shift Down.
Also nicht nur orientiere dich nach links,
entwicklungsbegleitend,
sondern schau noch mal auf die Pyramide
und bitte konzentriere dich auch nach unten,
damit das noch mal ein bisschen mehr propagiert wird.
Wir sind uns einig,
das ist das Ziel.
Ich habe hier irgendwie x-tausend Unit-Tests.
Muss nicht Perfektion sein,
sondern wahrscheinlich liegt die weit irgendwo mittendrin.
Aber es darf halt auch nicht sein,
dass ich meine ganzen Aktivitäten oben versammelt habe.
Haben wir ja schon ausführlich diskutiert, warum nicht.
Man kann das schon machen.
Hat halt Nachteile.
Genau.
Aber haben wir eigentlich schon hinreichend gut erklärt,
warum wir uns jetzt so auf diese Testpyramide versteifen
und dass sie eine Pyramidenform haben möge
und keine Eistütenform?
Ich meine, ist doch alles okay,
denn es ist halt eine Testeistüte.
Warum ist das denn jetzt wichtig,
dass das pyramidenförmig ist?
Also, ich glaube,
wir haben zumindest den ein oder anderen Aspekt schon angesprochen,
weil eben, wenn es eine Eistüte ist,
wenn wir Dinge auf oberen Ebenen, Integrationsstufen tun,
die uns teuer zu stehen kommen, länger laufen,
wir bestimmt kein Fast Feedback in jeglichem Sinne haben werden,
instabil sind.
Also, ich glaube, wir haben genügend Aspekte genannt,
warum ich das zumindest
in verteilten Architekturen für keine gute Idee halte.
Was ist dafür notwendig, um da hinzukommen?
Keine Eistüte zu haben, meinst du?
Ja, genau.
Also, wie kommt man quasi von wo auch immer man startet
zu einer guten Testpyramide?
Also, eine gute Basis,
um jetzt nicht unbedingt bei Adam und Eva anfangen zu wollen,
aber ist eine Teststrategie zu haben
und sich zu überlegen, wo machen meine Tests am meisten Sinn?
Und das muss nicht unbedingt heißen,
dass alle nach unten purzeln, die Pyramide entlang,
sondern sich tatsächlich zu überlegen,
was kann ich wo am besten testen?
Und da immer als oberste Prämisse sich vorzuführen ist,
wo kann ich mein Testobjekt am einfachsten, am besten isolieren?
Und wenn ich eine Schnittstelle habe,
und es gibt ja auch genügend Frameworks,
und ich benutze jetzt PACT,
um Consumer-Driven Contract Testing zu machen,
dann mache ich das halt da.
Wenn ich die Möglichkeit nicht habe,
dann schaue ich halt, ob ich meinen Service irgendwie
auf einer anderen Stufe isolieren kann gegen was anderes.
Also, sich zu überlegen, wo kann ich am besten isolieren?
Wo kann ich die Techniken, die es gibt, am besten anwenden?
Und da dann einfach den Test zu fahren
und das möglichst nach unten orientiert.
Aber Startpunkt, mach dir Gedanken über eine Teststrategie.
Schnapp dir deine Anwendungsarchitektur
und schneide klein von System über Produkt über Service
über Funktion über Klasse und schau, wo du das testen kannst.
Kleinschneiden ist, glaube ich, so ein Thema.
Architektur mit ins Boot holen gefällt mir.
Also, sowohl von der Dokumentation her,
als auch die Architekten gegebenenfalls
auch mal mit ins Team zu holen.
Und da dann in vier Augen, acht Augen, wie auch immer,
Gespräch ein Stück in die Tiefe zu gehen
und so isolierte Testobjekte zu bekommen.
Ist das Thema Microservices bei euch auch ein Thema?
Unbedingt. Also, Stichwort, wir wollen in die Cloud,
um das jetzt mal irgendwie so ganz profan zu nennen.
Wir haben eine sogenannte Technologieleitlinie
und die gibt mehr oder weniger
Microservice-Architektur vor.
Und deswegen ist auch unsere Pyramide
oder die Testpyramide entsprechend adaptiert worden.
Wir reden zum Beispiel von der Integrationsstufe,
die heißt Microservice.
Also, in der Anwendung zum Beispiel Frontend isoliert
von dem Backend testen zu können
oder Backend-Service 1 isoliert
von dem Backend-Service 2 testen zu können.
Also ja, ist bei uns ein Thema, ist mehr oder weniger
auch eine architekturelle zentrale Vorgabe so zu entwickeln.
Ja, dann hat man ja relativ schöne isolierte Objekte,
die man auch gut mit einfachen Schnittstellen ansprechen kann.
Wenn man die Arbeiten vorneweg,
Stichwort Domain Driven Design, die gut getan hat, ja.
Genau.
Und ich möchte noch mal kurz auf das zu sprechen kommen,
was wir vorhin gesagt haben über die Testpyramide.
Und weil nämlich schlussendlich,
um das noch mal auf den Punkt zu bringen,
wenn ich eine Test-Eistüte habe und viele großräumige Tests habe,
die, wie du sagtest, lang laufen,
die tendenziell bestimmt auch erst spät überhaupt lauffähig sind,
weil dafür einfach schon sehr, sehr viel da sein muss,
dann mache ich ja faktisch nichts anderes,
als Shift-Right.
Also genau das, was wir nicht wollen.
Ich verschiebe mein Feedback nach hinten,
sowohl wann ich das erste Mal so einen Test erfolgreich laufen lassen kann,
weil überhaupt genügend da ist, was getestet werden kann,
als auch die Dauer eines einzelnen Testlaufs,
die ja bei einem Systemtest, wenn es schlecht läuft,
auch mal ein paar Stunden betragen kann.
Das ist natürlich unglücklich.
Insofern, das ist mir ganz wichtig, da noch mal darauf rauszukommen,
warum reden wir über diese ganzen Sachen?
Warum machen wir dieses Shift-Down, wie du es nanntest?
Weil das eine Voraussetzung ist,
damit wir überhaupt ein erfolgreiches Shift-Left hinkriegen können,
dass wir also erfolgreich so früh wie möglich uns Feedback holen können
über das, was wir zu tun hier gerade im Begriff sind.
Und da sind wir jetzt auch wieder bei den Three Amigos.
Du holst dir Feedback vom Tester,
noch bevor die erste Codezeile geschrieben ist,
bevor überhaupt ein Test überhaupt Sinn machen würde,
sondern du lädst ihn direkt ein, wenn du spezifizierst.
Das ist doch die Idee dahinter.
Ja, und ein Zusatz noch, was völlig realitätsfremd wäre,
zu sagen, wir wollen überhaupt keine Tests auf oberen Stufen haben.
Ich brauche die natürlich nach wie vor.
Irgendwann will ich ja auch mal meine Anwendung in einem Geflecht,
in einem Prozess vielleicht auch testen können,
zusammen mit anderen Anwendungen,
und will sehen, wie die harmonieren, ob die konsistent sind,
ob die weichen Faktoren wie gefühlte Performance gegeben sind.
Aber das sind halt dann manuelle, explorative Tests vielleicht
und eher weniger automatisierte.
Eine Sache, die man bei der Gelegenheit vielleicht auch ansprechen muss,
ist, vergangenes Jahr war ich auf einem QS-Tag
und eine Frau hat dort einen sehr interessanten Vortrag gehalten,
in dem sie referiert hat über die Ergebnisse von einer Entwicklerumfrage.
Die war jetzt nicht besonders repräsentativ vielleicht.
Da gab es halt irgendwie Laufkundschaft.
Das wurde irgendwie, glaube ich, auch zusammen gemacht
mit High-Z-Developer und so.
Also es gab da bestimmt so eine gewisse Selbstauswahl.
Aber nichtsdestotrotz, was sie referiert hat, war unter anderem,
dass faktisch man momentan in der Industrie ein Shift-Right beobachtet.
Dass also Testen nach hinten geschoben wird.
Dass es weggeschoben wird.
Dass es irgendwie auf einmal vielleicht weniger das Problem von Entwicklern ist.
Also genau das Gegenteil dessen, worüber wir jetzt die ganze Zeit sprachen, Veit.
Wie stehst du dazu?
Hast du das auch vielleicht beobachtet in Diskussionen mit anderen?
Ist das eine Strömung, die du vielleicht wahrnimmst,
gerade wenn du jetzt neue Entwickler anheuerst?
Erzähl mal was dazu.
Also ich würde nicht so weit gehen, zu sagen,
dass das jetzt irgendwie eine Strömung ist.
Das würde ich ganz gern so Menschen wie der Kollegin überlassen,
die das da auch vorgetragen hat.
Aber ist natürlich schon zu beobachten.
Das ist das, was ich eingangs erwähnt hatte,
dass jetzt durch DevOps auch Impulse kommen,
die einen dazu verleiten, zu sagen,
na ja, gut, lass doch mal jetzt mal die schöne neue Welt rechts ausprobieren
und da vielleicht schauen, ob wir da nicht Dinge,
die wir eigentlich früher tun sollten,
in einer anderen Art und Weise einfangen, abfangen können.
Das ist halt leider ein Irrglaube.
Und von daher würde ich das so ein bisschen bestätigen wollen,
dass man das schon merken kann.
Also deswegen sagte ich ja auch,
für uns ist es Fluch und Segen zugleich,
jetzt über DevOps und dergleichen Dinge nachzudenken,
für uns jetzt in der zentralen Position, in der zentralen QM,
weil wir ja schon seit Jahr und Tag auf den Shift Left pochen.
Das ist ja jetzt nichts Neues.
Aber es wird halt noch mal ein bisschen erschwert,
wenn der Wind eher von der anderen Seite weht sozusagen,
von der rechten Seite.
Was fällt für euch alles unter Shift Right, rechte Seite rein?
Ist das nur betriebliche Themen?
Geht das auch in Richtung Security?
Geht das auch noch weiter, Governance generell?
Also ich habe da vor allem jetzt erstmal die ja schon Operations-Themen
oder auch die technologischen Themen auf dem Schirm
und auch die Monitoring-Themen oder so Sachen wie Feature-Toggling,
Can I Release, A-B-Testing.
Also die anderen Perspektiven, die du gerade noch reingebracht hast,
vor allem Governance ist natürlich auch spannend.
Da hätte ich jetzt aber gerade spontan gar keine Hinweise dazu.
Ja, aber DevSecOps ist ja ein Thema, was immer mal wieder diskutiert wird.
Wäre jetzt so ein Gedanke, wie kriegt man nicht nur funktionale
und vielleicht nicht funktionale Themen getestet,
so automatisiert, dass man sie halt recht früh auch im Prozess
regelmäßig nachtesten, Regression und Co. im Griff hat,
sondern dass man halt auch Security-Tests,
die vielleicht im Nachgang irgendwo Pentests,
vielleicht auch in Richtung statischer Analyse von Komponenten
und Vulnerability-Tests in die Continuous-Delivery-Pipelines mit reinzieht
und so halt auch in Richtung Links bewegen kann.
Es ist ganz interessant, dass du jetzt vor allem Stichwort
Vulnerabilities und statische Code-Analyse ansprichst,
weil deswegen bin ich gar nicht auf dich angesprungen,
weil wir das tatsächlich in der Dativ auch schon haben.
Also das ist ja auch ein Thema.
Also da laufen Dinge wie Widesource oder Fortify in,
jetzt bei uns der Jenkins-Pipeline, automatisiert mit.
Stichwort Penetrationstests, ja, das scheint mir immer,
da scheint noch irgendwie ein Stück weit Weg zu sein,
die zu automatisieren und das ist doch meistens immer noch
großer manueller Aufwand, soweit ich das beobachten kann.
Aber ja, macht das natürlich Sinn, das auch irgendwie links zu etablieren.
Das ist ja der Punkt, dass man sich mal so ein bisschen austauschen
und kennenlernt auch in so einer Folge
und die Gedanken mit Stichworten alleine vielleicht nicht reichen,
sondern Beispiele, die ganz hilfreich sind, finde ich auch so.
Wir hatten ja gerade auch so ein bisschen darüber philosophiert,
warum das irgendwie alles so in Richtung Tools zu gehen scheint
und in Richtung eben der rechten Seite dieser linken Acht.
Und meine persönliche Vermutung ist dann an dieser Stelle auch immer,
dass so Technologie halt irgendwie vergleichsweise harmlos ist.
Die tut ja keinem weh, so ein Jenkins, der ist gleich installiert,
da muss keiner an sich selbst zweifeln oder seine Herangehensweisen ändern
oder seine Verhaltensweisen ändern.
Sondern das kann man einfach mal machen.
Aber der wirkliche Wert, glaube ich, kommt eben genau aus den Dingen,
die viel weiter links passieren, nämlich da, wo Leute miteinander interagieren,
wo man gemeinsam versucht, überhaupt zu verstehen,
was das Produkt ist, das man da bauen sollte.
Und wenn man das gut macht, dann ist der aktive Schritt
des irgendwie geschweiften Klammern-Tippens und so,
meine Güte, das ist ja dann gemessen daran gar nicht mehr so wild.
Insofern gefiel mir das, was wir hier auch in unseren Notizen drinstehen haben,
einer Prozess-QS, dass man schauen soll, dass Qualität nicht nur daraus erwächst,
dass ich jetzt, keine Ahnung, halt eine Testsuite laufen lasse,
sondern dass da eine Vielzahl von ineinandergreifenden Aktivitäten stattfinden müssen,
als eine ganze Kette, als Resultat, der dann etwas hochqualitatives hinten rausfällt.
Und als ganz wichtiger Aspekt von dem, was du jetzt gerade gesagt hast,
um das noch zu ergänzen, bei uns gibt es immer das geflügelte Wort,
wir müssen mal zum Äußersten gehen und miteinander reden.
Am Ende ist es genau immer das, das kann dir kein Tool abnehmen,
das kann dir keine Vorgehensweise abnehmen.
Du kannst dir mit so Dingen wie einem 3-Amigo-Gespräch zumindest die Rahmenbedingungen schaffen,
dass man auch zusammenkommt, um miteinander reden zu können,
wenn man es anders nicht schafft. Aber darauf kommt es am Ende an.
Und darauf kommt es noch mehr an, wenn Dev und Ops,
wenn die unterschiedlichen Menschen, Prozesse, Kollegen zusammenwachsen sollen,
ja, Herrgott, dann müssen wir reden miteinander.
Und dann sollten wir es möglichst oft und viel tun.
Und ein Tool, ja, da bin ich bei dir, das ist dann am Ende auch schnell eingekauft,
wenn der Geldbeutel groß genug ist.
Ja, wie kriegt ihr dieses Reden hin zwischen Dev und Ops?
Werden da echt Teams zusammengewürfelt, die dann halt vorher einzelne Teams waren?
Werden die Teams dann nicht zu groß?
Oder wie geht ihr mit solchen Themen um wie Bereitschaft, Port und Co.?
Ja, das ist natürlich eine gute Frage, die ich so im Detail gar nicht wirklich beantworten kann,
weil ich da dann doch ein Stück weit zu weit weg bin.
Ich weiß, es ist noch nicht Teams oder die Anzahl der Produkte und die Anzahl der Teams, die wir haben,
da sind wahrscheinlich die wenigsten wirklich als DevOps-Team unterwegs.
Das sind jetzt Dinge, die erst erwachsen müssen, mit denen man sich genau,
das sind genau die Herausforderungen, die du beschreibst.
Kann man einfach die Leute zusammenwerfen und dann ist das plötzlich ein neues Team?
Was kauft man sich ein mit Operations? Stichwort Rufbereitschaft und solche Themen.
Das zieht ja noch viel weitere Kreise.
Stichwort irgendwie Betriebsrat und Arbeitszeitvereinbarung und Sonstiges.
Das sind alles Dinge, die besprochen, die diskutiert werden müssen, die jetzt gerade erst entstehen.
Also wird spannend sein, das zu verfolgen.
Am Ende, um es mir da auch ein bisschen leicht zu machen, schreibt man gerne überall drüber,
Whole Team Quality und die betrifft dann natürlich Menschen, die sich eher im Ops zurechtfinden,
genauso wie Menschen, die eher im Dev-Bereich sind.
Aber natürlich ist, das wissen wir ja auch, Größe von arbeitsfähigen Teams auch begrenzt.
Man muss schon schauen, wie man das gut hinbekommt.
Ich sehe das schon kommen, Veit.
Wir müssen dich noch mal zu einer Architektur-Folge einladen,
wo wir diese Themen dann en Detail diskutieren können.
Oh, ich will aber nicht in fremden Gewässern fischen.
Aber können wir uns gerne überlegen, ja.
Ja, oder bringst halt einen Architekten mit. Ist ja auch okay.
Oder das, genau.
Ja, noch einfacher.
Sehr schön.
Veit, was haben wir vergessen?
Was musst du ganz dringend den Hörerinnen und Hörern noch mitteilen?
Oh, das ist natürlich sehr überraschend.
Jetzt muss ich gerade mal rekapitulieren.
Eigentlich haben wir tatsächlich nichts vergessen.
Das kannst du ja alles dann schneiden.
Aber vielleicht kann man einfach …
Also, wenn du mich fragst, was wir vergessen haben.
Wir haben eigentlich nichts vergessen.
Wir können aber eine Aussage vielleicht noch mal ganz dick unterstreichen,
die wir auch schon am Anfang propagiert haben.
Nicht unbedingt, dass DevOps links beginnt.
Aber vielleicht, dass …
Und ich will auch nicht so weit …
Na gut, vielleicht streise ich das noch mal.
Weil ich weiß aus unserem Vorgespräch, dass du gesagt hast,
hier geht es nicht darum, das irgendwie in Balance zu halten,
sondern wir müssen links erst richtig machen, damit rechts auch funktioniert.
Ja, das habe ich gesagt.
Aber ich glaube, was du immer wieder mal propagiert hast,
da bin ich auch sehr mit dabei.
Nämlich, man muss es einfach überall machen.
Es gibt niemanden, der sich da zurücklehnen kann und sagen kann,
nicht mein Problem.
Ja, sonst funktioniert Whole-Team-Quality nicht.
Wenn sich ein Teil der Acht irgendwo rausnimmt,
ob das in der Anforderung, ob das in der Entwicklung,
ob das im Betrieb ist, ob das Support oder sonst wo steht,
jeder hat einen Beitrag dazu zu leisten,
damit Qualität wirklich Ende-zu-Ende funktioniert.
Und deswegen gibt es, glaube ich, auch in dem Training,
was du vorhin erwähnt hattest, so eine schöne Folie,
liegende Acht und dann Test hier, Test hier, Test hier.
Und zwar an allen Stellen von der Acht, ringsherum.
So ähnlich ist es halt, wenn Qualität funktionieren soll.
Das ist übrigens hochinteressant,
weil ich glaube, so ähnlich, so eine Folie,
die gibt es auch bei uns, ja.
Also von daher …
Ja.
Also von daher volle Zustimmung.
Ja, dann …
Sehr schön.
Haben wir es, glaube ich, oder?
Ich glaube auch.
Ich glaube, das wird eine ganz tolle Folge
oder ist eine ganz tolle Folge geworden.
Veit, vielen Dank, dass du da warst.
Danke, dass ich da sein durfte.

Folge 71: Isaac Perez on Infrastructure Strategy [EN]

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

Luca and Falko are joined by Isaac Perez, Head of Infrastructure at Fresha.

They discuss how to put together a strategy for the ever expanding responsibilities of devops/platform/infrastructure and all the areas that can fall under.

Questions discussed include the following:

  • What does the evolution of a traditional Infra / DevOps team to a modern one look like?
  • How do you show business impact of invisible work?
  • How do you modernise your strategy with old people?
  • How do you actively plan for the future, instead of being ambushed by it?

In this episode, Isaac Perez, head of infrastructure at Fresha, delves into the intricacies of creating and implementing an infrastructure strategy within the DevOps framework. He highlights the evolution from traditional operations to an agile, user-centric approach that aligns with modern software development practices. Perez underscores the significance of considering both technology and business objectives, while also focusing on improving developer experiences and service stability. He shares insights on enabling teams, dealing with distractions, and optimizing infrastructure decisions to support business growth and efficiency.

Inhalt

  • Introduction of Isaac Perez and his role at Fresha
  • The evolving role of infrastructure in DevOps
  • The significance of infrastructure strategy
  • The shift from traditional operations to agile methodologies
  • Integrating developer experiences with operational efficiency
  • The impact of infrastructure decisions on business outcomes
  • Challenges in balancing technology advancements and business needs
  • Role of microservices and platform stability in business growth
  • The importance of enabling teams and handling distractions
  • Infrastructure strategy’s influence on organizational structure
  • Recommendations for creating an effective infrastructure strategy
  • The role of microfeedback loops and efficiency in DevOps

Shownotes

Isaac’s Medium posts
Isaac’s LinkedIn

Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)

Welcome to a new episode of DevOps auf die Ohren und ins Hirn.
Or in English, DevOps from your ears straight to your brain.
Usually this is a German language podcast, but we sometimes make exceptions for international guests.
Today is one such exception.
My name is Luca Ingianni and I host this podcast together with my colleagues Dirk Sölner and Falco Werner.
We’re DevOps consultants, trainers and coaches trying to get teams to work together better and create better products for their customers.
And today we are joined by a very wonderful guest, Isaac Perez, the head of infrastructure at Fresha.
Isaac, very welcome to the show.
Thank you. Thank you for having me, Luca and Falco.
Tell us a little bit about yourself, Isaac. What do you do for a living?
I lead the infrastructure teams at Fresha, which is a beauty and wellness platform.
It’s actually two-sided. We have the marketplace where you can book your appointment in a hair salon or nails or a massage or spa.
And we have the business management platform that allow those businesses to do everything that they need to run their business,
manage the rotation of the staff, sell products, marketing campaigns, book appointments, take payments.
And anything that you need, really.
The main areas of the teams that I lead, which are part of the platform organization, are focused on cloud infrastructure.
So traditional, where you run your workloads for us, AWS and EKS mainly.
And the other parts are deployment pipelines and developer experience.
So how we can get that software development cycle shorter and have a better user experience.
My background is in systems administration, data center operations, then DevOps, then platforms.
So it’s kind of the evolution of the space as it went through the years.
Yes. And the topic that we have picked for today is infrastructure strategy, isn’t it?
Yes.
So this is something that I’m very curious about.
How to sort of deliberately create a strategy to evolve your infrastructure and the people operating it,
as opposed to being…
Stuck in a reactive mode and sort of trying to muddle through.
Okay. But before we dive into the topic, we have a tradition on this podcast for every guest to give us their definition of DevOps.
So, Isaac, what’s your definition?
That’s an interesting one, because it seems that everyone has a different definition and a different implementation.
To me, I started seeing it from one point, which was bringing…
Software development practices to operations teams.
Traditionally, operations teams were at most scripting and not necessarily like having a software lifecycle for their tooling,
like not treating their services, their outputs as a real service where you have to test it, deploy it.
So that was the initial part.
But then I realized that it has another component, which is before, like many years ago,
like development teams would throw things over the wall, as we say, and operations teams would have to run and deploy the changes or the new features that the software delivery teams did.
But that was the usual complaint.
But I also realized that operations teams used to do the same.
So we used to build a tool, whatever we wanted, and then tell all developers, now you use this.
Like, we don’t care what you think.
We don’t care about the user experience.
You’re just going to use it.
And that caused frictions.
Both ways.
So I think DevOps is bringing two walls closer together in the sense that operations do more software development, more agile and more user experience.
But at the same time, development teams also learn how to run their services.
They own them now.
In theory, they own them or they should own them.
They got better at productionizing those services and maintaining them and making them operationally excellent.
Which was not something that software product teams were good at or were not good.
Like, it was not one of the goals for them.
It was just ship features.
And now it seems that both walls got a bit of each other.
And to me, that’s a better outcome than the silos.
Okay.
And where is testing in this?
That’s a good question.
To me, testing, I see it as kind of a platform offering.
So the platform team.
The team should provide the tools to do testing, like tooling services, like build a framework and the software teams should do the testing because they know that their software better.
So I think they should be able to run, create better tests and it goes earlier in the in the cycle, but with that with some help because the testing mentality is a bit different from software mentality when they test a lot.
Think about edge cases and load.
And all that, but I still think it’s better if most of the testing happens early in the cycle like TDD and done by software engineers with the help of some either coaching and tooling and platform services provided by really real experts also doesn’t scale if it’s not distributed.
You cannot have like one tester or one QA or a team that ends being the bottleneck for everything that’s deployed that reduces.
You cannot have one tester or one QA or a team that ends being the bottleneck for everything that’s deployed that reduces.
Makes the deployment times or recycle time much, much longer.
After operations, is there something that you need to consider in the value stream that’s after the operations teams or the infrastructure?
That’s a good question.
I would say the product team, right?
After that, you need to ensure that the features that you deliver.
Well, there’s two dimensions.
One is that the features actually produced an outcome from the business that they’re not, I don’t know, we just shipped a feature, doesn’t provide anything.
And then that you can continuously maintain and evolve that feature.
So one would be more technical in the terms of like, can we maintain, can we evolve this feature?
Do we have the metrics to know from an operational point of view that’s working well?
But also do we have the metrics to know that from a business point of view, it’s working well, it’s worth it?
Is it worth the cost?
How’s your connection to the customer then?
My connection to the customer, it depends.
These are another interesting question because usually I have a very personal distinction between users and customers.
To me, in the platform world where I sit in infrastructure or DevOps or platform, users are usually software engineers.
Who use the tools that we build.
But they’re not our customers because they don’t pay our salaries.
Our customers are the end customers that buy the products that the company sell.
And at the end of the day, those are the important ones.
So our users or software engineers are just a proxy to reach the customers.
Sometimes, most times, they both align.
So we create better pipelines, better developer experience, so we can get more features out and more stable features out to the customers.
But sometimes we may do some security work that actually hinders a bit the developers, but it’s to protect the customers.
Maybe we do some high availability work that hinders the developers, but protects the customers.
So at the end of the day, the customers, the ones who pay, are the ones we serve.
And most of the time we do it through our users who are the software engineers.
All right.
So maybe now is a good time to switch gears.
And I’m going to ask you a question.
And take a step back and set the stage for what we want to talk about, which is infrastructure strategy, right?
Why do we need that?
And did we have that before?
And what does it look like?
What did it look like?
I mean, you spoke in the introduction a bit about this separation between dev and ops, you know, the famous wall of confusion.
Was that part of a strategy or was that just an accident?
That probably was a result of the environment.
I wouldn’t call it an environment.
I wouldn’t call it an accident or a strategy.
I’m pretty sure it was not part of a strategy, because when you think about it, it seems a pretty bad strategy to have.
It’s like, let’s get operations and developers not talking to each other so they cannot work together and we release worse features less often.
So that as a strategy seems something no one will come out with.
But that was the result.
So I think it was a product of the time where Agile was.
It was probably still coming.
Well, it didn’t even exist before.
It was very waterfall of planning and you had two different sections and they have their different waterfall processes and Agile started catching up, but operations was behind.
So I think that the strategy was always there.
It just didn’t caught up with the times or with the modern practices and people at the strategic level were not thinking, updating.
They were not thinking, updating.
They were not thinking, updating.
There’s a way of thinking about the strategy, a way of thinking about technology or engineering in a modern way.
They were just the old waterfall process.
This is my turf.
This is your turf.
Don’t touch it.
We’ll talk at the end kind of thing.
And I think it makes sense from the point of view that strategies are usually created by senior people who most of the time are older and they’re setting their ways.
Well, I’m saying that I’m not that young, but I think that because they were created by an older generation, it took some time until the new generation who were more in Agile and had a more open mind, at least to that point, started creating the strategies themselves and they realized, okay, this doesn’t make sense.
We’re going to get better outcomes if we work together and then started being part of the new class of strategies, if you want, of the new strategies that were being created.
Okay, so now we do need a strategy.
What is, what’s the point of this strategy?
What are the cornerstones of the strategy?
What does the strategy aim at versus what maybe does it explicitly say, this is out of scope for me?
Yeah, that’s the always problematic point when you start a strategy, like what do you want the strategy to do?
What is the strategy for?
And I think this is where…
Most, not most, but hard for business leaders or like engineering leaders, especially in infrastructure, you’re quite removed from the business and sometimes we forget about the business part and we’re just like, we need to use Kubernetes or we need to use like, and really no one cares if you use Kubernetes or not.
Like you think like they have salons care if we run in AWS and Kubernetes, no, they don’t.
They care about the reliability of the product, how fast the features are.
Arriving at their terminals, at their like fonts.
So the strategy should really understand what is the problem we’re going to solve for the business.
It can be a technological problem, but it has to help the business.
And where was the environment?
So I would not do, and I certainly did different strategy in smaller startups than a scale up like Fresha.
They’re different than bigger companies they work for like Thomson Reuters, we have like 5,000 people in the…
Business unit that I was working in.
And so the strategy not only has to take into account the problems that you want to solve for the business, not for technology itself, but also the environment where it works.
Not the same is a highly regulated industry.
It is not.
It’s like it doesn’t matter if you lose the data for like one hour.
It’s like those kind of things should guide the strategy too.
Okay.
So what is the point of the strategy?
What is the goal of such a strategy?
Or what happens if you don’t have such a strategy?
So, okay, those two different, let me see if I can split them.
The goal of the strategy, it has to be to help the business reach its goals.
So let’s say that you’re in growth mode, like hyper growth mode, and you need more users per month, more active users per month, which is usually like a common goal for growth companies.
Then how do you get those users?
And do…
How do you get and how do you lose these users?
Something I like from system thinking is when you have a stock, you can fill…
Let’s say you have a bathtub, you fill water and you have the drain.
So you can fill the bathtub, you can put more water faster than it drains or stop the drain.
So when you have more active users, I say you want more active users, you get new users, but users leave.
And more users, let’s say that you need more features.
And users leaving is because the platform is not stable.
So they get frustrated and they leave.
And simple examples.
And what we can do as a strategy from infrastructure in that sense will be less work on having deployments to production faster or short and feedback loops for developers.
Those two common things that are usually painful and people always want deployment from, you could make a change to it’s running in production faster.
So you could work on that or you could say, actually we’re losing lots of users because the platform is not stable.
Because the platform is not stable.
Die Plattform ist wirklich unstabil und wir müssen ein paar Arbeiten machen, um die Kette zu stabilisieren.
Und das ist wichtiger, als mehr Features zu haben.
Wir können sagen, eine kurze Strategie, um die Stabilität zu fixieren, damit wir die User nicht verlieren.
Und eine langfristige Strategie, wir wollen mehr Features erstellen.
Die Stabilität ist auf einem guten Niveau.
Okay, aber das klingt immer noch wie eine Produktstrategie, nicht so viel wie eine Infrastrukturstrategie, richtig?
Ja, aber die lustige Sache ist, dass wir die Infrastruktur als Produkt behandeln sollten.
Wir sollten es nicht selbst machen.
Zumindest glaube ich das.
Unsere Infrastrukturstrategie sollte nicht so anders sein wie die Produktstrategie.
Was sich ändert, ist, wie wir sie implementieren.
Zum Beispiel könnte eine Produktstrategie sein, dass wir diese neue Feature eröffnen,
die euch ermöglicht, Abonnenten zu buchen,
ich weiß nicht,
von eurem Handy.
Weil wir das vorher nicht gemacht haben, was auf der Website war.
Und von der Infrastrukturstrategie her könnten wir sagen,
wir müssen eine Deploying Pipeline für Mobiltelefone erstellen,
weil wir keine vorher hatten.
Und es hat drei Tage oder fünf Tage gedauert, um zu bauen, zu kompilen, zu publizieren und alles.
Also unsere Strategie für die Infrastruktur wird das Geschäftsziel in einer anderen Weise unterstützen.
Und vielleicht ist es, um euch ein Beispiel zu geben, ein bisschen mehr Infrastruktur.
Und ein Projekt, das wir momentan arbeiten, ist das Migration von Jenkins und anderen
Arbeitsplattformen zu Argo Workflows.
Warum denken wir, dass das wichtig ist?
Ich denke, weil sie diese zwei Bereiche entwickeln, mehr Dimensionen zu diesem.
Aber zwei wichtige sind die Entwicklungserfahrung und die Entwicklungserfahrung.
Also die Erfahrung, die die Entwickler haben,
und die Entwicklung der Deploying Pipelines,
mit denen wir denken, dass es in Argo Workflows viel besser werden wird.
Und unsere eigene Erfahrung in der Entwicklung der Pipelines,
die viel, viel schneller werden wird als in Jenkins,
weil es viel einfacher zu arbeiten ist, es ist einfacher zu testen und so weiter.
Also die Art und Weise, wie wir die Geschäftsstrategie halten,
wäre langfristig, wir migrieren zu einem Cloud Native Workflow Engine,
das kosteneffektiv sein wird,
viel schneller zu arbeiten,
und viel schneller zu entwickeln.
Aber das klingt immer noch reaktiv für mich, richtig?
Du hörst auf die Anmerkungen der Entwickler, was eine gute Sache ist,
nicht wahr?
Aber es ist nicht proaktiv, ist es nicht?
Du wirst nur warten, bis du die meisten Anmerkungen bekommst,
und dann gehst du und fixierst es.
Ja, ja und nein.
Wir, zum Beispiel, können,
wenn du nur die Anmerkungen hörst,
hast du Jenkins fixiert.
In diesem Fall zum Beispiel.
Aber ich denke, die Strategie kommt dazu,
das Problem zu sehen,
dass es bessere Deployment Pipelines gibt,
und dann zu denken, okay,
wir gehen zu Cloud Native Tooling,
oder wir gehen immer noch zu Cloud Native Tooling.
Jenkins, zum Beispiel, ist zwei Generationen alt,
wir wollen etwas, das Cloud Native ist,
für diese Gründe,
was kosteneffektiv ist,
einfach zu arbeiten,
einfach zu unterstützen,
weil wir bereits viel Erfahrung in Kubernetes haben,
und das funktioniert in Kubernetes,
also denke ich, es ist ein bisschen mehr,
es ist das Hören zu diesen Anmerkungen,
aber auch gleichzeitig,
du wirst deine Plattform weiterentwickeln,
in Richtung eines Zukunfts,
das sich mehr mit,
also du wirst die Plattform weiterentwickeln,
in Richtung einer flexibleren und nachhaltigeren Lösung,
die dir ermöglicht,
in der Zukunft schneller zu gehen.
Also vielleicht fragst du dich,
etwas, das wir gemacht haben,
ohne zu hören,
zu User Complaints zu Beginn.
Und das ist,
ich habe noch ein anderes Beispiel,
wir haben begonnen, Backstage zu nutzen.
Was ist Backstage?
Ich habe das noch nie gehört.
Okay, das ist eine interne Entwicklungsplattform.
Es wurde intern geschaffen,
Spotify hat es geschaffen,
sie haben es open source gemacht,
und es ist irgendwie das Standard,
open source,
eine interne Entwicklungsplattform.
Und wir haben mit Kit angefangen,
weil wir wussten,
wir haben einige Schmerzpunkte,
wie z.B.
finden Sie Ihre Services.
Wir haben begonnen,
mit Microservices zu migrieren,
und jetzt haben wir etwa 80
zwischen Monolith und Microservices.
Und es ist sehr schwierig,
eine neue zu erstellen.
Und es ist sehr schwierig,
die Services zu finden,
die sie besitzen.
Wir haben Splitsheets,
und du musst durch den Code gehen.
Also Backstage hat das Problem gelöst,
plus es ist ein weiteres Tool,
das, sobald wir einen Fuß in das Tool haben,
es wird uns ermöglichen,
viel mehr Sichtbarkeit und Fähigkeiten zu bieten.
Und das kam,
teilweise aus Schmerzen von Entwicklern,
aber es war okay,
wir sehen,
interne Entwicklungsplattformen
werden in der Zukunft wichtig sein,
also wollen wir in sie investieren.
Und wir haben mit Kit angefangen.
Und das ist eine Art Stepping Stone
zu einer Plattform-Team,
einer Plattform-Organisation,
anstatt der traditionellen Infrastruktur,
wo wir etwas bauen und es nutzen.
Interessant, ja, danke.
Das war ein sehr gutes Beispiel.
Aber es bringt mich zu etwas anderes,
was mich bedroht hat,
nämlich dass du selbst gesagt hast,
dass die Beauticianen
oder jeder, der deine Plattform nutzt,
nicht wirklich interessiert,
ob du Backstage oder Kubernetes
oder irgendwelche dieser lustigen Dinge nutztest.
Also, ich meine,
und ich stimme dazu,
dass dies wahrscheinlich wertvoll ist,
aber wie kannst du Business-Impact zeigen?
Wie kannst du Wert für solch unbeleuchtetes Werk zeigen?
Ja, das ist ein guter Punkt.
Und es kommt alles zu,
aus meiner Sicht,
Metriken,
über die das Unternehmen sich interessiert.
Also z.B. für Backstage
eine der Metriken,
die wir verbessern wollen,
ist Onboarding.
Also sagen wir,
dass du 50 Entwickler im Jahr hast
und anstatt Onboarding,
hast du für 4 Wochen
mehr als für 2 Wochen,
weil sie alle Dokumentationen finden.
Das sind 50 pro 2 Wochen,
du bekommst 100 Wochen Produktivität pro Jahr.
Also das ist sehr einfach
für das Unternehmen zu zeigen,
wie wir 100 Wochen Produktivität
zum Ingenieur-Team hinbekommen.
Und das Gleiche
mit täglichen Aufgaben.
Es ist nicht so einfach,
nicht so einfach zu sagen,
wir bekommen etwa 2 Tage mehr
oder so etwas wie das,
aber wir können Metriken haben,
z.B. wenn es User-Surveys sind.
Wie lange dauert es,
um einen Service zu finden,
mit dem du arbeiten musst?
Die Dokumentation,
die Anwohner.
Also vorher
dauerte es vielleicht ein paar Stunden,
bevor du an einem Ticket startest.
Jetzt dauert es 5 Minuten.
Also das sind die Metriken,
die du nutzen kannst,
um Impakt zu zeigen.
Und im Backstage
sind die meisten Metriken
zu dem,
wie lange es dauert,
um etwas für einen Entwickler zu machen,
als jetzt.
Ein weiteres gutes Beispiel ist,
dass wir uns in Richtung
der Migration
zu Microservices
und der Extraktion
des Monoliths
bewegen.
Das ist ein sehr neues Problem,
das noch niemand
vorher hatte.
Und das war eine Lüge.
Ich dachte,
ihr würdet…
Keine Ahnung.
Also,
es ist nicht einfach,
einen neuen Service zu erstellen,
ohne das Tool zu haben.
Aber das erste,
was wir mit Backstage gemacht haben,
war,
Service-Template zu nutzen,
also,
ihr klickt
und bevor es euch 2 Wochen dauerte,
um einen neuen Service zu erstellen,
im Allgemeinen.
Jetzt dauert es,
ich denke,
jetzt sind es ein paar Stunden.
Es ist nicht
Zero-Zeit,
aber
ihr ging von 2 Wochen,
also,
sagen wir,
ihr plant
diese neue Feature,
wir brauchen
einen neuen Service,
denn wir wollen
zu Microservices
migrieren
und das hat andere Vorteile.
Wir planen
4 Wochen
oder 6 Wochen,
weil die ersten 2
mussten wir
nicht haben,
den Service.
Und jetzt
sind diese 2 Wochen
weg.
Ja,
wir werden es machen.
Es sind nur 2 Stunden,
also müssen wir nicht
so viel für es zahlen.
Also,
ihr verringert
die Migration
aus
der Monolith,
was
alle
Kaskadeneffekte
oder
schnelleres Entwicklung
bringt.
Aber ihr entfernt
essentiell 2 Wochen Arbeit,
jedes Mal,
dass ihr das macht.
Und ich denke,
das sind die Metriken,
die das Unternehmen
interessiert.
Und
sie sind,
sie sind super cool.
Du musst ihnen sagen,
schau,
es hat 2 Wochen gedauert,
um ein Service zu schaffen,
jetzt dauert es 2 Stunden.
Und vielleicht in einem Monat,
wenn wir mehr investieren wollen,
dauert es 0.
Weil alles
automatisiert wird.
Nicht nur das,
der Service kommt
mit
90% Produktion,
was wir als
Produktion bereit
bezeichnen,
das ist
ein weiteres Monat Arbeit,
das die Entwickler
tun müssen.
Das bringt mich
zu einem interessanten
Frage,
das ich
während
deiner Rede
beantwortet habe,
dass es
so eine Strategie
Formulierung
gibt,
wie würde es Teil
deiner Strategie sein,
zu sagen,
wir werden
zurückgebracht
oder wird
die Strategie Formulation
auf einem hohen Niveau sein,
wo wir sagen,
oh,
wir müssen
Wege finden,
um den Zeitraum
für einen neuen Service
zu reduzieren,
oder so etwas.
Ja,
ich würde nicht
die Technologien
selbst in
der Strategie
inkludieren.
Und das ist etwas,
über das ich
auch darüber
nachgedacht habe,
dass es
eine Strategie
für dieses Jahr
gibt.
Und du sagst,
oh,
wir brauchen eine
internen
Entwicklungsplattform,
weil das
diese und diese
Probleme
lösen wird.
Und für
irgendeinen Grund
startest du
im Januar,
du startest
im Juni.
Ich würde nicht
meinen Namen
in einer Technologie
in diesem
Kutting Edge
im Januar
sein,
wie es
im Juni
sein wird.
Ich denke,
die Technologien
sollten da sein.
Du solltest entscheiden,
welcher Cloud Provider,
wie du sie benutzt
wirst.
Für diesen
muss die Technologie
da sein.
Für Strategien
von
wir werden
die Entwicklungserfahrung
verbessern
bis zum Ende
des Jahres,
was wir
tun wollen,
und Teil davon
ist,
dass wir
besser mit
den Ideen
integrieren wollen.
Ich würde nicht sagen,
dass wir
von Tag 0
mit Visual Studio
oder VS Code
integrieren wollen.
Ich würde sagen,
wir wollen besser
mit Ideen
integrieren.
Wir werden eine Phase
der Forschung
machen,
welche die
am meisten
genutzt
und gut
erhoben sind.
Und dann
entscheiden wir.
Das Wichtigste
für diese Strategie ist,
besser mit
der Idee
zu integrieren,
nicht mit welcher Idee.
Für große
Migrationen,
wenn du
von MySQL
nach Postgres
migrieren willst,
musst du
dich
in der
Art
der
Idee
konzentrieren.
Und dann
kannst du
die
Idee
mit
den
Ideen
integrieren.
Und wenn
du
die
Idee
mit
den
Ideen
integrieren,
dann
kannst
du
das
mit
den
Wettbewerben
machen.
Wenn du
eine
Entscheidung
hast, die
einen
Loch unter
der
Wetterlinie
machen wird,
brauchst du
eine gute
Entscheidung.
Wenn sie
über der
Wetterlinie
ist,
ist es
okay,
du
wachst.
Für
kleinere
Entscheidungen
weniger
Einwohnung
von
den
Wettbewerben.
Und
ich war
involviert
als Teil
von
der
Leadership
Level.
Ich habe nur
einige
Bedingungen
gesetzt.
Zum Beispiel
wollte ich
Cloud Native
sein,
damit wir
die Kosten
später
optimieren können.
Wir wollen
es in
Kubernetes
runten,
weil wir
die Kosten
optimieren.
Es ist
eine
gute
Entscheidung,
die
wir
haben.
Wir
wollen
die
Kosten
optimieren.
Wir
wollen
die
Kosten
optimieren.
Wir
wollen
die
Kosten
optimieren.
Wir
wollen
die
Kosten
optimieren.
Wir
wollen
die Kosten
und die
Kosten
en
nicht
übertragen
.
Das
sollte
bei
Kubernetes
auch
sehr
tätig
sein .
Aber
an
VP oder
CTO
Niveau,
es wird
constituiert, es wird
wie du in der Zukunft funktionierst, in einer großen Art und Weise.
Aber einige Tools, wie Backstage und all das,
aber das Problem ist, dass es nicht so viele Optionen gibt für Backstage,
das ist der einzige, der die Entscheidung für dich gemacht hat.
Aber wenn es zwei oder drei Contestants gäbe,
denke ich, dass das mehr eine Konversation sein könnte.
Okay, aber das bedeutet in der Regel,
dass auch wenn du nur Entscheidungen über die Wasserline delegierst,
das noch viel Verantwortung auf individuelle Teams aufbaut, nicht wahr?
Was geht es darum, Teams zu ermöglichen,
diese Verantwortung effektiv und sicher zu nehmen?
Es gibt zwei Wege, um über diese Liste zu denken.
Eine oder mehrere Dimensionen.
Eine ist, dass man sicherstellt, dass es ein sicheres Umfeld gibt,
wo Leute Fehler machen können und wir von ihnen lernen.
Also wirst du nicht öffentlich für Fehler verurteilt,
aber du arbeitest mit.
Du arbeitest mit ihnen, um sicherzustellen,
dass wir lernen, dass jeder von der Entscheidung lernt.
Und es hängt auch vom Niveau der Kompetenz ab.
Wenn du delegierst, delegierst du nicht das Gleiche für alle Individuen.
Einige Individuen haben viel bessere, andere Fähigkeiten als andere,
sodass du einige Taschen delegieren kannst.
Du musst also beachten, dass die Teams die Fähigkeiten,
die Wissen und die Erfahrung haben, um diese Entscheidungen zu machen.
Du kannst sie trainieren, hiren oder trainieren,
coachen sie, um auf dem Niveau zu kommen, um diese Entscheidung zu machen.
Dann geht es so, als wäre es auf der Wasserlinie.
Aber du musst auch sicher sein, dass es als eine Gelegenheit ist, zu lernen.
Nicht, wenn du das nicht richtig machst, dann werde ich dich verletzen.
Ja, niemand wird Entscheidungen machen oder endet alle mit Kaibm.
Das ist der alte, berühmte Quote.
Niemand wird verletzt, wenn man Kaibm wählt.
Also musst du ein bisschen experimentieren.
Und sicher sein, dass es okay ist, wir haben einen Fehler gemacht, wir lernen davon.
Also klingt es so, als ob das auch Teil deiner Strategie sein sollte,
diese Art von Kultur zu bauen, die Teams in Bezug auf, ich weiß nicht,
Fähigkeiten und Organisationen zu ermöglichen.
Würde das nicht richtig sein?
Ja, ich denke, das ist richtig.
Du planst die Strategie, du nimmst all diese Komponenten.
Und ich denke, dass, jetzt, dass du es erwähnt hast, es in den Umfeld kommt,
was du die Strategie für machst, denn wenn du die Strategie machst,
machst du es, um ein paar Probleme zu lösen, aber du hast die Grenzen des Umfeldes,
für das du eine Strategie bauen kannst.
Und diese Teil des Umfeldes ermöglicht Teams,
Entscheidungen zu machen, wenn das die Strategie ist, die sie folgen wollen.
Vielleicht willst du diese Strategie nicht folgen wollen.
Du bist wie ein Top-Down-Approach, der in einigen Umständen funktioniert,
oder unter einigen Umständen.
Aber ja, Teil der Strategie zu machen, ist wie, wir werden diese Entscheidung handhaben,
weil wir sie ermöglichen wollen, und sie werden mehr engagiert, wenn wir das machen.
Also ist es definitiv Teil der Strategie.
Gibt es gemeinsame beste Praktiken für Infrastrukturstrategien,
um sich davon zu erinnern, oder in irgendeiner Art und Weise
kann man einige Ideen verkaufen und nicht von Anfang an anfangen,
oder von einer Art und Weise auszutauschen, basierend auf dem, was funktioniert und was nicht funktioniert?
Denn Strategie ist meistens eine langfristige Sache, die man sich umsetzen kann.
Also ist es wahrscheinlich gut, einen Startpunkt zu haben.
Ja, ich denke, es gibt definitiv beste Praktiken,
wo es jetzt ein bisschen eine schlechte Reputation gibt,
für irgendeinen Grund, aber sie sind beste Praktiken, die ich denke,
du kannst anfangen, sie zu bekommen, du kannst dir helfen, deine Strategie zu orientieren.
Lass uns sagen,
ich bin nicht mehr mit AWS kennengelernt, das ist die einzige Cloud, die ich professionell benutze,
aber du hast AWS beste Praktiken und CIS, das Center for Internet Security Benchmarks.
Also du könntest sagen,
wir, ich meine, ich glaube nicht, dass jemand sagen würde,
wir wollen unsere Plattform weniger sicher machen.
Aber lass uns sagen, dass du sagst, okay, Teil der Strategie dieses Jahres ist,
dass wir versuchen müssen, dass die Plattform sicher ist.
Und das ist irgendwie
unheimlich.
Es ist nicht der Sinn, es zu sagen, aber was ist die Strategie?
Also du könntest sagen, wir werden CIS Benchmarks für AWS benutzen
und wir werden AWS beste Praktiken und die White Papers benutzen, die sie haben.
Und das wird dir die Strategie helfen.
Ich denke, das Problem ist, dass es keine beste Praxis gibt, um eine Strategie zu bauen.
Es gibt viel Lärm und es gibt einige gute Praktiken.
Du hast einige gute Bücher.
Aber es gibt keine Strategie,
zumindest die ich kenne, wie eine Template-Strategie für Infrastruktur.
Es gibt einige Dinge, die fast immer wahr sind.
Du willst eine bessere Entwicklungserfahrung.
Du willst schnellere Entwicklungszyklen.
Du willst mehr abhängige Software.
Aber es ist immer eine Balance.
Manchmal willst du viel mehr abhängige Software,
viel mehr Software als Entwicklungserfahrung oder viel mehr abhängige Software als Entwicklungserfahrung oder
die Geschwindigkeit der Feature-Belieferung.
Also ich denke, das ist business-spezifisch.
Und du kannst sehen, was andere Unternehmen
an einer ähnlichen Phase und einer ähnlichen Größe für die Beleuchtung gemacht haben.
Aber leider glaube ich nicht, dass es eine Template für Strategie gibt,
weil es so kontextabhängig ist und so businessabhängig ist,
dass es sehr schwer ist, über die Strategie zu denken.
Ich mag William Larsen, er hat einen guten Post,
den ich vielleicht teilen und in die Show Notes schicken kann.
Oh ja, wir legen das in die Show Notes.
Danke.
Und das Buch Good Strategy, Bad Strategy.
Das ist eine Art Bibel für Strategie von Richard Rummelth.
Das ist ein guter Leser, aber es wird dir zeigen, wie man eine Strategie bauen kann.
Nicht,
eine spezifische Strategie für Infrastruktur oder Technologie oder
was auch immer. Es geht darum, wie du weißt, ob das eine gute Strategie ist oder nicht.
Ja, ich wollte nur fragen, ob es einige gute Startpunkte gibt.
Danke, dass du diese beiden Ideen oder Ressourcen vorgibst.
Und natürlich musst du entscheiden,
basierend auf der Situation deiner Organisation,
ob du oder ob du wirklich neue Entwickler benötigst.
Dann ist es vielleicht wertvoll, um die Bedürfnisse der Entwickler zu priorisieren.
Vielleicht sogar vor dem Kunden.
Wenn die Kundenbasis breit und wach ist und das Wort von Maus zu Maus ausbreitet,
dann ist es wahrscheinlich nicht so wichtig, wenn du einen sehr guten Wert verwendest.
Es ist nicht so wichtig, um die Bedürfnisse des Kunden zu erhöhen oder sich auf die Bedürfnisse des Kunden zu konzentrieren.
Also aus diesem Grunde, ja, ich stimme dazu, was die Situation angeht.
Ja.
Aber seit wir über Menschen gesprochen haben,
würde eine solche Plattformstrategie auch in Bezug auf das Verorganisieren von Teilen oder sogar all deine Organisationen reichen?
Ja, absolut.
Ich denke, das muss sein.
Nun, total.
In meiner aktuellen Rolle, zum Beispiel,
würde es total Teil der Strategie sein und es ist Teil der Strategie.
Also wenn wir über die Strategie denken, zum Beispiel wollen wir uns viel darauf konzentrieren,
weil wir wissen, dass wir eine gute Erfahrung dieses Jahres haben.
Also eine der Dinge, die wir machen wollen, um diese gute Erfahrung zu erreichen,
ist es, eine Erfahrungsteilnehmer-Team zu erstellen und die zwei Teams, die ich leite, in drei Teams zu dividieren.
Eine wäre die Erfahrungsteilnehmer-Team, weil ich denke, es macht extrem klar,
was die Bedeutung dieses Teams ist, was die Ziele sind und was der Fokus ist.
Wenn du es in demselben Team hast, ist es wirklich einfach,
dich von allem zu zerstören und Prioritäten zu verändern.
Aber wenn du sagst, nein, Erfahrungsteilnehmer-Team,
dein einziges Ziel ist es, die Erfahrungsteilnehmer-Team besser zu machen,
dann ist die Frage, welche Erfahrungsteilnehmer-Team ich besser mache.
Nicht, ob ich EKS verbessern muss oder die Plattform stabilisieren muss.
Also ich denke, für größere Organisationen muss es am meisten Teil der Strategie sein.
Andererseits, weil ich viel Erfahrung in kleineren Organisationen habe,
macht es nicht so viel, weil du nicht so viel umzusetzen hast.
Also zum Beispiel die erste DevOps-Strategie, die ich gemacht habe,
war ich und jemand anderes.
Also, wie viel du mit zwei Leuten machen kannst.
Und ja, es ist wiederum kontextabhängig.
Aber in größeren Organisationen sollte es ein Teil sein, um sicherzustellen,
dass du die Ressourcen und die Kapazität, wo sie sein sollten, um deine Ziele zu erreichen.
In kleineren Organisationen, vielleicht kannst du ein bisschen damit spielen,
aber es wird sehr hart sein.
Ja, aber du sprichst immer noch über dieses Thema von Verletzungen.
Vielleicht kannst du ein bisschen mehr darüber sprechen.
Ja, ich denke, das ist eines der größten Probleme, die ich für die Erfüllung deiner Strategie sehe.
Das sind Verletzungen in zwei Gründen.
Und das ist etwas, worüber ich mich als Leiter sehr viel denke.
Und ich sage meinen Teams sogar, wenn ich dich verletze, sag mir, umdrehen zu lassen.
Und dann komme ich zurück, bis ich meine aktuellen Aufgaben beende.
Und ich denke, es gibt zwei Art von Verletzungen.
Die wichtigen, die du überlegen solltest.
Zum Beispiel, wir arbeiten auf dem langfristigen Projekt oder migrieren in Argo Workflows.
Aber die Stabilität der Deployment Pipelines,
und das ist einer der Gründe, weshalb wir aus Jenkins und dem aktuellen Setup migrieren wollen.
Es ist nicht großartig.
Also manchmal ist es so, dass es aufhört zu arbeiten und jeden Deployment Setup beeinflusst.
Und damit habe ich mit dem CTO gesagt, ich weiß, wir haben dieses langfristige Projekt.
Wir haben einen Meilenstein in einem Monat,
aber ich möchte zwei, drei Wochen in der Plattform stabilisieren, weil das jetzt sehr schmerzhaft ist.
Also lasst uns die Abläufe ein bisschen weiter entfernen, damit wir das lösen können.
Also ich denke, das müssen wir immer noch umsetzen.
Und wenn du die Strategie verändern musst, weil eine wirklich wichtige Sache kommt, musst du das machen.
Aber es gibt
die kleinen Dinge, die nicht wichtig sind, wie Mikrodistraktionen, die viel hinzufügen.
Zum Beispiel frage ich einen der Teamleute, hey, kannst du mir diesen Dashboard geben?
Kannst du mir diese Metrik geben?
Kannst du mir diese, ich möchte das von P99 zu P75 in diesem Dashboard ändern?
Also es gibt Dinge, die wir als Managern sehr schnell fragen,
zu unseren Vorschlägen oder den Leuten, mit denen wir leiten.
Und wir denken nicht, oh, morgen werde ich fragen,
warum hast du dieses Ticket nicht beendet?
Du hast gesagt, du wirst es morgen beendet.
Und dann habe ich die Hälfte des Tages von dieser Person verpasst,
um stupide Dinge zu fragen, die nicht wirklich für die Ziele zählen.
Also ich denke, es ist nicht einfach.
Ich mache es immer noch, und ich denke darüber immer mehr.
Also du musst dir als Leiter bewusst sein,
von all den Fragen, die du fragst und all die Interaktionen, die du hast mit den Leuten,
die zu dir antworten, entweder direkt oder indirekt.
Du musst die Sicherheit bieten und die Teams ermöglichen, zu sagen,
hey, kann ich das morgen machen, weil ich das beenden möchte?
Und es ist sehr hart.
Ich habe versucht, ich habe dem Team gesagt,
sag mir ernsthaft, lass dich alleine lassen.
Und sie tun es nicht so oft.
Also muss ich sie wieder erinnern, dass sie mir sagen können, das ist nicht wichtig.
Ich will diese andere Sache beenden.
Aber ja, es sind die Verletzungen.
Die Mikrodestruktionen sind ein
großes Problem, obwohl du denkst, es sind nur fünf Minuten,
aber es sind fünf Minuten, wie 20 Mal pro Woche.
Und die Mikrodestruktionen, die ich denke, du als Leiter musst wehren.
Ist es wichtig genug, uns von der Strategie zu bestrafen oder nicht?
Und manchmal wird die Antwort ja sein.
Ja, es ist interessant, dass wir immer wieder zurückkommen
auch zu diesem Thema von erhöhter Effizienz und darüber, wie wir etwas Zeit abschneiden können.
Und etwas, das ich ziemlich
bemerkenswert finde, ist dieses berühmte Webcomic XKCD.
Vielleicht hast du es gehört.
Der Kerl, der es schreibt, ist manchmal sehr interessant.
Nicht wirklich Comics.
Und eines der Dinge, das er macht, ist wie ein Tisch, in dem er sagt,
wie viel Zeit du investieren kannst für eine gewisse Zeitverschuldung,
abhängig davon, wie oft du eine Aktivität machst.
Und wenn, ich weiß nicht, wenn du fünf Sekunden 20 Mal am Tag sagen kannst, dann bedeutet das, dass du dir
ich kann es nicht erinnern, eine Woche von Optimierungseffort investieren
und du kommst voran in einem Jahr oder fünf Jahren Zeit.
Es ist ziemlich interessant.
Ja, das ist sehr interessant.
Ich war, ich war in den alten Händen für unsere Ingenieurarbeit.
Aber ich habe meine Seite in den alten Händen
für unsere gesamten Ingenieurorganisationen letzte Woche.
Und eine Sache, die ich in ein paar Artikel gelesen habe,
diese Mikrofeedback-Lupen und sie waren wie fünf, zehn Sekunden, 20 Sekunden.
Und
eine Teil meiner Präsentation war, eine war, dass wir diese Debex-Champions
in den Teams kreieren wollen und die andere war, dass ich den Ingenieuren sagte,
wenn du etwas hast, das zehn, 20 Sekunden, eine Minute dauert und du es oft machst,
lass uns wissen, weil wir dir helfen werden.
Ich möchte diese Feedback-Lupen abschneiden oder sie entfernen.
Und einer der Ingenieure kam zu mir und sagte, ich hätte das nie gedacht,
wenn du das nicht gesagt hättest. Ich denke, die Leute sind so verwendet.
Und ich sagte, ja, wenn du sieben, zehn Sekunden hast,
wenn du es genug Mal pro Tag machst, ist es wert.
Und es ist nicht nur einer, es sind 100 Ingenieure, 130, die wir haben.
Also stell dir vor, ob es wert ist oder nicht.
Ich denke, die Leute denken einfach nicht nur über diese kleinen Mikrofeedback-Lupen.
Und das ist etwas, das ich erwähnt habe.
Und die Leute waren überrascht und wir werden damit beginnen, daran zu arbeiten.
Ich denke, die Leute denken einfach nur über diese kleinen Mikrofeedback-Lupen.

Folge 70: Minimum Viable CD

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

In dieser Folge unterhalten sich Luca und Falko erneut über Continuous Delivery, dieses Mal aus der Perspektive des Projekts MinimumCD.

MinimumCD versucht einen allgemeingültigen Grundstock an Continuous Delivery Praktiken bzw. Sichtweisen zu definieren, der bei der richtigen Unsatzung als Leitfaden dienen sollte.

Falko und Luca haben sich mittlerweile aktive an diesem Projekt beteiligt, was uns zusätzlichen Schwung verleiht, ihm zu größerer Bekanntschaft zu verhelfen.

In dieser Podcast-Episode steht das Konzept des Minimum Viable Continuous Delivery (MinimumCD.org), mitbegründet von Bryan Finster und Dave Farley, im Fokus. Die Gastgeber, erfahrene Experten im Bereich DevOps, diskutieren technische und kulturelle Aspekte des Continuous Delivery. Sie teilen ihre Erfahrungen mit Continuous Integration und Deployment in verschiedenen Arbeitsumgebungen und betonen die Wichtigkeit von automatisierten Systemen im DevOps. Die Konversation beleuchtet auch Herausforderungen und Entwicklungen in der Softwareentwicklungspraxis, einschließlich trunk-basierter Entwicklung und der Auswirkungen dieser Methodologien.

Inhalt

  • Einführung in Minimum Viable Continuous Delivery
  • Erfahrungen mit Continuous Integration und Deployment
  • Technische Aspekte von DevOps und automatisierten Systemen
  • Kulturelle und organisatorische Herausforderungen im DevOps-Bereich
  • Trunk-basierte Entwicklung und ihre Auswirkungen
  • Evolution und Herausforderungen in der Softwareentwicklung

Shownotes

Minimum Viable CD manifesto

Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)

DevOps – auf die Ohren und ins Hirn
Ein Podcast rund um DevOps
Von Dierk Söllner, Falko Werner und Luca Ingiarni
Hallo und herzlich willkommen zu einer neuen Folge des Podcasts DevOps – auf die Ohren und ins Hirn.
Gestaltet und produziert von Luca Ingianni, Dirk Söllner und Falko Werner.
Wir sind DevOps-Trainer und Coaches mit langjähriger Erfahrung.
DevOps umfasst für uns kulturelle, organisatorische und technische Aspekte.
Heute haben wir ein recht spannendes Thema für euch, das wir schon so ein bisschen mal angerissen haben,
vor einer Weile, als Bryan Finster bei uns im Podcast zu Gast war,
der da berichtet hat von einer Initiative, die er zusammen mit ein paar anderen Leuten,
Dave Farley, glaube ich, unter anderem, ins Leben gerufen hat,
nämlich Minimum Viable Continuous Delivery, zu finden unter minimumcd.org.
Dieser Bericht, den uns da der Brian Finster gegeben hat,
hat Falko und mich irgendwie auch beide sehr begeistert,
weil ich finde, dass diese Initiative Minimum Viable Continuous Delivery, minimumcd.org,
ich weiß nicht, sehr den Nagel auf den Kopf trifft und viele Dinge zusammenfasst,
die, glaube ich, wir alle für wichtig halten.
Und insofern bin ich gespannt, weil ich habe ja einleitend gesagt,
DevOps umfasst für uns kulturelle, organisatorische und technische Aspekte.
Continuous Delivery klingt ja jetzt erstmal sehr technisch,
aber ich bin gespannt, wie kurz wir brauchen, bis wir plötzlich nach oben purzeln,
in Richtung Organisation und Kultur.
Aber vielleicht einleitend, mal so der Neugehalber,
wie lange ist es eigentlich her, Falko, dass du das erste Mal mit solchen Dingen wie Continuous Delivery zu tun hattest?
Na, letztendlich seit meiner Zeit als Entwickler, in der ich hauptberuflich Software entwickelt habe.
Meist im Automotive-Umfeld hatten wir zum Beispiel ein Portalprojekt mit Java-Basis
und Continuous Delivery Pipeline, die Jenkins-basiert war,
in der Zeit, bevor ich da war, noch die Hudson-Setups, die dann migriert worden sind,
wo dann so ein bisschen Testprozesse mit integriert waren,
aber auch viel händisches Deployment am Ende des Prozesses,
also mehr Continuous Build und halb Continuous Testing
und nicht ein komplett durchgängiger Prozess, der in Richtung Produktiv-Deployments oder so ging,
weil da teilweise Zugangspotenzial war.
weil da teilweise Zugangspotenzial war, weil da teilweise Zugangspotenzial war,
zur Hausberechtigung und Co nicht vergeben werden sollten an solche automatisierten Systeme.
zur Hausberechtigung und Co nicht vergeben werden sollten an solche automatisierten Systeme.
Wie sieht es bei dir aus, wann hattest du mit Continuous Delivery zuerst zu tun?
Also ach, du hattest an einer Zeit gefragt.
Ich hätte jetzt gesagt, irgendwo um 2016, 2015 war das bei mir. Wie sieht es bei dir aus?
Also bei mir war es noch früher und ich frage mich, Iggy, ob das bei dir nicht auch früher war?
Also bei mir war es noch früher und ich frage mich, Iggy, ob das bei dir nicht auch früher war?
Also als Jenkins noch Hudson hieß, da war das länger her als 2015 sogar.
Also als Jenkins noch Hudson hieß, da war das länger her als 2015 sogar.
Ich weiß es gar nicht mehr genau. Aber bei mir fing das sehr früh an und wie viele solche Sachen ja auch mehr so ein bisschen versehentlich. Das war jetzt nicht so, dass ich das irgendwie von langer Hand geplant hätte und gesagt, oh, ich muss eine Continuous Delivery Pipeline aufbauen oder sowas, sondern seien wir ehrlich, das war halt in der Hauptsache Faulheit.
Statt dass ich dieselben Handgriffe irgendwie hundertmal händisch mache, habe ich sie dann halt irgendwann mal wegautomatisiert. Das schlicht sich dann häufig so ein bisschen ein, dass man sich halt ein paar Skripte geschrieben hat, um sich die Arbeit zu vereinfachen, vielleicht auch nur punktuell, vielleicht irgendwelche Make Targets oder sowas.
Und das erste Mal, als ich ein, ich nenne es jetzt mal ein klassisches CICD-Werkzeug verwendet habe, das war eben damals Hudson, dass er sich dann irgendwann mal in Jenkins umbenannt hat.
Nachdem Oracle sich irgendwie die Supremacy…
… direkt einverleibt hat und die Namensrechte nicht mehr hergegeben hat, das muss im Jahre 2009, 2010 irgendwie so die Art gewesen sein. Ich weiß das schon gar nicht mehr genau, aber es ist schon sehr, sehr lange her.
Ich habe gerade noch ein bisschen recherchiert nebenbei. Also initial wurde Hudson 2005 released. Das letzte offizielle Release, die 3.3.3er Version, ist 2016 rausgekommen. Insofern kann das schon sein, dass es bei mir auch ein bisschen früher war, dass wir nicht mit der allerletzten Hudson-Version gearbeitet haben.
Aber ich denke viel…
… viel früher als 2012 war es bei mir nicht.
Okay. Und wenn du dir jetzt so mal anschaust, was so die Forderungen sind von minimumcd.org, wie viel von dem hast du denn damals schon umgesetzt? Was steht denn da drin?
Die minimalen Aktivitäten sind Continuous Integration, eine Applikationspipeline, unveränderliche Artefakte, Rollback on Demand. Was hast du denn damals schon einfangen können?
Na gut, also wir haben damals angefangen, kontinuierlich…
… die Integration, das heißt schon JAR-Files bauen, die dann als WARP-gepackaged auch auf die Produktivsysteme gekommen sind. Also das waren letztendlich auch Artefakte, die dann nicht nochmal angefasst worden sind, irgendwie händisch bei den Tests auch in Testumgebungen automatisch deployed worden sind.
Das war ja letztendlich auch nur Kopieren auf dem Application-Server und der hat das dann schlauerweise gleich mit ausgepackt. War schon ganz okay, was das anging.
Eine Anwendungspipeline ging halt bis in die Testumgebung. Also alles, was QA-Umgebung, Prerelease und Produktiv anging, war halt alles händischen Deployments versehen. Wir hatten an der Stelle eine Continuous Delivery Pipeline, die halt bei Tests aufgehört hat.
Wir hatten produktionsähnliche Testumgebungen, also es waren vergleichbare Server, waren halt in anderen Netzbereichen, nicht von außen erreichbaren Netzbereichen.
An sich von der Middleware, von den Versionen der verwendeten Software und Co. sehr gleich. Bisschen weniger Hardware, bisschen weniger Datenbank-Performance, aber an sich schon vergleichbar zu den Produktionsumgebungen.
Ein Rollback ist so eine Sache. Gab es für alle Datenbank-Anpassungen halt nicht. Das war dann teilweise ein händischer Prozess.
Das heißt, wir haben halt nur auf der Testumgebung immer wieder die Datenbank.
Wir haben die Datenbank frisch aufgesetzt und halt getestet, ob die Schema-Anpassungen passen.
Und ja, eine Anwendungskonfiguration war in den Artefakten teilweise mit abgebildet, dass du von Umgebungsvariablen ausgelesen bestimmte Anpassungen automatisch in der Produktiv-Umgebung, in der QA-Umgebung entsprechend hattest.
Also das war schon ganz in Ordnung.
Also Minimum-CD, Minimum Viable Continuous Delivery.
Ja, kontinuierliche Integrationsformate.
In der Konfiguration war es mehr als in eine Produktionsumgebung auch zu deployen oder in eine QA-Umgebung zu deployen.
Aber zumindest die Artefakte waren stabil, nicht zum Anpassen.
Die Umgebungen waren vergleichbar und wir hatten auch keine Testdaten in irgendeiner Form oder andere Konfigurationen in den Produktiv-Artefakten enthalten.
Also diese waren halt dann auf den Systemen hinterlegt. War ganz okay.
Wie sah es bei euch aus?
Wie sah es bei euch aus in der Zeit?
Da warst du nicht als Entwickler, sondern als Tester aktiv, ne?
Genau, da war ich Tester und habe mir da auch wiederum halt aus purem Eigennutzen eine Pipeline gebaut, weil ich es irgendwie leid war,
dieselben Tests irgendwie zu Fuß zu machen oder auch nur zu Fuß anzustoßen.
Und entsprechend war das zumindest für mich viel mehr ein U-Boot alles.
Das habe ich halt irgendwie gemacht.
Ich kann mich auch erinnern, ich bin damals in der Abteilung auf gar nicht so viel Verständnis gestoßen.
Die haben alle nicht so ganz verstanden, was ich da eigentlich so mache und wieso eigentlich.
Das ist ja komisch.
Das ist ja komisch, so alles automatisiert und so.
Aber ich kann mich erinnern, dass es für mich halt irgendwie eine echte Erleuchtung war,
weil all die Dinge, von denen man immer redet, das schwimmt dich halt, das gibt dir Ellenbogenfreiheit,
um dich auf die wichtigen Dinge zu fokussieren, explorative Tests zu machen und so.
Das ist dann halt tatsächlich alles passiert.
Und das ganz viel von diesem täglichen Klein-Klein und so war dann halt weg.
Das war übrigens ganz interessant.
Ich habe das auch seinerzeit für akzeptiert.
Ich habe einen Akzeptanz-Test eingesetzt von Komponenten, die von außen kamen.
Wir haben da ein Spezial-Testsystem für Avionik-Komponenten gekauft von einem Zulieferer
und die haben mit ziemlich hoher Frequenz neue Versionen uns gegeben.
Nicht deswegen, weil die irgendwie so gut waren, sondern weil ständig irgendwas anderes schief ging
und dann mussten sie immer nachlegen und nochmal nachlegen und nochmal nachlegen.
Und ich musste dann immer mich nochmal vergewissern, dass das Testsystem überhaupt noch richtig getestet hat.
Und insofern habe ich mir dafür dann auch sehr viele…
Abnahmetests für Produkte von außen geschrieben, was, glaube ich, ein gewaltiger Wert war.
Wie war denn die Testabdeckung, Unit-Tests und ähnliches in dem Zeitraum bei euch?
Weil wenn ich mir das vor Augen führe, war halt sehr viel Entwickler-Tests und wenig wirklich automatisierte J-Unit und Co.
Ja, da musst du natürlich stark unterscheiden, weil das eigentliche Produkt, an dem ich gearbeitet habe damals,
das war ja Helikopter-Avionik.
Die war natürlich stark reglementiert, die war sicherheitskritisch.
Da gab es natürlich fixe Ziele für Testabdeckungen, wobei die hauptsächlich manuell erreicht wurden.
Da haben wir wochenlang an irgendwelchen Helikopter-Eingabegeräten gesessen und Tests durchgeklackert und so.
Aber diese Eingangstests, die ich da gemacht habe, die waren dann schon ziemlich massiv automatisiert.
Also da bin ich dann auch quasi das komplette API von diesem Testsystem durchgegangen und habe da,
gegen jeden Mist, Tests geschrieben, im Rahmen der Zeit, die ich so hatte.
Und wie gesagt, das hat sich sehr bezahlt gemacht und das weiß ich noch, das hat auch damals den Zulieferer irgendwie sehr aus dem Konzept gebracht,
weil die irgendwie nicht damit gerechnet haben, dass ich so schnell Feedback liefern konnte.
Die haben gedacht, die schmeißen mir was über den Zaun, dann bin ich erst mal ein paar Wochen beschäftigt damit.
Und dann irgendwie habe ich ihnen dann am nächsten Nachmittag aber schon eine Liste von neuen Defekten geschickt.
Und das hat so ein bisschen gedauert, bis sie das tatsächlich für sich auch als Plus wahrgenommen haben.
Du meinst, dass vorhin…
Ja, vorhin, wann wir dann bei Kultur ankommen, das ist ja dann schon Kommunikation, Kollaboration,
erste Aspekte, die auch unternehmensübergreifend dann mit Erwartungen und Co. zu tun haben.
Das sind ja schon die ersten Kulturaspekte, die wir an der Stelle haben.
Unternehmenskultur, Erwartungen, Feedback, Zeiträume, Feedbackschleifen, mit denen man dann leben muss
und wo man dann halt auch erst mal geschockt ist, dass man nach einem Tag statt nach einer Woche oder nach einem Monat Feedback bekommt.
Ja, das war auch interessant, weil zunächst haben die natürlich auch so ein bisschen irgendwie…
Wurden die dann so ein bisschen nervös.
Aber nachdem sie dann gemerkt haben, ich meine es ja gar nicht böse mit ihnen,
sind wir dann auch tatsächlich auf eine sehr schöne, produktive Arbeitsebene gekommen
und konnten dann halt wirklich zusammenarbeiten.
Die haben dann auch gemerkt, oh, es lohnt sich auch für uns, da zuzuhören und aufzupassen,
weil wir haben ja einen Verbündeten, der uns hilft, das Produkt besser zu machen.
Also in dieser Hinsicht war es echt toll und da hast du recht.
Das war so ein Kulturwandel, so ein bisschen durch die Hintertür.
Das hat auf einmal die ganze Dynamik mit diesem externen Zulieferer verschoben.
Auch wenn das ja, schau mal, damals war ich ja noch ein junger Hupfer
und wusste noch gar nicht so richtig, wie die ganze Bude läuft.
Das ist mir alles mehr so passiert.
Ja, aber es war gut, wenn das so läuft und funktioniert.
Jetzt haben wir ziemlich viel über unsere frühen Erfahrungen gesprochen,
so 2010er Jahre, 11, 12, 15 oder so.
Wie sieht es denn aktuell aus?
Hast du noch Projekte, in denen du Continuous Delivery einsetzt?
Oder was waren die letzten, wo du aktiv damit gearbeitet hast?
Puh, das ist eine ganz interessante Frage,
weil in einem gewissen Sinne schwingt dieses Thema jetzt natürlich immer mit.
Ich vermute, das wirst du mir dann auch bestätigen können.
Das ist zwar häufig jetzt nicht mehr die Ebene, auf der ich mit den Teams spreche,
die ich berate beispielsweise,
aber natürlich haben die alle im Hintergrund eine mehr oder weniger wirkungsvolle Automatisierung,
Continuous Integration, Continuous Deployment oder solche Dinge.
Und jetzt geht es vielmehr um die Frage,
können Sie dieses mächtige Werkzeug, das es jetzt ja umso mehr geworden ist
und auch in einem gewissen Sinne ein viel einfacheres Werkzeug,
können Sie das überhaupt noch gut einsetzen?
Insbesondere, glaube ich, weil auch die Komplexität zugenommen hat.
Falco, du und ich, wir arbeiten jetzt ja weniger in Projekten,
die von einem Team gestemmt werden,
sondern wo dann sehr schnell viele Teams drin sind.
Und das gibt natürlich dann ganz neue Hürden für die Art und Weise,
wie man mit CI-Systemen umgeht und wie man auch mit deren Feedback,
umgeht.
Das ist ja was, was auch in den Minimum-CD drin steht.
All feature work stops when the pipeline is red.
Das ist eine von diesen typischen Sachen, die sagen sich sehr leicht,
aber hältst du das dann echt durch?
Genau, also die Arbeit an den Features wird dann unterbrochen,
wenn es eine Warnmeldung gibt aus dem System.
Also wenn die Continuous Delivery Pipeline rot meldet.
Das finde ich sinnvoll und richtig,
wenn man sich als Team so weit auf die Technik einlässt,
dass man auch die Pipeline letztendlich davon abhängig macht.
Also die gesamte Deployment-Prozesskette davon entkoppelt,
dass jemand dort händisch irgendwas tut,
sondern die Pipeline so weit automatisiert hat,
dass eben auch sehr viele Tests,
sehr viele Überprüfungen dort stattfinden von statischer Code-Analyse
über Unit-Tests, Schnittstellen-Tests,
Deployment mit bestimmten Testumgebungen Ende-zu-Ende abgeprüft werden,
Verhalten abgeprüft wird bis hin zu Unterstützung von Produktivumgebungstests,
die vielleicht auch Teil oder ganz automatisiert sind.
Und wenn man diesen Grad der Abhängigkeit oder Integration,
muss ja nicht negativ belastet sein,
sondern den Grad der Integration erreicht hat,
dann ist es natürlich wichtig, dass die Pipeline kontinuierlich gut funktioniert,
damit dass halt auch jeder Check-In getestet werden kann,
dass auch nach jedem Merge entsprechend bis in die jeweiligen Umgebungen deployed wird.
Und dann ist es natürlich, ich sag jetzt fast lebensnotwendig,
oder ja, auf jeden Fall notwendig für das Team,
dass die Pipeline stabil läuft.
Und wenn es halt einen Fehler gibt, der integriert wurde durch irgendeinen Zutun,
sei es ein Update von einer Library, die man nutzt,
oder von einer neuen Funktionalität,
einen neuen Update des Quellcodes,
dann ist es halt auch notwendig, sicherzustellen, dass die Pipeline weiter funktioniert.
Darum, ja, ähnlich wie beim Toyota-Produktionssystem,
Fließband, wo das Andon-Band, also die kontinuierliche Produktion gestoppt wird,
wenn halt dort ein Qualitätsfehler auftritt,
ist es letztendlich eins zu eins zu sehen wie eine rot meldende Pipeline.
Ja, und das ist ganz interessant, wo ich dir so zugehört habe.
Mir scheint früher…
Als wir da ein bisschen kleinere Brötchen gebacken haben
und auch irgendwie vielleicht niemand so wirklich erwartet hat,
dass wir eine Pipeline haben oder so,
sondern wir hatten die halt, weil wir das für eine gute Idee hielten,
da war irgendwie, da war das alles viel weniger kritisch
und auch viel weniger kulturell und prozessmäßig unterfüttert.
Damals konntest du dich irgendwie viel mehr drauf versteifen,
dass so eine Pipeline halt irgendwie ein technisches Gebilde ist,
wo irgendwie Bytes durchfließen.
Aber wenn jetzt hier zum Beispiel steht,
all feature work stops when the pipeline is red,
dann ist das ja erstens.
Das ist erstmal wirklich eine Vereinbarung auf Prozessebene
und ist etwas, wozu man sich wirklich bekennen muss als Organisation oder als Team,
dass man sagt, ja, das ist ein Wert, den wir dafür richtig empfinden,
für wichtig empfinden, auch wenn er uns vielleicht bisweilen mal auf die Nerven geht.
Weil wir haben ja alle irgendwie, wir haben irgendwelche Verpflichtungen,
wir wollen liefern und dann sagen wir, nein, wir machen es richtig.
Das ist ganz interessant.
Also ich habe das Gefühl, dass dieses ganze Thema,
immer mehr, wie soll ich sagen, seine Tentakel ausstreckt in Richtung nach oben,
in Richtung Prozess, Organisation, Kultur,
obwohl es natürlich weiterhin seine Wurzel in, sagen wir mal,
einfachen technischen Vorgängen hat.
Jemand checkt was ein und dann laufen halt irgendwie Dinge.
Naja, letztendlich ist es ja ein sozio-technisches System mit Komponenten,
die vorrangig in der Vergangenheit vor Einsatz von Continuous Integration,
Continuous Testing manuell abgelaufen sind.
Und immer mehr in Richtung Automatisierung gehen.
Und dann hat man halt diese Integration, diese auch Abhängigkeit.
Und muss man sich um das System kümmern, wie auch da wieder in der Automobilproduktion am Fließband
gibt es halt bestimmte Prozesse, die mit großen Pressenwerken,
mit Robotern, Schweißstationen und Co verbunden sind.
Wenn das Presswerk kaputt ist, muss das auch reparieren.
Wenn da irgendwie Ausschuss produziert wird, bringt es dir nicht weiter, das Presswerk laufen zu lassen.
Oder wenn der Roboter nicht ordentlich geschmiert ist und dann Stück für Stück Schweißpunkte an den falschen Stellen setzt.
Kannst du das auch als Ausschussproduktionsmechanismus verstehen?
Oder du sagst halt, du kümmerst dich auch darum, dass die Roboter an der Stelle funktionieren.
Und letztendlich ist eins zu eins das gleiche wie in der Softwareentwicklung.
Wenn du halt Dinge automatisiert, musst du halt auch sicherstellen, dass die Automatisierung funktioniert.
Wenn du dich darauf verlässt, dass Testumgebungen zur Verfügung stehen,
und du darauf testen kannst, ist es genauso ein Teil der Continuous Delivery Pipeline,
wenn diese Umgebung nicht da ist, dass sie halt dann repariert wird.
Genauso wie das Continuous Deployment oder Continuous Delivery Steuerungssystem,
sei es immer noch ein Jenkins oder sei es irgendein Git-Pipeline oder ein GitHub-System
oder was auch immer da noch so im Einsatz ist.
Wenn diese nicht funktioniert, dann funktioniert die Lieferung der Software nicht.
Dann ist alles,
was ein Entwickler tut, Verschwendung und deswegen gleiche Vorgaben,
gleiche Prozesse wie in Lean Production Systems, muss es repariert werden.
Roboter kaputt, Roboter reparieren.
Ja, aber das ist eben, du sagst es so, als sei das quasi einfach Natur gegeben
und irgendwie Gesetzmäßigkeit und so passiert das.
Aber ich habe das halt auch schon anders erlebt.
Der einzige Kunde, den ich je gefeuert habe, weil ich gemerkt habe,
wir werden da nicht übereinkommen, die waren genau so, die haben gesagt, na ja,
seit vergangenem Sommer sind wir nicht mehr in der Lage, Software zu bauen, aber macht ja nichts.
Ist ja okay, dann haben sie halt keinen Wert darin gesehen.
Die Frage ist halt, wo liegt der Wert in einer Continuous Delivery Pipeline, wenn man sie nicht nutzt?
Man kann sie theoretisch abschalten und kann es wieder händisch machen.
Also wenn sie sagen, sie können letztendlich nicht über die Pipeline deployen.
Wie haben sie dann ein halbes Jahr gearbeitet?
Haben sie halbjährliche Releases und es war egal?
Gut, mag ja sein.
Ja, sie haben,
das war dann genau ihr Problem, dass sie dann nicht mehr releasen konnten.
Und dann haben sich so langsam irgendwie die Features aufgetürmt.
Und dann haben sie gemerkt, das ist irgendwie jetzt doch ungünstig.
Insofern ja, aber das finde ich, ist das Spannende an solchen Pipelines.
Und das ist, glaube ich, auch der Grund dafür, dass ich dieses Minimum CD so spannend finde.
Wenn du es ernst nimmst, was da drin steht, dass du jeden Tag das Gesamtsystem integrierst,
dass du dich verpflichtest, keine weitere Feature-Arbeit zu machen, wenn der Build fehlschlägt
oder wenn die Pipeline fehlschlägt oder sowas, dann zwingt dich das dazu, handwerklich sauber zu arbeiten.
Und dann wirst du natürlich auch, das mag am Anfang vielleicht auch wehtun,
wenn du noch technische Schulden oder Architekturschulden aufzuarbeiten hast oder sowas.
Natürlich ist das dann echt scheußlich.
Aber wenn du dich dann mal rausgearbeitet hast aus dieser Grube, die du dir selber gegraben hast über viele Jahre,
dann wirst du halt wirklich belohnt mit einem sehr sauber funktionierenden, sehr verlässlichen, entspannten System.
Ich wollte mal sagen,
einfach eine Abstraktionsebene wieder zurückgehen und sagen,
wir reden relativ allgemein über Minimum Viable Continuous Delivery, also das Minimum CD Vorgabe.
Wir haben viel über kontinuierliche Lieferung gesprochen.
Wir haben in dem Zusammenhang über kontinuierliche Integration gesprochen.
Und letztendlich ist der dritte Pfeiler, den wir ja mit,
wir haben ja an der deutschen Übersetzung, du viel, ich ein bisschen weniger gearbeitet.
Wenn wir uns
die drei Säulen anschauen, haben wir über zwei davon gesprochen.
Und lustigerweise bildet jede von den Säulen immer auch einen Link auf die nächste.
Das heißt eigentlich so ein Top-Down-Ansatz.
Kontinuierliche Lieferung baut auf auf kontinuierliche Integration und diese baut wiederum auf auf trunkbasierte Entwicklung.
Darüber haben wir noch gar nicht gesprochen.
Deswegen hätte ich jetzt gesagt, wie siehst du das?
Ist das letztendlich so?
Siehst du auch diese Abstraktionsebenen, die Stück für Stück aufeinander aufbauen?
Und wenn wir letztendlich bei
trunkbasierter Entwicklung sind, vielleicht als Folgefrage, ist das dann die Basis?
Oder gibt es noch einen tieferen Kern, den man vielleicht noch erwähnen müsste?
Zunächst mal vielleicht, um alle Zuhörer abzuholen, die jetzt sich ein bisschen wundern,
was eigentlich trunkbasierte Entwicklung ist.
Viele haben den Begriff vielleicht schon gehört, aber nur der Vollständigkeit halber.
Was steckt dahinter?
Dahinter steckt, dass man sich abkehrt von dem jahrelang oder jahrzehntelang verfolgten Ansatz,
dass man Branches hat, Feature-Branches hat.
In der Entwicklung befindliche Sachen,
in der Entwicklung
befindlichen Code erstmal in Quarantäne schickt und dann das zu einem späteren
Zeitpunkt zurück in die Mainline mergt, sodass man da in Ruhe entwickeln kann,
ohne dass man versehentlich die Arbeit seiner Kollegen kaputt macht,
den Bild kaputt macht oder so was.
Erst wenn es fertig ist, dann mergt man es wieder zurück in die Mainline.
Das hat man viele Jahre so gemacht.
Gibt es ja auch bekannte Exponenten, GitHub, Flow und was es alles gibt.
Und man ist aber darauf gekommen, dass das mehr Probleme schafft, als es löst,
weil es halt irgendwie für sehr viel Komplexität sorgt.
Du hast ganz viele
verschiedene Branches und dann musst du die mergen oder nicht mergen.
Und dann gibt es irgendwie ein Mods-Regelwerk und alles sowas.
Dann haben wir gesagt, das ist alles Mist.
Wir machen es uns einfach.
Wir sagen, es gibt nur die Mainline.
Jeder Entwickler, egal wer, bastelt an dem einen Hauptzweig der Entwicklung rum.
Und wie gehe ich jetzt damit um, dass da ja auch halbfertige Sachen drin sind,
die dann naturgemäß nicht gescheit funktionieren?
Die werden dann für Testzwecke oder sogar für Deploymentzwecke totgelegt über
Schalter im Code, also dann kann ich halbfertigen Code, kann ich einfach für
Produktions- oder Testzwecke abschalten und auf diese Weise sorge ich dafür, dass ich
niemals in dieses Problem der Integration komme, dass, wenn man so einen Branch hat,
der zu lange läuft und zu lange nicht integriert wird, irgendwann passen die nicht
mehr zusammen, die dividieren immer weiter und die Schmerzen werden immer größer.
Der Integration.
Also sagt man, wir machen gar keine Integration.
Wir arbeiten sowieso alle immer an derselben Sache.
Integration auf Quellcode-Ebene, richtig?
Genau, weil halt unterschiedliche Personen an unterschiedlichen Stellen arbeiten.
Und alte Stände und neue Stände entstehen, die dann, je länger solche Feature-Branches
gelebt haben, immer weiter divergieren über die Zeit.
Deswegen möglichst kurz.
Nichtsdestotrotz kenne ich immer noch den
Ansatz, Feature-Branches zu machen, die dann aber höchstens einen Tag alt sein dürfen.
Ist das immer noch im Rahmen von Trunk-basierter Entwicklung akzeptabel oder geht das nicht?
Also aus meiner Sicht schon.
Also schau, es ist ja immer die Frage, wie du es machst.
Du kannst ja auch, du kannst ja implizite
Branches haben, indem du dann Feature-Flag hast, dass du einfach niemals einschaltest.
Dann hast du diese Komplexität auch versteckt und du kannst genauso ins Messer laufen.
Das ist, glaube ich, etwas, was man nicht übersehen darf.
Die Komplexität ist die Komplexität.
Du darfst dir Mechanismen überlegen, wie du ihr begegnest.
Seien das Branches, seien das Feature-Switches oder was weiß ich was.
Aber die geht ja nicht weg, die Komplexität, sondern die ist nun mal da.
In der Tat, aus meiner Arbeit mit Embedded Systems sage ich sogar, es gibt immer noch
einen Wert von Feature-Branches.
Insbesondere langlaufenden, weil vielleicht habe ich einfach konkret mehrere
Versionen im Feld über lange Zeiten, die wurden ausgeliefert.
Verschiedene Hardware-Stände oder sowas, für die muss ich dann vielleicht
verschiedene Software-Sätze pflegen und vielleicht macht das einfach viel mehr
Sinn, die in langlebigen, im Sinne von jahrelang lebenden Branches abzubilden,
anstelle von irgendwie mit einem Wust von Feature-Flags.
Insofern, auch wenn viele Leute sagen, Branches sind irgendwie des Teufels.
Ich sage es mal so, wenn man sie vermeiden kann,
glaube ich, das ist eine gute Idee, sie zu vermeiden.
Aber ich bin da weniger strikt als andere Leute.
Ich sage, unter bestimmten Voraussetzungen
kann das das richtige Werkzeug sein, um der Komplexität zu begegnen.
Hat letztendlich ja seine Idee auch gehabt,
hat eine Zeit lang eine recht weite Verbreitung gehabt.
Und ich sehe auch einen Unterschied, ob wir über Versionen, die lange im Feld
unterwegs sind, über die man nachdenken und reden muss, sind wir immer noch bei der
Entwicklung und beim Betrieb.
Das sind ja zwei unterschiedliche Sichten auf das System.
Die Entwicklungen sind letztendlich das,
wo wir hier über trunk-basierte, mainline-basierte Entwicklungen reden, während
der Betrieb ja schon auch mehrere parallel zu betreibende Versionen auf
unterschiedlichen Umgebungen regional oder wo auch immer die Gründe dafür sind, dass
man verschiedene Umgebungen hat, eine nicht etablierte oder nicht geplante
Kommunikation für Updates over DR oder wo auch immer, wo die Schnittstellen an anderen
Systemen liegen, na klar braucht man da mehrere Versionen, die vielleicht live sind,
die man halt weiter pflegen muss, wo man dann aber nicht über eine Weiterentwicklung,
sondern eher eine Maintenance, also eine Pflegephase dann redet.
Klar ist es da sinnvoll, auch in der Versionskontrolle diese Versionen
griffbereit zu haben, um dann halt auch darauf gut testen und sie verwalten zu können.
Aber wir haben uns verzettelt, weil ich
fand deine Frage oder deine Beobachtung ganz spannend, dass da irgendwie Sachen
aufeinander aufbauen, dass ich sage, ich brauche trunk-based Development, damit ich
kontinuierliche Integration erfolgreich oder mit akzeptablem Aufwand betreiben kann.
Das brauche ich, damit ich continuous
Delivery mit akzeptablem Aufwand und akzeptablem Risiko betreiben kann.
Und dann was? Was ist dann?
Ich behaupte, da baut ihr jetzt noch mehr drauf auf.
Das bedeutet ja dann, dass ich mich wiederum in die Lage versetze, kurz
zyklisch zu iterieren, zusammenzuarbeiten, Feedback einzusammeln.
Genau, wobei das steht nicht mehr beim Minimum CD als Minimum Viable
Konzept in dem Dokument.
Letztendlich macht man all das genau, um schnell Kunden Feedback einarbeiten zu
können, um vielleicht auch Dinge zu beachten und zu realisieren, wie
Bugfixes mit einer hohen Testabdeckung, um nicht nochmal neue Fehler oder sowas
mit einzubauen, weil man halt gerade eine sehr schnelle Änderung irgendwo vorgenommen hat.
Und um letztendlich auch kleine Pakete deployen zu können, um zu sehen Ja, jetzt
haben wir eine Änderung, da ist vielleicht ein Fehler aufgetreten.
Wir müssen jetzt aber nicht die ganze Codebasis nach der Ursache durchsuchen,
sondern halt nur das, was seit dem letzten Produktiv Deployment, wo der Fehler noch
nicht drin war, geändert wurde.
Und all diese Vorteile hat man dadurch, dass man Continuous Delivery hat.
Zusätzlich natürlich auch die eingesparte
Arbeitszeit, dass man sich nicht hinsetzen muss und manuell durchtesten muss, dass
man sich nicht hinsetzen muss und vielleicht mehrere hundert oder mehrere tausend Server
aktualisieren muss mit der neuen Software Version, sondern dass man sich dann halt
genau da, wo viel Mühe quasi auftritt, sich die Zeit dann sparen kann und in
exploratives Testen investieren kann, in die Pflege der Plattform, der Deployment
Pipeline Zeit investiert und vielleicht auch eine Verbesserung, eine kontinuierliche
Verbesserung etabliert, für die man vorher möglicherweise keine Zeit hatte.
Das sind dann die Effekte, die man hat mit Continuous Delivery.
Deswegen reden wir drüber.
Aber es gibt
noch was anderes recht Spannendes, nämlich, wenn du jetzt versuchst, diese
Grundsätze einzuführen, dass du sagst, du hast produktionsähnliche Testumgebungen,
dass du sagst, du hast Rollback on Demand, dass du sagst, du machst Trunk Based
Development, lauter solche Sachen, dann ist das ganz häufig ein Prüfstein
für ganz viele andere Aspekte deiner Organisation oder deiner Prozesse.
Kannst du das denn überhaupt?
Oder hast du da, ich weiß auch nicht, ein
Change Advisory Board oder sowas, das dann von dir Dokumentation verlangt?
Oder hast du Deployment Prozesse, die dazu überhaupt nicht in der Lage sind, das abzubilden?
Oder sind deine Produkte so gebaut, dass du gar nicht in der Lage bist, mehr als eine Umgebung zu betreiben?
Und lauter solche Sachen.
Das ist ganz, ganz spannend.
Diese vergleichsweise harmlosen Forderungen, die da drinstehen.
All feature work stops when the pipeline is red.
Das ist immer so mein Lieblingsbeispiel, weil das so unmittelbar ist.
Da gibt es irgendwie nichts daran zu deuteln.
Es kommt meiner Beobachtung nach häufig vor, dass Organisationen dann ziemlich
schnell sagen müssen Ja, eigentlich eine gute Idee schaffen wir aber noch gar nicht.
Und das, finde ich, macht einen der großen
Werte aus von Minimum CD, dass es dir hilft, mit Hilfe von von diesen ziemlich
technisch orientierten Praktiken, dich selbst darauf hin zu überprüfen, ganz
konkret, wie gut du eigentlich schon aufgestellt bist in Bezug auf deine
Architektur, in Bezug auf deine Organisation, in Bezug auf deine Prozesse,
um überhaupt diesen Wunsch, den du wahrscheinlich hegst, Wirklichkeit werden zu lassen.
Das ist einfach ein wahnsinnig instruktives
Werk.
Werkzeug habe ich das Gefühl, wirklich zu einfach mal auszuprobieren.
Wie? Wie weit komme ich denn eigentlich mit
diesen vergleichsweise harmlosen Forderungen, die da stehen?
Kann ich die denn wirklich alle erfüllen?
Das heißt, man könnte es auch für ein Assessment einer Entwicklungs Umgebung
nutzen und halt gucken für jeden Punkt, der hier bei Continuous Delivery, bei
Continuous Integration und bei Trunk Based Development aufgezählt ist.
Haben wir den erfüllt?
Ist der bei uns in unserer Umgebung für unsere Entwickler, für unsere
Betriebsmannschaft, vielleicht unser DevOps Team auch wirklich etabliert?
Und wenn nicht, was müssen wir tun, um ihn zu erreichen?
Letztendlich interessanter Ansatz.
Finde ich gut, auch hier Minimum CD so so einzusetzen.
Ja, das ist das, wonach es schreit für mich, dass man sagt Okay, diese diese
Praktiken als solche, die sind natürlich, sind natürlich auf jeden Fall empfehlenswert.
Aber dass sie auch in ihrer Gesamtschau,
dass man die wirklich als als als Checkliste gerade zu nimmt, um zu sagen, wo
hakt es denn noch in meiner Organisation, wenn ich versuche, das umzusetzen?
Wo finde ich denn da Schwierigkeiten?
Und ganz bestimmt, ihr werdet irgendwo welche finden.
Ich meine, irgendwo gibt es immer Sachen, die besser laufen könnten oder so was.
Und die werden dadurch einfach sichtbar gemacht.
Und das halte ich für wahnsinnig wichtig.
Gerade du hast ja vorhin angesprochen Lean, Falco und industrielle Prozesse.
Und weißt du, es ist halt so, wenn du eine Presse hast, die nicht gut läuft, dann
kannst du sehen, dass sich davor irgendwie Paletten und Paletten von Blechen
stapeln, die nicht durch diese Presse laufen.
Bei Software ist das nicht der Fall.
Du kannst das alles nicht sehen.
Darum musst du dir Hilfsmittel suchen, die es deutlicher machen, wo die
Schwachpunkte des Prozesses sind, weil du dir halt nicht die Zehen anhauen kannst an Bugs.
Ja, direkt nicht.
Aber du kannst natürlich schon schauen, wo du anstelle dessen hinschaust.
Du kannst gucken, wie sich das Kundenfeedback zum Beispiel, wenn du einen
Support hast, in der Support-Bereich entwickelt, steigt da letztendlich die
Rückmeldung von Fehlern aus Kundensicht.
Du kannst genauso auch darauf achten, wenn du zum Beispiel ein Kanban-System hast,
was viele Entwickler haben, ob das jetzt im Tool wie das verbreitete Jira oder eine
andere Bug-Tracking- und Planungssoftware ist, kannst du natürlich schon schauen,
wie sieht das kontinuierliche Flussdiagramm aus, also Cumulated-Flow-Diagramm.
Wie sehen die Entwicklungen über die Zeit aus?
Staut sich hier irgendetwas?
Genau dafür sind ja solche Tools auch für die Entwicklung da.
Und wenn du echt mit physischen Kanban-Boards arbeitest in einem Entwicklungsteam, ob das
jetzt Scrum oder Kanban oder andere Ansätze sind, siehst du ja auch, wo Karten liegen bleiben.
Genau da visualisiert man es ja.
Genau. Aber wie gesagt, ich finde eben, dass solche Dinge wie Minimum-CD das dann auch
wirklich sichtbar machen und dich zwingen und dem Ganzen auch einen Kontext geben.
Das wird dann nicht bloß irgendwie eine intellektuelle Übung, so ja, wir machen
jetzt irgendwie, wir hängen da jetzt ein paar Kärtchen um oder so, sondern wir machen
das einfach, sondern wir wollen hier tatsächlich was erreichen.
Zum Beispiel, so wie es hier steht, Immutable Artifact, no human changes after commit.
Was heißt das auf Deutsch?
Dass du das, was du ins Versionskontrollsystem reingibst und was dann gebaut wird von der
Pipeline, dass du das hinterher nicht nochmal anfassen musst.
Das ist fertig.
Du hast die komplette Beschreibung dessen, was du da bauen willst, in irgendeiner
Weise in deinem Quellcode-Repository drin.
Sei das jetzt Quellcode oder sei das Grafiken oder sei das noch andere
Dinge. Und das ist eine von den Hürden, wo ganz viele Organisationen meiner
Erfahrung nach scheitern, wo die dann sagen, naja, 80% des Weges sind wir schon, aber
jetzt haben wir halt noch 20% harte Nüsse, die uns hindern.
Und wo man dann sich auch, wie soll ich sagen, wo es einem dann häufig im
Alltagsgeschäft passiert, dass man sagt, naja, ist halt irgendwie so.
Und wo dann solche Dinge wie Minimum-CD einem sehr gut dabei helfen können,
das einfach nochmal zu hinterfragen und zu sagen, muss das wirklich so sein?
Okay, es ist jetzt so, verstanden, aber muss es weiterhin so sein?
Oder können wir einen Weg finden, um uns da davon wegzubewegen von diesem Zustand?
Klar, also es ist eine schöne Checkliste, es ist ein schönes Werkzeug, um letztendlich
auch eine Vergleichbarkeit von unterschiedlichen Continuous Delivery
Umgebungen in gleichen Unternehmen, aber auch unternehmensübergreifend zu erreichen.
Also ein Assessment, Hilfsmittel.
Man könnte natürlich wirklich daraus dann auch ein haben wir und Checkbox oder
anderes daraus ableiten, finde ich ein ganz interessanter Ansatz.
Und wäre vielleicht auch eine hilfreiche Ergänzung für Minimum-CD.
Vielleicht machen wir auch da nochmal einen Vorschlag mit den Kollegen.
Ansonsten gefällt mir bei Minimum-CD auch, dass es ein paar Zusatzinfos gibt zu dem
minimal verfügbaren, tragfähigen Continuous Delivery Konzept, dass man halt auch sagen kann,
es gibt so Ergänzungen in Richtung in kleinen Paketen, in Small Badges zu arbeiten, dass man
halt auch noch ein bisschen Ausblick hat, wie man
eine Continuous Delivery Umgebung aufbauen kann, wo man über die Minimum-Anforderungen
auch hinausgehen kann mit vielen Quellen und Referenzen zu den Büchern von Dave Farley
oder Dave Farley mit Jess Humble zu Continuous Delivery, Pipeline Aufbau,
verschiedene andere Bücher, Refactoring Databases, Release It, um solche mal zu nennen,
oder Continuous Integration Zertifizierung von Martin Fowler oder Five Minute DevOps von Brian Finster,
wenn man schon von ihm spricht.
Von ihm reden Blogpost, wie man Produktionsprobleme mit DevOps und Continuous Delivery voranbringen kann.
Finde ich letztendlich eine schöne Ressource zum Thema DevOps, zum Thema auch auf der technischen Ebene zu starten,
sich mit Continuous Delivery auseinanderzusetzen und auch zu schauen, haben wir wirklich das Minimum von Continuous Delivery schon implementiert?
Sind wir an einigen Stellen vielleicht auch darüber hinaus?
Wenn ja, können wir uns vielleicht auch von den anderen Ressourcen, die relevant sind, variieren lassen.
Das Ganze auch noch zu erweitern.
Schöne Geschichte, guter Hinweis von Brian.
Gefällt mir auf jeden Fall als Quelle für Entwicklungsteams, für unternehmensübergreifende Arbeiten, auch im skalierten Umfeld sehr gut.
Ja, genau.
Zumal das ist eben auch toll, da sind dann auch schwierige Handreichungen drin.
Zum Beispiel, wie könnte es denn, was sind so die typischen Problemfelder?
Tests stehen nicht zur Verfügung oder werden nicht gemacht oder ein beliebter Fehler ist, dass man nicht gut genug darin ist,
Storys klein zu machen, Aufgaben klein zu schneiden.
Das ist etwas, was ich auch oft beobachte, dass Teams sich damit schwer tun, weil es halt mehr Sachen reinpacken ist halt immer leicht.
Sachen weglassen ist vergleichsweise viel schmerzhafter.
Und wenn du dann aber eben versuchst, dich an die Dinge von Minimum CD zu halten und das dann tatsächlich in Etat umzusetzen,
dann merkst du halt auch da, oh, jetzt gerate ich in Schwierigkeiten, meine Storys, die kriege ich gar nicht klein genug, die kriege ich gar nicht atomar genug.
Solche Dinge mehr.
Wie gesagt, ich finde, es ist ein wahnsinnig gutes Hilfsmittel, um sich zu zwingen, irgendwie zu den Grundlagen zurückzukehren und zu sagen Ja, was?
Wo müssen wir uns eigentlich verbessern?
Wo tut es denn jetzt eigentlich weh, wenn wir es wirklich mal versuchen?
Insofern ja, ganz, ganz tolles Projekt.
Ich bin irgendwie ganz, ganz begeistert davon.
Und ich finde, man kann sich einfach wahnsinnig viele Lehren daraus mitnehmen.
Und gleichzeitig ist es halt irgendwie auch schön, schön zugänglich und erreichbar.
Das ist jetzt kein ganzes Buch von Zeug, sondern es ist echt nur eine Webseite.
Die kannst du in fünf Minuten durchlesen und dann hast du aber fürs nächste halbe Jahr zu tun, wenn du das alles wirklich umsetzen willst.
Ja, genau. Also ist auch immer die Frage Was bringt einem jeder dieser Punkte, die dort aufgeführt sind?
Ist es wirklich notwendig, jeden Punkt von Minimum Viable City zu realisieren?
Aber es heißt ja nicht Wünsch dir was CD, sondern das heißt Minimum Viable CD.
Also da bin ich auch tatsächlich stur, weil sonst kommt man wieder in das rein, dass man sagt Ja, anderswo geht es.
Aber bei uns geht es irgendwie nicht, sondern da wäre ich dann tatsächlich strikt.
Kann man drüber nachdenken?
Kann man drüber reden, weil jedes Unternehmen ist anders.
Aber ich sehe natürlich auch den den Wert von Minimum Viable CD.
Ich meine, auch das ist eine Seite von Leuten, die viel Erfahrung mit Continuous Delivery haben, haben sich bewusst Gedanken gemacht.
Was ist wirklich Minimum Viable?
Also was ist wirklich tragfähig?
Und ja, vielleicht reicht es aber auch, eine nicht tragfähige Continuous Integration Umgebung erst einmal aufzusetzen, sich nicht zu überfordern, sich nicht.
Oder zumindest an irgendeiner Stelle anzufangen und das Ziel, vielleicht Minimum Viable, also eine tragfähige Continuous Deployment Umgebung aufzubauen, zu erreichen.
Das auf jeden Fall.
Also man muss da ja nicht auf der Stelle alle Maximalforderungen umsetzen, aber man muss dann schon irgendwie den Ehrgeiz haben, alle Punkte von der Liste abzuarbeiten.
Nicht jetzt, aber dereinst.
Das ist schon das Wichtige, weil sonst bringt man sich da.
Bin auch nicht der Meinung, dass es Maximalforderungen sind.
Das heißt ja nicht umsonst Minimum Viable CD, also minimal tragfähiges.
Aber vielleicht hat man halt noch kein tragfähiges Continuous Deployment, Continuous Delivery, sondern man hat halt erst mal einen Startpunkt oder man ist irgendwo mittendrin oder hat vielleicht den Fokus auf etwas anderes gesetzt.
Aber um genau diese Tragfähigkeit zu erreichen, die Viability im Englischen, dafür ist es aus meiner Sicht ein echt gutes Werkzeug.
Und auch hier hätte ich gesagt, die Kollegen sind sicherlich offen für Vorschläge und Veränderungen.
Also wenn man feststellt, dass man auch bei Minimum Viable CD noch etwas hinzufügen muss.
Damit es tragfähig wird oder man etwas wegnehmen kann und es trotzdem tragfähig bleibt, können wir sicherlich genauso darauf hinweisen, dass man mitarbeiten kann.
Gut. Was müssen wir noch beraten, Falco? Was haben wir vergessen?
Ja, also letztendlich gibt es einige Übersetzungen, hätte ich jetzt gesagt.
Also wenn jemand über Deutsch, Spanisch, Französisch, Italienisch, Portugiesisch und Finnisch hinaus noch eine Sprache beitragen will, rufen wir natürlich unsere Hörer dazu auf, mitzuwirken.
Oder bei einer Übersetzung Verbesserungen vorzunehmen, ist natürlich auch immer eine Option.
Das stimmt, auch das ist wahr. Gut.
Falco, dann würde ich sagen, haben wir Minimum CD soweit vorgestellt, wie wir es gerne wollten und hoffentlich einige Leute inspiriert, um diesen Weg noch ein paar Schritte weiter zu gehen.
Insofern vielen Dank für das schöne Gespräch und dass wir hier irgendwie uns mal über dieses Thema austauschen durften.
Und dann würde ich sagen, liebe Hörerinnen, liebe Hörer, bis bald. Lieber Falco auch, bis bald. Macht’s gut.
Ja, macht’s gut. Bis zum nächsten Mal.
Ciao.
Ciao.

Folge 69: Continuous Delivery in nicht-trivialen Produkten

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

In dieser Episode diskutieren Luca Ingianni und Falko Werner die Nuancen der Implementierung von Continuous Delivery unter schwierigen Bedingungen und heben die Bedeutung von Pragmatismus und Anpassung an spezifische Umstände hervor. Sie erkunden, wie Continuous Delivery in verschiedenen Kontexten, von einfachen Softwareanwendungen bis hin zu komplexen, hardware-einbeziehenden Systemen, angewendet werden kann. Das Gespräch berührt auch kulturelle und organisatorische Barrieren, die Bedeutung von Automatisierung im Lieferprozess und die Notwendigkeit, eine robuste Pipeline zu schaffen, die schnelle Iteration und Feedback unterstützt.

Inhalt

  • Einführung in Continuous Delivery in herausfordernden Umgebungen
  • Die Beziehung zwischen Continuous Delivery und DevOps
  • Technische und organisatorische Aspekte von Continuous Delivery
  • Pragmatische Ansätze für Continuous Delivery in verschiedenen Kontexten
  • Umgang mit komplexen Softwareprodukten in Continuous Delivery
  • Überwindung kultureller und organisatorischer Barrieren
  • Die Rolle von Automatisierung und Pipelines in Continuous Delivery
  • Unterschiede zwischen Continuous Integration, Continuous Delivery und Continuous Deployment
  • Fallstudien und praktische Beispiele für Herausforderungen bei Continuous Delivery
  • Continuous Delivery in hardware-einbeziehenden und cyber-physischen Systemen
  • Strategien für den kleinen Anfang und Skalierung in Continuous Delivery
  • Die Bedeutung von Feedback-Schleifen und schneller Iteration in Continuous Delivery

Shownotes

MinimumCD
Mehr lernen? Hier findet Ihr unser Trainingsprogramm

Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)

DevOps. Auf die Ohren und ins Hirn.
Ein Podcast rund um DevOps.
Von Dierk Söllner, Falko Werner und Luca Ingianni.
Hallo und herzlich willkommen zu einer neuen Folge des Podcasts
DevOps auf die Ohren und ins Hirn.
Gestaltet und produziert von Luca Ingianni, Dierk Söllner und Falko Werner.
Wir sind DevOps-Trainer und Coaches mit langjähriger Erfahrung.
DevOps umfasst für uns kulturelle, organisatorische und technische Aspekte.
Dirk ist nach wie vor im Urlaub.
Insofern haben Falko und ich uns gedacht,
wir nehmen heute eine Folge auf zum Thema
Continuous Delivery unter erschwerten Bedingungen.
Mit anderen Worten zum Gast haben wir uns selber.
Hallo Falko.
Hallo Luca, schön von dir zu hören.
Ich dachte mir, statt uns selbst vorzustellen,
vielleicht ist es ganz gut und an der Zeit,
dass wir einfach die Zeit,
die wir hier im Podcast nutzen, um ein bisschen über Vempio zu reden.
Wir sind ja gerade dabei, Vempio als Gesellschaft zu gründen,
zu zweit mit enger Zusammenarbeit,
weiter auch mit Dirk Ideen gemeinsam umzusetzen und daran zu arbeiten.
Fällt dir etwas ein, was wir vielleicht an der Stelle noch erwähnen sollten?
Vieles, vieles.
Aber ich glaube, das Wichtige ist erstens,
es ändert sich erstens mal gar nichts und wenn doch,
dann nur zum Guten oder zum Besseren.
Genau, also Falko und ich sind dabei,
Vempio zu gründen und wir arbeiten weiterhin sehr,
sehr eng und eifrig mit Dirk und auch mit Peter Lehmann zusammen.
Und wir haben auch schon einige neue Trainings auf der Pfanne,
die wir dieses Jahr neu entwickeln wollen.
Und abgesehen davon sind wir auch dabei, momentan sehr fleißig offene Trainings
in Zusammenarbeit mit der DASA,
der DevOps Agile Skills Association, ins Leben zu rufen.
Die könnt ihr entweder bei uns auf der Webseite finden
oder im
Trainingskalender der DASA.
Das verlinken wir euch alles in den Shownotes für den Fall,
dass das jemanden gerade interessieren würde.
Cool.
Normalerweise fragen wir unsere Gäste traditionell nach ihrer persönlichen
Definition von DevOps.
Das haben wir hier für uns in unseren Folgen auch schon öfter gemacht.
Also ich denke, wer das möchte, kann auch in den früheren Folgen einfach mal schauen,
was wir zu DevOps gesagt haben.
Aber da das Thema ja heute Continuous Delivery ist,
ist es natürlich nicht verkehrt, uns mit diesem Thema auseinanderzusetzen.
Deswegen an dich die Frage, Luca, was ist Continuous Delivery aus deiner Sicht?
Genau.
Also was ist meine Definition von Continuous Delivery?
Für mich ist das die sehr häufige oder gern auch sehr, sehr häufige,
hoch bis voll automatisierte Bereitstellung von Produktinkrementen an das Business,
wie man so schön und so nebulös sagt.
Sprich nicht an den Kunden, sondern erst mal nur an jene Teile der Organisation,
die sich an den Kunden richten.
Und neue Produktinkrementen werden also erzeugt und stehen dann zur Verfügung,
um die, wenn man möchte, auszuprobieren, um die, wenn man möchte,
vielleicht einem Kunden herzuzeigen oder auch, wenn man das möchte,
die ganz konkret in die Produktion auszuliefern und tatsächlich wertschöpfend zu nutzen.
Diese Entscheidung obliegt völlig diesem nebulösen Business.
Das ist also keine technische Entscheidung mehr,
wann man eine neue Produktversion tatsächlich produktiv setzt,
sondern das ist jetzt wirklich einfach eine vollkommen wertgetriebene Entscheidung.
Mit anderen Worten,
Continuous Delivery ist aus meiner Sicht zwar ganz grundsätzlich eine technische Praktik.
Wir reden von, ich weiß nicht, Automation und Pipelines und all so ein Zeug.
Aber die eigentliche Wirkung entfaltet sich auf anderer Ebene.
Die entfaltet sich auf einer Prozessebene.
Wann tritt eigentlich wer mit wem und warum in den Dialog?
Am besten natürlich mit dem Kunden.
Falco, wie siehst du das?
Ja, ich stimme dir im großen Teil zu.
Also für mich ist es auch als Praktik zu verstehen.
Mir geht es dabei darum, sicherzustellen,
dass die Änderungen an der Funktionalität oder Konfiguration von Systemen
möglichst wenig manuellen Aufwand beinhalten.
Das heißt, dass man da mit Tool-Unterstützung, mit Pipelines arbeitet,
die viele aufeinanderfolgende Aufgaben, die man sonst manuell ausführen würde,
automatisiert durchführen.
Das kann von den Schritten aus dem Continuous Integration sein.
Letztendlich alles, was nach dem Code Review, nach dem Vier-Augen-Prinzip aus
der Entwicklung passiert, bis hin zu mindestens einer Pre-Life- oder QS-Umgebung,
die dann letztendlich die Übergabe an die Fachbereiche des Businesses,
wie du vorhin sagtest, gehen.
Theoretisch können sie auch bis in die Produktivumgebung gehen.
Spricht aus meiner Sicht auch nicht viel dagegen.
Wenn man dann mit Techniken arbeitet wie Feature-Flagging und anderem,
dann sind wir aber schon stark an der Grenze von Continuous Delivery,
zu Continuous Deployment.
Das ist quasi unser nächster Themenpunkt.
Lass uns doch da am besten gleich weitergehen.
Was gibt es denn in dem Umfeld von Continuous Delivery zu beachten?
Was gibt es da noch so?
Ich kann Continuous Integration, Continuous Delivery, Continuous Deployment,
wollen wir das einfach nochmal abgrenzen, damit allen klar ist, worum es uns hier geht?
Ja, das halte ich für eine gute Idee.
Insbesondere, weil die Definitionen ja doch so ein bisschen schwammig sind.
Und es mag auch den einen oder anderen,
oder anderen geben übrigens, der unsere Definitionen nicht teilt.
Das ist ja auch völlig okay, sondern wir erklären einfach mal,
was wir darunter verstehen.
Dann weiß jeder, woran er ist.
Und darf uns dann gerne irgendwie für doof halten
und seine eigene Definition weiter nutzen.
Genau, und darf sich auch gerne bei uns melden.
Und dann können wir auch gerne auch im Podcast darüber mal mit der oder demjenigen reden.
Auch das ist eine ausgezeichnete Idee.
Genau.
Gut, also was ist denn dann Continuous Integration, Falco?
Gut.
Also für mich ist Continuous Integration der erste Schritt einer Continuous Delivery Pipeline
mit dem Fokus darauf, alles zu tun, was nach dem Pair Programming passiert.
Das heißt, dem Merge von neuen Code-Bestandteilen, Konfigurationsbestandteilen,
dass man einen Bildprozess abbildet, dass man Testprozesse soweit abbildet,
die mindestens Unit-Tests abdecken auf einer Entwicklungs- oder Testumgebung,
die sehr entwicklernah ist, die letztendlich auch eine statische Code-Analyse beinhaltet,
und erste dynamische Tests.
Fehlt da für dich noch irgendwas?
Sollten wir da noch was ergänzen?
Oder passt die Beschreibung von Continuous Integration für dich?
Die Beschreibung passt für mich.
Es gibt bloß eine Sache, auf die es mir immer wichtig hinzuweisen,
nämlich, wenn du Continuous Integration jetzt wirklich beim Wort nimmst,
dann lässt du da jetzt diese Pipeline laufen und die macht da irgendwie Dinge
und produziert Artefakte und unterzieht die Tests.
Und was passiert hinterher?
Mit den Artefakten, du schmeißt sie weg.
Weil dir geht es ja gar nicht um die Artefakte,
sondern es geht dir um das Feedback, das du draus ziehst.
Waren alle Tests grün?
War die statische Code-Analyse erfolgreich?
Und so weiter und so weiter.
Das Artefakt selber, wenn man es jetzt wirklich beim Wort nimmt,
verpufft einfach hinterher wieder.
Das ist dann einfach, das ist eigentlich nicht wesentlich.
Das ist nicht wesentlich, aber letztendlich brauchst du es ja doch,
um es dann irgendwann ausliefern zu können, oder nicht?
Ja, aber das machst du ja bei Continuous Integration.
Nein, bei Continuous Integration noch gar nicht.
Sondern dann sind wir eben genau beim nächsten Schritt.
Dann sind wir bei Continuous Delivery.
Weil dann sagen die Leute, ja, das ist ja irgendwie dumm.
Jetzt habe ich mir doch extra so ein schönes neues Inkrement gebaut
und habe das getestet und habe festgestellt, das geht.
Dann wäre das doch irgendwie Verschwendung, das jetzt wegzuschmeißen.
Und dann war die eine andere Antwort zu sagen, ja, dann heb es doch auf.
Und was mache ich dann? Und wie mache ich das am besten, das Aufheben?
Das ist eine gute Frage.
Also das kann man ganz verschieden handhaben.
Das hängt ja auch immer damit zusammen, was ist denn eigentlich dein Artefakt?
Ist das jetzt irgendwie nur ein Softwarepaket oder ist das ein Atomkraftwerk?
Oder wovon reden wir denn hier?
Aber ich sage jetzt mal, der einfachste Fall ist,
dass dann einfach hinten aus deiner Pipeline, aus deinem Jenkins oder was auch immer,
hinten ein Programmpaket rausfällt, ein Binary rausfällt
und das plumpst dann einfach mal in irgendein Netzwerkverzeichnis rein oder so.
Und das war es dann vielleicht schon.
Das ist jetzt, würde ich mal sagen, die einfachste Ausbaustufe einer solchen Delivery.
Du legst dieses Artefakt einfach an einen vereinbarten Ort ab
und von dort kann es in beliebiger Weise weiterverwendet werden.
Und man kann sich dann natürlich beliebig verkünsteln
und es gibt ja Artifactory und alle möglichen anderen Werkzeuge,
die ganz spezifisch zur Artefaktverwaltung entwickelt wurden.
Die kann man natürlich auch einsetzen.
Gut. Wir sind jetzt gerade zwischen Continuous Integration und Delivery hin und her gewechselt.
Was ist denn der Kernpunkt von Continuous Delivery,
über das wir hier eigentlich vorrangig reden wollten?
Genau. Da ist dann eben, wie gesagt, der Witz dabei.
Ich habe jetzt mit Hilfe meiner Pipeline nachgewiesen,
dass dieses neue Inkrement irgendwie erstmal ganz grundsätzlich Hand und Fuß hat.
Die Tests sind grün, es gab eine statische Code-Analyse
und was weiß ich, was für Schritte da halt noch rein gehören aus eurer Sicht.
Und das habe ich jetzt abgelegt zur weiteren Verwendung.
Die weitere Verwendung wird bestimmt sein, dass man es dann staged auf einem Testsystem,
auf einem Präproduktionssystem, was auch immer einem da einfällt.
Ich bin auch da wieder so ein bisschen vage, weil es hängt einfach,
ganz stark davon ab, was passt denn zu euch, zu eurem Produkt, zu euren Kunden.
Was macht denn da Sinn?
Aber genau, man kann es dann aufwendiger in Tests unterziehen beispielsweise.
Man kann aber auch dann sagen, weißt du was,
ich will das jetzt wirklich in die Produktion deployen.
Und dann, glaube ich, sind wir eigentlich, ich sage mal, beim weitesten Schritt,
weil man kann ja auch die Vereinbarung treffen, weißt du was,
wenn immer was Neues delivered ist,
und es ist grün, alle Tests sind erfolgreich gelaufen und so weiter,
dann treffen wir die Vereinbarung, dass wir es auf der Stelle in die Produktion deployen.
Und dann sind wir bei Continuous Deployment.
Das ist also, ich sage es mal im Extremfall, der Entwickler entwickelt irgendwas,
checkt den neuen Code-Industry-Repository ein und dann ohne anhalten, ohne links und rechts schauen,
rauscht das durch die Pipeline durch, bis es auf den Produktionssystemen aufschlägt
und für den Kunden erreichbar ist.
Okay, und ist das nicht gefährlich, wenn dann einfach alles,
was da ein Entwickler tut, in der Produktionsumgebung landet?
Wenn der da einen Fehler macht, dann landet der da auch.
Ja, da darf er keine Fehler machen, ne?
Ne, aber ganz im Ernst, natürlich werden Fehler passieren,
aber zum einen ist das eine Frage des Vertrauens in eine Pipeline.
Sind deine Tests solide genug?
Ich meine, Hand aufs Herz, was passiert denn bei Continuous Delivery,
wo wir es erstmal irgendwie in ein Verzeichnis kippen,
was machst du denn zwischen, liegt in einem Verzeichnis und du deployst es wirklich?
Wirst du es dann nochmal akribisch auf Herz und Nieren prüfen oder sagst du,
naja, wird schon passen und knallst es dann halt manuell auf die Produktionsumgebung?
Das ist also das eine.
Und das andere ist, genauso schnell, wie du halt defekte Inkremente deployen kannst,
so schnell kannst du natürlich auch die Korrekturen deployen.
So schnell kannst du dann irgendwie einen Bugfix hinterher schieben
und du kannst dich sehr, sehr darauf verlassen,
dass dieses Bugfix-Deployment erfolgreich sein wird,
weil du deployst halt jeden Tag.
Weiß Gott, wie oft.
Diese Pipeline, die hört ja quasi gar nie auf zu arbeiten.
Und insofern ist es gar nicht so gefährlich,
wie es vielleicht auf den ersten Blick klingt.
Ich meine, das ist eine Frage, die ich häufig höre in meinen Trainings,
du wahrscheinlich auch, Falco.
Wer traut sich in das? Das ist ja mega gefährlich.
Eigentlich nicht.
Genau.
Und man kann natürlich da auch noch zwei, drei Dinge mit betrachten,
wo wir auch wieder in den Grenzbereich zwischen Continuous Delivery und Deployment,
wenn man dann mit Feature-Switches zum Beispiel arbeitet
oder über Berechtigungen oder andere Verfahren-Nutzern
diese neue Funktionalität, die vielleicht da gerade neu entwickelt worden ist,
noch gar nicht zur Verfügung stellt,
sondern halt sie erstmal nur dark auf ein Produktivsystem deployed
oder mit einer Alpha-Beta-Tester-Gruppe da arbeitet,
dann ist sie ja trotzdem produktiv,
aber die Gruppe kann darauf zugreifen,
aber noch nicht jeder Nutzer.
Deswegen wäre es auch nicht schlimm,
wenn da ein Bug oder ähnliches,
noch nicht gefunden worden ist aus den ganzen Tests,
die vorher automatisiert durchgelaufen sind.
Und natürlich ein weiterer positiver Effekt ist,
man kann diese Technologien auch nutzen,
um zum Beispiel unterschiedliche Benutzerverhalten dann gegeneinander abzuwägen
und ähnliches AB-Testing wäre dann wieder ein Vorteil.
Für mich ist ganz wichtig, Continuous Deployment muss nicht Release beinhalten.
Das ist eines der Learnings, die man auch auf SAFe immer wieder mitnimmt,
diese Trennung zwischen Deployment und Release,
dass man zwar produktiv deployt,
haben kann,
aber es noch nicht zwingend dem Endnutzer damit zur Verfügung stellt.
Zum Beispiel, wie gesagt, über Berechtigungssysteme,
über Feature Switches oder andere Mechanismen,
das Ganze dann zu kontrollieren.
Da sind dann Continuous Delivery und Continuous Deployment recht nah beieinander.
Klar ist eine neue Funktionalität dann Continuierlich Deployed.
Und das finde ich auch ganz wichtig darauf zu achten,
dieses Continuierlich.
Continuierlich heißt nicht unbedingt einmal alle Sekunde,
aber letztendlich mit,
im besten Fall jeder Code-Änderung,
wird halt ein neuer Build-Prozess angestoßen.
Und das kann dann halt, wie du auch sagtest,
mehrfach täglich, mehrfach stündlich, jede Minute passieren.
Je nachdem, wie das Gesamtsystem aufgebaut ist,
wie unabhängig vielleicht einzelne Komponenten voneinander sind,
können auch Teilkomponenten, Microservices,
sind da immer so die Dinge, über die man dann an der Stelle redet,
einzeln unabhängig voneinander deployed werden.
Und so kontinuierlich weiterentwickelt werden.
Genau. Und an der Stelle, wie gesagt,
das ist auch nochmal wichtig, glaube ich,
das hervorzuheben, was du ja auch schon gesagt hast.
Bloß weil ich jetzt mal angenommen jede Minute deploye,
heißt ja auch wirklich nicht,
dass ich jede Minute neue Funktionalität dem Anwender zur Verfügung stelle,
sondern es kann ja durchaus sein,
dass die noch hinter Feature Switches oder dergleichen mehr verborgen ist,
solange bis ich aufgrund anderer Erwägungen mich dazu entschließe zu sagen,
so, das wird jetzt scharf geschaltet,
das wird jetzt sichtbar.
Zum Beispiel einfach nur,
um meine armen Nutzer nicht völlig irre zu machen,
weil alle Nase lang schaut mein Produkt jetzt anders aus oder sowas.
Das macht ja durchaus Sinn,
dann da erstmal noch in den Dialog zu gehen,
ich weiß auch nicht, eine Schulung zu machen,
wenigstens einen Hinweis zu geben, was auch immer.
Vielleicht sind es auch Marketingmaßnahmen,
dass man halt Nutzer auch darüber in Kenntnis setzt,
es gibt jetzt eine neue Version, es ist sinnvoll und hilfreich,
du kriegst ein neues Feature, kostet dich gar nichts extra,
aber bezahl dein Abo trotzdem weiter und so weiter.
Genau.
Das, glaube ich, einigermaßen erschöpfend beleuchtet.
Jetzt stellt sich für mich aber immer noch die Frage,
wie grenzt sich das denn von anderen Dingen ab?
Was ist denn jetzt eigentlich der Zusammenhang
oder der Unterschied zwischen CI und,
also Continuous Integration, Continuous Delivery, Continuous Deployment
und einer Pipeline?
Ist das jetzt dasselbe? Ist das was anderes?
Und wie ist das mit DevOps?
Ist Continuous Delivery gleichberechtigt mit DevOps oder mit Agilität
oder, erklär mir das mal, Falco.
Ist ja schön, dass ich das jetzt erklären darf.
Na ja, fangen wir mal von vorne an.
Wie in unseren Daten,
wie in unseren Definitionen vorhin gesagt,
also eine Pipeline, eine Sammlung von Tools,
die aufeinander aufbauen, bestimmte Prozessschritte
bei der Abarbeitung der Veränderung des Systems
von Off-Code- und Konfigurationsebene
über Build, Test, Deployment und so weiter,
ist letztendlich die Pipeline, die Sammlung der Tools,
die eingesetzt werden.
Continuous Delivery ist eine Praktik,
die sich gut mit verschiedenen Arbeitsweisen verträgt.
Arbeitsweisen, die zum Beispiel agil sind,
das heißt, kontinuierlich mit neuen Anforderungen umgehen,
Produkte kontinuierlich weiterentwickeln,
zum Beispiel Scrum oder Kanban getrieben,
regelmäßig Veränderungen am Produkt generieren.
Und wenn man diese Veränderungen hat
und regelmäßig am Produkt etwas tut,
muss man diese Schritte,
die in der Pipeline automatisiert sind,
regelmäßig wiederholen.
Und bevor das ein Mensch tut,
der dabei vielleicht Fehler einbaut,
ist es sinnvoll, das zu automatisieren.
Da reden wir dann wieder von der Pipeline,
kommen wir wieder zurück zu dem gerade beschriebenen
Praktik der Pflege einer Continuous Delivery Pipeline,
die, wie gesagt, in agilen Arbeitsumgebungen
ganz hilfreich sein kann,
weil eben regelmäßig Veränderungen am System passieren.
Und das kann auch für sowohl die Entwicklung
als auch den IT-Betrieb hilfreich sein,
wenn man letztendlich darüber nachdenkt.
Man hat verschiedene Infrastrukturen,
die genauso bereitgestellt werden
wie eine neue Funktion in einer Anwendung.
Dann könnte man das sowohl in der Entwicklung
als auch im Betrieb umsetzen.
Und so spielt die Praktik von Continuous Delivery Deployment
in die Hände der Teams, die das nutzen wollen,
wenn sie zum Beispiel in einer agilen Arbeitsweise tätig sind.
Nichtsdestotrotz ist es auch in anderen Arbeitsweisen
sinnvoll und hilfreich, darüber nachzudenken,
wie viel Automatisierung in der Softwarebereitstellung,
in der Hardware-Systembereitstellung denn da ist.
Und so bildet sich letztendlich
auch die Toolkette, die Pipeline,
die man in verschiedenen von Cloud-Anbietern
bereitgestellten Systemen zum Beispiel auch wiederfindet.
Wir haben halt dann eine Standard-Pipeline,
die sie definieren, die man dann letztendlich gut nutzen kann.
Viele Tools, die aufeinander abgestimmt sind,
sodass man sie nicht selbst aufbauen muss,
was natürlich wieder in Cloud-Umgebungen der Vorteil ist.
Man kommt relativ schnell in die kundenfokussierte Arbeitsweise.
Das wäre noch so eine Ergänzung,
die aus meiner Sicht ganz sinnvoll ist.
Was sagst du?
Habe ich irgendwas vergessen?
Würdest du das gerne noch ergänzen?
Nee, ich glaube, das passt ganz ausgezeichnet.
Das Einzige, was vielleicht man noch so
als historische Perspektive ergänzen sollte,
ist Continuous Integration.
Was ja immer so ein bisschen,
ich sage jetzt mal, im agilen Umfeld erwähnt wird,
ist eigentlich älter zumindest als das Agile Manifest.
Das ist eigentlich eine Praktik,
die das erste Mal zumindest beschrieben wurde,
unter diesem Namen von Kent Beck
im Rahmen von Extreme Programming Mitte der 90er Jahre.
Unsere Episode heißt ja
Continuous Delivery in erschwerten Bedingungen.
Und was sind denn letztendlich erschwerte Bedingungen?
Oder vielleicht erster Schritt,
was sind denn die einfachen Bedingungen,
wo das gut funktioniert,
wo es vielleicht gut verbreitet genutzt werden kann?
Einfache Bedingungen, würde ich mal sagen,
sind halt genau die, wo die Dinge übersichtlich sind.
Ich habe ein überschaubares Produkt mit überschaubaren Risiken.
Ich sage jetzt mal,
eine einfache SaaS-Applikation,
die Server sind ganz klar unter meiner Kontrolle,
die laufen auch nicht davon oder sowas.
Die Risiken sind überschaubar.
Sollte diese Applikation doch irgendwie mal die Grätsche machen,
dann funktioniert sie halt nicht.
Und das ist zwar ärgerlich für die Kunden,
aber sprichwörtlich stirbt jetzt noch keiner davon.
Aber es gibt ja auch andere Systeme.
Genau, das wären dann die mit den erschwerten Bedingungen.
Genau.
Und eben auch, um das auch noch dazu zu sagen,
auch insbesondere kleine Teams,
wenige Mitarbeiter.
Ein Produkt von überschaubarem Scope.
Das sind die einfachen Bedingungen.
Da schreibt sich so eine Pipeline ja irgendwie schier von alleine.
Dann wird es halt spannend.
Komplexe Produkte, sprich solche,
die einfach sehr, sehr viele Einzelteile haben,
die vielleicht auch eben nicht trivialerweise miteinander zusammenhängen.
Das kann jetzt, ich sage jetzt mal,
das kann ein Atomkraftwerk sein,
aber das kann auch einfach eine gewichtige Software-Applikation sein.
Microsoft World von mir aus.
Stelle ich mir vor,
ist bestimmt schwierig zu managen.
Die ganze Pipeline und die ganzen Bildumgebungen und die Tests
und so weiter und so weiter.
Oder natürlich halt quasi die Umkehrung von all dem,
was wir gesagt haben.
Viele Mitarbeiter in vielen Teams,
womöglich grafisch verteilt.
Produkte, die nicht nur blanke Software
oder gar blanke Software as a Service sind.
Sprich Embedded Systems oder Versicherungsprodukte
oder Trainings, wie wir sie machen, Falco.
Oder so was,
die vielleicht nicht so leicht zugänglich sind für solche Techniken.
Oder Produkte, die mit besonderen Risiken behaftet sind.
Sicherheitskritische Produkte.
Was ein Automobilsteuergerät oder so was,
ein ABS-Steuergerät ist halt dumm, wenn das nicht bremst.
Da hast du dann meistens einen schlechten Tag.
Aber es muss ja gar nicht so schlimm sein,
sondern es kann auch in Anführungszeichen nur darum gehen,
Finanzprodukte beispielsweise,
wenn dann plötzlich dein Kontostand auf Null ist,
fälschlicherweise.
Das ist dann auch nicht schön.
Oder auch schlicht und ergreifend solche,
wo die Plattform nicht leicht zugänglich ist.
Ich sage jetzt mal ein Satellit.
Die Software in einem Satelliten oder so was.
Wenn jetzt mein Deployment fehlschlägt,
kann es ja sein,
dass der ganze Satellit nicht mehr erreichbar ist.
Ja, und dann schickst du den Mechaniker hoch.
Oder was ist dann die Alternative?
Das, glaube ich, ist das,
was wir unter erschwerten Bedingungen verstehen.
Da möchte ich dir noch was einfalken.
Ach, mit Sicherheit gibt es noch Dinge,
wenn organisatorische Grenzen zwischen Unternehmen dazukommen,
wenn man letztendlich Sprach- und Kulturgrenzen hat,
die in ein Produkt mit reinfallen.
Die Trainings mit verschiedenen Sprachen
ist natürlich auch blöd oder anderes.
Also mit Sicherheit kann man erschwerte Bedingungen generieren.
Ich denke, die Beispiele, die du gebracht hast,
sind auf jeden Fall gute Beispiele.
Und die sollten wir uns auch noch mal ein bisschen näher anschauen.
Wenn man jetzt in einem Umfeld Continuous Delivery betreiben will
mit erschwerten Bedingungen, wo fängt man an?
Was ist das Wichtige?
Macht man erst mal, soweit man kommt?
Ist es ein kontinuierlicher Entwicklungsprozess,
kontinuierlicher Verbesserungsprozess?
Oder hängt es auch davon ab,
welche erschwerte Umgebung hat man genau?
Und können wir auch Hinweise für diese Einzelheiten haben?
Kannst du uns ein paar Beispiele geben?
Macht es einen Unterschied, ob man ein komplexes Produkt hat
oder viele Mitarbeiter?
Oder einfach, weil du viele Mitarbeiter hast,
auch ein komplexes Produkt?
Und das beides fällt zusammen
und du hast die gleichen Lösungsvorschläge
für Continuous Delivery in solch einer Umgebung?
Ja, genau.
Also jetzt haben wir, glaube ich, ganz, ganz viele verschiedene Varianten angerissen.
Und ich glaube, jetzt läuft es darauf raus,
dass wir dann einfach nur sagen können,
na ja, kommt drauf an.
Wo sind denn deine Hürden?
Wo sind deine Schwierigkeiten?
Man sollte ja auch nicht verschweigen,
es gibt ja auch Hürden, die nicht rein,
ich sage jetzt mal, objektiver Natur sind,
irgendwie technischer Natur oder organisatorischer Natur,
sondern es gibt ja auch kulturelle Hindernisse.
Ist die Organisation überhaupt willens,
sich dem auszusetzen,
dass man so schnell iteriert?
Oder hat man da aus guten oder schlechten Gründen Angst davor?
Beispielsweise.
Gut, kommt drauf an.
Du hast vorhin so schöne Beispiele genannt
für Hürden im Bereich Continuous Delivery.
Gehen wir doch einfach mal durch.
Wenn man jetzt ein komplexes Produkt hat,
was sind da Vorschläge?
Was macht ein komplexes Produkt aus?
Also sehr viele Komponenten, Softwarekomponenten,
die integriert werden müssen,
sehr viele Schnittstellen vielleicht zwischen den Komponenten,
vielleicht auch unterschiedliche Programmiersprachen,
teilweise für die einzelnen Komponenten,
vielleicht auch unterschiedliche Middleware
oder unterschiedliche, äh,
Serverumgebung, in dem diese Applikation läuft.
Das wären jetzt so Gedanken, die ich hätte.
Wie geht man in solchem Umfeld
dann entsprechend mit Continuous Delivery um?
Genau, also jetzt mal ausgehend von dem Berühmten,
kommt drauf an, dass ihr jetzt, glaube ich,
noch öfter hören werdet.
Ich glaube, da liegt ein großer Wert einfach im Pragmatismus.
Zu sagen, kann ich zum Beispiel mein Produkt irgendwie aufbrechen?
Gibt es irgendwelche Nahtstellen, wo ich sagen kann,
da mache ich nicht eine riesen Pipeline,
die wahnsinnig verzwickt ist,
sondern kann ich zum Beispiel mehrere kleine Pipelines haben,
die Teilbereiche dieses Produkts überdecken
und die mir schon mal, na,
lass uns mal einen Schritt zurückgehen und zu sagen,
was ist denn der Zweck davon?
Der Zweck davon ist doch, leichter an Feedback zu kommen,
Risiken rauszunehmen, technische Risiken wie auch Produktrisiken.
Und wenn man es aus dieser Warte betrachtet,
dann, glaube ich, fällt es einem leicht, pragmatischer zu sein
und zu sagen, pass mal auf,
ich muss hier gar nicht alles auf einmal schaffen,
sondern hier habe ich ein paar Teile,
die kann ich in Isolation testen.
Oder die kann ich vereinfachen.
Gerade wenn es um das Problem geht,
dass komplexe Produkte häufig haben,
dass Prototypen sehr teuer werden.
Gerade wenn es nicht mehr reine Software ist,
sondern wenn du eine Brücke baust oder so.
Also Prototypen sind halt irgendwie ganz schön teuer.
Gut, das ist gut.
Gut, das ist aber, glaube ich, einer der nächsten Punkte,
die wir besprechen wollten.
Produkte, die über reine Software hinausgehen.
Ich sehe jetzt komplexe Produkte als schon softwarefokussiert.
Das heißt, letztendlich mit sehr vielen Komponenten,
mit sehr vielen Schnittstellen zwischen den Produkten.
Da hätte ich jetzt gesagt, es ist sicherlich sinnvoll,
so etwas einzubauen wie Contract First mit Schnittstellentests
und Ähnlichem zwischen den einzelnen Komponenten zu arbeiten.
Und diese dann auch in den Pipelines mit zu verankern.
Dass man halt sagt, okay, du kannst halt eine neue Version von einem,
keine Ahnung, Service X oder einer Komponente Y
nicht in die Integrationsumgebung deployen,
wenn sich der Vertrag verändert hat
und die ganzen Konsumenten darüber noch nicht informiert sind
und noch nicht Bescheid wissen.
Solche Dinge würde ich an der Stelle ansetzen,
wo man in Richtung komplexe Softwareprodukte geht.
Wir hatten als Stichpunkt auch den Punkt lange Zyklen,
dass man sich halt auch die Zeit nimmt, die man braucht
und vielleicht schaut, wie weit man mit Automatisierung kommt
und an den Stellen halt, an denen Automatisierung geht,
sie zuerst umsetzt und an denen, wo es halt schwieriger ist,
sich dann später die Zeit nimmt.
Also auch so einen kontinuierlichen Verbesserungsprozess darauf ansetzt,
Continuous Improvement über einen längeren Zeitraum,
dann diese komplexe Pipeline, die man dann halt für ein komplexes Produkt braucht,
dann entstehen zu lassen.
Und dann auch aus dem Feedback entsprechend zu lernen,
wäre jetzt für mich der Punkt.
Wie sieht es bei vielen Mitarbeitern aus?
Was ist da der Ansatz?
Da ist, glaube ich, das Wesentliche, dass man…
Das ist ja, sagen wir mal, ein Nebenaspekt von komplexen Produkten.
Wenn ich viele Leute habe, die Hand in Hand miteinander arbeiten müssen,
dann hat das in sich eine gewaltige Komplexität,
sowohl wahrscheinlich des Produkts,
als auch einfach die Interaktionen zwischen den Leuten.
Die müssen miteinander reden können,
die müssen sich austauschen können,
Fehler müssen gesucht werden können.
Da macht es also einfach sehr viel Sinn,
besonders viel Augenmerk zu legen auf möglichst reibungsarme Kommunikation.
Das bedeutet auch solche Dinge wie zum Beispiel
besonders starke Visualisierung des Zustands in der Pipeline,
dass einfach möglichst viel Klarheit darüber herrscht,
was passiert denn eigentlich gerade in meinem Produkt
und übrigens auch in meiner Pipeline.
Ist meine Pipeline überhaupt ganz grundlegend gesund?
Was passiert denn in der…
Unter welcher Last steht die und so fort?
Und dass man die Pipeline da so ein bisschen auch vielleicht als…
oder Continuous Delivery da als Mittel zum Zweck nutzt und sagt,
wir definieren Standards, indem wir sagen,
das, was sich mit den technischen Mitteln unserer Pipeline umsetzen lässt,
das gilt jetzt erstmal als genehmigt,
dass man da also einfach ein bisschen für Klarheit sorgt,
ein bisschen Kommunikation vielleicht vorwegnimmt oder unnötig macht.
Mhm.
Also ich sehe auch hilfreich, einheitliche Sprachen zu definieren.
Wenn man jetzt sieht, wie weit zum Beispiel
so ein Framework wie SAFe in der Wirtschaft angewendet wird,
ist es natürlich auch ein Vorteil,
dass es eine gewisse Definition von
wie nennen wir Teams, wie nennen wir Teams von Teams,
wie nennen wir letztendlich Produktkomponenten und ähnliches,
welche Rollen gibt es, dass man in der Richtung halt die Vorteile nutzt und sagt,
okay, wir haben kommunikationsgleiche Sprache,
gleiche Frameworks, gleiche Arbeitsweisen,
um so ein bisschen darüber hinwegzukommen,
dass jeder in seiner eigenen Welt lebt und Dinge unterschiedlich versteht.
Das ist aus meiner Sicht wichtig.
Und natürlich ist dann, ich habe, als du das gerade beschrieben hast,
Meryl Conway so ein bisschen um die Ecke winken hören,
technische Systeme, die komplex sind.
Brauchen natürlich auch die entsprechende Teamstrukturen und anderes.
Kann man natürlich auch mit an der Stelle betrachten und mit einbeziehen.
Vielleicht auch Team-Topologies mit einsetzen und mal zu visualisieren,
inwiefern passt denn die Komplexität, die im Produkt steckt,
auch mit den Team- und Mitarbeiter- und Kommunikationsprozessen überein
und wo kann man da optimieren, wäre letztendlich so ein Ansatz.
Also Frameworks notwendig,
Frameworks nutzen, Visualisierung nutzen
und das Ganze dann in die Pipeline bringen
und sie halt über die Zeit weiterentwickeln.
Magst du noch was ergänzen?
Ja, nämlich etwas wird an der Stelle immer deutlicher und wichtiger,
je mehr so eine Pipeline, so ein CD-System an Komplexität zunimmt,
desto mehr wird es dann plötzlich selbst zu einem Produkt,
einem Produkt, das eben zum internen Verbrauch bestimmt ist,
für die eigenen Mitarbeiter.
Für die eigenen Ingenieure.
An das dann auch all dieselben Maßstäbe angelegt werden,
wie wir es an gewöhnliche Produkte tun.
Da liegen Qualitätsmaßstäbe an.
Das muss getestet sein.
Das muss dokumentiert sein.
Da muss ein Monitoring dahinter stehen und so.
Das entwickelt dann unter Umständen ganz plötzlich ein Eigenleben,
was ja zum Beispiel auch SAFE auch ganz ausdrücklich sagt.
Die haben doch dann diese zwei Arten,
diese zwei Arten von Wertströmen.
Wie hießen die gleich wieder, Falco?
Ich komme nicht drauf.
Entwicklungswertströme und operative Wertströme.
Ja, genau. Richtig.
Wo das dann also wirklich sein eigenes Produkt wird irgendwann mal,
diese ganze Pipeline-Klempnerei.
Ja, passt ganz gut zu einem Zitat,
was auch mal ein Elon Musk in einem Interview gebracht hat,
oder ja, eigentlich definiert hat,
was denn das Produkt von Tesla sei.
Da ist die Aussage nicht gewesen, die Fahrzeuge,
sondern die Gigafactory ist das Produkt.
Die Gigafactory ist das Produkt von Tesla,
die dann hinterher die Fahrzeuge ausspuckt
und teilweise sogar so ausspuckt,
dass nicht jede Fahrzeugserie gleich ist,
sondern jedes einzelne Fahrzeug ein eigenes Produkt ist
mit eigenen anderen Eigenschaften als das,
als gegebenenfalls ein Vorgängerprodukt
oder ein Produkt von einer Woche vorher,
weil sich die Fabrik verändert hat
und damit halt die Produkte anders werden.
Zum Beispiel eine Schraubverbindung
durch eine Klebeverbindung ersetzt wurde oder anderes kontinuierlich,
was dann halt mit verschiedenen Prozessen, Tests und anderem halt einhergeht
und auch eine Automatisierung bis hin zur Freigabe dieser Produkte,
zur Anmeldung von bei den entsprechenden Behörden,
dass halt auch diese veränderten Versionen entsprechend
auf der Straße fahren dürfen,
also freigegeben werden vom Kraftfahrtbundesamt
oder ähnlichem.
Ganz interessante Sicht darauf,
dass letztendlich das Produkt, die Pipeline,
dann ein internes Produkt wird
und ich gehe davon aus,
dass so auch die AWS und Azure und Co. entstanden sind,
dass sie halt für die eigenen Entwickler
als internes Produkt da waren
und dann die Qualitätsmaßstäbe
auch für externe Entwickler irgendwann erfüllt haben
und so dann halt auch direkt als Produkt für Firmen wie Netflix,
die auf AWS bauen oder andere,
dann weiter genutzt werden können.
Also so wird dann halt das interne Produkt
auch sogar zum externen.
Okay, wir waren gerade immer noch bei den erschwerten Bedingungen
für Continuous Delivery
und eine von denen, die du vorhin erwähnt hattest,
sind Produkte, die über reine Software hinausgehen,
also eben nicht nur die App oder die Web-Anwendung,
die dann irgendjemand nutzt,
sondern mit Hardware-Komponenten beinhaltende Produkte,
Cyber-Physical Systems,
verteilte Systeme mit dem Abstand von RGAP oder anderem.
So Produkte, die mir da einfallen, wären halt so ein Drucker,
der halt auch physische Komponenten hat,
die Druckerpatrone, die Steuerungselemente und anderes.
Wie baut man da Continuous Delivery Pipelines auf?
Worauf muss man achten?
Und was ist letztendlich Tipps und Hinweise,
die wir unseren Hörern mitgeben können?
Genau, das ist eine ganz, ganz wichtige Frage,
glaube ich.
Wie fängt man denn an solchen Stellen an?
Und dort gilt noch mehr als allgemein diese Weisheit,
wie isst man einen Elefanten Gabel für Gabel?
Einfach mal irgendwo anfangen, agil sein,
auch bei diesem Produkt Pipeline,
bei diesem Produkt Continuous Delivery.
Das erlebe ich ganz häufig in Trainings,
dass die Teilnehmer dann so ein bisschen wie das Kaninchen
auf die Schlange, auf diesen Riesenberg an Möglichkeiten starren
und sagen, wir sind ja noch so weit weg davon.
Aber man muss halt mal irgendwo anfangen.
Und man darf da auch gerne pragmatisch sein
und man kann da auch mit Fug und Recht einfach mal Sachen rauslassen.
Ein Beispiel aus meiner eigenen Praxis ist vielleicht
ein Kunde von vor einigen Jahren.
Die haben im weiteren Sinne Industrieroboter gebaut.
Und wir haben es so weit gebracht, dass wir eine Pipeline hatten,
die neue Software-Inkremente von diesem Roboter über Nacht
auf den Roboter drauf geflasht hat.
Und dann eine einzige ganz banale Trajektorie abgefahren ist.
Das war also, wenn man so will, eigentlich echt nur ein Smoketest.
Na ja, zuckt das Ding überhaupt noch?
Aber das war schon mal sehr, sehr viel wert.
Wir konnten uns jeden Tag aufs Neue davon überzeugen,
dass unser Bildprozess nach wie vor richtig ist,
dass unsere Deployments nach wie vor funktionieren
und dass wir nach wie vor in der Lage sind,
erfolgreich diesen Roboter anzusteuern
und definierte Koordinaten anzufahren,
das auch zu beweisen, dass wir dort gelandet sind.
Nur dieser eine Test hat schon wahnsinnig viel uns gebracht.
Und natürlich, man hätte das dann noch weiter ausbauen können.
Es ist dann auch aus anderen Gründen nicht dazu gekommen.
Meine Beauftragung hat geendet und so weiter.
Aber lange Rede, kurzer Sinn.
Allein dieser Schritt von null Tests zu einem Test
und sei ja auch nur so trivial,
hat, ich weiß nicht, ob 80 Prozent,
aber sehr, sehr viel des Werts erzeugt, des Gesamtwerts.
Ja, so wie bei Pareto.
Ich glaube, das ist ein sehr guter Schritt,
um zu schauen, wo kann man anfangen,
dass man die Dinge, die halt vielleicht viel Zeit kosten,
dass die Dinge, die viel Aufwand in der Wiederholung
oder vielleicht auch eine hohe Fehleranfälligkeit haben,
diejenigen werden, die man halt zuerst automatisiert,
um sich damit dann Zeit zu schaffen,
auch später weitere Elemente zu bedenken.
Sowas wie, wie gehe ich damit um,
wenn ein Flaschen von einer Komponente,
von einem Steuersystemgerät
oder von einem Router
oder anderer Komponente im System
letztendlich nicht funktioniert,
dass es halt ein Fallback gibt,
dass dieses System halt zumindest auf einen vorherigen Stand
wieder zurückkommt.
Dass man letztendlich darüber nachdenkt,
Techniken einzusetzen,
die bestimmte Prozesse verkürzen.
Ich bin ja aus der Ingenieurinformatik heraus
auch mit Prototyping,
zum Beispiel bei der Entwicklung von neuen Geräten,
neuen Systemen im Kontakt gewesen,
dass man 3D-Druck,
dass man verschiedene Techniken halt einsetzt,
bis hin zu Drucken von Leiterplatinen und ähnlichem,
dass man all das nutzt, was halt da ist.
Genauso aber eben auch mit Mocking.
Das heißt, dass man Softwarekomponenten einsetzt,
die so tun, als wären sie Hardwarekomponenten,
so ähnlich wie das bei dem DevOps-Handbook
und der Firmware-Tests bei HP beschrieben worden ist.
Dass man halt wirklich sagt,
okay, für jede Druckerserie hat man halt
einen physischen kleinen Drucker irgendwo im System,
der halt angesteuert werden kann,
aber eben auch genauso entsprechend Mocks,
die viel häufiger, viel schneller das Feedback liefern,
letztendlich etwas so funktioniert,
wie es sollte oder nicht
und mit diesen beiden Techniken entsprechend arbeitet.
Oder halt auch den allerersten Schritt,
wie du es immer so gerne sagst,
mit Null-Automatisierung zu starten.
Dass man halt okay sagt,
ich baue mir erstmal ein Framework auf,
mit dem ich anfangen kann zu automatisieren,
also eine Pipeline im allereinfachsten Fall
und baue die kontinuierlich weiter auf
und für einzelne Komponenten integriere die,
habe vielleicht erstmal einen Fokus auf eine Testumgebung
oder auf eine Entwicklungsumgebung
und baue die dann über die verschiedenen Stages hin weiter auf.
Vielleicht auch erstmal nur die Continuous-Integration-Sicht
für eine einzelne Komponente,
das dann für alle Komponenten stückchenweise dann aufzubauen
in Richtung Integrationstests
und dann so zu einem Ende-zu-Ende-Pipeline zu kommen,
die Continuous-Deployment ermöglicht.
Genau.
Ich finde, an der Stelle ist es immer sehr hilfreich,
sich wieder vor Augen zu halten.
Das, worauf wir auch zwischendurch
bei unserem DevOps Specify & Verify Training
immer wieder zurückgekommen sind,
nämlich was ist denn eigentlich der Kern,
der Kern hinter Softwarequalität,
weil es ist ja so nebulös, wie lässt sich das fassen?
Es lässt sich so fassen, dass man sagt,
habe ich Vertrauen darein,
dass der Wert tatsächlich erbracht werden kann?
Und wenn ich jetzt an mein Roboterbeispiel von vorher denke,
allein der Umstand, dass ich jede Nacht
das neueste Inkrement geflasht habe,
dass ich jede Nacht den Roboter einmal habe fahren lassen,
hat mir ein ganz großes Grundvertrauen gegeben,
dass das System als Ganzes noch nicht so schlimm im Graben ist,
wie es sein kann.
Selbst wenn da mal irgendwie ein bisschen was faul ist,
wir haben es ja sofort gemerkt.
Und selbst wenn wir natürlich in Einzelheiten
noch jede Menge Bugs hatten oder sowas,
aber ganz grundsätzlich,
das Ding tut, was wir von ihm wünschen.
Und aus dieser Warte, glaube ich,
kommt man dann auch sehr leicht wieder dahin,
wenn Leute sagen,
ja, also CD ist ja an sich eine gute Sache,
aber für uns geht das nicht, weil Grund, Grund, Grund.
Wenn man sagt, okay, was kannst du denn tun,
womit du das Vertrauen heben kannst
in dein Produkt?
Dann finden die meisten Leute doch sehr schlaue Lösungen,
sehr schlaue Antworten,
die vielleicht nicht perfekt sind,
die vielleicht Dinge auslassen,
ganz bewusst auch Dinge auslassen.
Einfach aus der Überlegung heraus,
das Bessere ist der Feind des Guten.
Lieber eine einfachere Version jetzt gleich haben
und jetzt sich gleich davon überzeugen können,
ja, geht,
als sich zu verkünsteln und dann am Ende
hast du ein Dreivierteljahr rumgebastelt
und hast immer noch keine Pipeline am Laufen.
Genau, das kommt auch so ein bisschen
zu dem Schlussthema, was wir noch besprechen wollten,
nämlich eignet sich Continuous Delivery denn wirklich
in allen Fällen?
Oder anders gefragt,
welche Ausreden gibt es denn, keinen CD machen zu können?
Gerade gesagt, okay, fangt an, macht es mit kleinen Schritten,
versteckt euch nicht hinter dem perfektionistischen Ansatz,
alles von Ende zu Ende automatisiert zu haben
und das ist nie erreichbar,
weil das halt so ein großer Klotz ist,
sondern schneidet den Elefanten klein,
esst ihn Gabel für Gabel und fangt an.
Continuous Delivery umzusetzen,
von mir aus in einzelnen Komponenten,
um dann über die Zeit eine Pipeline zu bauen,
die Continuous Deployment und Release on Demand möglich machen.
Genau so ist es.
Also aus meiner Sicht gibt es keine Ausrede,
um nicht Continuous Delivery in irgendeiner Form umzusetzen.
Mag sein, dass das anders ausschaut als bei anderen.
Mag sein, dass ihr halt nicht mehr
zwei Wochenzyklen hinkriegt,
sondern bloß drei Monatszyklen,
weil das ist halt das Beste, was man so erreichen kann,
wenn man Atomkraftwerke baut oder so.
Alles okay, alles wunderbar.
Solange man sich darauf zurückbesinnt,
dass man sagt, es geht mir darum, kurz zu iterieren,
was auch immer kurz heißt,
es geht mir darum, Feedback zu gewinnen,
es geht mir darum, Vertrauen zu schaffen,
es geht mir darum, um die Erzeugung von Artefakten abzukoppeln,
von der Auslieferung von Wert.
Dass ich sagen kann, ich generiere ständig irgendwie neue Produktinkremente,
ich schreibe jede Menge JavaScript-Code oder was auch immer
und das ist vollkommen getrennt davon,
wann ich jetzt eigentlich eine neue Version meines Produkts
meinen Kunden vorsetze, dann bin ich auf dem richtigen Weg.
Und alles, was ihr dann macht, wird schon stimmen.
Solange ihr dieses Ziel im Auge behaltet,
könnt ihr ja gar nicht verkehrt sein
und dürft sehr gerne natürlich auch an der Stelle agil sein und sagen,
ich mache auch die Weiterentwicklung meiner Pipeline.
Kurz, zyklisch, Feedback getrieben in dem Bewusstsein,
dass ich bestimmt auch ab und zu mal einen Bock schieße,
aber macht ja nichts, dann machen wir es nächstes Mal besser.
Und jetzt will ich trotzdem noch mal kurz darauf eingehen,
auch wenn die Zeit schon ein bisschen lang wird.
Falco, wenn jetzt jemand sich ernstlich bemüht, Continuous Delivery einzuführen
und es fällt ihm aber irgendwie schwer, es klappt nicht gut,
die Pipeline ist doof und worauf mag das hindeuten?
In was für Probleme mag er sich?
Kann er vielleicht hineingelaufen sein?
Was für Erfahrungen hast du da gemacht?
Das ist auch relativ breit gefächert.
Da kann man halt verschiedene Gründe ansetzen.
Einerseits kann es fehlendes Wissen sein,
wo man mit Schulungen, mit Erfahrungen von Entwicklern,
die das vielleicht zwei, drei Mal in ihrer Vergangenheit schon gemacht haben,
gut nach vorne kommen kann,
wo man sich auch mit einem entsprechenden Berater vielleicht gefallen tut.
Letztendlich muss man halt schauen,
wird es überhaupt auch genutzt,
was man sich da als Continuous Delivery Pipeline aufgebaut hat.
Wenn man es letztendlich einmal gemacht hat, dann feststellt,
ja, ist okay, wir nutzen das jetzt.
Und derjenige, der es vielleicht gebaut hat, hat das Unternehmen verlassen,
Wissen geht an der Stelle vielleicht verloren,
es ist nicht gut genug dokumentiert.
Dann schläft auch solch ein Produkt, auch wenn es ein internes ist,
oder gerade wenn es ein internes ist, dann auch schnell ein.
Das sind so die Gedanken, die mir jetzt ad hoc zu dieser Frage kommen.
Magst du das noch ergänzen?
Hast du noch Hinweise aus deiner Sicht?
Ja, klar.
Also ich meine, was du beschrieben hast, ist natürlich auch so ein Klassiker.
Das war irgendjemand ein Steckenpferd und der hat das jetzt aufgebaut.
Und dann wendet er sich neuen Themen zu.
Dann verfällt das irgendwie so ein bisschen.
Das ist natürlich immer sehr traurig, wenn das passiert.
Und das hat für mich dann auch immer so ein bisschen,
entweder deutet es darauf hin,
dass derjenige am tatsächlichen Bedarf seiner Kollegen vorbeigebaut hat,
oder es deutet darauf hin,
dass der Wert vielleicht noch gar nicht erkannt wurde,
vielleicht auch tatsächlich noch nicht realisiert wurde,
weil die wirklich coolen Sachen, zu denen ist man vielleicht noch gar nicht gekommen.
Wir haben es ja schon ein paar Mal erwähnt.
Es geht darum, sich selbst Vertrauen zu erschaffen,
sich selbst in die Lage zu versetzen, schneller zu iterieren.
Nicht zum Selbstzweck, sondern um auf diese Weise noch leichter dem Wert folgen zu können.
Aber was halt auch sehr häufig ist,
ist, dass das auch schlicht und ergreifend ein kulturelles Problem ist.
Schon klar, wir haben da jetzt irgendwie eine technologische Plattform,
die uns ganz viel ermöglicht.
Wir machen dann gar nichts draus.
Wir bleiben bei, ich weiß nicht, quartalsweisen Releases.
Oder wir bleiben dabei, dass wir ganz viele manuelle Freigabeprozesse brauchen,
weil das muss so sein, weil das haben wir schon immer so gemacht.
Man darf sich sehr stark eingeladen fühlen,
das jetzt wirklich auch als Gelegenheit zu nutzen,
zu sagen, wo gibt es denn hier alte Zöpfe, die ich abschneiden kann.
Es steht ja außer Frage, dass Prozessschritte,
die mal eingeführt wurden, mit Fug und Recht eingeführt wurden,
um bestehende Probleme zu lösen oder wenigstens zu lindern.
Aber existiert das Problem noch?
Wenn ich zum Beispiel häufig ausliefere,
ist das Risiko einer Auslieferung wirklich immer noch so hoch,
dass ich dafür einen manuellen Freigabeprozess brauche?
Oder kann ich nicht sagen, wird schon stimmen,
und wenn nicht, dann schiebt man einen Bug-Fix-Release gleich hinterher?
Wir haben ja die technischen Möglichkeiten.
Lasst uns einfach riskieren.
Das Risiko der Langsamkeit ist plötzlich größer als das Risiko der Schnelligkeit.
Da kommt man natürlich auch zwei Schritte weiter gedacht
in Richtung Wertstromanalyse,
Richtung Wertstromdesign,
dass man sich, bevor man in die Automatisierung geht,
natürlich auch darüber Gedanken macht,
welche Prozessschritte sind überhaupt werthaltig,
die wir jetzt aktuell haben?
Und können wir die ersetzen?
Können wir sie wegautomatisieren?
Also können wir sie in der Automatisierung tun
und dann gehen sie halt relativ schnell und einfach?
Oder sind sie gar nicht mehr relevant,
gar nicht mehr werthaltig,
weil sie vielleicht früher mal einen Wert geschöpft haben,
der jetzt gar keiner mehr ist,
weil Kunden daran gar nicht mehr interessiert sind,
weil vielleicht auch andere Abteilungen,
für die man das mal gemacht hat,
nicht mehr daran interessiert sind?
Und auch da hat man natürlich eine gute Grundlage,
dann über Continuous Delivery nachzudenken.
Genau.
Also, welche Gründe gibt es dafür,
dass Continuous Delivery schwierig sein kann?
Kultur, haben wir gerade gesagt.
Das Zweite ist, ich nenne es mal Featureitis,
dass man sich nicht ausreichend zurücknimmt,
und sagt, wie klein kann ich Inkremente überhaupt machen?
Wie kann ich es mir überhaupt ermöglichen,
dass ich kurze Zyklen fahren kann,
dass ich die umsetzen kann,
dass die für mich auch Sinn machen,
dass ich die im Griff behalten kann?
Also ich sage jetzt mal etwas,
was völlig auf der Produktebene passiert,
was passiert lange bevor ich geschweifte Klammern tippe,
sondern schon wirklich in der Phase von Produktmanagement
und Product Ownership.
Und das Dritte,
was glaube ich auch oft ein Paradebeispiel ist
oder ein Paradethema ist,
ist Architektur.
Genauso wie beim Testen,
man weiß ja die Binsenweisheit,
wenn Tests schwer zu schreiben sind,
dann bist du entweder einfach nur inkompetent im Testen,
aber viel wahrscheinlicher ist es,
dass deine Architektur es einfach schwer macht,
Dinge so weit zu entkoppeln,
dass sie vernünftig testbar sind.
Und genauso ist es mit Continuous Delivery.
Wenn sie dir schwer fällt,
dann ist das häufig ein Signal dafür,
dass in den Strukturen,
die bestehen in deinem Produkt oder in deiner Organisation,
Conway lässt grüßen,
übermäßig enge Verknüpfungen vorhanden sind,
die es dir schwer machen,
eine Pipeline wirklich erfolgreich zu bauen und zu betreiben.
Das wären so die drei Klassiker,
sage ich mal,
die mir auch immer wieder mal unterkommen.
Finde ich letztendlich wirklich hilfreich,
dass man darüber nachdenkt,
dass man auch diese unterschiedlichen Gründe,
Kultur, Feature,
Architektur unabhängig voneinander betrachtet
und dann schaut,
ob man dagegen vorgehen kann
oder wie man damit gut umgeht.
Okay, wollen wir zum Schluss kommen?
Gibt es noch Bemerkungen?
Gibt es noch Punkte,
die wir bis jetzt nicht erwähnt haben,
die es noch wertvoll sind für die Zuschauer, Zuhörer?
Wenn wir sie vergessen haben,
meldet euch auf jeden Fall
und sagt uns, was euch wichtig ist.
Ansonsten erst mal Luca.
Genau.
Also ich glaube,
ich kann mich der Einladung von Falco anschließen.
Falls ihr Fragen oder andere Fragen habt,
dann schreibt uns sehr gerne.
Vielleicht machen wir mal eine Follow-Up Episode
mit Hörerzuschriften,
Hörerinnenzuschriften.
Ich glaube, dass das ein Thema wäre,
das sich dafür sehr eignen würde.
Insofern immer her mit dem Zeug.
Ich möchte aber auf jeden Fall noch auf etwas hinweisen,
nämlich es gibt eine Webseite,
die mich momentan sehr beschäftigt,
die nennt sich minimumcd.org.
Die ist ins Leben gerufen,
ich glaube von Brian Finster
und noch so ein paar Leuten,
die alle sehr, sehr schlau sind.
Und die versucht haben,
eine argumentative und technische
oder wie soll ich sagen,
organisatorische Basis für Continuous Delivery
niederzuschreiben.
Und ich lege euch allen ans Herz,
diese Webseite mal anzuschauen,
die ist sehr, sehr kurz und knackig
und euch einfach mal anzuschauen,
welche Prinzipien dort aufgezählt werden,
an die man sich halten sollte,
um erfolgreich Continuous Delivery zu betreiben
und damit in der Verlängerung
auch erfolgreich agil zu arbeiten.
Wir packen natürlich den Link noch in die Shownotes,
aber minimumcd.org,
könnt ihr auch einfach direkt jetzt schon mittippen.
Genau, da warst du ja sehr fleißig bei der Übersetzung.
Ich habe nochmal drüber geschaut.
Sind jetzt auch offizielle Mitarbeiter
oder Kontributoren, deutsch das Wort.
Ja, auf jeden Fall sinnvoll und hilfreich,
um zu schauen, wie minimum,
cd darüber denkt,
was Continuous Delivery wirklich ausmacht,
wo die Kerne des Themas sind.
Und ja, können wir gerne nochmal ein wenig tiefer darauf eingehen
in einer späteren Folge.
Besonders dann, wenn ihr uns sagt,
es interessiert euch.
Oder auch, es interessiert euch nicht
und dann hört ihr nie wieder davon.
Das ist auch okay.
Ja, das glaube ich nicht.
Gut, aber wir, Falko, sollten, glaube ich,
ganz dringend zum Schluss kommen.
Die Episode wird doch schon wieder ganz schön lang.
Mir hat es sehr viel Spaß gemacht.
Vielen Dank für das interessante Gespräch.
Vielen Dank für deine Einsichten, Falko.
Ja, liebe Hörerinnen und Hörer, bis bald.
Da schließe ich mich ein, auch von mir.
Bis bald.

Folge 68: Dierk, Falko und Luca zu Wertstrommanagement (2/2)

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

In dieser Folge des DevOps-Podcasts diskutieren die Teilnehmer ausführlich über Wertstromanalysen im Kontext von DevOps. Sie erörtern die Bedeutung der Kundenperspektive, die Identifikation und Visualisierung von Wertströmen, und wie man durch deren Analyse effiziente Optimierungsstrategien entwickeln kann. Besonderer Fokus liegt auf der praktischen Durchführung einer Wertstromanalyse, der Einbeziehung verschiedener Teamrollen und der kontinuierlichen Verbesserung von Prozessen. Sie teilen auch Einblicke und Erfahrungen aus ihrer eigenen Praxis und referenzieren relevante Literatur und Methoden.

Inhalt

  • Einführung in Wertstromanalysen und deren Bedeutung in DevOps
  • Diskussion über die Kundenperspektive in Wertströmen
  • Identifikation und Visualisierung von Wertströmen
  • Praktische Durchführung einer Wertstromanalyse
  • Rolle verschiedener Teammitglieder in Wertstromanalysen
  • Bedeutung von Metriken und kontinuierlicher Verbesserung
  • Diskussion über Tools und Methoden für Wertstromanalysen
  • Erfahrungsaustausch und Praxisbeispiele
  • Literaturhinweise und Schulungsempfehlungen

Shownotes

Dierks Roman zu Wertstrommanagement

Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)

DevOps – auf die Ohren und ins Hirn
Ein Podcast rund um DevOps
Von Dierk Söllner, Falko Werner und Luca Ingianni
Hallo und herzlich willkommen zu einer neuen Folge des Podcasts DevOps auf die Ohren und ins Hirn.
Gestaltet und produziert von Luca Ingianni, Dierk Söllner und Falko Werner.
Wir sind DevOps-Trainer und Coaches mit langjähriger Erfahrung.
DevOps umfasst für uns kulturelle, organisatorische und technische Aspekte.
Heute dürft ihr euch freuen auf den zweiten Teil der Unterhaltung,
die Dirk, Falko und ich angefangen haben in der vergangenen Folge,
wo wir uns dem Thema Wertströme, Wertstromanalysen, Wertstromdesign genähert haben.
Und diese Folge wurde so spannend und so lang, dass wir beschlossen haben, sie in zwei Teile zu hauen.
Der erste Teil war also der, nennen wir es mal, etwas allgemeinere Teil.
Und der zweite Teil, der soll jetzt noch viel konkreter sich mit dem Thema befassen.
Wie macht man denn eigentlich ganz praktisch so eine Wertstromanalyse?
Wie läuft das denn ab?
Worauf möchte man achten?
Was wird man dabei vielleicht beobachten?
In welche Probleme wird man vielleicht laufen?
Also freut euch mit mir auf diesen zweiten Teil dieses Podcasts über Dirk Söllner.
Wertstromanalyse.
Ist die Wertstromanalyse, der Value Stream Mapping, der erste Schritt?
Muss man vorher noch an irgendwas anderes denken?
Welchen Wertstrom will ich denn genau angucken?
Das ist ja vielleicht ein Thema, eine Frage, die man sich vielleicht vorher beantworten muss.
Ja, also erstmal die Frage, welchen Wertstrom.
Und ich habe ja vorhin gesagt, ihr dürft mich gerne korrigieren.
Ihr habt es bis jetzt noch nicht gemacht.
Wer euch erinnert, so vor 10, 15 Minuten habe ich was erzählt von, dass die richtigen Leute zusammenkommen.
Also die, die im Wertstrom mitarbeiten.
Und davor finde ich noch einen ganz wichtigen Punkt.
Und Falko, du hast mich eben schon auf diesen Hinweis von mir jetzt gebracht.
Du hast von Kunden gesprochen und von gemeinsamer Sprache.
Das, was ich eben auch interessant finde, ist, wenn man mit dieser Technik von dem Value Stream Mapping,
wenn man startet, ist eigentlich sozusagen der erste Schritt, also der Schritt Null quasi, die Stimme des Kunden.
Ja, also sich zu überlegen, aha, ich will Wert schöpfen.
Ja, ist ja wunderschön.
Dann muss ich ja jemanden haben, der bewerten kann, ob das wertvoll ist, also ob das Wert für ihn generiert.
Und auch das, finde ich, ist ein Unterschied, zumindest in der Sichtweise zu einem Prozessmanagement.
Also insofern, um das nochmal klarzumachen, der erste Schritt ist, wenn man diese Frage geklärt hat,
wir können etwas verändern, wir wollen etwas verändern, dass man dann sagt, okay, was ist die Stimme des Kunden?
Was will der Kunde von uns?
Und allein das ist auch schon mal häufig.
Eine sehr hilfreiche und wertvolle Aktivität, nämlich klarzumachen, was will der Kunde von uns?
Und da ist man dann manchmal auch vielleicht gar nicht ehrlich oder man weiß gar nicht, was der Kunde wirklich will.
Und auch das finde ich einen schönen Nebeneffekt.
Man macht sich mal wirklich Gedanken, was liefern wir alle in einem Wertstrom, einen Wert für einen Endkunden?
Also insofern, das ist vielleicht nochmal der Vollständigkeit halber zu ergänzen.
Der erste Schritt ist.
Sich über den Wunsch, über die Stimme des Kunden Gedanken zu machen.
Im Rahmen einer Wertstromanalyse, also Value Stream Mapping oder noch davor?
Also für mich ist das, also man kann es natürlich vorher machen, aber für mich ist es Schritt oder Aktivität in der Value Stream Mapping,
also in der Analyse, weil ich damit eben auch sicherstellen kann, über welchen Wertstrom rede ich.
Also ich habe mir einen Wertstrom überlegt und dann fange ich an, wer ist der Kunde dieses Wertstroms?
Was sind die Stakeholder und welchen Wert liefere ich diesen Kunden, diesen Stakeholdern?
Wie geht es dann weiter, wenn man letztendlich weiß, was man an Wert liefert, für welche Kunden?
Wie muss man sich so eine Wertstromanalyse vorstellen?
Also wir haben alle Personen.
Versammelt, von denen wir meinen, dass sie dazu beitragen können, von den Product Ownern, bis zu den Testern, bis zu was weiß ich noch wem alles.
So weit wie der Wertstrom halt geht.
Dann sollte man sich mal überlegen, haben wir den denn wirklich richtig verstanden, unseren Wertstrom?
Jetzt haben wir diese ganzen Leute.
Man geht ja rein mit irgendeiner Idee, woraus der Wertstrom denn besteht.
Und meistens, wenn man dann alle zusammentrommelt, an die man so gedacht hat, dann stellt man fest, dass die sagen, ja, aber an folgende Leute haben wir ja noch gar nicht gedacht.
Und folgendes haben wir noch gar nicht gedacht.
Das heißt, der erste Schritt ist eigentlich wieder ein Schritt zurück.
Nämlich der zu sagen, okay, was haben wir übersehen?
Wie sind unsere Wertströme wirklich?
Und erst wenn man diesen Schritt gegangen ist, dann kann man sagen, welchen wollen wir denn jetzt analysieren?
Häufig ist es ja dann auch so ein ganzes Knoll von Wertströmen.
Es gibt ja häufig auch einander kreuzende Wertströme zum Beispiel.
Die eine Abteilung baut ein Produkt, das die andere Abteilung verwendet, um tatsächlich irgendetwas für den Kunden zu bewerten.
Das heißt, die eine Abteilung baut ein Abrechnungssystem und die andere Abteilung, die macht dann halt die Abrechnung und verschickt die Rechnung an den Kunden und sowas.
Es geht aber, glaube ich, sogar noch ein bisschen weiter, weil das war etwas, was mich sehr vom Hocke gehauen hat, als ich mal dieses klassische Buch gelesen habe, Value Stream Mapping, von Karen Martin und Mike Osterling.
Die haben gesagt, es gibt überhaupt nicht den einen amtlichen Wertstrom, sondern es ist halt echt nur ein Modell.
Und sie sagen, ein vernünftiges.
Vernünftiger Wertstrom hat circa 25 Schritte.
Das ist so.
Und wenn du irgendwie jetzt einen Wertstrom auseinander gemappt hast und du landest bei 40 Schritten, dann hast du ihn zu granular gemappt.
Dann kannst du dich jetzt entweder entscheiden, kannst sagen, den haue ich jetzt in zwei Teile.
Dann habe ich zwei Abschnitte von circa 22 Schritten.
Ist okay, sagen die.
Oder ich zoome ein bisschen raus und fasse Blöcke zusammen, bis ich wieder bei circa 25 angekommen bin.
Wie begründen Sie diese Grenze von 25?
Aus Pragmatismus.
Die sagen, das ist einfach bequem, um darüber zu diskutieren.
Und das finde ich eben ganz spannend, weil sie wirklich ganz aggressiv damit umgehen, dass das wirklich nur ein Modell ist.
Das ist keine Realität.
Das ist ein mehr oder minder willkürliches Modell.
Und ich finde, da steckt eine gute Nachricht drin, weil du bist nicht dazu verdammt, es irgendwie richtig zu machen.
Sondern wenn es hilfreich ist, dann war es gut.
Alles fein.
Mach dir keine Gedanken.
Deswegen, dass das jetzt stimmen muss oder so.
Es muss nur hilfreich sein.
Wichtiger Hinsatz.
Es muss hilfreich sein.
Und es muss nicht richtig sein.
Also um das auch nochmal klar zu machen.
Es ist nicht die Realität.
Es ist ein Abbild der Realität.
Es ist ein Bild der Realität.
Und da kann man sehr schön drüber sprechen.
Deswegen fand ich vorhin den Hinweis sehr, sehr wichtig zu sagen, wenn ich nichts verändern kann oder möchte, dann macht es eigentlich keinen Sinn.
Also ich kann das trotzdem machen.
Das ist Beschäftigungstherapie.
Also ich sollte es einsetzen, um herauszufinden, wo kann ich Dinge besser machen?
Wo kann ich mehr Wert schöpfen?
Wo kann ich schneller Wert schöpfen?
Wo kann ich mehr Qualität liefern?
Da hatten wir jetzt ja auch schon ein paar Beispiele mit dazu gebracht.
Ja, und um das zu sagen, das kommt gar nicht so selten vor, dass dann auch in Unternehmen wirklich Denkverbote herrschen an gewissen Stellen.
Und da muss man dann sagen, also ja, wir können es in Velostream irgendwie ausmappen, aber es wird uns zu nichts führen.
Ja, gut, also wenn ich jetzt überlege, wir haben gesagt, wir sollten uns über den Kunden Gedanken machen, zu überlegen, für wen wird das Produkt oder der Wertstrom letztendlich angeschoben?
Also für wen generieren wir Wert?
Dann müssen wir über die richtigen Leute nachdenken, die daran beteiligt sind, sodass sie Ende zu Ende auch den Wertstrom mappen können.
Also eine Wertstromanalyse, mit denen üblicherweise so um die 25 Schritten auch von Ende zu Ende abbilden können.
Wie geht es dann weiter?
Wie geht es dann weiter?
Wenn man sich jetzt also so ein bisschen die Grenzen seines Systems überlegt hat, dann sollte man sich überlegen, oder wenn man sich auch die Systembestandteile überlegt hat, die verschiedenen Schritte, die man sich so ausmodelliert hat,
dann sagt man, wer ist denn dafür verantwortlich?
Wer betreibt das denn?
Wer ist da im Spiel?
Ja, und da finde ich das wieder interessant.
Du hast vorhin den Begriff Product Owner genannt.
Es gibt auch vielleicht einen Process Owner.
Also es gibt schon verschiedene Rollen.
Und das ist auch ein Punkt gewesen, auf den wir in unserem Buch, von dem ich jetzt doch schon zum zweiten Mal berichte, in einem Beitrag, auf den wir eingehen.
Value Streams bringen neue Verantwortlichkeiten.
Also es gibt jetzt schon Value Streams, wenn ich es eben nutze, um bestehende Abläufe, bestehende Value Streams anzuschauen.
Es gibt sie schon.
Einen Product Owner kennt sie vielleicht, einen Scrum Master kennt sie vielleicht auch, einen Process Owner kennt sie vielleicht, einen Service Owner kennt sie schon.
Also es gibt in den Unternehmen schon Value Streams und es gibt Menschen, die diese Value Streams auch meistens so ein bisschen durchblicken.
Und die binde ich natürlich mit ein.
Und ich wollte darauf hinweisen, dass es eben genutzt werden kann von Menschen, die was verbessern, was verändern wollen.
Gut, nochmal.
Die ganzen Leute haben wir jetzt zusammengeholt, virtuell oder physisch in einem großen Raum.
Was machen die jetzt?
Die mappen einen Wertstrom Ende zu Ende.
Dann hat man ein großes Bild an der Wand oder auf einem virtuellen Whiteboard oder so.
Ja.
Und dann?
Ja, Falco.
Das ist eine gute Frage.
Ich würde gerne noch, bevor wir bei den Schritten weitergehen, eine Sache ergänzen, nämlich die Frage in Präsenz oder also auf dem Brown Paper an der Wand oder auf einem virtuellen Whiteboard.
Und ich glaube, dass da so viel Kreativität da ist.
Ich würde immer empfehlen, es in Präsenz zu machen.
Die hervorragende, die hervorragende, das Argument ist natürlich da, okay, Mensch, ich bin flexibel und kann auch jemanden weiter digital dazuschalten.
Aber ich persönlich bin der Meinung, wenn wir diese Value Streams visualisieren, sollte man es in Präsenz machen, weil es einfach viel mehr Kreativität bringt und viel mehr Austausch.
Ich finde das gut.
Ich würde das auch unterstützen, habe aber auch gute Erfahrungen gemacht mit virtuellen Value Stream Mapping Sessions.
Und zwar einerseits im Rahmen von Safe DevOps Schulung.
Wo auch ein Value Stream Mapping Übung enthalten ist, um letztendlich dann den Current State des Value Streams zu definieren, Maßnahmen auch abzuleiten und dann daraus einen zukünftigen Designansatz ableiten zu können.
Und das funktioniert mit Miro, Concept Board und anderen virtuellen Tools erstaunlich gut.
Und genauso haben wir es auch bei einem Kunden gemacht, bei dem wir Wertströme.
Um Analysen gemacht haben im Umfeld von einer Portalentwicklung für Kommunalportale und auch für Fertigungsmanagement, das heißt virtuelle Serverbereitstellung, automatisierte Bereitstellung von virtuellen Maschinen und Co.
Und da hat es erstaunlich gut funktioniert, auch wenn man virtuell zusammensetzt, die Visualisierung hilft.
Und ein Riesenvorteil, den du am Ende einer…
…digital gesteuerten Session hast, ist, du kannst das Ergebnis mitnehmen und ausdrucken und du kannst es dir auch immer wieder verändern.
Und müsstest das halt erst nochmal nacharbeiten, wenn du es physisch mit Post-its an der Wand gemacht hast.
Aber auch das habe ich auch in der Safe-Schulung mal vor Ort gemacht, hat auch genauso gut funktioniert.
Also aus meiner Sicht muss man es nicht physisch vor Ort machen.
Dann lass uns noch…
…nochmal den Stand jetzt überlegen oder rekapitulieren, wo sind wir jetzt gerade.
Wir haben angefangen, also sind wir im Value-Stream-Mapping.
Wir sind dabei, unsere Value-Streams sichtbar zu machen.
Wir haben angefangen, dass wir sagen, es muss jemand da sein, der etwas verändern möchte und verändern kann.
Das sind dann die Grundvoraussetzungen.
Dann haben wir gesagt, der erste Schritt ist, die Stimme des Kunden zu haben.
Zweiter Schritt, der Folgeschritt ist eben, die richtigen Menschen zusammenzubringen, sei es virtuell, sei es…
…eine Präsenz, dass wir uns Gedanken machen über den Value-Stream.
Wir hatten die 25 Schritte, die Luca ja auch ergänzt hatte.
Und dann haben wir irgendwann ein Bild von einem Value-Stream.
Im Idealfall ist das wirklich auch einer, der quasi so wirklich real so da ist.
Den haben wir komplett schön modelliert und transparent gemacht.
Dann haben wir gesagt, wer ist wofür verantwortlich?
Also wer macht welchen Schritt?
Wer macht welche Aktivität?
Und dann habe ich ja vorhin auf die Metriken hingewiesen.
Zum Beispiel Durchlaufzeit oder First-Time-Ride.
Und das wäre dann einer der nächsten Schritte, nämlich zu sagen, okay, wie lange brauchen wir dafür?
Wie lange braucht eine Karte, wie lange braucht ein Element, durch diesen Wertstrom durchzulaufen?
Das kann man dann natürlich erheben.
Entweder vielleicht sogar aus irgendwelchen digitalen Systemen, wenn man so etwas hätte.
Oder man macht es sozusagen einfach virtuell, trägt zusammen.
Und wo sind vielleicht auch Rückflächen?
Also wo habe ich einen Rücksprung?
Wo muss ich nacharbeiten?
Das wäre einer der nächsten Schritte, wenn ich es visualisiert habe, das auch zu nutzen,
um, wie gesagt, Metriken zu erheben und Kennzahlen daraus abzuleiten.
Ich möchte da nochmal kurz darauf eingehen, weil du hast das jetzt so in einem Nebensatz abgetan mit den Rückflüssen.
Aber das ist ja irgendwie so der Gott sei bei uns der Lean-Leute.
Alles, wo du Rückflüsse hast in deinem Werkzeug.
Wertstrom.
Und was meine ich mit einem Rückfluss?
Zum Beispiel ein Umstand, dass ich einen Bug entdeckt habe und ich muss jetzt irgendwie diesen Code, den ich geschrieben habe, den muss ich nochmal aufmachen, muss der den Bug ausmerzen oder sowas.
Sowas ist ultra blöd.
Erstens erzeugt es natürlich Verzögerungen, die mag keiner.
Aber vor allem erzeugt es auch Verwerfungen weiter Strom auf.
Das sind ja auch andere Sachen, an denen man gerade arbeitet.
Die muss man jetzt beiseite legen.
Jetzt verzögert sich wieder was anderes.
Man muss irgendwie seinen Kontext umschalten und so.
Das ist etwas von…
Von dem die Lean-Leute sagen, das ist unter allen Umständen zu vermeiden.
Insofern ist das ganz, ganz wichtig, wenn man so einen Rückfluss entdeckt und natürlich wird man welche entdecken, dass man besonders aggressiv versucht, da was dran zu verbessern.
Mein Stichwort.
Verbessern.
Mein Lieblingsthema.
Überschrift für all das, was ich tue.
Kontinuierliche Verbesserung.
Das heißt, wir haben jetzt, das was du auch gerade gesagt hast, wir haben Rückflüsse entdeckt.
Wir haben Wartezeiten entdeckt.
Wir haben entdeckt, dass wir eine Effizienz von unter einem Prozent haben.
Was weiß ich auch immer.
Alle Führungskräfte sind aus allen Wolken gefallen, weil sie erst mal sehen, was da für Verschwendung produziert wird, was sie sich vorher nie so vorstellen könnte.
Wir haben ja den Prozess beschrieben.
Also man sieht ja, was in der Realität dann abläuft, wenn man es sozusagen vernünftig macht.
Und jetzt, wie gesagt, der Punkt, der für mich wichtig ist, kontinuierliche Verbesserung.
Also wirklich Zukunft.
Wo können wir Dinge verändern?
Und das eben in der Ende-zu-Ende-Verantwortung.
Natürlich kennen wir alle kontinuierliche Verbesserung.
Da können wir lokal etwas optimieren.
Aber wir sind ja in einer Ende-zu-Ende-Verantwortung.
Das heißt also ableiten von einer kontinuierlichen Verbesserung.
Also kontinuierlich daran zu arbeiten, Rückflüsse zu eliminieren, Nacharbeiten zu eliminieren, Durchlaufzeiten zu erhöhen.
Immer mit kleineren oder größeren Maßnahmen.
Das ist für mich der nächste Schritt.
Durchlaufzeiten zu erhöhen, würde ich vermeiden wollen.
Insofern nochmal einen Schritt zurück.
Die Metriken auch richtig anzuwenden.
Ich finde es gut, dass es die Metriken gibt.
Dass man halt Durchlaufzeit und Arbeitszeit, Prozesszeit in jedem Schritt erhebt.
Dass man auch die Erfolgsrate, quasi wie viel Prozent der Anfragen, die durch Wertstromschritt X laufen, halt auch wirklich erfolgreich durchlaufen.
Dass man darauf letztendlich achtet.
Und das nicht nur…
Für den einzelnen Wertstromschritt letztendlich macht, sondern dass man auch entsprechend das mal aufsummiert.
Und am Ende wirklich den Kunden, die Kundensicht von Anfrage bis zur Lieferung des Werts dann auch im Blick behält.
Also die gesamte Durchlaufzeit, Flowtime, dann entsprechend misst und bewertet und vielleicht auch als Optimierungskenngröße.
Einsetzt und nutzt.
Das ist für mich letztendlich der zweitwichtigste Schritt.
Nach dem Qualitätsmaßstab möglichst keine Nacharbeiten.
Also keine Rückflüsse, keine Wiederaufnahme von Arbeiten.
Deswegen ist ja da das Toyota Produktionssystem mit diesem Andon-Cord die ganze Produktionslinie zu stoppen, wenn man sowas hat.
Um dann den Lernprozess anzustoßen, alle mit einzubeziehen.
Eines der interessanten Methoden und Tools, die man letztendlich einsetzen kann.
Und die dann halt auch zu übertragen auf die IT-Welt.
Luca, du wolltest glaube ich noch was sagen.
Ja, ich wollte nochmal eingehen auf diese Metrik der Fehlerfreiheit, nenne ich es mal.
Das, was dann immer heißt, Percent, Complete und Accurate.
Wie viel von dem, was ich tue, ist aufs erste Mal bereits vollständig und korrekt.
Weil wir haben jetzt gerade irgendwie…
Sehr hochträubend drüber geredet.
Ja, ja, das ist mega schlimm und so und das darf gar nicht sein.
Es ist vollkommen gewöhnlich, dass man eine Percent, Complete und Accurate von Null hat.
Eingangs einer solchen Analyse.
Das ist durchaus üblich, dass einfach auf Anhieb nichts klappt.
Sondern, dass man überall nochmal eine Schleife drehen muss.
Was ich damit sagen will ist, grämt euch nicht, wenn ihr jetzt eine Wertsturmanalyse macht und ihr kommt auf solche Werte.
Dann wisst einfach, ihr seid da in einer hervorragenden Gesellschaft.
Trotzdem wir darüber reden, dass das irgendwie ganz wichtig und ganz schlimm und so ist.
Das ist einfach ein wahnsinnig hohes Ziel.
Und da einfach bei Null anzufangen und zu sagen, Stand jetzt müssen wir immer nochmal eine Korrekturschleife drehen.
Das ist vollkommen gewöhnlich.
Erschreckt euch nicht, wenn ihr sowas seht.
Kann passieren.
Macht was draus.
Macht’s besser.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Genau.
Das sind ja immer die Wahrscheinlichkeiten, die man da letztendlich von Prozessschritt
zu Prozessschritt multipliziert.
Und wenn man halt 90 Prozent bei 20 Prozessschritten hat, kommt man da bei irgendwo einstelligen
Prozentwerten raus.
Und wenn man halt einen Schritt hat, wo man jedes Mal nacharbeiten muss, auch wenn es
immer nur eine Mini-Nacharbeit ist, immer eine Rückfrage auftaucht oder so, dann kommt
man halt ganz schnell auf die Null.
Genauso auch bei der Flusseffizienz, wo man halt sagt, okay, wie viel Null man hat, die
viel produktive Arbeitszeit und wie viel Durchlaufzeit, wie viel Liegezeit
letztendlich Anteil hat man da, dass man, wenn man den Gesamtwertstrom
betrachtet, ja häufig auch bei manchmal nur 3, 4, 5%
aktive Arbeitszeit und 90%,
95% Liege- und Wartezeiten
in der Ende-zu-Ende-Betrachtung hat. Auch da
letztendlich nicht erschrecken, sondern akzeptieren.
Häufig sind auch bei ersten
Optimierungsprozessen nach ersten Durchlaufen auch nur 15%
aktive Arbeitszeit bei Prozessen mit einem
hohen manuellen Arbeitsanteil realistisch machbar.
Immer dann, wenn man Übergaben hat von einer Person zu einer
anderen, dauert das Ganze halt letztendlich auch.
Genau, also auch
dieses Heere-Ziel, dass man sagt, ich habe
100% Fluss-Effizienz. Alle Zeit, die ein
Work-Item sich im Durchlauf befindet, wird daran gearbeitet.
Seien wir ehrlich, das ist ein ganz schön dickes Brett. Ich glaube, die
wenigsten Organisationen werden das tatsächlich schaffen, dieses Nirvana
zu erreichen. Aber das ist vielleicht auch gar nicht notwendig. Ich meine, das ist ja das, was Lena auch
immer sagt. Nimm einfach die Dinge so, wie sie sind und dann mach sie besser.
Und wenn gemäß deiner Metriken sie momentan ganz schrecklich sind, dann mach sie halt ein bisschen weniger
schrecklich. Ist total
okay. Und ich finde, da ist wieder mal eine gute Nachricht drin, weil du bist nicht
dazu verdammt, die Dinge perfekt zu machen. Du musst nur in die richtige Richtung
laufen. Mehr will gar keiner von dir. Du machst es so gut, wie du kannst.
Mehr kann man von dir einfach nicht verlangen. Aber
jetzt bin ich doch nochmal neugierig, weil, Falco, du hast vorhin diesen Begriff
Andon-Cord einfach so mal kurz in den Raum geschmissen. Da verbirgt sich bestimmt eine spannende Geschichte dahinter.
Was ist denn das für ein Ding? Letztendlich ist das
eine Leine, die
an jeder Arbeitsstation in einem Toyota-Produktionssystem
Prozess, sag ich jetzt mal, an der
Produktionsstraße zur Verfügung steht,
bei der ein oder jeder Arbeiter angehalten ist,
der feststellt, dass er nicht qualitativ
den Anforderungen entsprechende Zulieferungen bekommen hat,
den Prozess anzuhalten und zu sagen, hier läuft irgendwas
nicht gut.
Das heißt auch bewusst darauf zu achten, keine fehlerhaften
Teile einzubauen oder keine fehlerhaften Baugruppen
zusammenzuschrauben, die dann letztendlich vielleicht sogar
Rückrufe oder Nacharbeiten im Nachgang
produzieren, sondern an der Stelle alle dazu zu bringen,
diesen Fehler anzunehmen, zu akzeptieren, zu
analysieren, Ursachen zu finden. Dann halt häufig auch mit
so Techniken wie 5Y-Frage-Methoden, die Ursachen bis zur Quelle zu verfolgen
und dann darauf zu reagieren, um sicherzustellen, dass so ein Fall möglichst nicht wieder auftaucht
und man halt auch die Nacharbeit entsprechend dann nicht provoziert.
Genau, also mit anderen Worten wirklich die Fallhöhe sozusagen zu erhöhen,
zu sagen, also wenn hier jetzt eine Schwäche im Prozess auftritt,
dann sorgen wir dafür, dass die sichtbar wird, dass die wehtut, dass die irgendwie eklig ist,
damit wir uns einen Anstoß geben, sie wirklich an der Quelle zu beheben, so wie du sagtest.
Und nicht so, ja Vorarbeiter, komm mal schnell, wir sind jetzt gerade die 10er-Schrauben ausgegangen,
kannst du mal schnell ins Lager sausen, mir 10er-Schrauben holen oder so,
sondern nein, wie kann das sein, dass mir sowas Banales wie 10er-Schrauben ausgegangen sind?
Das müssen wir jetzt irgendwie dafür sorgen.
Wir müssen dafür sorgen, dass mir das nie wieder passiert und dann ist dieses Problem einfach weg, für immer und ewig.
Genau, außer es taucht aus irgendeinem anderen Grund, den man jetzt nicht gesehen hat, vielleicht doch wieder auf,
aber dann hat man zumindest eine neue Quelle und einen neuen Ansatz, wieder Optimierungen voranzutreiben, genau.
Genau, und es ist übrigens auch ganz interessant, als Toyota seine ersten Werke in Amerika aufgebaut hat,
dann haben die natürlich auch alle diese Techniken mitgebracht und haben so eine Andonleine angeschleppt und so
und irgendwann hat man dann auch wieder eine neue Quelle.
Und dann haben dann die amerikanischen Werksleiter, haben dann berichtet, wie es so lief, Produktionsanlauf und so
und haben ganz stolz erzählt, ja, liebe japanische Vorgesetzte, wir haben es geschafft, dass wir niemals die Andonleine gezogen haben
und die Japaner waren so, nein, ihr habt es genau missverstanden.
Ihr habt alle Probleme unter den Teppich gekehrt und sie sind immer noch da.
Hättet ihr niemals gezogen bleiben.
Es wird genutzt, aus den Problemen zu lernen.
Genau.
Ihr habt die Krisen, die Chance, eine Krise zu verwenden, um etwas an Verbesserungen zu erzeugen, einfach an euch vorbeiziehen lassen.
Genau.
Genau.
Und vielleicht sollten wir da jetzt auch nochmal drauf eingehen, zurückschreitend zum Thema Wertstromanalyse, Wertstromvisualisierung.
Wenn ich mir so einen Wertstrom mal aufgemalt habe, dann kann ich den natürlich instrumentieren.
Dann kann ich da nochmal draufschreiben, wo habe ich zum Beispiel welche Warteschlangen tief.
Wie viele Werkitems.
Wer ist dafür verantwortlich?
Vielleicht stellt sich dann auf einmal raus, dass es irgendwie einen Typen gibt, der ist für drei Viertel aller Stationen verantwortlich oder so.
Diese Visualisierung, diese Verschriftlichung kann man sich auch zunutze machen, um weitere Hinweise daraus zu ziehen, was passiert eigentlich in diesem Prozess?
Wie gesund ist der eigentlich?
Wo sind Rückflüsse?
Kann ich die irgendwie aufmalen?
Wo sind Stauungen?
Kann ich die irgendwie aufmalen oder sonst beziffern?
Ganz wichtig.
Ganz wichtig, dass man alles, was man da so zusammentragen kann an sachdienlichen Informationen, wie es die Polizei immer sagt, dorthin bringt und eine Diskussion zugänglich macht auf diese Weise.
Genau, das erinnert mich natürlich gleich wieder an ein ganz interessantes Buch von Herrn Goldrath, The Goal, auch ein Business-Roman.
Wenn du es schaffst, die Arbeit sichtbar zu machen, ähnlich wie das bei Produktionssystemen ist, dann hast du auch eine relativ hohe Wahrscheinlichkeit,
den Engpass im System zu finden.
Das ist nämlich die Arbeitsstation im Wertstrom, die letztendlich die längste Warteschlange vor sich hat.
Das heißt, da, wo letztendlich daran gearbeitet wird.
Und das ist aus meiner Erfahrung oder letztendlich aus vielen Erfahrungen auch in der Theorie, in der Wirtschaft, der Punkt, der die Gesamtproduktivität des Systems definiert.
Das schwächste Glied in der Kette sozusagen, die die Reißfestigkeit.
Die Gesamtkette auch definiert.
Und wenn du es schaffst, den zu optimieren, kriegst du auch durch das Gesamtsystem viel mehr Durchfluss.
Das heißt, du musst ihn erstmal identifizieren.
Dazu ist es natürlich auch hilfreich, so eine Wertstromanalyse zu machen, zu schauen, wo hakt es denn am ehesten.
Und natürlich hilft es da, mit den Liege-Warteschlangen und Ähnlichem zu hantieren.
Das muss man dann halt virtuell auch machen.
Also mit Jira-Tickets.
Jira-Tickets, die im Kanban-Board letztendlich lange liegen oder Ähnliches, kann man das ja auch relativ gut visualisieren.
Und an der Stelle anzusetzen, lohnt natürlich dann am drittmeisten, nachdem man halt letztendlich die Rückläufe reduziert hat.
Nachdem man letztendlich die Prozessschritte oder Wertstromschritte identifiziert hat, die keinen Beitrag zur Wertschöpfung haben.
Dass man dann halt reinschaut und sagt, okay, wo ist unser…
Angpass, Theory of Constraints, Analysen macht und sagt, okay, jetzt wollen wir den Gesamtdurchlauf, die Gesamtproduktivität des Systems erhöhen,
indem wir den Angpass ausweiten, letztendlich mehr Kapazität zur Verfügung stellen,
alle anderen Arbeitsprozessschritte dem letztendlich unterzuordnen,
vielleicht auch den Angpass zum Taktgeber zu machen und Ähnliches,
um dann so kontinuierliche…
Einfluss zu generieren.
Das sind so viele Optimierungsansätze, die man in dem Fall halt hat.
Und was aus meiner Sicht dann wichtig ist, ist dann Maßnahmen abzuleiten, um ja wirklich ins konkrete Doing zu kommen.
Das heißt, man hat dann den Wertstrom-Ist-Zustand, man hat die Analysen gemacht, man hat bestimmte Metriken erhoben,
man hat verschiedene Gedanken zusammengetragen und ja, dann geht es halt häufig in die Optimierung.
Das heißt wirklich Maßnahmen…
Im Backlog aufzubauen, sich zu priorisieren, zu überlegen, was bringt am meisten.
Da haben wir ja so ein paar Hinweise gerade schon gegeben, wo man am ehesten anfängt,
wo man dann als zweites und drittes drauf eingeht und dann kontinuierlich diese Dinge auch umsetzt.
Das heißt, den Prozess designt in einen Zoll, in einen Zielzustand zu überführen mit kürzeren Durchlaufzeiten,
weniger Verschwendung, weniger Liegezeiten und natürlich auch einem kontinuierlichen Fluss,
und das Schöne ist, man hat ja die Metriken, mit denen man sich vergewissern kann, dass man auf dem richtigen Weg ist,
und man hat den iterativen Ansatz, um zu sagen, also wenn wir jetzt was ausprobiert haben
und es hat nicht den gewünschten Erfolg gebracht, dann probieren wir halt was Neues.
Genau.
So, jetzt haben wir sehr detailliert, wie mir scheint, so einen ganzen Prozess mal durchleuchtet.
Jetzt sollen wir nochmal zusammenfassen, damit die geneigten Zuhörerinnen und Zuhörer überhaupt,
noch wissen, wovon die Rede war.
Ja, klar. Ich denke, kurz in zwei, drei Sätzen lohnt sich das sicherlich zusammenzufassen.
Also wir fangen an, holen letztendlich den Gedanken nach vorne, was ist der Kunde,
wer ist letztendlich derjenige, auf den wir die Wertschöpfung ausrichten,
sind es die Nutzer von der Anwendung, sind es die anderen Stakeholder, Unternehmenseigner, Shareholder, sind es die Mitarbeiter,
oder schafft man es vielleicht sogar alle, als Zielgruppe zu definieren und zu schauen,
wie kann man für alle den gesamten Prozess, vielleicht auch sogar bis hin zur Gesellschaft,
Umwelt und Co. Aspekte mit einzubringen, für alle die Wertschöpfung zu generieren.
Und wenn man den Startpunkt hat, dann geht es eigentlich kontinuierlich relativ schnell weiter.
Die richtigen Leute ins Boot holen, gemeinsam eine Wertstromidentifikation machen,
welchen Wertstrom wollen wir jetzt wirklich aus dem gesamten Unternehmen betreiben,
betrachten, den Wertstrom zu mappen, also einen Ablauf darzustellen,
die Verantwortlichkeiten für jeden Wertstromschritt zuzuweisen.
Wenn man das hat, dann hat man eine gute Übersicht.
Dann kann man anfangen, in Richtung zu analysieren, die Richtungen haben wir gerade auch schon genannt,
Maßnahmen abzuleiten für Verbesserungen, die umzusetzen und den neuen Ist-Zustand nach den Maßnahmen dann letztendlich zu visualisieren.
Und dann kann man letztendlich in den iterativen Prozess übergehen.
Das kann man dann regelmäßig wiederholen, alle halbe Jahre, alle Jahre, je nachdem, was man halt für ein System hat,
vielleicht sogar häufiger, vielleicht ist es sogar sinnvoll, das mit jeder Iteration, jedem Programminkrement,
jedem Sprint vielleicht auch zu machen und kontinuierlich diesen Verbesserungsprozess dann anzustoßen.
Dann hat man das für einen Wertstrom gemacht.
Dann geht es natürlich darin über, das in das gesamte Unternehmen zu betreiben.
Vielleicht auch in Wertströme zu klassifizieren.
Entwicklungswertströme sind häufig von operativen Wertströmen ein bisschen anders zugewiesen.
Es gibt vielleicht sogar sowas wie ein Wertstromnetz durch das gesamte Unternehmen,
das sich im Wertstrom aufspaltet, in verschiedenen Richtungen wirkt,
dass man vielleicht einen Wertstrom hat, der aus zwei Zulieferern zusammenfließt
und so einen kontinuierlichen Entwicklungsprozess hat.
Und wenn man das für das ganze Unternehmen schafft, kann man dann natürlich auch andere Konzepte mit einfließen lassen.
Zum Beispiel auch Teamstrukturen mit zu hinterlegen, also auch Congress Law mit im Hintergrund zu haben,
organisatorische Strukturen letztendlich anzupassen.
Das geht dann eigentlich zwei, drei Stufen weiter.
Ich finde es immer ganz sinnvoll und hilfreich, verschiedene Tools an der Stelle auch zu erwähnen, die man nutzen kann.
Virtuelle Whiteboards hatten wir vorhin erwähnt, Post-its und physische Sichten.
Ist letztendlich hilfreich auch zur Dokumentation.
Es gibt natürlich auch spezialisierte Werkzeuge, die dann aus Lean-IT-Sicht mitwirken und hilfreich sind,
wenn man das über ein gesamtes großes Unternehmen hinweg tun möchte.
Passt die Zusammenfassung?
Hast du noch Themenpunkte, die ich gerade vielleicht übersehen habe?
Nee, alles prima.
Gut, dann haben wir es, glaube ich, geschafft, oder?
Wie seht ihr das?
Ja, ich denke, wir haben es soweit geschafft.
Wenn Dirk noch was dazu sagen will und sich dann auch nicht mehr stumm darstellt,
können wir gerne auch.
Dann können wir auch an der Stelle die letzten Worte einläuten.
Möchtest du anfangen, Dirk, und zu dem Thema die letzten Worte aus deiner Sicht mit uns teilen.
Was sagst du?
Also, ich fand das wieder cool, unser Gespräch hier.
Ich hoffe, dass es auch bei den Teilnehmenden, bei den Zuhörern so ankommt.
Wir haben ja doch die eine oder andere Rückmeldung, dass wir, zumindest bei denen, die sich bei uns melden,
uns als locker einschätzen, dass sie die Gespräche mögen.
Und es war wieder mal ein schönes Gespräch zu dritt zu einem Thema.
Und insofern, mir hat es Spaß gemacht.
Und es kommen keine letzten Worte mehr, weil ich möchte ja noch ein bisschen länger in meinem Leben was erzählen.
Aber insofern, vielen Dank euch beiden.
Ja, vielen Dank auch dir, Dirk.
Und ich muss gestehen, ich habe dein Buch noch gar nicht gelesen.
Das muss ich dringend mal beheben.
Das hat mir das Gespräch jetzt gerade einen neuen Schwung gegeben,
um mich noch mal ein bisschen mehr mit diesem ganzen…
mit diesem Thema Wertströme noch mal auseinanderzusetzen,
weil es einfach wahnsinnig spannend und wichtig ist.
Insofern, es war eine ganz tolle Folge.
Wir haben sie auch versehentlich ja jetzt noch zu einer Doppelfolge ausgebaut.
War gar nicht so gedacht, aber es gibt einfach so viel zu erzählen.
Ja, zum Thema wertvoll, dem Buch, bei dem auch Dirk Mitautor ist.
Habt ihr da schon das Hörbuch in Vorbereitung oder vielleicht schon veröffentlicht?
Das habe ich noch gar nicht gesehen.
Also, wir sind jetzt dabei, ich sage mal,
über eine Simulation zu, wir planen, wir planen eine Simulation.
Dann gibt es eventuell eine englische Übersetzung.
Wir haben auch schon Rückmeldungen aus der ganzen Welt.
Das klingt jetzt ein bisschen mehr, als es wirklich ist, aber wir haben das vorgestellt,
dass auch an anderen Ecken der Welt man auf dieses Buch aufmerksam geworden ist
und englischsprachige Menschen gesagt haben, übersetzt das doch.
Also, insofern, wir haben erst mal genug zu tun und es wird uns nicht langweilig,
mit einer wertvollen,
Value-Stream-Story.
Also, Hörbuch ist erst mal nicht im Plan, habe ich das richtig verstanden?
Es ist in der Priorität nicht ganz oben.
Okay, schade, dass nicht meine Priorität zählt.
Ja, guti.
Ja, ansonsten, keine Ahnung, was gibt es noch zu sagen?
Ich hatte noch zwei, drei Gedanken in der Vorbereitung.
Kann man ja vielleicht, wenn Zuhörer von uns noch Interesse haben, auch gerne vertiefen,
dass man halt überlegen kann, wenn man über Value-Stream-Management nachdenkt,
die Identifikation von Wertströmen kann man mit guten Workshops unterstützen.
Das Mapping haben wir ja gut beschrieben, auch sehr detailliert jetzt in der zweiten Folge.
Wertstrom-Design kann man natürlich nicht nur die Maßnahmen, die wir halt haben,
sondern halt auch da in die Tiefe gehen, können wir gerne auch unterstützen.
Und aus meiner Sicht ist es auch ganz hilfreich, so ein bisschen zu überlegen, zu separieren
zwischen der Flotte und der Wertströmung.
Also zwischen der Flow-Organisation und der operativen Organisation, also unterschiedliche
Wertstrom-Arten im Unternehmen auch voneinander zu trennen.
Realisierung gegenüber dem Flow, unterschiedliche Metriken.
Gibt es auf jeden Fall viel Theorie, viel auch Praxiserfahrung bei uns im Team.
Und wer da Unterstützung haben möchte, wer vielleicht einfach auch von der Erfahrung,
die wir bei uns im Team haben,
bei anderen Kunden gemacht haben, profitieren möchte, kann natürlich auch gerne auf uns zukommen.
So viel von mir, so viel von uns allen, weiß ich nicht.
Vielen Dank, hat mir auch wieder Spaß gemacht.
Ich freue mich auf unsere nächste Folge.
So ist es. Also vielen Dank, Jungs.
Ich wünsche euch einen schönen Abend.
Bis dann. Tschüssi.
Ciao.
Ciao.

Folge 67: Dierk, Falko und Luca zu Wertstrommanagement (1/2)

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

In dieser Podcast-Episode wird das Thema Wertstrommanagement in der IT tiefgehend erörtert. Die Moderatoren, erfahrene DevOps-Trainer und Coaches, beleuchten die Bedeutung und Anwendung von Wertstrommanagement für die Optimierung von Produktions-, Material- und Informationsflüssen in IT-Organisationen. Sie diskutieren die Unterschiede zu traditionellem Prozessmanagement, die Relevanz von Metriken und die Bedeutung der Kundenperspektive. Am Ende der Episode wird angekündigt, dass ein zweiter Teil folgen wird, der sich konkreter mit der praktischen Umsetzung von Wertstromanalysen beschäftigen soll.

Inhalt

  • Einführung in das Thema Wertstrommanagement
  • Unterschied zwischen Wertströmen und traditionellem Prozessmanagement
  • Bedeutung von Kundenperspektive im Wertstrommanagement
  • Diskussion über die Relevanz von Metriken im Wertstrommanagement
  • Der Einfluss von Wertstrommanagement auf IT-Organisationen
  • Ankündigung eines zweiten Teils der Diskussion mit Fokus auf praktische Anwendung

Shownotes

Dierks Roman zu Wertstrommanagement

Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)

Hallo und herzlich willkommen zu einer neuen Folge des Podcasts
DevOps auf die Ohren und ins Hirn. Gestaltet und produziert von Luca Ingianni, Dierk Söllner und Falko Werner.
Wir sind DevOps-Trainer und Coaches mit langjähriger Erfahrung.
DevOps umfasst für uns kulturelle, organisatorische und technische Aspekte.
Heute freuen wir uns auf das Thema Wertstrommanagement.
Und zu Gast haben wir…
Ta-da-da-da! Niemanden!
Heute habt ihr eine Folge mit uns dreien.
Wir haben uns dieses Thema mal angenommen, dass wir drei darüber sprechen.
Mein Name ist Dierk Söllner.
Ich habe ja die letzten Folgen mit Abwesenheit geglänzt,
weil wir uns einfach auch besprochen haben, dass wir nicht mit drei Moderatoren,
nicht mit drei Gastgebern und einem Gast in eine Long-Shield begeben.
Also kurzum, heute sind nur wir drei dabei.
Alles klar.
Ja.
In unserem Podcast haben wir…
In unserem Podcast haben wir die Tradition, all unsere Gäste nach ihrer persönlichen Definition von DevOps zu fragen.
Und da wir heute unsere eigenen Gäste sind und um das Ganze etwas spannender zu machen,
außerdem haben wir unsere Definition ja bereits auch mehrfach in den vergangenen Folgen genannt und erklärt.
Lasst uns das Ganze mal auf maximal drei Worte beschränken.
Also, Dirk, wie lautet deine Definition von DevOps in drei Worten?
Ja, das könnte ich so tun, das müsste ich überlegen.
Die Frage habe ich ja erwartet.
Ich sage mal, Philosophie hochperformanter IT-Organisationen.
Darf ich es auch noch erklären oder reicht es nur mit diesen drei Worten?
Das Ziel war es, in drei Worten kurz und knackig zu halten.
Erklären können wir es vielleicht, wenn wir es in der Runde nochmal ein wenig hinterfragen wollen.
Wenn wir es zum Thema vielleicht auch in Beziehung setzen wollen.
Luca, wie sieht es bei dir aus?
Was ist deine Definition von DevOps in drei Worten?
Naja, jemand hatte mir da in den Mund gelegt, Wertschleifen.
Und ich setze da jetzt aber einen drauf.
Ich sage, Wertschleifen, nicht Wertströme.
Falco, jetzt müssen wir dich fragen, was denn deine drei Worte sind zum Thema DevOps.
Meine DevOps-Definition in drei Worten lautet,
Wird digitale Transformation kundenfokussiert?
So, für die geneigten Zuhörer, die jetzt noch nicht ganz schlau geworden sind,
ihr dürft gerne die alten Folgen anhören.
Da haben wir ganz viele tolle Definitionen von DevOps.
Und wenn Falco uns oder mich in diesem Fall nicht auf drei Worte begrenzt hätte,
dann hätte ich noch eine Definition aus einer der ersten Folgen genannt,
nämlich nachhaltige Geschwindigkeit.
Ich glaube, das war die Folge 4.
4 oder 5, also das ist ja schon Jahre her.
Der Podcast hat ja auch schon einige Jahre auf dem Buckel.
Und das fand ich eine ganz tolle Definition.
Also nachhaltige Geschwindigkeit haben wir immer noch in unseren DevOps-Folien
und Schulungsunterlagen getrennt.
Also kurzum, das wäre noch eine Ergänzung dazu.
Aber wir haben ja heute nicht DevOps, wir haben heute ja Value Stream Management.
Und wenn wir so ein Thema haben, dann ist ja auch immer die Frage,
was steckt dahinter?
Die, die von euch, die jetzt schon ein bisschen,
dabei geblieben sind, die müssen ja irgendwie ein Interesse
im Value Stream Management haben.
Also haben sie vielleicht eine ungefähre Folge,
eine ungefähre Vorstellung von dem, was da hinter steckt.
Und ich fange mal an mit der Definition von Wertstrommanagement
aus unseren Schulungsunterlagen.
Wir haben ja eine Schulung, zwei Tage zum Thema Wertstrommanagement.
Und uns wird heute bestimmt noch das eine oder andere Mal
auf Value Stream rausrutschen.
Das wäre die englische Übersetzung dazu.
Das können wir auch nochmal diskutieren.
Wir fangen mal an mit Wertstrommanagement.
Und das ist für uns.
Für uns ein betriebswirtschaftlicher Ansatz,
um den Produktions-, den Material- und den Informationsfluss zu optimieren
und eine Organisation konsequent an der Wertgenerierung
für den Kunden auszurichten.
Und wenn man sich das anschaut,
ich denke, der eine oder andere von euch wird stolpern
über Produktionsfluss oder Materialfluss.
Das soll aus unserer Sicht quasi der übergreifende Ansatz sein.
Das ist ja ein übergreifender Ansatz.
Und wir wollen heute auch ein bisschen darüber sprechen,
was steckt denn dahinter?
Was steckt in Value Stream Management?
Genau.
Und jetzt haben wir viel über Management
und Management von Wertströmen, Value Streams gesprochen.
Für mich ist erstmal wichtig zu klären,
was überhaupt ein Wertstrom ist.
Warum reden wir dann über Wertströme?
Warum ist das wichtig?
Und zum Verständnis,
wir sehen ein Wertstrom als eine Sequenz,
eine Aneinanderreihung von Aktivitäten,
in einem Team oder einer Organisation,
die es möglich macht,
Wert für einen Kunden oder für Stakeholder im Allgemeinen zu generieren
und so auf Kundenwünsche, Kundenanforderungen und Bedürfnisse zu reagieren.
Jetzt könnte man das Ganze noch ein Stück weiter treiben
und das Thema Wert noch ein Stück hinterfragen.
Das ist, glaube ich, eins von den Steckenpferden von Luca,
wenn er schon sagt, Wert schleifen.
Magst du dazu was sagen?
Na ja, Wert ist eben genau das,
was unsere Kunden, unsere Nutzer, unsere Stakeholder erzielen wollen.
Es ist keine Aktivität, es ist kein Produkt,
es sind all diese Dinge nicht,
sondern es ist wirklich das,
um es mit Helmut Kohl zu sagen, was hinten rauskommt.
Da finde ich es immer interessant,
was der CEO von Black & Decker mir in Feldsein Name gesagt hat.
Man könnte glauben, dass wir den Kunden Bohrer verkaufen,
denn immerhin stellen wir Bohrer her.
Aber wer das glaubt, der hat leider Unrecht,
denn was wir den Kunden verkaufen, ist ein Loch in der Wand.
Der Bohrer ist vollkommen uninteressant.
Keiner will einen Bohrer haben.
Die Leute wollen ein Loch in der Wand.
Und das ist, glaube ich, die Perspektive, die man einnehmen muss,
wenn man über Wert nachdenkt.
Was ist Mittel und was ist Zweck?
Und nicht das eine versehentlich mit dem anderen.
Ja, und dann vielleicht auch den Ende-zu-Ende-Gedanken
noch ein Stück zu verfolgen.
Das Loch in der Wand ist meiner Meinung nach
auch nur ein Schritt in der Mitte,
weil selten möchte man echt Löcher in der Wand haben,
sondern üblicherweise Mittel und Wege finden,
zum Beispiel um Bilder anzubringen
oder um Strom- oder Wasserleitungen durch Wände zu verlegen
oder andere Gründe, die dahinter stecken.
Also auch da aus meiner Sicht noch einen Schritt weiter
wirklich zu schauen,
was der Kunde will
und nicht nur den einen Schritt von Bohrer zum Loch in der Wand zu gehen.
Ich finde das ganz toll, dass du das gesagt hast, Falco.
Und auf die Gefahr hin,
dass ich jetzt vielleicht einen Schritt zu weit nach vorne rase schon.
Das ist auch etwas, was man, glaube ich,
wenn man Wertströme sich überlegt,
wenn man die mappt und so,
dass man sich dessen immer bewusst sein muss.
Es gibt ganz verschiedene Perspektiven
und alle haben ein gewisses Maß an Gültigkeit.
Es gibt nicht den einen amtlichen Wertstrom.
Das muss ich auch mal an der Stelle sagen.
Sondern ein Wertstrom ist ja nur ein Modell.
Und ich glaube, Einstein hat gesagt,
alle Modelle sind falsch, aber manche sind nützlich.
Insofern ein Modell, das dir dabei hilft,
zu verstehen, was du tust,
beziehungsweise was du tun solltest,
das ist nützlich.
Wo setzt man dann dieses Modell Wertstrom sinnvollerweise ein?
Das klingt nach einer Frage für Dirk.
Ja, der Dirk wollte jetzt erst noch mal auf das Thema Value eingehen.
Also, ich stelle die Frage mal zurück
oder stell du die Frage mal zurück.
Ich wollte auf das Thema Wert eingehen,
weil was ich auch noch interessant finde oder wichtig finde,
ist, wenn wir über Wert sprechen,
den wir erzeugen mit einem Wertstrom,
mit einem Wertströmen,
dann sind das unterschiedliche Werte, die wir erzeugen.
Also, wir haben ja gesagt,
unsere Sichtweise ist,
dass es ein betriebswirtschaftlicher Ansatz ist.
Aber es geht aus meiner Sicht,
wenn wir über Value sprechen, auch über andere Dinge.
Also zum Beispiel den Value,
den wir auch vielleicht für den Mitarbeiter erzeugen,
den Value, den wir für Lieferanten oder von Lieferanten bekommen.
Es geht darum, dass wir,
wie das der Black-and-Decker-CEO gesagt hat,
dass wir mehr machen als nur Output.
Wir reden also auch über Outcome.
Aber der Wert ist eben etwas,
was ein bisschen, ich finde, auch weiter gefasst ist.
Wir könnten auch überlegen,
ob nicht auch Nachhaltigkeit
oder soziales Engagement mit reinspielt.
Also rein eine Sichtweise,
eine Sichtweise,
wir müssen die Wertströme optimieren,
um möglichst viel Geld zu machen,
um Deckungsbeitrag zu erhöhen.
Das ist ein Wert.
Das kann ein Wert sein.
Es kann aber auch sein,
dass man einen Wert anders bezeichnet.
Also dieser Begriff Wert ist für mich total weit gefasst.
Sehr, sehr vielfältig.
Das wollte ich noch ergänzen zu der Sicht auf Wert.
Das bringt mich jetzt wieder zu einem anderen spannenden Punkt,
der mir da gerade eingefallen ist,
während du geredet hast, Dirk.
Wenn ich nämlich mich zurück erinnere
an Taichi Ohno,
der bei Toyota viele dieser Techniken und Überlegungen,
wie soll ich sagen, ins Leben gerufen hat.
Der hat ganz ausdrücklich gesagt,
Wertstromanalyse heißt für uns,
den Ablauf zu untersuchen zwischen
Kunde erteilt einen Auftrag für ein Auto
und Kunde bezahlt für das Auto.
Das war für ihn der Wertstrom.
Also er hat das ganz klar auf Kohle gemünzt.
Stopp.
Auf Kunde gemünzt.
Stopp.
Widerspruch.
Er hat es nicht nur auf Kunde gemünzt,
er hat es auch auf die Mitarbeiter gemünzt,
weil er schon darauf hingewiesen hat.
Vielleicht habe ich da ein unglückliches Wort verwendet.
Ich habe nämlich gesagt Kohle, Geld.
Ja, ja, aber jetzt hast du gesagt,
wenn du dich an den Herrn Ohno erinnerst,
ich hoffe, dass du nicht so alt bist,
dass du ihn noch persönlich erlebt hast an der Stelle.
Aber ich habe das Buch nicht gelesen,
das muss ich hier zugestehen,
aber ich habe mich damit beschäftigt.
Deswegen weiß ich, dass es eben auch nicht nur darum ging,
den Wert für den Kunden zu haben,
sondern auch auf die Mitarbeiter zu achten,
die in diesem Wertstrom agieren.
Also das vielleicht als kleine Ergänzung.
Ansonsten ist das okay für mich.
Okay.
Also so doll alt muss man nicht sein,
um ihn theoretisch noch persönlich kennengelernt zu haben,
da er bis 1990 sein Leben gefristet hat.
Aber persönlich habe ich ihn nicht kennengelernt.
Wie sieht es bei euch aus?
Naja, auch nicht.
Auch nicht.
Gut, dann hatten wir gerade die Frage zurückgestellt,
die ich dann jetzt einfach wieder vorhole.
Und zwar lautete die,
das Modell des Wertstroms zum Nutzen für irgendwas.
Wo habt ihr denn gute Erfahrungen gemacht
bei der Nutzung dieses Modells von Wertströmen?
Die Frage hast du mir ja eben gestellt.
Und dann werde ich jetzt auch nochmal die Chance ergreifen,
zu sagen, warum ich dieses Thema so interessant finde.
Nun kommen wir alle drei ja aus der IT-Welt.
Und die IT-Welt lebt ja davon,
wir auch, Methoden und Frameworks zu kaufen,
zu trainieren, anzuwenden.
Und das ist für mich etwas,
wo ich eigentlich sozusagen so einen übergreifenden Ansatz sehe.
Also wir reden hier nicht darüber,
dass irgendein Framework da ist,
was wir anwenden.
Also was wir sozusagen in der IT irgendwie fest anwenden.
Für mich ist das eine Art Sichtweise.
Also ich schaue mir meine Wertströme an.
Ich organisiere mich anhand von Wertströmen.
Und das ist für mich eben eher so eine,
es kann man auch Philosophie sagen,
aber es ist auf jeden Fall nicht ein Framework,
was ich sehen würde im Vergleich zu ITIL oder DevOps
oder Scrum oder anderen Dingen.
Für mich ist es eben ein Ansatz,
ein Unternehmen,
ein Unternehmen zu gestalten.
Und das ist das,
was ich einfach interessant finde an diesem Begriff,
an diesem Modell.
Ja, vielleicht müssen wir an der Stelle
dann auch tatsächlich noch mal
das so ein bisschen ausdifferenzieren und sagen,
es gibt einerseits das,
was du gerade angesprochen hast,
nämlich das Konzept,
vielleicht sogar die Philosophie eines Wertstromes,
das man sich zu eigen machen kann,
das man nutzen kann,
um über Prozesse und ihre Möglichkeiten
und Verbesserungen nachzudenken.
Und dann ist man eigentlich beim Wertstrommanagement gelandet
als eine Konsequenz,
sagen wir mal,
aus dieser Wertstromperspektive.
Sprich, sich gezielt und bewusst darüber Gedanken zu machen,
was sehe ich denn hier vor mir
in Form eines Wertstromes
und wo erkenne ich da Möglichkeiten,
etwas zu verändern, etwas zu verbessern.
Und dabei, um das jetzt auch noch zu sagen,
gibt es Techniken wie zum Beispiel
Value Stream Mapping,
die einem dabei helfen sollen,
zu visualisieren und systematisch Prozesse zu analysieren,
einen Ist-Zustand zu erfassen
und wie gesagt daraus dann
Verbesserungsprozentiale abzuleiten.
Und das finde ich ja genau das Coole,
das, was du gerade auch gesagt hast.
Ich komme nicht mit einem festgeschriebenen Framework,
mit einem festgeschriebenen Ansatz und sage,
das müsst ihr jetzt so machen
oder das solltet ihr so machen,
sondern ich komme mit dem Ansatz,
den Ist-Zustand mir anzuschauen.
Ich analysiere den Ist-Zustand
und das kann ich auf einer ganz abstrakten Ebene machen,
also ziemlich weit oben in einem Unternehmen.
Ich kann es aber auch total detailliert
auf einer tieferen Ebene machen.
Aber für mich ist es einfach super interessant,
immer zu sagen, es gibt einen Ist-Zustand
und den analysiere ich, den mappe ich,
wie du es gerade gesagt hast,
mit einer bestimmten Technik.
Also ich fange da an, wo das Unternehmen gerade ist.
Das finde ich so interessant.
Ja, nichtsdestotrotz ist es ja Teil von vielen Frameworks.
Wenn ich da jetzt an so einen großen Staubsauger
von Best Practices wie SAFE denke
oder an DevOps,
wo wir es in den Grundlagenschulungen
auch immer wieder definiert
und teilweise auch genutzt haben,
immer wieder tauschen,
immer wieder taucht das Thema auf.
Und wenn man sich die Historie mal anschaut,
kommt es ja, wie wir es gerade gesagt haben,
auch aus dem Lean-Ansatz, Lean-Management,
Toyota-Produktionssystem oder den ganzen anderen
darauf aufbauenden Gedanken und Sammlungen.
Und wir beziehen es aktuell aus unserer Sicht
natürlich mit unserem Podcast
DevOps auf die Ohren und ins Hirn
ja auch auf DevOps und die IT-Welt.
Und da finde ich eine Beschreibung,
die das Value-Stream-Management-Konsortium gemacht hat.
Wo kommt denn DevOps her?
Wo taucht es auf?
Aber genauso auch, wo ist denn der Bezug
zu Wertstrommanagement?
Und dass man sagt, okay,
man hat diese Projektdenkweise,
die dann über die Zeit vom Wasserfall,
über Scrum, Extreme Programming,
andere agile Frameworks,
Safe, Less und anderes
auch in Richtung große Unternehmen skaliert reinpasst.
Und man hat die Flow-Organisation,
den operativen Wertstrom,
die Produktionsprozesse,
die Dinge, die halt auch die längere Historie haben,
wie bei Toyota, wo man sagt,
okay, von der Bewegungsstudie,
Zeitaufnahme, Zeitreihenaufnahmen und ähnliches
über Lean und Kanban in der Produktion,
wo dann das Wertstrommanagement aufgetaucht ist.
Aber auch,
Lean IT,
Application Lifecycle Management,
agiles System administrieren,
agile IT Service Management Prozesse,
wo jetzt auch wieder das Thema
Wertstrommanagement auftaucht.
Es kommt also wieder,
also ist die Frage,
warum kommt es denn wieder?
Warum ist es jetzt gerade aktuell?
Warum ist es genauso
in den betriebswirtschaftlichen Sichten
in Produktionssystemen?
Relevant und aktuell,
aber auch in der IT-Welt
ein aktuell relevantes Thema.
Wie seht ihr das?
Da kann ich vielleicht darauf antworten
mit einem Schwank aus meiner Jugend.
Ich bin gespannt.
Genau.
Ich glaube,
du kennst die Geschichte auch schon.
Nämlich,
ich habe ja meine berufliche Laufbahn begonnen als Tester.
Und nach wie vor mag ich testen wahnsinnig gern.
Es ist unter allen Sorgen,
unter allen Softwareentwicklungsaktivitäten,
die, die mir am meisten Spaß macht.
Und als ich irgendwann mal
den Gedanken gefasst habe,
mich selbstständig zu machen,
habe ich mir gedacht,
ja, weißt du was,
dann wirst du irgendwie
selbstständiger Softwarequalität,
dann wirst du irgendwie Softwaretester.
Das kannst du, das magst du gerne, passt.
Bis ich irgendwann mal draufgekommen bin,
das geht gar nicht.
Ich kann nicht am Ende einer Entwicklung
irgendwie auftauchen
und dann eine Qualität hineinzaubern,
und das ist das,
damals habe ich von dem Begriff Wertstrom
und so noch nie was gehört gehabt.
Aber das ist das,
was mich schlussendlich auch zu DevOps geführt hat,
dass ich gesagt habe,
ich muss diese komplette Kette
irgendwie in den Blick bekommen,
damit ich am Ende sicher sein kann,
ein zufriedenstellendes,
ein wertvolles Ergebnis zu liefern.
Und ich glaube,
das ist die Antwort auf die Frage, Dirk.
Ja.
Was ist denn die Aufgabe eines Testers?
Ja,
Bugreports schreiben, ne?
Ja, Fehler finden.
Und da sage ich, nein, das ist es genau nicht,
weil es ist ja nicht deine Aufgabe als Tester,
Fehler zu finden,
sondern im Idealfall findest du keinen Fehler,
weil keiner drin ist.
Ja, andererseits,
als altgehender Tester,
lass mir sagen,
es ist wie mit dem Staubsauger,
es macht nur Spaß,
wenn es im Schlauch rasselt.
Okay, gut, alles klar.
Deswegen bin ich auch vielleicht kein Tester geworden.
Aber vielleicht,
um jetzt wieder weg vom Staubsauger
und von einem anderen Schwank aus deiner Jugend zu kommen,
ich glaube,
Volker wollte so ein bisschen auch in die Richtung,
wozu kann man das überhaupt sinnvoll verwenden?
Warum machen wir das überhaupt?
Und da finde ich auch einen ganz wichtigen Punkt.
Also abgesehen davon,
dass man natürlich mit so einer,
mit so einem Value Stream Mapping,
also mit der Transparenz machen des Wertstroms,
kann man natürlich sehr gut kommunizieren und optimieren.
Was ich aber sehr interessant finde,
ist,
dass genau über das Thema Lean Management
auch eine ganze Reihe,
auch eine ganze Reihe von Metriken mitkommt.
Und aus meiner persönlichen Sicht,
also ich bin überzeugter Angelist,
aber aus meiner persönlichen Sicht
gibt es zu wenig Messgrößen in Scrum jetzt zum Beispiel.
Und das finde ich einfach interessant,
dass ein paar Metriken mitkommen,
wonach ich eben auch optimieren kann.
Also ich kann etwas messen
und kann einen,
habe eine sachliche Grundlage über die Diskussion.
Es geht ja nicht darum,
dass ich mit diesen Messen Menschen,
ja,
ich sozusagen,
also Menschen loswerden will,
sondern ich möchte einen Ablauf messen,
um zu gucken,
ist das denn gut oder ist das nicht gut?
Und dieses Messen sollte,
diese Metriken sollten sozusagen auch transparent nachvollziehbar sein.
Und deswegen finde ich es wichtig oder interessant
beim Wertstrommanagement,
dass Metriken mitgeliefert werden,
dass Metriken mitgeliefert werden,
um etwas zu messen.
Wie gesagt,
ich will niemanden kontrollieren,
also keine Personenkontrolle und so etwas.
Aber ich möchte versuchen,
aber ich möchte verlässliche,
ich möchte sachliche Grundlagen haben,
auf denen ich etwas messen und bewerten kann.
Welche Metriken würdest du denn empfehlen?
Was sind denn die Metriken aus deiner Sicht,
die am hilfreichsten sind?
Durchlaufzeit zum Beispiel.
Wie lange braucht etwas,
um durchzulaufen?
Also eine,
wenn ich jetzt an die Autos denke,
dann ist das ein Auto,
weil ein Auto bringt erst dann Wert,
wie Luca ja vorhin schon gesagt hat,
wenn der Kunde es hat und bezahlt hat.
Und wenn ich das übertrage auf die IT,
sind das einfach Aufgaben,
die so schnell wie möglich durchlaufen sollten.
Und wenn sie nicht so schnell durchlaufen,
dann schaffen sie keinen Wert,
Wert Strom.
Und dann sollte ich dafür sorgen,
dass sie so schnell wie möglich durchlaufen.
Also dann Blockaden beseitigen,
Hindernisse beseitigen zum Beispiel.
Aber Luca,
du kennst bestimmt auch noch eine Metrik, oder?
Durchlaufzeit ist auf jeden Fall spannend.
Spannend ist auch die Frage nach der,
wie nennt sich das dann,
nach der Zykluszeiteffizienz.
Das heißt,
von der Durchlaufzeit,
ich sage jetzt mal in Kalenderzeit,
und der tatsächlich investierten Arbeitszeit.
Da kommen nämlich zum Teil ganz,
ganz furchtbar enttäuschende Effizienzen raus,
von unterhalb von einem Prozent.
Mit anderen Worten,
man arbeitet konkret an einer gegebenen Aufgabe
eine vergleichsweise kurze Zeitspanne,
ich sage jetzt mal zwei Stunden.
Aber dieser Auftrag braucht irgendwie zwei Monate,
um unseren Prozess zu durchlaufen.
Und diese Effizienzen,
von unterhalb einem Prozent,
hören sich erstmal völlig abstrus
und aus der Luft gegriffen an.
Aber jeder von uns, glaube ich,
kennt aus seiner persönlichen Erfahrung
solche Prozesse.
Und es ist natürlich jedem leicht ersichtlich,
dass das zumindest wahnsinnig frustrierend ist,
aber zum Teil eben auch ein wirkliches,
ernsthaftes geschäftliches Problem darstellen kann.
Und allein sich solche Umstände bewusst zu machen
und zu sagen,
was passiert denn hier,
was für ein Missverhältnis existiert denn hier,
kann häufig ein sehr heilsamer Anstoß sein,
zu sagen,
irgendwas müssen wir doch machen können.
Und wenn wir es nur von zwei Monaten Wartezeit
auf anderthalb Monate reduzieren,
dann ist zwar die Prozentzahl nicht besonders größer geworden,
aber de facto wartet der Kunde schon mal zwei Wochen kürzer.
Das ist doch auch schon mal schön.
Und vor allen Dingen,
was ich daran interessant finde an deinem Beispiel ist,
normalerweise würde man ja diese zwei Stunden Tester zum Beispiel,
dass man sagt, Tester, zwei Stunden sind zu lang,
wir müssen schneller werden,
teste mal in einer Stunde.
Das heißt, man gewinnt mit einem vergleichsweise hohen,
vergleichsweise hohen Einsatz,
nämlich den Druck auf den Tester auszuüben,
eine Stunde.
Wenn man aber diese Wartezeit,
diese Liegezeit verkürzen würde,
was vielleicht mit einer Prozessoptimierung
oder Wertstromoptimierung viel einfacher wäre,
gewinnt man zwei Monate.
Also an den richtigen Stellen.
Und das finde ich einfach auch,
das ist wirklich das,
was ich eben meinte mit dem Beispiel.
Es geht darum, den Durchfluss eben zu optimieren
und das auch transparent zu machen.
Also insofern gutes Beispiel.
Da habe ich auch eine kleine Anekdote,
die ich mit einbringen will.
Und zwar der Aspekt,
den ein CIO mal gebracht hat.
Und zwar fokussiert euch auf das,
was Wert liefert.
Ihr Entwickler,
es wäre zwar schön,
wenn ihr schneller tippt,
aber das alleine,
nur schneller zu tippen,
liefert keine schnellere Wertschöpfung.
Ja, das stimmt.
Ja.
Ich würde gerne noch eine weitere Metrik ergänzen.
Ich bin ja ein Freund von Qualitätsmanagement
und von Qualität,
also von eingebauter Qualität.
Und da gibt es diese schöne Kennzahl
oder den schönen Ansatz
first time right.
Also mach es auf Anhieb richtig.
Und die Frage ist ja immer,
wie gehe ich damit um,
wenn mir jemand schlechte Qualität liefert
in meiner, ich sage mal Prozesskette.
Es kann ja auch ein Wertstrom sein.
Es ist ja im Prinzip erstmal das Gleiche.
Wie gehe ich damit um,
wenn ich am Ende der Kette,
also Luca wieder als Tester,
da sitze ich und der liefert mir schlechten Code.
Ja, was mache ich denn?
Und das finde ich einfach interessant,
zu gucken,
wie viele Ansätze haben wir gebraucht,
um es richtig hinzubekommen.
Also wenn ich jetzt first time right nehme,
mit dem Ziel,
es auf Anhieb richtig zu machen.
Und dass Luca eben als Tester
von hinten versuchen sollte,
die Qualität nach vorne zu bringen,
also shift left,
ist ja auch ein DevOps-Thema.
Das eben hinzubekommen
und das mit einer Kennzahl zu versehen,
wie oft mussten wir quasi zurückgehen
und wie oft haben wir es geschafft,
auf Anhieb einen richtigen Job zu machen,
finde ich interessant.
Und da kommt auch, glaube ich,
manchmal auch eine gewisse Problematik her.
Jetzt kommen wir auch zu der Frage,
vielleicht auch zu der Frage,
wann sollte man sich
um Baystream-Management kümmern
und was bedeutet das überhaupt?
Und das bedeutet für mich,
organisatorisch auch etwas zu verändern.
Denn ich muss ja,
ich nehme wieder Luca als Tester,
ich muss ja von hinten,
ich muss ja von hinten nach vorne gehen
und damit gehe ich eventuell über Bereichsgrenzen,
über Abteilungsgrenzen.
Ich gehe aus meinem Silo raus
in einen anderen Silo vielleicht rein.
Und das finde ich einfach auch super interessant,
wenn man das über ein Mapping transparent macht,
also mal aufzeigt, was da passiert,
diese zweieinhalb Monate Wartezeit.
Und wenn man dann dahin geht und sagt,
wie können wir das verändern?
Wie können wir da ein besseres Verhältnis hinbekommen?
Und auch,
haben wir denn was verändert?
Wenn ich jetzt zum Beispiel
wieder auf dein Beispiel von vorhin zurückgreife, Dirk,
und sage,
jetzt habe ich es irgendwie geschafft,
keine Ahnung,
meine Testabläufe zu optimieren
und anstelle von zwei Stunden
brauche ich jetzt für den Test
bloß noch eine Stunde.
Und dann schaue ich mir meine Durchlaufzeiten an
und stelle fest,
oder meine Zykluszeiteffizienz,
ja auch die Durchlaufzeit,
es hat sich genau gar nichts geändert.
Das ist völlig,
geht dem Rauschen unter.
Und jetzt weiß ich es wenigstens schwarz auf weiß,
auch wenn ich es natürlich nicht gerne höre,
aber dieser Ansatz führte zu nichts.
Da weiß ich jetzt Bescheid.
Zumindest für den Test.
Zumindest für den Kunden,
wenn man aus Kundensicht schaut.
Ich meine,
für die Entwickler vielleicht schon,
weil sie ein Stück ihrer Aufgaben automatisiert haben
oder weil sie jetzt schneller durch die Testsuite kommen,
weil sie vielleicht ein paar Tests auch eliminiert haben,
die nicht werthaltig waren,
aber für den Kunden halt nicht.
Ja gut,
aber ich sage es mal so,
wenn es für den Kunden was gebracht hat,
dann müsste es sich ja an irgendeiner Stelle bemerkbar machen.
Was heißt denn nicht,
dass ich insgesamt schneller
oder dass ich mehr Features in der gleichen Zeit auf den Markt bringe oder so,
auch wenn die Durchlaufzeit pro Feature immer noch unbefriedigend ist oder sowas.
Also wenn du tatsächlich was Positives bewirkt hast,
dann muss es ja an irgendeiner Stelle erkennbar werden.
Auch wenn man jetzt natürlich sagen kann,
ja, wir messen wahrscheinlich nicht alles.
Und so wie du sagst,
Falco, auch Entwicklerzufriedenheit ist ja ein ein lohnendes Ziel,
dass jemand sagt,
meine Arbeit macht mir mehr Spaß,
weil meine,
weil mein Prozess mir nicht auf den Senkel geht.
Also wann ist der richtige Zeitpunkt,
über Value Stream Management,
Wertstrommanagement Gedanken zu machen,
wenn wir bereit sind,
auch Veränderungen vorzunehmen?
Ja, also das ist ein guter Punkt.
Wenn man sowieso nicht in der Lage ist,
entweder sachlich oder gedanklich etwas zu verändern,
dann braucht man sich über Veränderungen keine Gedanken zu machen.
Das ist wahr.
Aber wenn ich auf dem Standpunkt stehe,
dass ich sage,
irgendwas muss ich doch besser machen können,
ich glaube,
dann bist du schon an der richtigen Stelle.
Und dann kann diese Wertstromperspektive
hilfreiche Impulse liefern.
Finde ich auch interessant,
weil damit wird für mich ja auch klar,
dass Wertstrommanagement,
auch wenn es so klingt wie betriebswirtschaftlicher Ansatz
und wir haben Kennzahlen,
es ist ein Mittel für Organisationsentwicklung,
für Transformation.
Und damit passt es natürlich auch sehr schön in das Thema DevOps mit rein.
Also wenn ich auch wieder auf den Titel unseres Podcasts schaue.
Also klingt ganz spröde,
Wertstrommanagement,
aber da steckt ganz viel,
ganz viel mit drin.
Und wie ihr sagtet,
es geht darum,
Veränderungen anzustoßen,
Veränderungen zu begleiten.
Und vielleicht auch da wieder,
was mir besonders gut daran gefällt,
ist vielleicht auch ein bisschen naiv.
Das können wir gleich nochmal diskutieren.
Wen nehme ich denn mit dazu?
Also wen beteilige ich denn?
Und das finde ich eben auch interessant.
Der erste Schritt sollte eigentlich sein.
Nein,
es ist nicht der erste Schritt.
Ihr dürft mich gleich korrigieren.
Ich sage jetzt mal,
es ist der erste Schritt,
die richtigen Menschen zusammenzubringen.
Nämlich die Menschen,
die in dem Wertstrom arbeiten.
Und das finde ich eben super interessant.
Nämlich nicht irgendwelche Berater oder Führungskräfte.
Die müssen auch mit dabei sein oder sollten auch mit dabei sein.
Aber die Menschen,
die in diesem Wertstrom arbeiten,
die diesen Wert erzeugen,
die mit dazu zu nehmen,
weil die wissen nämlich,
wo diese zweieinhalb Monate Testzeit herkommen.
Luca, der Tester am Ende der Nahrungskette hinten,
der sieht,
dass er immer nur Müll bekommt beispielsweise.
Und jetzt fragt ihn mal einer
und jetzt kann er berichten,
wie häufig er Dinge zurückgeben muss.
Ja, oder wie häufig dann auch,
das ist ja das klassische Leid des Testers,
dass die Sachen dann viel zu spät ankommen,
ganz kurz vorm Auslieferungstermin,
weil alle trödeln rum,
alle lassen sich Zeit.
Und der, der sich keine Zeit mehr lassen kann,
weil er am Ende von der Nahrungskette ist,
das ist dann halt der Tester.
Das habe ich so oft erlebt,
dass ich eigentlich offiziell ein Zeitfenster von,
ich weiß nicht,
zwei Wochen gehabt hätte,
um eine Lieferung in aller Ruhe zu testen
und bereit zu machen für die Auslieferung.
Ja, dann kam das Softwarepaket aber doch erst 18 Stunden
vor der Auslieferung bei Benja an.
Und dann waren sie irgendwie alle ganz enttäuscht,
dass ich das jetzt nicht in 18 Stunden
alles irgendwie durchbollere.
Hast du keine Testautomatisierung
in der Entwicklungszeit aufgebaut?
Oder wie?
Wieso ging das nicht?
Die Tests waren vollautomatisiert.
Aber das waren sprichwörtlich waschkorbweise Steuergeräte,
Automotive Steuergeräte.
Allein,
allein die alle anzustecken und abzustecken
dauert quasi diese 18 Stunden.
Ach so, physische Hardware in the Loop Tests.
Warum habt ihr da keine Virtualisierung vorgenommen?
Die war vorher schon.
Das war wirklich die Probe aufs Exempel.
Geht das Ding wirklich?
Das war cool,
wenn ich das jetzt mal so am Rande sagen darf.
Da gab es wirklich Racks,
da liefen auch wirklich Einspritzpumpen drin.
Also da haben dann wirklich die Einspritzpumpen drin gerattert.
Und wenn der seine Tests gefahren hat,
dann hast du auch gehört,
jetzt fährt er schneller,
dann rattern die schneller
und dann rattern sie wieder langsamer und so.
War schon,
war schon cool.
War schon cool, was die da gemacht haben.
Klingt wirklich cool.
Ja, das stimmt.
Genau.
Aber ich finde,
wir müssen noch mal einen kleinen Schritt zurückgehen,
bevor wir uns darüber unterhalten,
wer da alles dazukommen soll.
Weil ich finde,
wir haben das jetzt gerade so ein bisschen zu flapsig abgebügelt
mit dem,
wann ist denn der richtige Zeitpunkt
für so eine Wertstromanalyse,
für so ein Wertstrommapping.
Wann denn?
Wenn der Prozess noch gar nicht existiert,
wenn der schon längst existiert,
wenn der prototypisch existiert,
wenn die Firma,
keine Ahnung,
mehr als 50 Mitarbeiter hat.
Was sagt ihr denn?
Was sind denn so Paradebeispiele,
wo es vielleicht eine blöde Idee ist
oder wo es eine gute Idee ist?
Lass mal überlegen.
Also wir haben letztendlich eine Möglichkeit,
wenn wir über Wertstromdesign nachdenken,
auch zum Zeitpunkt,
wo man über neue Prozesse nachdenkt,
einen werthaltigen Prozess von Anfang an
zu designen.
Fände ich letztendlich sinnvoll,
wenn man das auch visualisiert
und das in Form von einer Wertstrommap letztendlich,
Value Stream Map,
auch als Diskussions- und Kommunikations-
und Designmedium nutzt.
Von daher,
vielleicht auch bevor ein Prozess am Laufen ist.
Häufig ist es gut,
wenn man Kommunikation zwischen Abteilungen
über Silo-Grenzen und anderes hinweg
aufbrechen will
und Ende-zu-Ende-Prozesse
vielleicht auch im Rahmen einer Transformation,
wenn man sowieso schon über Veränderungsprozesse nachdenkt,
dann gleich in der Form bringen will,
die dann auch von allen Beteiligten besprochen worden ist,
sodass auch jeder sich da wiederfindet,
dass auch jeder sieht,
was die anderen machen.
Dass man halt auch überlegen kann,
gibt es Prozesse, die Prozessschritte,
die in dem Wertstrom ablaufen,
die vielleicht gar keinen Kundennutzen
oder keinen Unternehmensnutzen haben,
die man vielleicht einfach,
wegen ihrer langen Warte- und Liegezeiten
irgendwo anfassen und optimieren muss,
sodass man eine Chance hat,
am Ende einen Prozess zu haben,
den man vielleicht auch im Ganzen
gut automatisieren kann.
Dass man halt auch an den Stellen
über Übergaben und anderes nachdenkt
und am Ende letztendlich dahin kommt,
die Durchlaufzeit
vielleicht von Monaten auf Minuten zu reduzieren,
weil man halt sagt,
okay, da sind so viele Dinge dabei,
wo man Wartezeiten reduzieren kann,
wo man letztendlich optimieren kann,
wie die Rücklauf- oder Durchlaufquoten
oder die Erfolgsquoten First-Time-Ride zu 100 Prozent
ist natürlich immer super,
wenn man das erreichen kann
und dazu ist es letztendlich hilfreich
und das passt auch gut zum DevOps-Gedanken.
Dieses Ende-zu-Ende-Fluss
von der Kundenanforderung bis zum Kundennutzen,
als durchgängigen Prozess zu verstehen
und ihn dann so weit zu bringen,
dass man einen möglichst hohen Automatisierungsgrad
und dadurch wenig Liegezeiten
und insofern dann auch eine kurze Durchlaufzeit generieren kann.
Das erinnert mich ganz stark an meine Doktorandenzeit
an der Uni Magdeburg im Lehrstuhl für Logistik.
Kommt auch spannend aus deiner Jugend, Falco.
Ja, genau, darum ging es halt.
Die Prozesse meist dann im produzierenden Gewerbe zu hinterfragen
und dann auch aufzunehmen, zu visualisieren
und dann so weit zu optimieren,
dass es möglichst einfach ist,
dann halt zum Beispiel Robotertechnik einzusetzen,
Fließbänder und so dann mit Automatisierung zu arbeiten,
aber eben auch an den Stellen, wo manuelle Arbeit
in Fertigungsgruppen,
in Fertigungszentren oder Ähnlichem organisiert ist,
dann so zu bringen,
dass sie halt zum Beispiel in einer Taktstraße,
in einem gemeinsamen Rhythmus,
gemeinsamen Takt entsprechend ablaufen können.
Das ist mich auch wieder so an Iterationen im agilen Arbeiten,
Scrum, Sprints oder Save-Iterationen und Programmingremente erinnert,
dass man da halt versucht, irgendwie einen gemeinsamen Rhythmus zu erreichen,
dann regelmäßig dann die Fortschritte zu integrieren,
und dann halt im nächsten Schritt wieder weiterzubringen,
sehe ich immer wieder Parallelen.
Ich finde das auch spannend, Falco,
dass du ja jetzt auf physische Produktionsprozesse
und sowas gegangen bist,
weil ich finde, da ist ein ganz starkes Argument drin
für Value-Stream-Mapping,
insbesondere in unserem IT-Kontext,
in unserem nicht-physischen Kontext,
weil diese Analysen da glaube ich noch viel wirkmächtiger sind,
gerade wenn ich dann Wertströme mal visualisiere
und wirklich in Gedanken abnehme,
in Gedanken abschreite.
Eine Produktionslinie,
die kann ich immer wirklich mit meinen eigenen zwei Füßen entlanglaufen,
und wenn da irgendwo 100 Paletten mit Getriebegehäusen stehen,
dann stehen da 100 Paletten mit Getriebegehäusen,
und jeder kann sehen, dass das blöd ist,
und dass die im Weg sind.
Aber 1000 Jira-Tickets schauen auch nicht anders aus als 10 Jira-Tickets.
Und insofern, um das einfach nochmal zu sagen,
es ist glaube ich ein noch viel mächtigeres Kommunikationsmedium,
Werkzeug, um überhaupt erstmal auf einen gemeinsamen Stand zu kommen,
um überhaupt sich eine gemeinsame Sprache zu erarbeiten,
eine gemeinsame Sicht zu erarbeiten.
Dirk, ich habe dich lange genug warten lassen.
Och, ich konnte nochmal ein bisschen sammeln
und meine Wörter nochmal in die richtige Reihenfolge bringen jetzt.
Vielleicht nochmal zurück zu der Frage.
Die Frage war ja,
kann man es im Prinzip auf der grünen Wiese auch anwenden?
Und meine erste Antwort wäre gewesen, nein.
Beziehungsweise wende ich es meistens an,
wenn schon etwas da ist,
also um Dinge zu analysieren.
Und ich bin jetzt durch Falkos Aussage,
er hat ja ganz viel über Prozesse gesprochen,
ich glaube Luca hat auch immer das Wort Prozesse genommen,
bin ich so ein bisschen an das Buch erinnert worden,
was ich gerade mit sechs anderen wunderbaren Menschen
zusammen geschrieben habe.
Ich erkläre das Buch ganz, ganz kurz.
Entschuldigt dieses Product Placement,
diese Sendung wird finanziert von das Buch.
Nein, Spaß beiseite.
Und ich erkläre auch gleich, warum ich auf dieses Buch gekommen bin.
Also, das Buch heißt,
das Buch heißt wertvoll, eine Value Stream Story.
Und dieses Buch besteht quasi aus zwei Teilen,
nämlich einem ersten Romanteil.
Und das war der erste Punkt, wo ich daran erinnert worden bin.
In diesem Roman nutzen wir quasi Wertstrommanagement,
wir nennen es im Roman, schreiben wir von Value Stream,
nutzen wir das, um anhand einer fiktiven Unternehmung,
Jakobsens Apfelsaftproduktion, nutzen wir Value Stream Management,
um das Unternehmen ein bisschen voranzubringen.
Also, da ist es im Prinzip schon so, dass man zwar Abläufe hat,
aber mit Value Stream Management zumindest in unseren fiktiven Unternehmen
einen neuen Ablauf designt.
Und das andere, der zweite Teil dieses Buches,
das sind zehn Fachbeiträge.
Und das ist der Punkt, wo ich darauf gestoßen bin.
Ein Fachbeitrag heißt, Value Streams sind ungleich Prozesse.
Also, es ist nicht so,
dass wir mit Value Stream Management jetzt ein wunderschönes neues Wort
für Prozessmanagement haben.
Da steckt schon ein bisschen was mit dahinter,
nämlich der Punkt, dass wir uns wirklich an den Wert orientieren,
dass wir uns an den Kunden orientieren.
Prozesse laufen ja ab und produzieren irgendetwas.
Und deswegen verweise ich gerne auf dieses Buch.
Wir packen bestimmt in die Shownotes auch einen Link rein,
dass man das Buch zumindest mal weiß, was dahintersteckt.
Man kann es auch kaufen.
Kleiner Hinweis, in Deutschland wird man von Fachbüchern nicht reich.
Also, wenn ich jetzt dafür Werbung mache,
ist das nicht so, dass ich davon reich werde.
Um das auch kurz zu erklären.
Also, für mich ist das einfach auch ein wichtiger Punkt.
Wertströme sind ungleich Prozesse.
Und man kann mit Wertströmen, denke ich,
auch auf der grünen Wiese anfangen.
Also, das ist das, was ich quasi eben im Rahmen eurer Erläuterung gelernt habe.
Ja, ich glaube, man kann es vielleicht ein bisschen verallgemeinern
und kann sagen, es gibt ein paar Naturwerte,
man kann sagen, es gibt ein paar natürliche Punkte,
wo sich Wertströme oder wo sich Wertstromanalysen anbieten,
weil sie einem schon fast so ein bisschen in den Schoß fallen.
Einer dieser Fälle ist, wenn man gerade anfängt,
sich über einen nagelneuen Ablauf Gedanken zu machen,
dann kann man ja direkt diese von dir eingangs zitierte
Wertstromperspektive einnehmen, Dirk.
Man kann sagen, okay, wenn ich es aus dieser Warte betrachte,
macht das denn alles Sinn, was ich mir jetzt gerade so einbilde?
Genauso auch, was der Falco vorhin gesagt hat,
wenn ich eine tiefgreifende Veränderung mache,
zum Beispiel, weil ich Automatisierung einführen möchte,
dann quasi als Nebenprodukt fällt mir da ja etwas raus,
das schaut schon aus wie eine Wertstromanalyse.
Dann muss ich ja zerlegen in verschiedene Schritte,
in Arbeitsergebnisse, die muss ich irgendwie, keine Ahnung,
hin und her transportieren, übertragen, transformieren und so fort.
Das heißt, es gibt so gewisse Punkte,
da kriege ich eine Wertstromanalyse eigentlich für lau.
Insofern, ich glaube, erstens, es ist immer eine gute Idee,
und zweitens, manchmal ist es eine besonders gute Idee.
Ja, es hat halt immer Vorteile,
je nachdem, wofür man letztendlich das Konzept nutzen will.
Wenn es halt nur darum geht, gemeinsames Verständnis zu erzeugen,
was aus meiner Sicht auch ein legitimes Mittel ist,
einfach Transparenz, Sichtbarkeit, Visualisierung zu nutzen,
um überhaupt zu erklären, was machen wir und wie läuft das,
was machen wir und wie läuft das ab?
Hat das an sich einen Wert, die Kommunikation, das Verständnis?
Dann kann man es natürlich in die Analyse gehen und Optimierungen vornehmen.
Man kann auch einfach an der Stelle aufhören und sagen,
wir verstehen jetzt, wie es geht, und das reicht uns fürs Erste.
Kann ja völlig okay sein.
Häufig geht man natürlich den weiteren Schritt, versucht zu optimieren,
wertschöpfende Tätigkeiten in den Vordergrund zu stellen,
und vielleicht Verschwendung zu eliminieren, Wartezeiten, Liegezeiten
und Ähnliches zu eliminieren.
Es kann hilfreich sein, um eine gemeinsame Sprache aufzubauen.
Also der eine spricht halt, keine Ahnung, vom Testen,
der andere spricht von Qualitätssicherung,
der nächste spricht halt von Kundenfreundlichkeit und gutem Produkt.
Letztendlich reden sie vielleicht alle von dem gleichen Schritt
in der Wertstromkette.
Insofern kann auch da es hilfreich sein,
zum Verständnisaufbau auch eine gemeinsame Sprache zu finden.
Und es ist natürlich ein hilfreiches Werkzeug,
um auch Arbeitsprozesse zu vergleichen.
Zum Beispiel habe ich in einem Unternehmen,
das IT-Servicemanagement macht,
virtuelle Maschinenserver in verschiedenen Rechenzentren hostet
und für Kunden auch zur Verfügung stellt.
Und da gibt es halt in den unterschiedlichen Standorten
unterschiedliche Arbeitsweisen.
Unterschiedliche Toolsets, die im Einsatz sind,
unterschiedliche Reihenfolgen,
teilweise sogar von Wertstromprozessen oder Wertstromsichten.
Und da kann auch eine Vereinheitlichung ein sinnvolles Ziel sein,
wenn man halt zwei Produktionsstraßen hat,
die ähnliche Ergebnisse liefern,
aber trotzdem unterschiedlich darin vorgehen.
Und wenn man versucht, dann halt vielleicht auch
eine Vereinheitlichung zu erreichen,
um das Ganze mehr gemeinsam zu optimieren
oder auch die Tool-Landschaft zu vereinheitlichen,
kann das hilfreiches Mittel und Medium sein,
eine Wertstromanalyse.
Ist die Wertstromanalyse,
Value-Stream-Mapping, der erste Schritt?
Muss man vorher noch an irgendwas anderes denken?
Welchen Wertstrom will ich denn genau angucken?
Ist ja vielleicht so ein Thema,
eine Frage, die man sich vielleicht vorher beantworten muss.
Ja, also erstmal die Frage, welchen Wertstrom?
Und ich habe ja vorhin gesagt,
ihr dürft mich gerne korrigieren.
Ihr habt es bis jetzt noch nicht gemacht,
wenn ihr euch erinnert,
so vor 10, 15 Minuten habe ich was erzählt von,
dass die richtigen Leute zusammenkommen,
also die, die im Wertstrom mitarbeiten.
Und davor finde ich noch einen ganz wichtigen Punkt.
Und Falco, du hast mich eben schon auf diesen Hinweis
von mir jetzt gebracht,
du hast von Kunden gesprochen und von gemeinsamer Sprache.
Das, was ich eben auch interessant finde, ist,
wenn man mit dieser Technik von dem Value-Stream-Mapping,
wenn man startet, ist eigentlich sozusagen der erste Schritt,
also der Schritt Null quasi, die Stimme des Kunden.
Ja, also sich zu überlegen, aha, ich will Wert schöpfen.
Ja, ist ja wunderschön.
Da muss ich ja jemanden haben, der bewerten kann,
ob das wertvoll ist, also ob das Wert für ihn generiert.
Und auch das, finde ich, ist ein Unterschied,
zumindest in der Sichtweise zu einem Prozessmanagement.
Also insofern, um das mal klar zu machen,
der erste Schritt ist, wenn man diese Frage generiert,
wenn man diese Frage geklärt hat, wir können etwas verändern,
wir wollen etwas verändern, dass man dann sagt,
okay, was ist die Stimme des Kunden?
Was will der Kunde von uns?
Und allein das ist auch schon mal häufig eine sehr hilfreiche
und wertvolle Aktivität, nämlich klar zu machen,
was will der Kunde von uns?
Und da ist man dann manchmal auch vielleicht gar nicht ehrlich
oder man weiß gar nicht, was der Kunde wirklich will.
Und auch das finde ich einen schönen Nebeneffekt.
Man macht sich mal wirklich Gedanken,
was liefern wir alle in einem Wertstrom,
einen Wert für einen Endkunden?
Also insofern, das ist vielleicht nochmal
der Vollständigkeit halber zu ergänzen.
Der erste Schritt ist, sich über den Wunsch,
über die Stimme des Kunden Gedanken zu machen.
Im Rahmen einer Wertstromanalyse, also Value-Stream-Mapping?
Oder noch davor?
Also für mich ist das, also man kann es natürlich vorher machen,
aber für mich ist es so,
Schritt oder Aktivität in der Value-Stream-Mapping,
also in der Analyse,
weil ich damit eben auch sicherstellen kann,
über welchen Wertstrom rede ich überhaupt?
Also ich habe mir einen Wertstrom überlegt
und dann fange ich an,
wer ist der Kunde dieses Wertstroms?
Was sind die Stakeholder?
Und welchen Wert liefere ich diesen Kunden,
diesen Stakeholdern?
Wie geht es dann weiter,
wenn man letztendlich weiß,
was man wert,
was man an Wert liefert,
für welche Kunden?
Wie muss man sich so eine Wertstromanalyse vorstellen?
So, verehrte Zuhörerinnen und Zuhörer,
an der Stelle etwas überraschend knall ich euch jetzt
mitten in die Aufnahme hinein,
denn wir haben während der Unterhaltung festgestellt,
dass wir das Thema so ein bisschen unterschätzt haben
und dass wir ihm gerne den Raum einräumen wollen,
der ihm gebührt.
Mit anderen Worten,
dass 45 Minuten einfach zu kurz sind,
um sich diesem Thema ausrechnen zu können.
Daher haben wir beschlossen,
dass wir diesen Podcast
wieder mal zu einem Zweiteiler machen.
Was ihr jetzt gehört habt,
war der erste Teil.
Der zweite Teil wird in Kürze folgen
und enthält dann unsere Gespräche darüber,
wie man das denn vielleicht praktisch umsetzt,
wie man eine Wertstromanalyse
jetzt tatsächlich konkret handwerklich angeht,
was einem dabei vielleicht passieren kann,
was man dabei beobachten kann,
wie man damit umgeht.
Das heißt,
diese Folge, die jetzt gerade endet,
war vielleicht ein bisschen
eine etwas theoretischere,
auf höherer Flughöhe befindliche Folge
und die nächste Folge wird hoffentlich
noch etwas konkreter,
noch etwas unmittelbarer sein.
Ich bedanke mich bis hierhin
ganz herzlich für eure Aufmerksamkeit
und ich hoffe,
dass ihr euch auch die zweite Folge
noch mit großem Genuss anhören werdet.
Die ist ein bisschen kürzer als diese hier.
Die ist, glaube ich,
bloß ungefähr 35, 40 Minuten.
Aber jedenfalls,
da ist auch ganz viel tolles Zeug dabei.
Ich habe sie auch schon fertig geschnitten.
Und ich freue mich schon darauf,
dass ihr sie anhört.
An dieser Stelle vielen Dank fürs Zuhören,
auch im Namen von Dirk und Falko,
die jetzt natürlich nicht
ihre üblichen Grüße am Ende reinwerfen,
weil das alles so ein bisschen
holteripolter mitten unterm Gespräch war
und wir wollten unseren Fluss nicht verlieren.
Macht’s wunderbar gut.
Habt ein wundervolles Weihnachtsfest.
Ich schneide diese Episode am 23.12.
und werde sie jetzt auch gleich veröffentlichen.
Ich freue mich mit euch
auf ein ganz schönes Jahr 2023.
Macht’s gut. Bis bald. Ciao.
Auf Wiedersehen.