Kaizen 2 go 246 : Wertströme in der Software-Entwicklung

Inhalt der Episode:

Was grenzt den Wertstrom in der Software-Entwicklung ab?
Wie sind Sie auf das Thema Wertstrom (Mike Rother) gestoßen?
Das Dilemma der Software-“Produktion”: Kunden sind nicht gleich Kunden.
Wertstromanalyse im Software-Kontext, wie funktioniert sehen und verstehen, wenn es eigentlich nichts klassisch physisches zu sehen gibt?
Was sind typische Elemente in Wertströmen der Software-Produktion?
Was sind typische Fälle und Ursachen von Warte- und Liegezeiten im Software-Kontext? Wie stellt sich Batching im Software-Kontext dar? Was steht dort dem Ideal des One-Piece-Flow entgegen und wie sieht der eigentlich aus?
Gibt es eigentlich im Software-Kontext auch einen Kundentakt bzw. was tritt ggf. an dessen Stelle, um Glättung und Ausgleich zu erreichen?
Was sind typische Effekte und Ergebnisse einer Wertstromanalyse im Software-Kontext?
Wie lässt sich die Kontinuierliche Arbeit & Verbesserung am Software-Wertstrom aufrechterhalten?
Welche Erkenntnisse lassen sich zurück in klassische Wertströme transferieren?

Notizen zur Episode:

Mitmachen?

Wenn Sie selbst ein interessantes Thema für eine Episode im Umfeld von Geschäftsprozessen haben, können Sie mir das auf dieser Seite mit Vorbereitungsfragen vorschlagen.

Ich freue mich darauf!

Ihnen hat der Inhalt gefallen? Dann bewerten Sie die Episode bitte bei iTunes.

Jetzt eintragen und Artikel/Denkanstöße zukünftig per eMail erhalten.

Artikel teilen auf ...

(Teil)automatisiertes Transkript

Episode 246 : Wertströme in der Software-Entwicklung

Herzlich willkommen zu dem Podcast für Lean Interessierte, die in ihren Organisationen die kontinuierliche Verbesserung der Geschäftsprozesse und Abläufe anstreben, um Nutzen zu steigern, Ressourcen-Verbrauch zu reduzieren und damit Freiräume für echte Wertschöpfung zu schaffen. Für mehr Erfolg durch Kunden- und Mitarbeiterzufriedenheit, höhere Produktivität durch mehr Effektivität und Effizienz. An den Maschinen, im Außendienst, in den Büros bis zur Chefetage.

Götz Müller: Heute habe ich Justus Graumann bei mir im Podcast-Gespräch. Er ist Entwickler und Software-Architekt bei der Swiss Re. Hallo Herr Graumann.

Justus Graumann: Ja hallo oder wie man in der Schweiz sagt Grüezi oder guten Abig miteinand. Ja, also mein Name ist Justus Graumann, ich bin bei der Swiss Re oder auf Deutsch Schweizer Rückversicherung seit über acht Jahren tätig. Rückversicherung ist natürlich ein bisschen etwas, was die Leute vielleicht eher nicht so kennen. Ich erkläre es immer gerne, die Rückversicherung ist praktisch die Versicherung der Erstversicherer, also das ist natürlich ziemlich einfach erklärt, natürlich machen wir auch hier und da Industrieversicherung und so, aber das soll ja heute nicht so das Thema sein, dass wir über die Rückversicherung sprechen, sondern wir haben ja ein ganz anderes interessantes Thema, ja.

Götz Müller: Genau. Wir haben uns das Thema Wertstrom in der Software-Entwicklung vorgenommen. Jetzt kann ich mir vorstellen, dass einige von meinen Zuhören aus dem Lean-Kontext natürlich mit dem Begriff Wertstrom definitiv etwas anfangen werden, aber wahrscheinlich die Abbildung, den Transfer zur Software-Entwicklung jetzt nicht notwendigerweise auf dem Schirm haben. Deshalb vielleicht so zum Einstieg die Frage, weil das sonst im klassischen, sagen wir mal Produktionsumfeld natürlich eine wichtige Abgrenzung ist, wo fängt es an, wo hört es auf, wie grenzt sich ein Wertstrom in der Software-Entwicklung ab.

Justus Graumann: Ja, das ist dann immer die Frage, welchen Scope man setzt, wir haben auch bei uns immer so Diskussionen, wie ermittelt man den Wertstrom, ich sage immer, es ist immer gut, erstmal zu beginnen bei Teams, welche Software-Produkte die herstellen und welche Nutzerkreise sie haben und gerade in meinem Umfeld, ich mache auch DevOps-Transformation, ist es auch enorm wichtig, den Scope nicht zu hoch zu setzen, denn sonst hat man nachher einen riesigen, ziemlich abstrakten Wertstrom mehr und man hat dann eigentlich zu viele Menschen dahinter und das ist das Problem, das dann runter zu brechen auf einzelne Änderungen. Wir haben es dann immer so gemacht, dass wir dann im Einzelnen mit einzelnen Teams angefangen haben.

