Andreas von Motionpixxl, Johannes von Metamorphant und Boris von Eficode reden über Grundlegende Konzepte von Lean und Scrum als Waffe.
Boris (00:01):
Hallo und willkommen zu unserem neuen Podcast. Bei mir ist Johannes Knauf und Andreas Einzmann. Ich bin Boris Schulz und wir reden heute über das Thema "Lean" und wie man das Leuten gut erklärt, die sonst wenig Bezug haben zu moderner Softwareentwicklungstechnik. Johannes wird wie schon beim letzten Mal die Moderation übernehmen und ich würde sagen, ihr stellt euch vor und danach mache ich die Einführung in das Thema.
Johannes (00:26):
Danke Boris. Dann stelle ich mich kurz vor. Ich bin Johannes Knauf von der Metamorphant GmbH, bin unterwegs als Consultant im weiteren Feld DevOps und viel mehr möchte ich da auch gar nicht sagen. Andreas
Andreas (00:39):
Das ist wenig. Johannes Danke. Dann halte ich es auch kurz Mein name ist Andreas Einzmann von Motionpixxl. eigene Firma. Ich bin im Moment als Senior Agile Coach unterwegs und treibe gerade eine Agile Transformation bei einem großen Mittelständler.
Johannes (00:55):
Sehr schön. Dann Boris, würde ich sagen, Bühne frei für dich. Du darfst dich auch bitte noch mal kurz vorstellen. Es könnte sein, dass der eine oder andere dich nicht kennt und... nein! völlig unmöglich, völlig unmöglich. Aber könnte ja passieren. Und dann erzähl uns doch mal, was du uns mitgebracht hast.
Boris (01:12):
Ja genau. Ich bin Boris Schulz. Ich bin Team Lead bei Eficode Deutschland. Die Situation, die ich gerade beim Kunden habe, ist, dass ich gefragt wurde, was Lean ist. Ich wurde gefragt von Leuten, mit denen ich nicht einfach auf DevOps verweisen konnte oder auf Agile oder auf Toyota oder auf all die anderen Dinge, die man halt so in der Regel nennt, wenn man Dinge erklärt, die eigentlich in aller Munde sind. Ich kam dann zu einem Erklärungsansatz, den ich mal eben vorstellen möchte. Ich denke, danach können wir den zerpflücken, überlegen, wie passende der ist und einfach gucken, wohin uns die Reise führt. Lean ist ein Weg oder ein Mittel, um den evolutionären Druck, den man als Firma ausgesetzt ist, gewachsen zu sein. Evolutionärer Druck, heißt in dem Fall, man ist ja als Firma kein Einhorn auf der grünen Wiese ohne Konkurrenz, sondern man hat die Marktbegleiter und die Marktbegleiter wollen auch besser werden. Der Markt selbst ändert sich auch dauernd. In meinen Workshops erkläre ich immer schön, dass wir in einer sehr, sehr fragilen, instabilen Welt leben, wo das, was wir heutzutage wissen. Nächstes Jahr schon veraltet sein kann. Das heißt, der evolutionäre Druck besteht einmal darin, dass man in einem Pool ist mit lauter Mitbewerbern, die einen überholen wollen und aber auch daran, dass sich der Pool selbst dauernd ändert. Lean ist ein Mittel, um diesem Druck besser standzuhalten. Lean sorgt dafür, dass man das ganze unnötige Fett, also den ganzen Ballast, den man so als Firma mit sich herumträgt, einfach loswird. Es gibt dann diese 5 Lean-Grundsätze, auf die wir gleich eingehen können. Aber in erster Linie geht es darum, dass man mal versteht, die Firma ist einem Druck ausgesetzt und Lean ist ein Mittel, um dem Druck besser standhalten zu können. Ja, ich würde sagen, DevOps kann man auf eine ähnliche Art und Weise erklären. Lean schneidet den Ballast ab und DevOps macht dann einfach, die Anpassung schneller möglich. Das wären sozusagen zwei Seiten der gleichen Medaille. Aber mich interessiert jetzt mal: Wie steht ihr dazu?
Andreas (03:21):
Mein Verständnis von Lean. Ich nutze es auch im agilen Kontext. Natürlich basiert alles auf dem agilen Manifest, das ist letztes Jahr 20 Jahre alt geworden und viele Prinzipien wurden daraus übernommen und haben sich daraus entwickelt. Du hast recht, Toyota, gutes Stichwort gab es schon vorher und wir haben wirklich so Themen wie Caysen und so weiter, und so weiter. Wir nutzen in Lean ähnliche Prinzipien wie auch in anderen Methoden. Wie Scrum Kanban, ganz wichtig und die Leitsätze ähneln sich auch sehr. Also meiner Meinung nach ist, dass es eine ein bisschen andere Methode als z.B. Scrum Kanban und so weiter. Nutzt aber die gleichen Werte und Prinzipien und die gleichen Leitsätze, was ich völlig gut finde. Der Fokus ist hier ein bisschen anders gesetzt, wie du auch gesagt hast, dass es Verschwendung vermeidet. Das nutze ich aber auch im agilen Kontext, wenn ich Scrum durchführe. Also Scrum-Methode, ganz wichtig. Also es ähnelt sich sehr, bloß der Fokus ist ein bisschen anders, das ist meine Meinung.
Johannes (04:22):
Jetzt hat der Boris das Ganze in den Kontext gesetzt mit so einem, ich überspitzt es mal, einem bisschen "darwinistischen Bild" von einem evolutionären Druck auf Unternehmen, wie würdest du das da einordnen, Andreas?
Andreas (04:35):
Also, da unterscheiden sich die Methoden gar nicht so viel. Wenn du jetzt Scrum nimmst, was aus dem agilen Manifest entsteht, ist da der gleiche Druck da. Es geht um, Agilität, schnelle Veränderungen, reagieren, ganz klar. Ein Wert beim agilen Manifest und da sind sie alle gleich, die Methoden, ist halt Einfachheit und Uknompliziertheit. Das ist genau der Lean-Ansatz. Also das ist jetzt nochmal eine Spezialisierung, meiner Meinung nach.
Boris (05:04):
Also das klingt jetzt bei dir so ein bisschen wie, als wäre Agile und Lean quasi austauschbar. Ich glaube Lean geht ein bisschen eine andere Richtung, aber man kann Agile sehr gut einsetzen, um die Lean-Grundsätze im Alltag durchzusetzen oder durchzuführen.
Andreas (05:19):
Absolut, absolut. Ich habe auch nur gesagt, dass der Fokus ein anderer ist. Bei Lean, fokussierst du dich wirklich auf die Vermeidung von Verschwendung, wo ich ein großer Freund von bin und das lebe ich auch in meinen Produkten, ganz klar. Ich finde es super wichtig und wertvoll und da hat sich halt über die Zeit genau dieses Lean herauskristallisiert, das ist ja auch etwas revolutionäres auch durch den Druck wie du gesagt hast und das ist für mich eine Spezialdisziplin, also eine Untermenge ist zu klein gesagt, aber das ist ein anderer Zweig von dem Ganzen. Also meine Meinung tatsächlich, die überlappen sich alle. Das ja nicht so, dass eine so, das andere ist so, bloß der Schwerpunkt, der Fokus ist ein bisschen anders. Und ich finde das super wertvoll. Also daraus ist ja auch Lean Startup entstanden und ganz viele andere Dinge, was ich mega wichtig finde und auch schon praktiziert habe oder versucht habe, zumindest.
Johannes (06:09):
Boris, jetzt hast du zu Beginn gesagt: „Wenn dieser evolutionäre Druck auf dem Unternehmen wird, dann ist es wichtig, schneller zu werden.", sich also zu beschleunigen in den Anpassungsprozess. Hast du vielleicht ein Beispiel für uns dabei von einem Unternehmen, vielleicht auch aus deiner täglichen Praxis, wo das Einführen von solchen Prinzipie das Unternehmen beschleunigt hat?
Boris (06:29):
Also ich führe ja nicht nur Lean ein, ich führe Lean im Kontext von DevOps oder Agile ein. Von daher ist das jetzt ein bisschen falsch gefragt, aber ich glaube, um das Konzept zu erklären. Gegenbeispiele gibt es einige, also Firmen, die es nicht geschafft haben, sich dem Markt anzupassen, die es nicht geschafft haben, dem dem evolutionären Druck standzuhalten. Da gibt es, glaube ich, ganz viele. Und ich mache immer gerne die Frage in meinen Workshops: „Darf ich jetzt mit Firmen kommen, die nicht überlebt haben?"
Andreas (07:00):
Kodak, ist mein Beispiel.
Boris (07:02):
Ja, genau, das kam tatsächlich schon mehrmals. Ja, genau. Es gibt jede Menge Firmen, die das offensichtlich nicht geschafft haben. Ein Beispiel, das öfter mal genannt wird von Firmen, die es schaffen, ist Microsoft. Sie schaffen es ja doch immer relativ gut, sich neu zu erfinden und dem Markt anzupassen. Ich denke, man sieht bei denen ohne zu wissen, wie die arbeiten, dass sie die Grundsätze zumindest durchführen und leben, ob sie das jetzt so nennen, weiß ich nicht. Vielleicht sollten wir einmal die Grundsätze kurz vorstellen. Die 5 Original Grundsätze von Lean, wie man Wert erschafft, ohne dass man Verschwendung erzeugt. Das sind also Value, d.h. man muss sich überlegen, welchen Wert der Kunde eigentlich braucht und bezahlen möchte. Danach braucht man ein Team für ein Produkt, das den Wert von vorne bis hinten begleitet und erzeugt. Das sieht man auch schon ganz, so ein paar Ideen von Agile oder DevOps, also ein Team pro Produkt und nicht ganz viele Teams. Dann der Value Stream, dass man das Ganze visualisiert, aufmalt oder anhand von der Visualisierung sich überlegt, welche Schritte vom Prozess man einfach streichen kann. Dann den Flow, dass man versucht, möglichst den Wert, den man am Ende erzeugt, durch die ganze Firma fließen lässt, ohne dass da irgendwo der Wert aufgehalten wird. Also nicht nur ein Release alle halbe Jahr oder sowas. Pull, finde ich ganz interessant. Das heißt, man lässt die einzelnen Entitäten, die Mitarbeiter, die Teams oder was auch immer, selbst entscheiden, wann sie bereit sind, neue Arbeit aufnehmen zu können. Und Perfektion, sehr japanisch: „Sei jeden Tag ein bisschen perfekter".
Andreas (08:38):
Und das ist genau das, was ich meine, tatsächlich. Ich begleite gerade drei Scrum-Teams und das sind genau die Werte, die wir auch leben, nennt sich ein bisschen anders "Customer Centricity". Welchen Value generieren wir in unseren Teams? Ganz wichtig, dass das immer überprüft wird. Der Flow wird auch immer überprüft. Wie können wir schneller sein? Wie können wir ohne Ballast schneller arbeiten? Wir sind autonom in den Produkten, ganz wichtig und wir entscheiden selber im Team, wie es weitergeht, priorisieren also durch MPU, Scrum Master und Team, ihr kennt das alles und so weiter. Also das ist alles super ähnlich, meiner Meinung nach. Ich bleibe dabei, tatsächlich. Ich vermische natürlich Lean und Scrum bei mir, ganz klar, weil ich da auch hinterstehe. Es gibt so viel, Waste der da erzeugt wird bei vielen Produkten, die überhaupt kein Value kreieren und das sollte man vermeiden, immer.
Johannes (09:30):
Nachdem was ich gesagt habe, versuche ich mich mal an einer ganz knackigen Kurzzusammenfassung und ihr zerreißt sie mir bitte. Während so in der agilen Welt man sich als Produktmanager vielleicht öfter fragt: „Was kann ich bauen, um meinen Kunden zu begeistern?". Da ist der Gedanke hinter Lean vielleicht eher: „Was kann ich weglassen?"
Andreas (09:49):
Das widerspricht sich nicht für mich. Das sind zwei Seiten einer Medaille, tatsächlich. Also, sehe ich nicht so krass und ich sehe auch nicht, dass es unterschiedliche Welten sind. Das sind vielleicht andere Länder oder so. Aber schon auf einem Planeten, so würde ich das sehen.
Johannes (10:06):
Also um darauf zu reagieren, ich hätte es jetzt eher betrachtet als zwei unterschiedliche Konzepte, die sich ergänzen.
Andreas (10:11):
Ja, bin bei dir, bin bei dir!
Johannes (10:13):
genau, aber trotzdem die man dadurch halt abtrennen kann. Vorhin hatten wir so das Bild von okay, das sind zwei Mengen, die wir irgendwie einen starken Overlap haben. Aber vielleicht kann man es ja auch auseinander drösseln, konzeptionell und damit vielleicht auch leichter verdaubar zu machen. Die Ausgangsfrage war ja: „Leute, die jetzt vielleicht nicht so aus der IT oder oder aus der Autoindustrie kommen, wie erkläre ich es Ihnen?" Boris, du hattest dich gemeldet, dass du was dazu sagen möchtest.
Boris (10:35):
Ja, ich glaube, das ist eine schöne Erklärung. Also, würde ich unterschreiben. Wahrscheinlich wird jetzt Andreas anfangen zu protestieren...
Andreas (10:41):
Nein!
Boris (10:41):
...aber wenn ich Lean einführe, dann werde ich wahrscheinlich erst mal jede Menge Sachen abschneiden von meinen Prozessen und vielleicht auch von den Features vom Produkt entfernen. Ich glaube, wenn ich Agile einführe oder DevOps, dann wird wahrscheinlich erstmal der Fokus darauf sein: „Wie kann ich rauskriegen, was der Kunde will?" Also es sind zwei, zwei Enden von einem Optimierungsprozess, der natürlich am Ende dazu führt, dass ich das beste Produkt für den Kunden ausliefere.
Andreas (11:10):
Ja und vielleicht ganz super wichtiger Aspekt, bei Lean, so habe ich es verstanden, gerade im Sinne von Lean Startup, MVP, Time to Market. Ich liefere schnell Value. Geschwindigkeit ist ein Thema bei Lean, was ich auch total schätze, was wir auch praktizieren, in meinen Scrum-Teams, das wir mit MVP's, POC's anfangen. Das ist genau das und wir lassen den ganzen Bull$hit weg, was uns sonst belastet. Das ist tatsächlich so und wenn man in die Firmen guckt, es gibt total viel Waste in den Firmen. Es gibt eine Untersuchung von Stanley Group glaube ich: Agile Projekte scheitern zu 50%. Da gibt es eine Korrelation zu Entscheidungsfindungen, also Zeiten und da sind wir wieder beim Flow. Wie lange dauern Entscheidungen? Bei Lean geht man davon aus oder versucht Entscheidungen so schnell wie möglich herbeizuführen und nicht irgendwie Umlauf... wie hieß das Umlaufakten? Ne, Unterschriftsakten hieß das früher analog für...
Johannes (12:06):
Umlaufmappen?
Andreas (12:07):
Dankeschön!
Johannes (12:08):
Das sind die, wo auch immer so schöne Kästchen drauf sind und jeder muss einmal unterzeichnen und so, ja.
Boris (12:13):
Genau, genau. Das will man ja alles vermeiden. Lange Prozesse mit tausend Unterschriften, Genehmigungen und so. Das lässt man alles und das finde ich, ist ein gutes Beispiel, wie diese Korrelation, wieso scheitern Agile Produkte, Projekte und bei Lean... nochmal, setzt du den totalen Fokus drauf, diesen ganzen Waste zu vermeiden und das ist super, super wichtig!
Boris (12:35):
Jetzt ist ja 50% Scheitern, eher wenig. Ich habe mal an der Uni gelernt, 90% der Startups scheitern im ersten Jahr, das heißt 50% Agile Projekte, die scheitern, klingt erst mal viel, ist aber eigentlich eine sehr, sehr gute Zahl.
Andreas (12:50):
Das sehe ich wie du, aber im Vergleich zu Wasserfall Projekten, meine letzte Zahl Zenith Group sind nur 27% erfolgreich, also 73% scheitern Wasserfall, klassisch. Ich war erst mal erstaunt und es wurde halt wirklich untersucht: „Woran liegt das denn, Finden wir da einen Faktor, wieso die scheitern?" Und das war genau diese Entscheidungsfindung. Entscheidungen dauern zu lange und die blockieren natürlich das Projekt oder Produkt. Also ein echtes Impetiment, fand ich super spannend.
Johannes (13:20):
Ist ja auch so eine klassische Predigt, zumindest in der Lean-Softwareentwicklung, dass man sagt Okay, wenn jemand ein halbes Jahr nach seinem Feature Request auf sein Feature wartet, dann liegt es meistens nicht daran, dass der Entwickler so lange braucht, sondern das liegt halt so lange rum und wird von links nach rechts gegeben und dann wieder von rechts nach links. Bis halt irgendjemand mal sagt: „Ja das bauen wir jetzt."
Andreas (13:40):
So ist es.
Boris (13:41):
Ich habe da ein ganz tolles Beispiel für die Entscheidungsfindung. Ab und zu kommen ja Kunden und sagen: „Hey, wir sind hier in einer ganz anderen Industrie, dass das klappt bei mir alles nicht!" Und neulich habe ich jetzt gehört, dass Nintendo für das neue Zelda, also "Zelda: Breath of the Wild" großartiges Spiel. Die haben, um die Physik- und Chemie-Engine zu testen, eine Version in 8-Bit geschrieben. Die haben quasi ein Spiel komplett geschrieben, das aussah wie das erste Zelda auf dem NES, nur um ihre Ideen zu testen. Das ist, glaube ich, der schönste Ansatz in Lean oder Agile, den ich, auch in der Spieleindustrie, wo ja auch wirklich Milliarden drinstecken, bisher gehört habe.
Andreas (14:19):
Im Grunde ist das dieser MVP-Ansatz. Wir wollen schnell Time to market erreichen und wir wollen schnell dem Kunden etwas zur Verfügung stellen, um sehr schnell Feedback zu erhalten dazu. Das ist super, dass genau der richtige Ansatz, natürlich. Wir wollen nicht ein halbes Jahr entwickeln oder ein Jahr und dann erst hören, ob die Kunden das in Ordnung finden, sondern wir wollen schnell auf dem Markt sein
Johannes (14:41):
Oder scheitern. Lieber früh als spät.
Andreas (14:43):
Oder scheitern! Auch das. Man muss auch mal vom wirtschaftlichen ausgehen. Ich entwickle ein Jahr, ein Spiel und alle finden das doof. Ist nicht schlecht, kann man machen, aber es ist nicht gut, wenn man ein 8-Bit schreibt, was weniger an Entwicklungskapazitäten bindet und Kosten. Kriegt man sehr schnell Kunden-Feedback. Also das ist wirklich dieses Thema Customer Centricity. Wir wollen schnell etwas ausliefern, um Feedback einzusammeln, um uns zu verbessern auf Basis des Kunden-Feedbacks, super Ansatz. Genau.
Boris (15:13):
Wir sollten glaube ich noch einmal kurz erklären, was "Waste" ist. Also "Waste" oder Verschwendung ist in dem Kontext alles was man tut, das am Ende weder der eigenen Firma noch dem Kunden irgendwie einen Gewinn bringt, der Firma gewinn und dem Kunden das was er bezahlen möchte am Produkt.
Andreas (15:30):
Ich glaube also für mich eine Erklärung, die ist sehr einfach in ein, zwei Sätzen. "Waste" ist alles was kein Value kreiert. Also man sollte immer alles was man tut darauf überprüfen, kreiert das irgendeinen Value. Das ist für mich meine Erklärung, so erkläre ich das auch meinen Teams. Jetzt kann man auch weiter philosophieren, in die Details.
Boris (15:50):
Ja, finde ich aber einen sehr wichtigen Punkt, weil zur Unterscheidung von Lean und Agile oder Lean und DevOps. Ich hatte eine ganze Menge Firmen, die waren relativ agil und relativ oder DevOpsien gemacht, aber die wussten gar nicht, wofür der Kunde bezahlt. Ich finde diesen Ansatz schön bei Lean, dass man sagt, es ist Teil von den Kernprinzipien rauszukriegen: „Was will der Kunde eigentlich?" Und das finde ich, ist ein ganz, ganz wertvoller Punkt, warum es sich lohnt Lean zu machen, auch wenn man sonst Agile macht oder DevOps oder irgendwas. Man sollte noch diese 5 Prinzipien obendrauf packen, um genau diesen Punkt abzudecken.
Andreas (16:29):
Genau im Scrum-Umfeld machst du es natürlich durch das Review, wo alle Stakeholder dabei sind, also sprich Kunden. Da versuchst du halt die Nähe zum Kunden zu schaffen, um dann Feedback daraus zu erreichen, um eventuell zu korrigieren, nachzubessern oder überhaupt Feedback, Pain sonst was einzusammeln. Du hast halt diese Sprint getriebenen Zyklen. Ja, mehr muss ich dazu auch nicht sagen. Also ich bleibe dabei, es ähnelt sich alles so ein bisschen.
Boris (16:58):
Es ähnelt sich schon ziemlich, doch auf jeden Fall. Es muss ja auch das gleiche Problem lösen. Es muss lösen, dass die Firma in diesem sehr, sehr volatilen Umfeld überlebt.
Andreas (17:07):
Ja, und das Schöne finde ich an Lean, das ist halt nicht so komplex wie Scrum oder Kanban. Du hast nicht diese ganzen Zeremonien so stark, dass es halt viel begrenzter einfach und dadurch auch viel leichter verständlicher. Meiner Meinung nach.
Boris (17:23):
Das sprichst du einen schönen Punkt an, sagt Lean überhaupt, wie man arbeiten soll? Ich meine Kanban ist ja irgendwie eine Arbeitsweise, Scrum und so was. Agile und DevOps geben wesentlich mehr vor, wie man arbeiten sollte und Lean sagt ja nur: „Beachte diese fünf Prinzipien und dann machst du alles richtig!"
Andreas (17:40):
Genau. Und das ist genau das. Im Grunde, die Prinzipien zeigen schon, wie einfach das ist. Wir haben kein großes Framework, wie ich sag mal Agile und ich sag mal Scrum. Du, was halt viele vorgaben und das ist auch okay für die meisten Teammitglieder, dass sie erst mal das Grundprinzip verstehen. Also agiles Manifest daraus ist eine Methode entwachsen, wie Scrum zum Beispiel aber du hast sehr viele Regularien. Du hast drei festgelegte Team-Rollen, du hast bestimmte Zeremonien und du hast drei Artefakte.
Boris (18:13):
Glaubt ihr, dass Lean in der Softwareentwicklung zwangsläufig in so was wie Agile oder DevOps endet? Also wenn ich zu einer Firma gehe und sage: „Fangt mal auf der grünen Wiese an. Hier sind 5 Prinzipien." wir nennen sie jetzt Lean und die Firma hat keine Ahnung. Endet man zwangsläufig bei irgendwas, das sehr ähnlich ist oder exakt identisch ist zu Agile oder DevOps?
Johannes (18:34):
Ich würde dich bei der Frage zurückspielen und sagen: „Woran würde ich denn erkennen, dass es Agile oder DevOps ist?"
Boris (18:40):
Meine Definition von DevOps, die ich momentan vertrete und die ziemlich übereinstimmt mit der von Eficode ist, DevOps ist: Technologien und Kulturen nutzen, um das Produkt messbar schneller an den Markt zu bringen und messbar höhere Qualität zu erzeugen. Das ist die Definition: messbar höher, Qualität schneller und Technologie und Kultur.
Andreas (19:04):
Und bei DevOps, wir haben letztes mal schon drüber geredet Time to market, was du gesagt hast, aber auch Kundennutzen stiften. Wir sind schon wieder beim Thema Value, also wirklich Customer Centricity. Ich kann schnell dem Kunden etwas zur Verfügung stellen, was er nutzen kann. Das finde ich super. Also das ist ja genau das, sehe ich auch so. Und bitte, ihr redet immer von Agile... Meint ihr Scrum damit? Wahrscheinlich? Rigchtig?
Johannes (19:28):
Oh, da muss ich dir den Go-To-Talk empfehlen, den ich vor kurzem angeschaut hab, wo sich also einer der großen agilen Köpfe, müsste noch mal nachschlagen wer es war, lange drüber ergeht, dass Scrum mit Agile, also nun wirklich nicht mehr viel zu tun hat. Der Talk hatte einen großartigen Titel, ich schaue ihn nach und dann berichte ich gleich.
Boris (19:53):
Und den muss ich sehen!
Andreas (19:56):
Da bin ich gespannt! Wie gesagt, Agile ach, jetzt sage ich auch schon Agile, Scrum ist eine Methode, die aus dem agilen Manifest erwachsen ist, ganz klar, dann muss man gar nicht diskutieren. Wie Agile das ist und wie nicht, ist eigentlich dahingestellt. Wenn die Methode funktioniert, also das ist mein Mindset, dann sollte man die benutzen, ganz klar. Man sollte mal gucken, was will ich erreichen und dann nutze ich die richtige Methode. Ich bin da überhaupt nicht dogmatisch, zero und ich gehe auch bei Kanban man mit ich gehe bei Lean mit, ich gehe bei Design Thinking mit. Aber es geht genau darum, was will ich erreichen? Das sollte man vorher einmal überlegen. Wenn man es nicht weiß, dann macht man Design Thinking, finde ich völlig ziemlich fair oder Lean. Ist ein super, super Startpunkt für alles weitere finde ich einfach.
Johannes (20:42):
so, hier habe ich ihn für dich rausgesucht. Du wirst ihn lieben oder hassen und er wird alles in Frage stellen, was du gerade gesagt hast, der Talk. Er hat den großartigen Titel "War is Peace, Freedom is Slavery, Ignorance is Strength, Scrum is Agile" und der Redner heißt Allen Holub.
Andreas (21:03):
Hört sich gut an, hört sich total spannend an, aber tatsächlich bei meinem Mindset hinterfrage ich immer alles. Ist das die richtige Methode, sollte man Scrum nicht ändern, ein bisschen? Wir hatten eine, große Änderung letztes Jahr mit 2020 Scrum Guide ganz witzig und ich will mich nicht selber loben aber ich habe das schon lange gemacht, was da drinsteht im neuen Guide. Also das ist ein Framework einfach, genau.
Boris (21:28):
Ja, ich würde sagen, da ist auch so ein bisschen die Gefahr. Also ich denke, man kann sagen, Scrum hat nicht viel zu tun mit Agile, weil man Scrum auf eine Art auf dem Papier implementieren kann, die am Ende nicht mehr agil ist aber ich denke, wenn man den 5 Prinzipien von Lean folgt, dann folgt man den einfach und wenn man ihnen nicht folgt, dann folgt man ihnen nicht. Das ist, glaube ich, der große Unterschied. Entweder macht man Lean oder nicht, aber man kann es nicht auf eine Art machen, die dem Originalgedanken widerspricht.
Andreas (21:56):
Total richtig was du sagst. Entschuldigung, wenn ich kurz was sage ich habe ein Veto gemacht und einer hat eine Karte geschrieben: „Postet Scrum als Waffe? und so wird es auch teilweise eingesetzt und da stimmt halt das Mindset nicht. Es muss immer stimmen, bei allen agilen Methoden, die ich einsetze. Natürlich kann ich nicht Scrum als Waffe benutzen und einfach sagen: „Ne, in unseren Scrim kommt nichts mehr rein. Dann müssen wir erst mal neu planen. Ich mache gar nichts für dich."
Boris (22:24):
Aber ich glaube, der Mensch ist so kreativ. Wir können alles als Waffe einsetzen.
Johannes (22:29):
Oder man landet im legendären "Scrumsterwheel", wo der PO mit der Peitsche oben sitzt und die Entwickler-Hamster scheucht.
Andreas (22:38):
Ja, natürlich. Ich erwische mich ja selber, dass das Daily Standup teilweise ein Rapporte ist, was es nicht sein soll. Ich falle auch in die Fallen rein, logisch.
Boris (22:47):
Ja, ich finde auch, ein Daily Standup über einen Zeitraum von 1-3 Jahren jeden Tag gut zu machen, das ist was, da habe ich den größten Respekt vor und ich schaff das nicht.
Johannes (22:57):
Ich würde gerne noch mal zu unserer Ausgangsfrage zurückkehren. Das klang jetzt so alles ein bisschen sales pitchy und jetzt will ich mal so eine bisschen ketzerische Zwischenfrage stellen, nämlich: „Okay, das klingt so, als hätte es eigentlich nur Vorteile, Lean einzuführen. Wann könnte es denn vielleicht auch unangebracht sein? Was könnten die Downsides sein?"
Andreas (23:23):
Finde ich total schwierige, die Frage. Danke dafür. Mir fällt nämlich nichts ein, weil das ist so klein und so begrenzt und so geframed im Grunde, das nichts schief gehen kann. Ich weiß nicht, wieso man was gegen Lean haben sollte oder wieso das scheitern sollte. Natürlich hängt es immer von den Menschen ab. Also ganz wichtig ich kann alles kaputt machen, logisch. Durch eine negative toxische Haltung. Das geht immer. Da ist es egal welche Methode du einsetzt. Ich finde es ist so beherrschbar, so klein, so super leicht verständlich, dass das einfach ein super Anfang ist, wenn Agile noch nicht irgendwie gelebt wird in der Firma. Du lernst in der Praxis. Du hast wenige Werte, wenige Prinzipien, das für jeden sofort verständlich.
Boris (24:10):
Mir fällt da auch nichts ein, Johannes, aber wir können uns ja mal fragen. Ich habe hier im anderen Tab noch die 5 Prinzipien offen. Wie könnte man diese 5 Prinzipien missbrauchen, also Value rauskriegen, was der Kunde braucht und dann ein Team daraus bauen, das sich darum kümmert, den Value Stream, also die Prozesse aufmalen, mit Meta-Informationen versehen über wie lange die Schritte dauern über wer daran beteiligt ist, was die Kosten sind etc. und dann wegstreichen, was man nicht braucht. Flow, dass der Wert kontinuierlich fließt. Pull, hab ich vorhin erklärt, in Perfektion. Ich sehe gerade relativ wenig Möglichkeiten, das zu missbrauchen.
Andreas (24:49):
Durch meine Erfahrungen in diversen Projekten mit unterschiedlichen Menschen kann ich es mir vorstellen aber da müssen wirklich sehr schwierige Menschen drin sein, die alles ablehnen, tatsächlich. So eine Anti-Haltung. Und ich finde ja auch, es gehören ja auch die agilen Leitsätze dazu. Mir fällt persönlich nichts ein, was man dagegen haben kann. Die Firma muss natürlich bereit sein. Das Management muss sich committen dazu, dass man so etwas ausprobiert und startet. Das ist ganz wichtig, du brauchst immer das Backing oder Sign-Off von oben, dass das so ist. Es gibt bestimmte Voraussetzungen, auch für Lean, glaube ich.
Boris (25:25):
Aber die Frage war ja, in welchen Fällen kann man es nicht einsetzen? Und ich meine, dass die Voraussetzungen beim Management und im Mindset da sein sollten, ist glaube ich, bei allen Sachen gegeben, egal was man macht. Es gibt sogar ein Fachwort, das ich habe vergessen. Ein Argument, das man gegen alles anwenden kann. Aber das wäre das dann wohl.
Andreas (25:46):
Scrumbut bei Scrum, aber egal.
Johannes (25:49):
Okay. Aber was man sich ja vorstellen könnte, ist zum Beispiel Ich bin jetzt eine große unagile Firma, unagil im Sinne von Mindset, also sehr starr, sagen wir mal industriell geprägt. Und diese Transformation kostet mich ja auch einen Haufen Geld. So ist es ja nicht. Ich muss da investieren. In teure Coaches wie den Boris oder den Andreas. Jetzt würde mich ja schon mal interessieren, wer von euch teurer ist, aber das erfahren wir bestimmt in einem anderen Podcast. Also man muss ja auf jeden Fall was investieren an der Stelle, um nachher auch einen Outcome daraus zu haben. Ich könnte mir schon vorstellen, dass es Firmen gibt, bei denen dieser Invest z.B. zu groß ist und unterwegs halt einfach... Ja, vielleicht sogar in die Insolvenz führt, keine Ahnung.
Boris (26:39):
Nein, das glaube ich nicht. Also man muss schon eine sehr, sehr unbewegliche Firma sein, die sich wirklich mit Händen und Füßen währt, dass man nicht irgendwo einen positiven Effekt hat. Und ich denke, das gilt noch mehr für Lean als für alles andere. Am Ende ist ja auch das Ziel von Lean, das langfristige Überleben zu sichern. Also mein Eingangsbeispiel war ja evolutionärer Druck und es geht ja nicht darum, dass man jetzt in diesem Moment ein paar Euro mehr macht oder weniger. Es geht darum, dass die Firma langfristig am Markt überleben kann. Und da sehe ich gerade nicht, wie das ein Problem sein sollte.
Andreas (27:12):
Ich sehe natürlich Probleme, die ich auch sonst habe in einer agile Transformation. Es gibt viele Menschen im Unternehmen, die keine Kontrolle abgeben wollen, ganz schwierig für diese Menschen und die werden, kommt drauf an, wie motiviert sie sind, immer dagegen schießen: „Wir haben keine Kontrolle, die machen ja irgendwas. Ich verstehe das nicht!" Das hast du immer glaube ich, dass hast du auch bei Lean, egal was du einführst, für eine neue Methode wirst du immer haben. Aber das hat mit Lean nichts zu tun, sondern es ist ein generelles Mindset im Unternehmen, natürlich.
Boris (27:44):
Ich habe vor ein paar Monaten so einen Blogpost geschrieben, wo ich genau darauf eingehe. Es gibt Leute, die wollen einfach nicht. Man muss damit transparent umgehen und da muss man sich überlegen, wollen wir das machen? Ja oder nein? Wenn ich es nicht schaffe, das mittlere und obere Management zu überzeugen, dann ist eventuell Lean, DevOps, Agile in dem Moment das Falsche. Dann glaube ich aber nicht, dass das langfristige Ziel, nämlich zu überleben, genauso gut gewährleistet werden kann wie mit einer Transformation. Also nur weil es in diesem Moment vielleicht zu teuer wäre, glaube ich nicht, dass es sich nicht trotzdem lohnen würde.
Andreas (28:19):
Ich denke auch, es lohnt sich immer. Aber ich sehe auch die Widerstände ganz klar. Und was ich gelernt habe, jetzt auch im letzten Jahr, ist, man will Leute überzeugen, Menschen, natürlich. Aber man darf sie nicht missionieren. Das ist so mein Learning letztes Jahr. Dann muss man irgendwie auch sagen: „Okay, du willst das nicht. Akzeptiere ich, verstehe ich, mach das so, wie du das willst. Ist in Ordnung, aber unsere Unternehmensstrategie ist folgende: Willst du nicht da mitgehen, ist auch völlig fine für dich. Dann ist das so..."
Johannes (28:50):
Ja, mir ist noch ein anderer Kritikpunkt eingefallen, der vielleicht von so einem klassischen gestandenen Projektmanager kommen würde. Jemand, der sich wirklich auch als Projektmanager bezeichnet, ist ja heute eine Seltenheit geworden. Aber gibt es ja noch. Der könnte zum Beispiel kritisieren und sagen: „Ja Lean, das klingt ja ganz toll." So auf einer kleinen Ebene. Keine Ahnung. Ein Team. Du hast ja selber schon gesagt, Boris Okay, wir wollen möglichst viel von dieser Gestaltungsmacht in einem Team konzentrieren und das autonom gestalten. Aber wie ist das, wenn es skalieren muss, wenn es also aufs ganz Große rausgeht?
Boris (29:25):
Na ja, Lean sagt ja nicht, ob das im Großen und im Kleinen funktioniert. Lean sagt ja nur: „Egal wie groß du bist, hier sind 5 Grundsätze. Halte dich dran." Und ich denke, an der Stelle müsste man dann einfach sagen: „Du kannst das das Rad neu erfinden. Oder du nimmst eins von den vorhandenen Frameworks, die existieren, die erfolgreich von großen Firmen eingesetzt werden." Und ich denke, dann kommt man dann zu diesen ganzen agilen großen Frameworks, SAFe oder irgendwas, die in meinen Augen so ein bisschen over-engineered sind, die aber genau diesen Fall abdecken.
Andreas (29:55):
Ich sehe es genauso wie du und ich sehe es auch wie du, das SAFe und so weiter over-engineered sind. Da sind wir wieder beim Thema "Waste" also, durch diese over-engineered erzeuge ich eine Menge Waste, eine Menge Rituale, eine Menge Rollen, eine Menge Prozesse. Das ist natürlich Anti-Lean ab einer bestimmten Stelle. Aber ich glaube, ja, das sollten wir genau diskutieren. Das ist nämlich eine gute Frage von Johannes. Im Grunde, im größeren Maßstab funktioniert das noch. Ich bin immer noch bei dir, dass die Prinzipien, Leitsätze und Werte genauso bestehen, in einem größeren Zusammenhang.
Boris (30:32):
Aber die Frage ist doch, ab einer bestimmten Größe nicht: „Funktioniert es so wie wir geplant", sondern „Funktioniert es besser als die Alternativen?" Und wenn ich dann so einen ganz klassisch geführtes Unternehmen habe, da kennen wir alle die Probleme, die sind groß, die sind unbeweglich, da tut sich gar nichts. Innovation ist irgendwie ein Schimpfwort und ich denke, das ist ja, was man sich angucken muss, bin ich besser als an der Stelle meine Konkurrenz, die andere Methoden einsetzt?
Andreas (30:56):
Ja, sehe ich auch so. Mir sind die Menschen halt wichtig und da sind wir bei den agilen Leitsätzen, dass man eine Kultur einführt, auch über Lean, wo man dann über Werte redet. Also ich, ich. Ich freue mich drauf, dass viele Firmen darüber nachdenken, dass nicht alles Werte basiert sein soll Value Spaced Leadership zum Beispiel. Ganz viele Dinge. Und das deckt Lean auch ab. Und Lean ist ein guter Einstieg, um mal eine agile Arbeitsweise auch auszuprobieren bei Unternehmen. So einen Eisbrecher und wir verstehen, dass wir versuchen das und dass man da reingeht an der Stelle deswegen super wertvoll.
Johannes (31:32):
Also du meinst, weil die Einstiegshürde einfach so gering ist, ist eine gute Einstiegsdroge.
Andreas (31:39):
Ich kann euch sagen, in meinem Unternehmen alle, die bei mir in die Scrum Teams reingekommen sind, also das agile kennengelernt haben. Frage ich die immer: „Und wollt ihr zurück in die Linie." „Niemals!" fertig. Ich habe sie abhängig gemacht, weil sie es kennengelernt haben, dass wir nach Werten leben, dass wir Leitsätze haben, also das ganze Thema Respekt, Wertschätzung, Offenheit, Transparenz, Lean gehört auch dazu und nicht Linien gesteuert top down. Wenn die es einmal kennengelernt haben, wie ein anderes Arbeiten funktioniert auch Lean, Scrum kann man, egal, da wollen die meisten nicht zurück. Also kann ich so sagen aus meiner Erfahrung, was ich schön finde.
Johannes (32:19):
Was mir zu der Frage noch einfällt. Ich erinnere mich leider nicht mehr, in welchem von diesen schönen Romanen, Stil-Büchern das war. Entweder war es im Ziel von Eliyahu m. Goldratt oder es war im Phoenix Project. Ich bin mir nicht ganz sicher, aber tatsächlich hat sich da ja gerade rausgestellt, dass eigentlich globale Optimierung das Ziel von so einem Lean-Ansatz ist und man eben auch out-of-the-box denkt und auch auf eine auf global galaktischen Ebene, also auf Unternehmensebene Zöpfe abschneiden kann und da im Grunde jeder zu berufen ist.
Andreas (32:56):
Das war Phoenix, ganz klar. Ich liebe das Buch ja abgöttisch. Ich habe es nochmal gelesen im Sommer, letzten Sommer und ich finde die Rebellion am besten, mann muss sich da ja so eine Schatten-IT aufbauen, im Grunde so eine Untergrundbewegung, mega. Also ganz richtig, weil anders geht es nicht. Das war genau diese Schmerzen und deswegen noch mal Lean ist eine gute Einstiegsdroge. Sehe ich genauso.
Boris (33:20):
Ich glaube, da ist aber auch die Antwort auf die Frage von Johannes: „Wann sollte man Lean und andere Methoden dieser Art nicht einsetzen?" Wenn die globale Optimierung dazu führt, dass einfach 90% der Firma abgeschnitten werden würden? Ich glaube, dann hätte ich mit so viel Widerstand zu rechnen, dass es unmöglich wäre. Es gibt einen gewissen Widerstand, mit dem kann ich arbeiten, den ich auch erwarte und mit dem ich umzugehen weiß. Aber ich glaube, bei einer bestimmten Problemgröße würde ich einfach als Firmenchef das Handtuch werfen, eine neue Firma gründen und nochmal von vorne anfangen.
Andreas (33:55):
Das passiert ja im Projekt Phoenix, im Grunde. Sie erfinden die Firma neu und es ist einfach eine neue Firma. Und ich habe tatsächlich ein praktisches Beispiel auch bei Phoenix ist ja ein ganz schlimmes Thema das "CAB Change Advisory Board". Und exakt das erlebe ich gerade. Exakt das gleiche. Formulare und dadurch wird es langsam und Genehmigung und bla und total witzig, gerade. Da werden Zöpfe abgeschnitten, natürlich. Da verlieren Leute ihren Job. Es ist so und da haben die Ängste. Es ist klar.
Johannes (34:26):
Also ich versetze mich in die Rolle eines optimistisch denkenden Managers und Entrepreneurs und sage, da gewinnen Leute neue Zeit, um wertvolle Dinge zu schaffen und sich persönlich weiterzuentwickeln.
Andreas (34:42):
Total bei dir.
Johannes (34:43):
Euphemismus Ende.
Andreas (34:44):
Nein, nein, nein, nein!
Johannes (34:45):
Aber es ist wahr, es ist ein Kern von Wahrheit.
Andreas (34:48):
Yes und wir reden wieder über Werte und Value, ganz klar. Und das andere ist Waste, wenn ich irgendwelche Prozesse einhalte, die überhaupt nichts bringen.
Boris (34:57):
Mein erster CTO hat mal zu mir gesagt: „Boris, wenn du weiterhin so optimistisch denkst, fliegst du raus."
Johannes (35:02):
Es ist auch widerlich, wenn montags morgens immer jemand in die Kamera grinst. Das kriege ich auch jede Woche zu hören.
Boris (35:09):
Ja, aber ich denke, es geht nicht darum, Optimismus zu zeigen. Ich denke, es geht darum, den Status Quo möglichst genau aufzuzeigen. Und wenn man dann Leute hat, die vielleicht ihren Job verlieren würden, dann ist es, wie Andreas immer sagt, dass Mindset das wichtig ist. Und wie gehe ich damit um? Also was mache ich mit Leuten, die vielleicht drei Jahre vor der Rente sind? Wenn ich auf die nicht zugehe und nichts sage, was die die nächsten drei Jahre erwarten können, dann sind die mir im Weg. Aber es ist ja meine Aufgabe, dafür zu sorgen, dass die Transformation erfolgreich wird. Auch wenn ich dann so ein paar unangenehme Fragen stellen muss. Auch wenn ich mit Leuten Gespräche führen muss, wo es vielleicht um ihre Zukunft geht, um ihre Jobsicherheit, um Familie, keine Ahnung. Und da hilft mir halt kein optimistisches Denken. Und ich denke auch, das ist gerade in der Branche eben ein Problem, wenn ich mich vor den Kunden stelle und sage: „Ja, ach, das wird alles gut. Es gibt keine Probleme" dann ist das gelogen. Ich weiß ja, es kommen Probleme. Und noch mal auf den Blogpost von mir verweisend. Mein letzter Blogpost hieß "Im Kern von DevOps liegt der Konflikt" also "In the Heart of DevOps lies Conflict" und ich finde, das kann man gar nicht oft genug ansprechen. Das Mindset ist wichtig und man darf nicht optimistisch sein. Es werden Probleme kommen und Lean gibt uns Möglichkeiten, damit umzugehen, wenn das Mindest stimmt.
Andreas (36:27):
Absolut richtig. Ich möchte es noch verstärken oder supporten. So ein bisschen was ich immer sage bei der agilen Transformation, seid ihr euch sicher, dass das der richtige Weg ist, weil da kommen viele, viele Schmerzen auf euch zu. Ganz klar. Also wenn man die Erfahrung noch nicht gemacht hat, weiß man auch nicht, wie das wehtun kann für alle. Also ich sehe das genauso wie du. Da muss man einfach durch, durch die Schmerzphase und dann wird alles besser, vielleicht. Das ist mein Optimismus da drin oder was ich immer sage es ist kein leichter Weg.
Johannes (36:57):
Ein schönes Schlusswort
Andreas (36:58):
Schon fertig, was!? Ich könnte noch zwei Stunden, egal.
Boris (37:07):
Ja, wenn die erfahrene Berater immer wieder beim gleichen Thema enden und immer wieder darauf kommen, dass die Kultur einer Firma viel wichtiger ist als irgendwelche Tool Chains und eingeführten Technologien, dann kann das eigentlich nur zwei Dinge heißen: 1. Jede Firma sollte diesem Bereich, dem Bereich Kultur wesentlich mehr Aufmerksamkeit schenken, als es bisher der Fall ist. 2. Wir drei werden uns in einem den nächsten Podcast dem Thema Kultur intensiv widmen.