Götz Müller: Ja. Das sehe ich schon mal eine gewisse Ähnlichkeit zum klassischen Wertstrom, da hat man im Grunde eine ähnliche Herausforderung, wie grenze ich es so eher produktseitig ab, um nicht zu diesen Pullover-Wollknäuel-Effekt zu haben, ich ziehe an einem Faden und zum Schluss ist der ganze Pullover aufgezogen oder das ganze Wollknäuel.

Justus Graumann: Genau. Richtig, ja.

Götz Müller: Jetzt haben Sie gerade noch einen anderen wichtigen Begriff genannt, wo ich auch glaube, dass das jetzt den klassischen Lean-Menschen wahrscheinlich gar nichts sagt, nämlich DevOps, und vielleicht sagen Sie da noch 2-3 Sätze wahrscheinlich oder vielleicht sogar noch ein paar mehr, was denn dahinter steckt, damit, ich sage mal meine Lean-Menschen, das einordnen können.

Justus Graumann: Ja, eigentlich DevOps und Lean, die haben eigentlich, finde ich, ziemlich viel gemeinsam und, ja, es ist eigentlich auch immer kein Wunder, dass so neue Methoden meistens so aus dem Methodenkoffer von bestehende Methoden etwas nehmen und ein bisschen, sage ich mal, ein bisschen anders verpacken und formulieren. Der Grundsatz von DevOps ist ja erstmal, ganz profan, dass du früher getrennte Teams, so wie klassische Anwendungsentwicklung und auf der einen Seite und auf der anderen Seite das klassische Operations, die dann die Anwendung betreiben, dass die einfach näher zusammen kommen, dass sie praktisch erkennen, ok, an sich, was wir machen, wir betreiben eigentlich zusammen ein Produkt und liefern eigentlich und erzeugen dadurch mit diesem Produkt eine Freude bei den Anwendern oder einen gewissen Wert, ja. Ich finde auch den Begriff Wertstrom, da habe ich auch neulich mal skizziert, kann man auch lang diskutieren, Wert- oder Nutzenstrom, geht aber in die gleiche Richtung, dass diese gemeinsamen, dass so ein gemeinsames feeling entsteht, ja, zwischen Dev, zwischen Anwendungsentwickler, und Operations. Und das war eigentlich der Ursprung, ja, und daraus hat sich natürlich viel mehr entwickelt oder kann sich vielmehr entwickeln. Schon allein die Idee, dass man diese Barrieren zwischen klassischen Silos aufhebt, ja. Das ist auch einen ganz wichtigen Element im DevOps, so dieses klassische, ja. Das ist auch ganz, ganz lustig. Das klassische Business, das Anforderungen stellt und dann schickt es dann drüber per Word-Dokument an die Entwicklungsabteilung, die entwickelt dann etwas und schickt das dann auch rüber als Paket, ja, irgendwie an das Operations und das spielt ein und ja, das ist so dieses klassische Silodenken. Und es gibt auch viele Ansätze zum Beispiel im agilen Umfeld, das ja auch das versucht zu brechen.

Götz Müller: Jetzt könnte ich mir auch vorstellen, der ein oder andere, dem natürlich Wertstrom ein absoluter Begriff ist und da, wo das herkommt, Mike Rother und Co, der sich jetzt vielleicht fragt, ja, ok aus der Produktion kenne ich das, wie ist jetzt jemand aus der Software-Entwicklung auf den Begriff Wertstrom gestoßen und dann auch noch zu sagen „Hey, das ist ja eine coole Sache und ich bilde das auf mein Geschäft, meine Tätigkeit ab.“?

Justus Graumann: Ja, das ist auch interessant. Ja, also ich erzähle mal so aus meinem Leben ein bisschen, vorher kannte ich den Begriff eigentlich auch nicht, ja, Wertstrom, was ist denn das. Und ich bin eigentlich dadurch drauf gekommen, über diese DevOps-Einführung, klassischer Weg, ein DevOps-Consultant kommt von draußen und der hat sich dann überlegt mit uns zusammen, ja, wie bringen wir eigentlich so Teams näher an DevOps, ja, und der hat dann eben diese Methodik Value Stream Mapping eingeführt und natürlich, wenn jetzt einer aus der Produktion das sieht, ja, die Optimierungen in der Produktion, die sind, ich kenne das auch an Beispielen, die sind ja sehr an Zahlen fixiert, er würde vielleicht, wenn er das sieht, sagen „Das ist ja, das ist mir zu flach“, ja, sage ich mal, weil hier ging es sehr viel um qualitative Veränderungen bei uns.

Götz Müller: Jetzt … ich meine ich selber habe auch einen Software-Hintergrund, sagen wir mal in meinem früheren Leben im letzten Jahrtausend, und ich kenne da ein, ja ich möchte es mal Dilemma nennen, der Software-Produktion. Ich habe das für mich so und unter der Begrifflichkeit „Kunden sind ja nicht gleich Kunden“ beziehungsweise ich habe halt unterschiedliche, ja, ich will es gar nicht mal Nutzer nennen. Unter Kunden hat jeder sofort ein Bild im Kopf, vielleicht wenn er halt aus einem Produktionsumfeld rauskommt, jemand kauft ein Auto als Kunde und dann fährt er es auch. Das heißt, Käufer, Kunde, Nutzer ist im Grunde alles das Gleiche. In Software-Kontext und speziell in diesem betrieblich-kommerziellen Kontext, vielleicht bei der Embedded Software noch mal ein bisschen anders, wo ich jetzt herkomme, da ist ja Anwender und Nutzer, der vor dem Bildschirm sitzt, nicht der, der irgendwann mal entscheidet „Ich kaufe diese Software.“ und daraus hat sich für mich damals, und ich glaube, das ist nicht besser geworden, immer ein gewisses Dilemma ergeben.

Justus Graumann: Ja, ich finde, erstmal ist es wichtig, von diesem Kundenbegriff ein bisschen abzuweichen. Also mal ein Beispiel, ich bin also im Finance-Bereich, Finance-IT-Bereich zuständig, und es ist schon mal erstmal interessant, wer überhaupt der Kunde ist, von dem, was wir erzeugen. Also sich darüber Gedanken zu machen, weil es wird viel zu leichtsinnig der Begriff Kunde immer verwendet. Der Kunde ist zum Beispiel nicht der Business User, der Change Requests erstellt, ja, und anfordert, ja. Das muss nicht unbedingt der Kunde sein. Und ich wäre auch sehr vorsichtig, wenn es Leute sind, die in der gleichen Firma arbeiten. Das sind dann eher Anwender oder User oder wir haben auch Begriffe bei uns wie Power-User. Power-User sind die, die extrem viel mit der Anwendung arbeiten und auch sehr schnell Feedback haben und die haben auch so meistens, das ist interessant, so spezielle Feedback-Kanäle zu der IT. Ich finde das deshalb wichtig, weil der Begriff Kunde deshalb manchmal falsch verwendet wird. Da entsteht praktisch auch so eine Distanz wieder, zwischen dem, der die Anwendung entwickelt, ja, und dem, der die Anwendung nutzt. Da gibt's auch so ein Hierarchiedenken im Gehirn scheinbar, ja, dass der, der die Anwendung nutzt, erhaben ist über alles. Ja, genau, er ist schon wichtig, aber es muss halt zusammen spielen, finde ich.

Götz Müller: Ja, und im Kontrast halt so zu so etwas Klassischen wie ein Auto, da ist ja typischerweise der Nutzer der, der es irgendwann mal gekauft hat und dafür bezahlt hat. Jetzt bei einem Software-Anwender, der macht ja selber persönlich, so wie ich jetzt hier vor meinem Bildschirm sitze, ich mache ja nicht meinen Geldbeutel auf, oder ich schon, aber jemand in ihrem Kontext, ein Nutzer einer Software macht ja nicht den Geldbeutel auf und der kann sich dann auch … und der hat auch nicht, glaube ich, diesen Hebel zu sagen „Ja, wenn du mir das nicht so entwickelst wie ich das brauche, bezahle ich nicht dafür, wie so jemand anders. Er hat ja gar nicht die Wahl.

Justus Graumann: Ja, er hat aber schon, im innerbetrieblichen Kontext, hat er schon die Wahl, die Software nicht nur zu benutzen, sondern hoffentlich auch Feedback zu geben und das Feedback auch schnell bei dem ankommt, der die Software betreibt. Also die Möglichkeit hat er schon, wenn es, sage ich mal, eine in-house-entwickelte Software ist. Ist es hingegen eine Software, die die Firma kauft von außen, ja, dann musst praktisch … also angenommen die Swiss Re hat jetzt ein Produkt von Software-Firma XYZ gekauft, ja, dann gilt trotzdem, dass eine gute Kommunikation zwischen den Nutzern der Software und dem, der die Software praktisch betreibt oder ein Kontakt da zur Softwarefirma, um dort auch Feedback zu geben. Es geht ja immer bei Software darum, Software wird ja genutzt, um, sage ich mal, Prozesse zu vereinfachen und sollte ja nicht dafür sein, Prozesse zu erschweren.

Götz Müller: Ja und mir kommt noch ein Punkt gerade in den Sinn, weil ich es gerade in einem anderen Kontext, im Grunde bei einem Kunden erlebe, im Software-Kontext ist man dann eher geneigt manchmal, man hat ja die Chance, zu sagen „Da bastle ich mir halt irgendwas mit Excel zusammen“, diese beliebten Schatten-Prozesse, die Schatten-IT, die es einem ja leicht machen. Wenn ich das wieder aufs Auto übertrage, kann ich ja nicht sagen … da könnte man es theoretisch auch machen, da greife ich dann zum Tuning oder so irgendwas, aber da sind dann vielleicht die Möglichkeiten eingeschränkt, während, und speziell wenn wir dann über so Dinge wie low code und no code nachdenken, gehen ja da alle Türen auf und ich finde es immer Stück fast sogar gefährlich und ich glaube, da kommt mir jetzt gerade in den Sinn, deshalb ist es umso wichtiger im Grunde, hinzuhören, was die Nutzer da draußen wollen, um sie nicht irgendwie auf dunkle Pfade zu führen.

Justus Graumann: Ja, das ist auch wichtig, auch dieses Excel-Beispiel ist hervorragend gewählt, ja, weil ich gerade in Finanzabteilungen ist es ja praktisch das Parade-Tools schlechthin, ja, und in der Tat an sich kann man es ja auch nicht verhindern, dass sie das so bauen. Und das geht auch so, wenn wir zum Wertstrom zurückkommen, bei Analysen geht's ja immer darum, erstmal zu verstehen, was passiert eigentlich. Ja, also diesen Ist-Zustand aufzunehmen. Gut, es gibt auch Anhänger, die sagen „Nein, das brauchen wir nicht, wir wollen den zukünftigen Zustand haben“, aber bin eher Verfechter des Ist-Zustand aufnehmen. Und gerade bei solchen Leuten, die jetzt mit Excel anfangen, also das schlimmste, was man machen kann einfach sagen: „Nein. Wir verbieten euch das jetzt einfach.“ Weil die haben das ja nicht ohne Grund gemacht, ja. Meistens weil die bestehende Software vielleicht nicht das abbildet, was sie gerne machen wollen oder es zu langsam ist. Also da kenne ich auch Beispiele, jetzt darf ich nicht zu viele sagen, aber es ist ja heutzutage auch so, das Bild des Fachusers hat sich auch geändert, ja. Die Leute, die in den Fachabteilung sitzen, die können nicht nur Excel bedienen, sondern auch Python-Scripte schreiben und so weiter und das muss man ein bisschen aufnehmen und dann manchmal, wenn man da eine Software einführt, auch solche Fälle dann verstehen und aufnehmen. Damit dann diese Software das dann auch richtig abbildet.

Götz Müller: Genau. Damit sie letzten Endes den Zweck erfüllt, den sich der Nutzer vorstellt und im Grunde ist es ja auch das Einzige, was zählt, weil Software soll ein Problem lösen, einen Prozess ermöglichen, verbessern, beschleunigen und wenn sie das nicht macht, dann verliert sie im Grunde schlagartig …

Justus Graumann: Aber bleiben wir doch bei diesem schönen Beispiel mit dem Excel und, weil das ist, finde ich, auch so essenziell bei dieser Wertstromanalyse, dass man schon ein bisschen einen leicht übergeordneten Prozess abbildet oder darstellt, transparent macht. Es kann ja sein, dass die Person A irgendwo in der Finanzabteilung in dem Prozess diese tollen Excel-Tabellen macht, Daten zur Person B schickt, ja, die hat auch so eine tolle Excel und beide optimieren praktisch in den Jahren immer in den kleinen Excel-Programm herum, wissen aber nichts voneinander, ja, und so etwas gilt es auch in Unternehmen ein bisschen zu verhindern und das geschieht erst dann, wenn man Transparenz über Teams machte. Das finde ich immer eigentlich dieses faszinierende Moment in so Wertstrom-Mapping-Analysen, ja, oder Workshops, wenn die Leute dann mal zusammen sind und dann diesen Ist-Zustand mal aufmalen. Das ist so praktisch wie das Aha-Erlebnis.

Götz Müller: Absolut. Das gibt es im Grunde überall. Das würde ich gern noch ein bisschen vertiefen, diesen, ich glaube die Lean-Menschen kennen natürlich klassisch wieder eine Wertstromanalyse und der Mike Rother hat ja nicht umsonst sein erstes Buch zu dem Thema „Learning to See“, also sehen lernen genannt und jetzt da mal konkret nachgefragt, jetzt ist ja Software nichts, gut, ich sehe eine Benutzeroberfläche, aber so wirklich etwas sehen, wie wenn ich durch die Produktion durchlaufe, da stehen Waren, natürlich Material steht rum, da stehen Maschinen, Anlagen rum, so eins zu eins lässt es ja auf den ersten Blick nicht übertragen und trotzdem, Sie haben es ja schon mehrfach erwähnt, nutzen Sie es. Und deshalb da noch mal hinterfragt, ja, wie funktioniert hier das Sehen lernen, Verstehen dadurch, wenn es eigentlich nichts Physisches zu sehen gibt?

Justus Graumann: Ja, gut es passiert schon etwas Physisches oder es agieren ja eigentlich letztendlich Menschen miteinander in der Nutzung und Entwicklung der Software, bloß der Unterschied ist hier, man hat kein physisches Produkt hier vor sich sagt und sagt, jetzt können wir es anfassen und ein bisschen ausprobieren. Das hat man nicht. Man sieht auch nicht diese ganzen Werkshallen, wie das Produkt entsteht. Was man aber auch erkennen kann, dass man den Prozessablauf, ja, so ein bisschen erkennt, die Möglichkeit hat zu erkennen, wenn man einfach mit den Leuten redet und das klingt jetzt so profan, „Rede doch mal mit den Leuten“, sondern mit den Leuten redet, die wirklich, sage ich mal, Dinge tun. Ja also, in unseren Analysen, wir haben das mit vorgefertigten Interviews gemacht, wir haben uns überlegt, welche Fragen wollen wir stellen, weil wir einfach nicht die Zeit hatten, jetzt, sage ich mal, Projektteams zu begleiten, deshalb haben wir so strukturierte Interviews gemacht und aus diesen Interviews haben wir dann eine Idee entwickelt, wie der Ist-Wertstrom aussieht, ja, aber, und das finde ich immer ganz wichtig, letztendlich war das nur eine Vorbereitungsstufe für einen Workshop. Also die Leute, die an den Interviews beteiligt, die wir interviewt haben, die haben letztlich abgestimmt über diesen Ist-Zustand, das Ist-Verständnis eines Wertstroms, da haben sie gesagt „Ja, das ist es“ oder haben es noch innerhalb des Workshops verändert, aber es ist wirklich eine Kunst, wertfrei zuzuhören. Ich glaube, das ist eine ganz, ganz wichtige Eigenschaft. Ich gebe Ihnen mal ein ganz lustiges Beispiel. Am Anfang, das passierte als Anfänger in diesem Bereich ja wenn man jetzt ein Team einfach so fragt, wie viele Deployments die im Monat haben, also Software-Deployments in Produktion und die sagen einfach, wir hätten nur eins. Und dann kann man natürlich sagen so aus der DevOps-Sicht, das ist jetzt aber komisch, ja, eins klingt jetzt ziemlich wenig und dann könnte man sofort kommen bei so einer Zahl, jetzt will ich die challengen, dass ich sage „Nein, das ist ja so viel zu wenig, was ihr da macht“, aber man muss ja erstmal verstehen, ja, liegt es vielleicht an dem Business Case, dass sie so wenig machen oder dürfen sie nur ein Deployment machen aus regulatorischen Gründen etc. etc. Man muss da also wirklich den ganzen Kontext verstehen und nicht zu schnellen Schlüssen kommen.

Götz Müller: Um vielleicht da auch wieder, ich setze immer so ein bisschen die Brille, oder die Ohren, der klassischen Lean-Menschen auf, jetzt in einem physischen Wertstrom haben wir zwei so ganz große Elemente, wir haben Anlagen, Arbeitsplätze, also da wo Wert entsteht, und dann haben wir zwischendrin immer diese klassischen Pufferlager, die halt dann typischerweise die Durchlaufzeit erhöhen. Was sind so, was sind denn so typische Elemente, sind es auch nur zwei oder sind es eventuell mehr, im Wertströmen in der Softwareproduktion?

Justus Graumann: Ja, es gibt, jetzt muss ich mal so ein bisschen in meinen Gehirn herumkramen, was wir da so erlebt haben, also es gibt ja auch im klassischen Wertstrom so den Begriff des Waste und da gibt es natürlich so … wirklich der Klassiker ist immer, wie die Teams miteinander kommunizieren und lustigerweise gibt's dann solche Sachen, wie wir schreiben mal eine Mail und fragen dann eine Woche später nach, ob da eine Antwort gekommen ist, also diese Wartepuffer sind eigentlich so legendär und auch die Transparenz zum Beispiel über ein Richtfest bei einem anderen Team, das ist praktisch, dass man nicht immer nachfragen muss, sondern es ist offensichtlich irgendwo, wie der Zustand ist. Solche Dinge sind eigentlich immer, finde ich, schon prädestiniert im Bereich Software, Softwareentwicklung.

Götz Müller: Dann höre ich jetzt ein Stück weit raus, im Grunde ist es natürlich ein Informationsfluss, den ich habe, im Vergleich zu einem physischen Produkt, das da langsam angereichert wird, wo dran rumgeschraubt wird, wo dran bearbeitet wird, hier habe ich einen Informationsfluss und da kann an sich genau das Gleiche passieren, wie Sie es gerade angedeutet haben, dass es halt einfach irgendwo mal eine Woche lang rumliegt bis jemand nachfragt in einer Mailbox drin, wo halt jemand von oben oder von unten abarbeitet. Und da kommt mir jetzt der Gedanke, das sind nämlich dann diese typischen, und das lässt sich dann wieder eins zu eins fast übertragen, diese typischen Warte- und Liegezeiten, aus der Brille dessen, der da als Kunde, als interner Kunde, irgendwie etwas haben will und dann da eine Mail oder irgendwas anderes geschickt und dann halt nicht gleich am nächsten Tag sagt, ja „Wie ist es?“, sondern vielleicht eine Woche wartet und dann erst rauskommt, es ist halt eine Woche rumgelegen aus dem und dem Grund.

Justus Graumann: Genau, ja. Was mir immer wichtig ist, ist zu sagen, der erste Schritt ist immer Transparenz zu schaffen. Es geht jetzt nicht erstmal im ersten Schritt das Fingerpointing zu machen, „Das ist schlecht“, sondern es muss erstmal gesehen werden, dass es eine Woche herumliegt, ja, und es muss allen klar sein, also wirklich Transparenz da sein, dass es eine Woche rumliegt und ich weiß nicht, ob der Begriff Gemba Walk, ja, ist ja auch ein klassischer Lean-Begriff und wir haben das so als abstrakten Gemba Walk gesagt, also Gemba Walk wäre eigentlich, wenn man ins Büro geht und dann wirklich den Leuten zuschaut, ja, was passiert jetzt zum Beispiel, wenn jetzt ein Fehler vom User kommt und man sitzt da in der Nähe und beobachtete einfach mal. Und das ist jetzt zurzeit eh nicht möglich, aber auch bei verteilten Teams ist das nicht möglich und deshalb schauen wir dann immer, verschiedene Blickwinkel auf die gleiche Sache zu erhalten und das ist immer ganz interessant, ja. Was wir nicht machen ist, sage ich mal, zum Manager zu gehen und zu sagen „Zeichne mir das mal auf.“, weil das ist praktisch eine PowerPoint-Fiktion, die da entsteht.

Götz Müller: Den kannte ich jetzt noch nicht, aber schön.

Justus Graumann: Ja, den habe ich gerade entworfen.

Götz Müller: Klasse. Jetzt gibt's im klassischen, wieder physischen, Wertstrom ja so einen Effekt des Batchings, so nach dem Motto „Jetzt habe ich hier diese Maschine und wenn ich da fünf gleiche Teile drauf mache und dann anschließend fünf andere Teile, dann muss ich die umrüsten zwischendrin“ und deshalb, um die Maschine möglichst gut auszulasten und möglichst wenig zu rüsten, weil das ist ja, in Anführungszeichen zumindest, nicht wertschöpfend, vielleicht nicht verschwendend, aber auf jeden Fall nicht wertschöpfend, tritt so etwas wie Batching auf, also das heißt, ich mache halt fünf und wenn ich irgendwann merke, da kommt jede Woche einer mit fünf mal fünf, dann ist die Tendenz irgendwie so, ich glaube, im menschlichen Genom verankert, aus klassischen Vorzeiten, dann mache ich halt mal 25 auf einen Schlag, weil dann muss ich nur einmal rüsten. Gibt’s so etwas Vergleichbares auch im Software-Kontext?

Justus Graumann: Ja, einmal gibt’s so eine menschliche Komponente, ja, dieses Work in Progress, das wird von den meisten so ein bisschen leichtfertig unterschätzt, man sagt „Ja, also dann mache ich eben 3-4 Dinge nebeneinander, das stört mich ja nicht“, aber das Problem ist einfach, wenn man sich mal in sich selbst reinschaut, was bedeutet das? Man muss immer den Kontext wechseln, ja, und das bedeutet letztendlich, dass die Arbeit langsamer wird, ja, oder unvollständig, nicht mehr so 100% konzentriert. Das erkennt man auch …

Götz Müller: Also so das klassische Multitasking letzten Endes?

Justus Graumann: Ja, richtig. Und das andere Phänomen ist natürlich so, dass, ich nenne es mal das Scrum-Phänomen, ja, dass man mit Sprints anfängt, man legt dann los und dann kurz vor dem Ende des Sprints stellt man fest, das gesamte Team muss jetzt alles machen, ja, und dann entsteht natürlich so also eine Art Druck, dass man plötzlich am Ende des Sprints so ganz viele Aufgaben auf einmal machen muss, ja, genau. Das ist natürlich auch schädlich. Das wäre das zweite Beispiel. Das dritte ist vielleicht auch, ja, auch etwas Typisches, ja. Angenommen ich bin jetzt Softwareentwickler und habe jetzt, sage ich mal, mein Deployment optimiert, also ich kann jetzt immer viel schneller deployen, sage ich mal, ich deploye jetzt in die Testumgebung, ja, und das geschieht viel besser als früher. Bloß in der Testumgebung wird jetzt, sage ich mal, manuell noch getestet und da sitzt jetzt nur eine arme Socke, ich schätze mal und die muss laufend immer neue Pakete testen und kommt gar nicht mehr voran und da entsteht dann auch so etwas.

Götz Müller: Ja und dass er sagt, dass er sich vielleicht sagt „Ja, jetzt kommen die, morgen kommen sie mit dem gleichen und dieser kleinen Änderung, dann lass ich die eine mal liegen und teste morgen das gemeinsam“, oder?

Justus Graumann: Nein, es kann auch sein, dass dort alles sich verzögert, ja, vom Prozess her. Dass zwar der Entwickler denkt, er ist jetzt ganz schnell, ja, aber dann letztlich, bis es zur Auslieferung kommt, es doch wieder gleich lang dauert, weil dort ein Bottleneck ist, den man aber gemeinsam, wenn man es denn sieht, also ich komme jetzt wieder auf das gemeinsame Sehen, ja, dann kann vielleicht der Entwickler dem Tester helfen, indem er vielleicht Ideen einbringt, wie man Dinge automatisiert, die vielleicht hätten der Tester … vielleicht hat er die Ideen nicht.

Götz Müller: Weil er ja in seine Blackbox reingucken kann und im Grunde am besten weiß, was er da entwickelt hat.

Justus Graumann: Genau, ja.

Götz Müller: Jetzt gibt's im physischen Kontext noch ein ganz zentrales Element, nämlich den Kundentakt und da ist bei mir so ein bisschen das Fragezeichen auch in der Vorbereitung zu unserem Gespräch entstanden: Gibt's eigentlich so etwas Ähnliches? Weil da habe ich mal so bisschen reflektiert aus meinem früheren Leben. Hatten wir so etwas Ähnliches wie einen Kundentakt im Software-Kontext?

Justus Graumann: Das ist eine gute Frage. Kundentakt. Ja, wie definieren wir jetzt Kundentakt? Ich frage jetzt mal zurück, was ist Ihr Verständnis?

Götz Müller: Ja, spontan kam mir dann der Gedanke, es hat so ein bisschen was mit dem zu tun, so dieses continuous integration, dass ich also im Grunde, ja, ständig in der Lage bin, eine lauffähige Software zu haben. Dadurch entsteht dann im Grunde auch das Zweite oder etwas Weiteres, wonach man im Lean-Kontext so strebt, dieser Fluss-Gedanke, nicht dieses Ziehende einerseits, sondern halt fließen, ziehen hat immer noch etwas Aktives, aber am einfachsten ist es ja, wenn es wie so ein ruhiger Fluss so dahin fließt, also ständig, und auf den Software-Kontext übertragen hätte ich jetzt spontan gesagt, eben ständig halt etwas Lauffähiges zu haben und bei jeder Kleinigkeit, wo einer sagt, „Hier, diese Maske gefällt mir nicht, da müssen wir etwas tun.“ und dann fast mit dem Finger schnippen und plötzlich ist da das neue Eingabefeld da, ohne dass jetzt hier tage-, wochenlange Integrationsarbeit notwendig ist, die dann genauso lange dauert bis der Benutzer sein Bedürfnis erfüllt kriegt.

Justus Graumann: Ja, das gibt's natürlich auch, aber man muss immer die Anwendungsfälle schauen, es ist klar, immer Ziel, so einen ruhigen Fluss der Softwareentwicklung herzustellen. Warum? Weil es ein sehr geordneter Prozess, weil es eine stetige Veränderung mitbringt, die Menschen im Prozess sind dann, sage ich mal, diesen Spitzen, also es entstehen keine Arbeitsspitzen mehr, so wie früher, dass Quarterly Release rausgebracht wird, ja, wo dann ganze Pakete zusammengeschnürt werden, und am Wochenende werden die installiert, sondern es entsteht ein ruhiger und stetiger Fluss. Was man aber doch beachten muss, es gibt, wie schon am Anfang gesagt, man sollte jetzt nicht immer erwarten, dass jede Woche einen Produktionsdeployment stattfindet, ja, vielleicht gibt es regulatorische Gründe, warum das in gewissen Zeiten nicht der Fall sein darf und das ist natürlich schon ein, und da kommen wir auch wieder zum DevOps, ja, das ist auch dieser Gedanke, dieser verschiedenen Flüsse, dieser verschiedene Wege, die man im DevOps hat, ja, einmal hat man diese Fluss-Gedanken, dann hat man natürlich … der zweite Weg ist praktisch, wie kriegt man dann ein kontinuierliches Feedback zurück, ja, von dem Anwender, ja, zurück zum Eingang eines Change Requests, sage ich mal, ja, dass das dann vorhanden sein muss. Und der dritte Weg ist, das ist so ein bisschen angelehnt aus diesem berühmten Phoenix-Handbuch, vielleicht kennen Sie das auch, ist natürlich auch, dass man in einer Organisation auch immer so einen Freiraum für Experimente und Learning haben muss, ja, warum ist das so wichtig, weil genau daraus entsteht dann auch Innovation für ganz neue Software oder ganze neue Ansätze, Software zu entwickeln.

Götz Müller: Den Punkt würde ich, ich guck so ein bisschen Richtung Uhr, den Punkt würde ich ganz zum Schluss noch ganz gerne ein bisschen vertiefen, wie man diesen Aspekt kontinuierliche Verbesserung in der Software-Entwicklung, im Software-Wertstrom umsetzt, weil ich auch glaube, und das finde ich immer spannend, wenn ich Unterhaltungen führe mit jemandem, der so im Grunde auf den ersten Blick so ganz weit weg vom klassischen Lean ist und dann aber trotzdem plötzlich unheimliche Ähnlichkeiten oder auch Lernchancen entstehen. Deshalb, und sie hatten es gerade auch ein bisschen angedeutet, wie schafft man es im Software-Kontext, immer so diesen Schritt neben sich zu treten und zu überlegen, wie können wir das, was wir tun, auch noch verbessern, weil das ist jetzt im physischen Kontext auch eine echt große Herausforderung, so nach dem Motto, wir müssen Schrauben machen, wir müssen Schrauben machen oder wir müssen Bäume fällen, haben aber keine Zeit, die Säge zu schärfen.

Justus Graumann: Dazu habe ich etwas sehr Allgemeines, es hängt auch diesen Impuls, dass man etwas verbessern, der muss erstmal von sich selbst kommen. Das ist sehr intrinsisch gelagert, ja. Bloß eine Firma muss die Möglichkeit, diesen Freiraum geben, diesen Impuls auszuleben. Und was wir eigentlich nicht eingeführt haben beim Experimentieren, also wir haben solche Labs oder Community of Practice, haben wir sie genannt, ja, wo dann verschiedene Leute aus verschiedenen Bereichen zusammenarbeiten und, sage ich mal, gewisse neue Technologien erforschen, völlig erstmal ohne Business Case, sondern praktisch so wie in einem Experimentierlabor, ja, und dafür auch gewisse Zeitbudgets bekommen und hier finde ich auch zwei Aspekte ganz wichtig: einmal, dass man neue Dinge lernt, mit anderen, also nicht alleine und dass man mit Leuten zusammenarbeitet, mit denen man normalerweise im Produktteam vielleicht nicht zusammenarbeitet, sondern so ein bisschen über seinen eigenen Tellerrand rausschaut. Das ist dann, sage ich mal, auch der zweite Aspekt bei diesem Community of Practice. Aber noch einmal, es ist sehr wichtig, vielleicht muss man das viel mehr lernen, ja, dass die Leute ein bisschen raus kommen aus ihrer eigenen Komfortzone und so ein bisschen Neugier haben, etwas Neues zu probieren und so auch zu wagen und dem Wagen ist auch etwas ganz Wichtiges zur Risikokultur, ja, einer Firma. Also Fehler müssen dann auch ein bisschen tolerierbar sein oder man muss auch Fehler verstehen. Ich habe jetzt einen lustigen … es ist vielleicht gar nicht so lustig, einen Fall gehabt … da habe ich aus Versehen beim Cloud-Bereich, da haben wir auch einen Experimentier-Workspace gehabt und da hatten wir zu viele Rechte gegeben und das hatte die plötzliche Auswirkung, dass eine Userin aus Versehen zu viel gelöscht hat. Früher, mit dem alten Mindset, was hätte man gemacht? Man wäre sofort zum Vorgesetzten gegangen und hätte dann Tamtam daraus gemacht, ja. Aber man muss eben akzeptieren, okay, das ist halt passiert und daraus auch lernen, ja, was können wir dann verbessern.

Götz Müller: Und einen Impuls ziehen, wie kann ich so eine Situation verhindern, dass zu viele Rechte vergeben werden.

Justus Graumann: Genau.

Götz Müller: Im Grunde auch wieder ganz viele Ähnlichkeiten, und wo Sie gerade erzählt haben, von diesen Runden, da sprang mir sofort der Begriff in den Sinn Quality Circle, was man im klassischen Produktionsbereich macht, wo man halt einfach aber schlichtweg erstmal die Zeit braucht dafür und das ist das Allerwichtigste. Wenn ich den Menschen die Zeit nicht gebe, dann brauche ich mich nicht zu wundern, wenn sie an der Verbesserung nicht mitwirken können und wenn ich es halt auf die Spitze treibe, dann töte ich jeden Impuls, jede Motivation über das reine Tun hinaus zu denken und darüber nachzudenken, was kann ich verbessern. Und das finde ich jetzt hochspannend an unserer Unterhaltung, die ganze Zeit im Grunde schon und jetzt zum Schluss noch mal noch mal verstärkt, dass es im Grunde immer wieder um die gleichen Sachen geht: Laste Menschen nicht zu 100% aus, wenn du möchtest, dass sie besser werden.

Justus Graumann: Genau. Richtig. Ja, das darf man auch beim ganzen Scrum-Ansatz nicht vergessen, ja, Freiräume zu geben, zur Weiterbildung oder zum Experimentieren, weil wenn man immer in diesem Scrum-Rad ist, in diesen Zwei-Wochen-Sprints, darf man einfach diesen Aspekt nicht vergessen, sonst steigt dann auch im Laufe der Zeit immer eine gewisse Unzufriedenheit bei den Leuten. Genau.

Götz Müller: Ja, absolut. Gut. Prima. Herr Graumann, ich fand das wieder, ja, da wiederhole ich mich schon fast immer, weil das ist im Grunde in jeder Episode, aber hier noch mal ganz speziell, weil so auf den ersten Blick die Themen so ganz weit auseinander lagen und trotzdem, also für mich zumindest, im Lauf des Gesprächs unheimlich viele Ähnlichkeiten, ich will nicht sagen entstanden, die waren ja vorher schon da, aber mir persönlich bewusst geworden sind und ich könnte mir auch vorstellen, dem ein oder anderen Zuhörer, dass es immer wieder im Grunde die gleichen Sachen sind, Menschen Zeit geben, den Kontext zu gestalten. Also den Kontext zu gestalten, indem man ihnen Zeit gibt und damit die Chance gibt, zu verbessern, über Dinge nachzudenken, was man tagtäglich tut und zu verbessern. Deshalb ich danke Ihnen da noch mal vielmals für Ihre Zeit, für die interessanten Impulse.

Justus Graumann: Vielen Dank auch für die Einladung, bei Ihnen zu sprechen.

Götz Müller: Das war die heutige Episode im Gespräch mit Justus Graumann zum Thema Wertströme in der Software-Entwicklung. Notizen und Links zur Episode finden Sie auf meiner Website unter dem Stichwort 246.

Wenn Ihnen die Folge gefallen hat, freue ich mich über Ihre Bewertung bei iTunes. Sie geben damit auch anderen Lean-Interessierten die Chance, den Podcast zu entdecken.

Ich bin Götz Müller und das war Kaizen to go. Vielen Dank fürs Zuhören und Ihr Interesse. Ich wünsche Ihnen eine gute Zeit bis zur nächsten Episode. Und denken Sie immer daran, bei allem was Sie tun oder lassen, das Leben ist viel zu kurz, um es mit Verschwendung zu verbringen.