Kaizen 2 go 027 : Scrum, agile Software-Entwicklung, Lean

Inhalt der Episode

Vorteile von Scrum und agilen SW-Entwicklungsmethoden
Herausforderungen und Fehler bei der Scrum-Einführung
Rolle der Führungskräfte und deren Unterstützung
Mitarbeiterentwicklung im Scrum-Umfeld
Standards in Scrum und der SW-Entwicklung

Notizen zur Episode

Ihnen hat der Inhalt gefallen? Dann bewerten Sie die Episode jetzt bitte bei Apple Podcasts.

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

Artikel teilen auf ...

(Teil)automatisiertes Transkript

Eine KI-generierte Zusammenfassung finden Sie am Ende des Transkripts.

Episode 027 : Scrum, agile Software-Entwicklung, Lean

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 Ruth Wächter bei mir. Wir werden uns unterhalten über das Thema Scrum, agile Softwareentwicklung und Lean. Herzlich willkommen, Ruth.

Ruth Wächter: Hallo, herzlich willkommen ebenfalls.

Götz Müller: Schön, dass du dabei bist heute. Jetzt möchte ich als erstes dich wie sonst bitten, stell dich doch einfach kurz unseren Zuhörern vor.

Ruth Wächter: Okay, also ich bin die Ruth Wächter, bin Wirtschaftsinformatikerin, habe auch programmiert, aber dann habe ich schon recht bald den Scrum Master Job für mich als meinen Beruf gefunden. Ich komme eigentlich wo ganz anders her. Ich habe ein künstlerisches Studium hinter mir und ein geisteswissenschaftliches Pädagogik studiert. Habe dann in Schulklassen unterrichtet, habe Ensembles geleitet und Chöre dirigiert. Habe auch im Leistungssport ein Innovationskonzept für die Trainingsarbeit geschrieben. Also kurz gesagt, ich habe immer andere Menschen dazu befähigt, über ihre Grenzen hinaus zu wachsen. Und genau das ist so mein Punkt, womit ich jetzt auch antrete. Mittlerweile programmiere ich nicht mehr, sondern konzentriere mich ganz und gar darauf, IT-Teams zu fördern, zu begleiten und ihnen zu helfen, noch besser zu werden. Also mein Fokus liegt auf der IT-Prozessberatung, besonders die agilen Prinzipien und Scrum.

Götz Müller: Genau, und das war ja dann auch der Impuls für mich persönlich, dich zu bitten, doch an unserem Podcast-Gespräch teilzunehmen. Ein paar Stichworte hast du schon genannt. Das Thema, es kommt auf die Menschen an, das ist ja auch im Lean-Umfeld ganz zentral, auch wenn es manchmal übersehen wird und vernachlässigt wird. So eine erste Frage zum Einstieg. Was ist denn aus deiner Sicht besonders bei agiler Softwareentwicklung, bei Entwicklungsprojekten und den zugrunde liegenden Prozessen zu beachten?

Ruth Wächter: Also zunächst mal ist ja in der agilen Softwareentwicklung alles so ein bisschen auf den Kopf gestellt. In der klassischen Softwareentwicklung kennt man das so, man bekommt das Projekt, plant das ganz genau, und dann läuft das so paar Monate oder auch Jahre und am Schluss gibt man was ab und wenn man Glück hat, war es dann auch das Rechte. In der agilen Software-Entwicklung geht das fast andersrum. Da legt man nicht den Inhalt fest, sondern die Zeit und das Geld, das der Kunde ausgeben möchte und so grob, was er will. Und dann bekommt er genau zu festgesetzten Terminen einen Teil von seinem Produkt, was dann schon funktioniert. Er weiß nur eins, er weiß, wann die Termine sind und er weiß, wie viel Geld er dafür ausgibt, aber er kann nicht genau wissen, was er da inhaltlich bekommt.

Das ist das Neue und meiner Erfahrung nach tun sich da doch viele Teams ein bisschen schwer, so alteingesessene Programmierer, die das erst andersrum gemacht haben, die sagten, wir müssen genau das fertig kriegen. Und der will genau das haben, egal was es kostet und wie lange es dauert. Und jetzt ist das alles umgekehrt.

Also ich würde sagen, man muss dann auch in der Programmierung ein bisschen anders vorgehen. Sehr viel von Anfang an testgetrieben, sehr modular. Schon von Anfang an immer im Blick haben, wir wollen was fertig kriegen. Es muss dann nach drei, vier Wochen wirklich was laufen. Und, ach ja, was auch noch ganz wichtig ist, der Kunde. Der Kunde ist in der agilen Softwareentwicklung immer mit dabei und sehr aktiv. Er muss da mitspielen und im Allgemeinen macht er das gern. Er gibt ja immer das Feedback und gestaltet das ganze Projekt von Anfang an mit.

Götz Müller: Ja, ich denke, das ist auch der, wie du schon gesagt hast, der große Unterschied, die Einbeziehung des Kunden. Aus meiner eigenen Softwareentwicklungserfahrung weiß ich nämlich auch, dass er ja am Anfang gar nicht immer, aber ganz oft nicht wirklich weiß, was er denn will bzw. Braucht. Und von daher einen Plan zu machen von etwas, wovon die Beteiligten am Anfang ja nicht wirklich sicher sind, dass es das dann sein wird, was zum Schluss rauskommt, hat ja eben auch seine Vorteile. Und auf die Vorteile möchte ich jetzt noch ein bisschen mehr eingehen. Was sind denn aus deiner Sicht die größten Vorteile agiler Softwareentwicklung?

Ruth Wächter: Gerade darauf bezogen, dass es diese kurzen Lieferzyklen gibt, wird natürlich das Risiko minimiert, dass am Schluss das Ganze vielleicht dem Kunden gar nicht so gefällt. Also das kann nicht passieren. Denn der Kunde sieht dann vielleicht schon nach dem dritten oder vierten Zyklus, oh, das war nicht so richtig das, was ich dachte. Und dann kann man das korrigieren.

Weiterhin dadurch, dass von Anfang an Test getrieben und auch oft in Pair-Programming gearbeitet wird und zum Beispiel auch mit Scrum, werden sofort irgendwelche Defizite und Fehler und Mängel sichtbar, die sonst so vor sich hin trillen und vielleicht erst nach Monaten überhaupt zum Tragen kommen, wenn mal einer einen Test schreibt. Also wenn das Projekt auffliegt, fliegt es gleich am Anfang auf. Das mag ein Vorteil sein. Es gibt dann auch noch einen Vorteil durch diese in sich abgeschlossenen Einheiten, die man liefert. Ist es viel leichter möglich, einen Cut zu machen, wenn es denn nötig werden sollte? Also ohne Konventionalstrafen, ohne diesen ganzen Hickhack, wie rechnen wir jetzt ab? Denn der Kunde hat ja seine fertigen Teile und die können abgerechnet werden. Also das Auseinandergehen würde sehr viel einfacher funktionieren.

Götz Müller: Ja, ich denke, dieses Liefern in kurzen Zyklen immer nur kleine, unfertige Dinge zu haben. Fachbegriff Work-in-Process. Das sind ja auch Dinge, die eben dem Lean-Gedanken zugrunde liegen. Und ich finde es sehr spannend, dass es hier, ich weiß nicht genau, inwieweit die Menschen die agile Softwareentwicklung ins Leben gerufen haben, inwieweit die Lean-Gedanken im Hinterkopf hatten. Wenn sie es hatten, finde ich es nämlich als Lean-Verfechter eine interessante Sache. Ich finde es aber eben auch interessant, wenn Sie es nicht hatten, dass Sie auf vergleichbare Ideen kamen.

Ruth Wächter: Soweit ich weiß, hatten sie es und zwar sehr stark. Denn zumindest die beiden Entwickler von Scrum haben den Lean-Gedanken etabliert in den Retrospektiven, wo es genau darum geht, diese Prozesse zu verbessern. Das hat da also einen ganz festen Bestand drin. Also so allgemein agil, das weiß ich jetzt nicht, aber da waren ja ganz viele dran beteiligt.

Götz Müller: Ja, das ist dann ein Stück weit wieder Wasser auf meine persönlichen Mühlen oder vermute ich auf die anderen Lean-Verfechter, dass eben die Lean-Gedanken nicht nur, das ist ja so eine Argumentation, der wir sehr oft begegnen, eben nicht nur in klassischer Produktion möglich sind, sondern eben auch in sowas Unikat-getriebenen wie einem Softwareentwicklungsprojekt. Das sagte schon der Begriff Projekt, was ja als wichtiges Kriterium die Einmaligkeit zugrunde liegen hat, eben dort auch Lean-Prinzipien einsetzbar sind. Jetzt ist natürlich aber trotzdem eine gewisse Herausforderung, so in den klassischen Bereichen der Softwareentwicklung Lean-Aspekte einzuführen oder eben Scrum-agile Aspekte einzuführen. Was sind denn so die Herausforderungen, mit denen Unternehmen rechnen müssen, wenn Sie Scrum einführen, wenn Sie agile Entwicklungskonzepte einführen?

Ruth Wächter: Nun, es ist so, dass die agilen Prozesse, ganz besonders natürlich Scrum, zunächst mal ganz viel transparent macht, ganz viel offen legt. Auch die Mitarbeiter werden ja dazu ermutigt, Stellung zu nehmen, zu benennen, was sie hindert bei der Arbeit, was sie stört.

Und da kann doch ganz vieles plötzlich offengelegt werden, was bis zu dem Tag in einem Unternehmen so mitläuft und so ein bisschen unter den Teppich gekehrt wird. Das ist ganz sicher eine große Herausforderung, damit dann umzugehen. Und es entsteht auch oft für das Unternehmen dann doch ein gewisser Handlungsdruck, weil alle erwarten, dass dann diese Hindernisse abgeschafft werden. Es gibt also offene Kritik, Unruhe, all diese Dinge, die man dann händeln muss und worauf sich ein Unternehmen einstellen muss. Darüber hinaus ganz sicher Unsicherheit bei den Mitarbeitern. Jetzt ist plötzlich wieder alles neu. Auch die Transparenz. Ich weiß, dass nicht jeder die mag, also nicht jeder Entwickler mag, dass plötzlich offengelegt wird, wie gut sein Code wirklich ist oder wie wertvoll oder wie intensiv seine Arbeit ist. Ja, und viele gehen dann ja auch.

Also ich würde sagen, je nach Kultur, die im Unternehmen zu dem Zeitpunkt herrscht, gibt es einen mehr oder weniger krassen Veränderungsprozess.

Ein Problem ist auch noch, also so habe ich es erlebt, dass oftmals das Management sieht, mit Scrum oder mit agilen Methoden könnten wir hier sehr viele Probleme lösen. Dass die Mitarbeiter dann aber zwar die Dringlichkeit sehen, dass Probleme gelöst werden müssen, aber dass die noch lang nicht so sehen, dass das mit Scrum passieren muss. Und das sind solche Dinge, wo ich nur raten kann, die vorab doch ein bisschen zu klären, ehe man da Hals über Kopf in Scrum oder Agile reinstürzt.

Götz Müller: Ja, kann ich mir sehr gut vorstellen, sind auch durchaus Dinge, die man bei einer Lean-Einführung, wo sich auch im Unternehmen viel verändert, vergleichbar sieht. Mir kam gerade ein Gedanke wieder in den Kopf, das habe ich so Mitte der 90er Jahre erlebt, so dieser Aspekt Transparenz, den du gerade genannt hast, da wurde bei meinem damaligen Arbeitgeber Softwaremetriken eingeführt. Und das ist natürlich ein sehr vergleichbares Thema, wo plötzlich Softwareentwickler messbar wurden, in Anführungszeichen. Denn in meinem persönlichen Erleben von damals, Ich habe noch in kaum ähnlichen anderen Bereichen so starke Produktivitätsunterschiede bei dem, was eben Menschen leisten, wenn wir es mal von körperlichen Aspekten absehen, wie eben in der Softwareentwicklung. Also ich habe damals durchaus, ja, über den Daumen gepeilt, Faktor 10, wenn man es jetzt zum Beispiel an Lines of Code in der Zeiteinheit misst, habe ich da Produktivitätsunterschiede erlebt.

Und da kann ich mir schon vorstellen, dass sowas jetzt nicht nur auf ungeteilte Begeisterung steht.

Ruth Wächter: Da nennst du einen ganz heißen Punkt, der mit den Metriken. Da stürzen sich die Leute ja immer drauf und wollen unbedingt messen, wie viel sie besser werden. Und das ganz Schlimme bei diesen Metriken ist ja, sie werden immer erfüllt. Also die Betroffenen werden alles dafür tun, dass die Metriken erfüllt werden. Und das ist so ein Schuss nach hinten, den man sich dann gar nicht klar macht. Also wenn wir als Metrik festsetzen, es kommen weniger Bugs oder Lines of Code, es werden jetzt mehr geschrieben, Lines of Code pro Woche. Dann kann man sicher sein, dass nach einiger Zeit tatsächlich mehr Lines of Code geschrieben werden. Und es werden auch irgendwie seltsamerweise weniger Bugs auftreten, weil natürlich die Mitarbeiter dann versuchen, diese Metrik zu erfüllen, wie auch immer.

Das ist also ein ganz gefährliches Pflaster und am Ende misst man dann unter Umständen gar nicht das, was man eigentlich messen wollte. Schön, dass du das Beispiel genannt hast. Sehr abschreckend.

Götz Müller: Ja, da gilt dann auch wieder der alte Spruch der meistens Elektroingenieure, wer misst, misst Mist.

Ruth Wächter: Ja, der kriegt das, was er misst.

Götz Müller: Genau. So, da haben wir jetzt auch schon einen interessanten Aspekt aufgegriffen, der nämlich auch zu meiner nächsten Frage, zu meinem nächsten Gesprächsimpuls führt. Was sind denn die Fehler, die Unternehmen immer wieder machen, wenn sie Scrum einführen und umsetzen?

Ruth Wächter: Also den Hauptfehler, den ich immer wieder sehe, der ist ganz einfach ein Missverständnis. Es heißt dann immer, ja, wir führen Scrum ein, denn Scrum ist was unheimlich Gutes und dann wird es auch alles gut. Unsere Programme werden besser, wir werden schneller und produktiver mit Scrum. Dabei ist ja eigentlich das Gegenteil der Fall. Scrum selbst ist gar nichts Gutes, sondern ich würde sagen, Scrum ist ein Spiel mit ganz fiesen Spielregeln, die nämlich alles offenlegen. Und dann sind viele Unternehmen furchtbar enttäuscht oder auch verzweifelt, wenn durch die Einführung von Scrum erst mal gar nichts besser wird, sondern alles nur noch schlimmer und ganz, ganz viele schlimme Dinge rauskommen.

Das ist ein Missverständnis wo denke ich auch Scrum Master sehr damit kämpfen müssen also zum Beispiel ich das klar zu machen nein Scrum deckt auf und das was Scrum aufdeckt die Mängel die könnt ihr verbessern und wenn ihr das tut dann wird alles besser aber nicht weil Scrum eingeführt wird. Ich denke also, dass das Unternehmen sich klarmachen muss, ob sie dann im Ernstfall wirklich alle auch etwas verändern wollen. Es bringt nichts, Scrum einzuführen und zu sagen, ja, wir hatten dann aber so Phasenmodell und Wasserfall und das wollen wir aber so auch beibehalten, weil das können wir so schnell nicht ändern. Das geht natürlich dann der Schuss eher nach hinten weg. Also das finde ich sehr problematisch, wenn die Bereitschaft nicht da ist, auch Grundlegendes zu ändern.

Götz Müller: Das hört sich für mich sehr ähnlich an zu dem Dilemma, was wir manchmal oder ganz oft im Lean-Management haben. Es geht ja unter anderem darum, die Durchlaufzeit zu reduzieren und Durchlaufzeit wird in vielen Fällen durch Zwischenpuffer, zwischen einzelnen Bearbeitungsschritten hervorgerufen. und ja, was macht man natürlich? Man reduziert halt die Zwischenpuffer. Heißt auch da, dass der Fluss in der Produktion dann oft zum Halten kommt und dass dann das große Heulen und Zähneklappern losgeht und dann bis hin zu Wüstenbeschimpfungen auftreten, Wüstenbeschimpfungen vielleicht in Anführungszeichen. Lean funktioniert nicht und unsere Produktion kommt deshalb zum Stillstand, weil wir hier das Mittel der Zwischenpufferreduktion einsetzen.

Ruth Wächter: Genau. Das ist ein schönes Beispiel. Das ist bei Scrum zum Beispiel genauso. Es wird Scrum eingeführt. Alles geht schief, weil natürlich ganz viele Sachen jetzt plötzlich rauskommen. Und dann heißt es, das böse Scrum ist schuld. Das passt bei uns einfach nicht und überhaupt ist es schlecht. Wir machen wieder so wie bisher und kehren zurück zu unserer Wasserfallmethode und zu unserem Phasenmodell. Das war eben doch viel besser.

Oder was ich noch schlimmer finde, ist, dass die Schuld abgegeben wird an das Team. Das also heißt, du Team, du hast versagt, weil jetzt hättest du dich selbst organisieren können, du hast das nicht hingekriegt und das ist eine ganz üble Sache. Da kriegt das Team dann Schuldgefühle und es wird ein Druck aufgebaut, auch ein psychologischer und ein Gruppenzwang, wo die Leute teilweise gar nicht mehr wissen, wie sie da wieder rauskommen sollen. Sie wollen eigentlich nur gute Arbeit machen und jetzt plötzlich kommt ein falsch verstandenes Scrum und wird ihnen da aufoktroyiert. Also ich kann eigentlich nur empfehlen, das nicht selber irgendwie zu machen, sondern sich professionelle Hilfe, einen professionellen Coach oder Berater zu holen, der das Ganze begleitet und wirklich schaut, dass solche Ausrutscher nicht passieren.

Götz Müller: Ich könnte mir auch vorstellen, zumindest erlebe ich es im Lean-Umfeld so, dass sich eben auch die Rolle der Führungskräfte an der Stelle wandelt. Es muss eine, ja ich denke auch da eine andere Fehlerkultur sein. Eingeführt werden, umgesetzt werden, eben der Grundgedanke, Fehler sind nichts Schlimmes, sondern Fehler sind eine Chance, Dinge zu verbessern, die wahrscheinlich vorher schon da waren, die nur eben jetzt im Lean-Umfeld unter einem großen Zwischenpuffer versteckt wurden oder im Scrum-Umfeld eben, wie du es vorhin genannt hast, transparent gemacht werden und dadurch die Chance zur Verbesserung da ist. Wie erlebst du die Rolle der Führungskräfte in der agilen Softwareentwicklung?

Ruth Wächter: Es ist ganz unbedingt so, wie du gesagt hast. Die Führungskräfte, die dürfen ja nicht plötzlich abdanken. Also es hilft sicher nichts, wenn die Führungskräfte sich dann zurücklehnen und sagen, ach schön, es läuft jetzt irgendwie alles selbst organisiert. Und ich habe leider auch erlebt, was es heißt, wenn die Führungskräfte oder die Führungskraft ihre Führung nicht mehr übernimmt. Das heißt, sie verantwortet bis zuletzt die Folgen einer solchen Lean- oder Scrum-Einführung. Die Verantwortung liegt bei der Führungskraft und nicht bei den Teams, was die Folgen anbetrifft. Und wenn die überfordert sind oder wenn sie etwas falsch verstehen oder eben Fehler machen, dann muss trotzdem jemand da sein, der das ganze Unternehmen zusammenhält und die Richtung nach wie vor vorgibt. Das heißt, die Führungskraft muss sagen, wohin wollen wir, was sind jetzt die Spielregeln, nach welchem Prinzip gehen wir vor.

Und ganz wichtig, die Führungskraft etabliert ja auch diese neue Kultur, die entstehen soll. Also man sieht an deren Verhalten, wie ernst das Ganze gemeint ist.

Ich denke da an Anreizsysteme oder auch Beförderungskriterien, Gehaltserhöhungen. Wer kriegt die? Wer sich so benimmt, wie es dem agilen Mindset entspricht oder kriegt es halt doch der mit den stärkeren Ellenbogen? Und dann ist das Ganze schon kaputt. Dann ist es nicht mehr glaubwürdig.

Götz Müller: Jetzt finde ich einen Aspekt, den du gerade genannt hast, den finde ich sehr spannend, Weil das erlebe ich jetzt im Lean-Umfeld eher etwas anders. Du hast erwähnt, dass so ein, vielleicht sind es aber auch nur sekuläre Ereignisse, dass Führungskräfte sich hier eher zurücklehnen und sagen, ja, das Team macht es schon. Im Lean-Umfeld begegnen mir ganz oft die Sorge der Führungskräfte, dass ihre Rolle infrage gestellt wird.

Ruth Wächter: Ja, und genau diese Sorge oder sagen wir diese Unsicherheit kann ja zu zwei Extremen führen. Der eine kann seine Kontrolle nicht abgeben, also er hat Angst, dass dann ihm alles entgleitet und er mischt sich dann doch ein oder kommt und sagt, wie es gemacht werden muss. Und dann gibt es aber andere, die sind dann ganz verschüchtert, weil der Berater gesagt hat, oh, ihr dürft jetzt da nicht mehr Anweisungen geben, ihr müsst euch jetzt da raushalten, die machen das jetzt allein. Und um ja nichts falsch zu machen, sagt er jetzt gar nichts mehr. Also ich habe beides erlebt und beides ist schwierig. Und ich denke, es ist auch wirklich schwierig, da das Mittel war es zu finden, nicht mehr Anweisungen zu geben, Aber sehr wohl präsent zu sein, zu begleiten, zu ermutigen, nachzufragen, Hilfe anzubieten, ich denke, das ist oft eine Gratwanderung.

Götz Müller: Was würdest du sagen, wie kann man Führungskräfte bei den Veränderungen am besten unterstützen?

Ruth Wächter: Nun, die externen Berater hatten wir ja schon jetzt im Gespräch. Finde ich in jedem Fall eine Hilfe, weil die auch fachlich über die Hintergründe Bescheid wissen, weil sie schon vorher wissen, wo Fallstricke sind, was man also besser nicht machen sollte. Es kann auch der Scrum Master sein, der von Haus aus ja auch die Aufgabe hat, einfach da zu sein, aufzuklären, Probleme vorauszusehen. Es gibt da noch einen interessanten anderen Aspekt, dass nämlich im Unternehmen selbst sich für so eine Einführung oder für so einen Veränderungsprozess eine kleine Koalition bildet. Dass also unter den Führungskräften sich vielleicht zwei, drei zusammentun. Und in dem Moment bildet sich schon ein kleines Team und es kann gegenseitig Ermutigung, Korrektur stattfinden. Gegenseitig kann man schauen, was wollen wir eigentlich erreichen. Im Alleingang wird das schwer sein für eine Führungskraft. Das sind so die drei Punkte, die mir so einfallen.

Götz Müller: Okay, das geht auch ein bisschen in die Richtung meiner nächsten Frage. Was sollten denn Entscheider, also typischerweise eben auch eine Unternehmensführung, was sollte die denn tun, wenn sie Scrum, wenn sie agile Konzepte im Unternehmen einführt? Ein Aspekt, den ich jetzt gerade herausgehört habe, ist eben, die Verantwortlichen unterstützen in ihrer neuen Rolle, in ihrer veränderten Rolle zu unterstützen. Was gibt es denn noch für Dinge, die Entscheider hier fürs Unternehmen, fürs Team, für alle Beteiligten tun können?

Ruth Wächter: Ich würde in so einem Fall so ähnlich vorgehen, wie wenn ich einem Kunden ein Produkt herstellen oder verkaufen will. Da frage ich ja auch erstmal, was war eigentlich dein Problem? Was war der Auslöser dafür, dass du daran gedacht hast, ein neues Produkt zu wollen? Was erhoffst du dir damit? Und all diese Fragen im Unternehmen selbst aufzustellen. Wie kamen wir eigentlich auf den Gedanken, jetzt gerade Scrum einzuführen? Was schwebt uns vor? Wo wollen wir hin? Und unter Umständen kann man dann feststellen, dass das ja gar nicht nur mit Scrum geht, sondern dass man da auch was anderes machen könnte dafür, dass das Problem also wo ganz anders liegt. Bedeutet die Vorab-Analyse, wie ist die Produktart, die hergestellt werden soll? Ist das überhaupt ein komplexes Produkt oder ist das genau terminiert? Dann brauchen wir auch keinen Scrum und auch kein Agile. Wie ist die Kundenstruktur? Machen die Kunden überhaupt mit?

Wie war die bisherige Arbeitsweise? Und dann vor allem, wo wollen wir hin? Warum? Das Zweite, was man sich überlegen könnte, in welcher Art Scrum eingeführt werden soll. Es gibt ja nun nicht immer nur dieses dogmatische Bilderbuch Scrum, so voll und ganz, in der ganzen Firma, sondern es gibt die Möglichkeit, erstmal ein kleines Pilotprojekt zu starten. Oder es gibt die Möglichkeit, in einem abgeschlossenen Studio oder Raum da mal ein Produkt durchlaufen zu lassen mit der ganzen Unterstützung des Unternehmens, wo man aber noch nicht die Unternehmensstrukturen als Ganze ändern muss. Das sind alles solche Fragen, die sicher sehr hilfreich sind, wenn man sie vorab durchgeht.

Götz Müller: Ja, auch das sind Aspekte, wo ich wieder eine hohe Ähnlichkeit zu Lean entdecke, nämlich auch dort ist ein Ansatz nicht so das Unternehmen komplett am ersten Tag auf den Kopf zu drehen und überall gleichzeitig auf den Knopf zu drücken und sagen, Tschakka, jetzt machen wir Lean, sondern auch dort an Pilotprojekten, an Pilotabteilungen das Thema einführen, um daraus zu lernen, bestimmte Fehler bei der Einführung vielleicht nur einmal zu machen oder nur in einem kleinen Rahmen zu machen, um dann an anderer Stelle sofort wieder daraus zu lernen. Jetzt möchte ich noch auf einen Punkt eingehen, den wir am Anfang kurz hatten, das Thema Produktivitätsunterschiede, wo ich jetzt im persönlichen Erleben aus der Historie heraus weiß, dass es diese großen Produktivitätsunterschiede gibt, wie auch immer man die jetzt messen mag.

Was gibt denn das Thema Scrum, Agilität, was gibt es denn neben der Transparenz her, hier einen Ausgleich zu schaffen? Natürlich einen Ausgleich nicht im Sinne von, dass die Guten schlechter werden, sondern dass die nicht so guten eben besser werden.

Ruth Wächter: Ja, okay. Also zaubern kann ja jetzt Agilität sicher auch nicht. Und eins muss man ganz klar sagen. Aus einem Team aus lauter Entwicklern, die nichts drauf haben, da lässt sich auch mit Scrum nichts machen. Also da lässt man dann besser die Finger von. Agile Softwareentwicklung geht schon aus von mündigen Entwicklern, die irgendwo ihr Handwerkzeug verstehen. Und wenn das nicht der Fall ist oder weniger der Fall ist, Und dann gilt auch da, dass entweder der Scrum Master oder vom Team her der Impuls kommt, hör mal, wir haben da zwei Leute, die tun sich wahnsinnig schwer mit Testen, die verstehen das überhaupt nicht, wie sie das entwickeln könnten. Was machen wir da? Entweder man schickt sie dann auf eine Fortbildung oder organisiert sich im Team.

Also ich habe schon erlebt, dass ein Team zum Beispiel für Leute, die neu reinkommen, so ein kleines Empfangensbuch geschrieben haben, wo so die wichtigsten Sachen drinstehen und auch die Grundregeln, wie man was macht, um relativ schnell auf den gleichen Standard zu kommen. Also Antwort wäre, einerseits sorgt das Team selbst organisiert dafür, dass das einfach hinkommt.

Und dann, zweite Antwort wäre, durch den Aspekt des Pair-Programming, der ja im agilen Kontext sehr verbreitet ist, würde schon so eine Art Mentor-Schüler-Verhältnis entstehen, wo der Schwächere sehr, sehr schnell lernen kann. Und das dritte ist gezielte Weiterbildung, dass die Leute ihre Sachen hinkriegen.

Götz Müller: Jetzt unterliegt ja auch das Thema Software-Entwicklung, Projektmanagement im Allgemeinen und die Prozesse, die darunter wirken, unterliegen ja ständiger Veränderung, hoffentlich auch Verbesserung. Was ist denn so ein bisschen dein Blick in die Glaskugel aus dem Lean-Gedanken raus? Sind natürlich Arbeitsstandards sehr favorisiert, weil sie eben die stabile Basis darstellen. Arbeitsstandards meine ich jetzt im Software-Entwicklungsumfeld nicht unbedingt so etwas Plattes wie Codierrichtlinien. Was würdest du sagen, was da so die Zukunft noch bringen wird?

Ruth Wächter: Diese Frage halte ich für sehr wichtig. Also so wie ich sie verstehe, ist die Tendenz zur Zeit ein kleines bisschen in die Richtung, wir machen alles maßgeschneidert, wir machen das alles individuell und da muss man dann mal schauen.

Jede neue Entscheidung, die man treffen muss, wie so ein Arbeitsablauf geht, wie viele Meetings angesetzt werden, kostet unheimlich viel Energie und Kraft. Und genau die fehlt nachher bei der Arbeit. Ich halte es also für gerade jetzt für Zukunft sehr wichtig, Standards zu haben, auch Prozessabläufe zu haben, welche auch immer. Die Orientierung geben, die Halt geben, damit in so eine Arbeit Ruhe oder auch ein Rhythmus einkehren kann. Ich würde mal fast sagen, lieber den falschen Standard oder den nicht ganz so passenden, dann aber den wirklich konsequent, dass jeder weiß, woran er ist, was kommt und man sich auf die Arbeit konzentrieren kann.

In Scrum ist ja dieser Standard relativ ausformuliert. Da weiß jeder Bescheid. Man trifft sich, man macht die Retrospektiven, man plant so und so und das entlastet ungeheuer. Und auch Lean hat ja diese einzelnen Schritte, diese einzelnen Aspekte, die befolgt werden. Man hat immer etwas, woran man sich orientieren kann. Also um kurz zu antworten, ich halte es bis sehr wichtig, dass sie bleiben.

Götz Müller: Ja, Arbeitsstandards eben und die Routine, die daraus entsteht, du hast es gerade schon angesprochen, entlastet eben. Und ich gebe dir auch da völlig recht, Lieber nicht ganz die Mitte treffen, aber kontinuierlich knapp daneben lässt sich viel leichter korrigieren, wie mal links vorbei, mal rechts vorbei, mal oben vorbei, mal unten vorbei.

Ruth Wächter: Ja, ich meine, das ist in der Kindererziehung ja genau dasselbe. Man sagt dem Kind, du darfst das oder du sollst das nicht machen. Das Kind hat die Regeln und wenn die ständig umgeschmissen werden, irgendwann weiß das Kind ja dann auch nicht mehr, was überhaupt Sache ist. Und deswegen bin ich kein Freund davon, dass man Scrum einführt und dann gleich mal am Anfang sagt, das gilt auch bei uns nicht und das auch nicht und das machen wir auch ein bisschen anders. Dann ist nämlich dieser ganze Standard, der Hilfe und Orientierung geben könnte, auch wieder weg.

Götz Müller: Ja, eben auch von anderen Lernen, Fehler, die unter Umständen andere gemacht haben oder Entwicklungen, die andere schon durchgemacht haben, die muss man ja nicht notwendigerweise wiederholen. Ich denke, das war jetzt auch ein guter Abschluss. Ruth, ich danke dir für deine Zeit in dem Gespräch. Ich fand, da kamen spannende Themen hoch, eben auch, was die Beziehung zwischen Scrum Agile auf der einen Seite und Lean auf der anderen Seite angeht. Ja, vielen Dank nochmal für deine Zeit.

Ruth Wächter: Ich bedanke mich auch für das spannende Gespräch und auf Wiedersehen.

Götz Müller: Das war die heutige Episode im Gespräch mit Ruth Wächter zum Thema Scrum, agile Softwareentwicklung und der Bezug zu Lean.

Wenn Ihnen die Folge gefallen hat, freue ich mich über Ihre Bewertung bei Apple Podcasts. 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.

KI-generierte Zusammenfassung

In dieser Episode spricht Götz Müller mit Ruth Wächter über Scrum, agile Softwareentwicklung und die Verbindung zu Lean-Prinzipien. Ruth Wächter stellt zunächst ihren beruflichen Hintergrund vor. Sie ist Wirtschaftsinformatikerin, war anfangs selbst als Programmiererin tätig und arbeitet heute als Scrum Master und IT-Prozessberaterin mit Schwerpunkt auf agilen Prinzipien. Ihre Laufbahn begann jedoch im künstlerischen und pädagogischen Bereich. Sie leitete Ensembles, unterrichtete Schulklassen und entwickelte im Leistungssport Innovationskonzepte. Der rote Faden ihrer Tätigkeit ist die Befähigung von Menschen, über sich hinauszuwachsen. Heute begleitet sie IT-Teams dabei, ihre Zusammenarbeit und ihre Ergebnisse kontinuierlich zu verbessern.

Im Gespräch erläutert Ruth Wächter die grundlegende Umkehrung, die agile Softwareentwicklung im Vergleich zum klassischen Vorgehen bedeutet. Während im traditionellen Modell Inhalt, Funktionen und Spezifikationen möglichst vollständig zu Beginn definiert werden und Zeit sowie Budget sich daraus ergeben, wird in der Agilität Zeit und Budget fixiert. Der Kunde erhält in kurzen, festen Zyklen lauffähige Teilergebnisse. Der genaue inhaltliche Umfang bleibt flexibel. Diese Herangehensweise stellt insbesondere erfahrene Entwickler vor Herausforderungen, die an langfristige Planung und vollständige Spezifikationen gewöhnt sind.

Ein zentrales Merkmal agiler Entwicklung ist die enge Einbindung des Kunden. Dieser gibt kontinuierlich Feedback und beeinflusst die Priorisierung. Dadurch sinkt das Risiko, am Ende ein Produkt zu liefern, das am Bedarf vorbeigeht. Durch kurze Iterationen, testgetriebenes Vorgehen, modulare Architektur und Praktiken wie Pair Programming werden Fehler früh sichtbar. Probleme werden nicht erst am Ende eines langen Projekts erkannt, sondern möglichst in den ersten Zyklen. Zudem ermöglicht die Lieferung in abgeschlossenen Inkrementen ein vergleichsweise einfaches Beenden eines Projekts, da bereits nutzbare Teile vorliegen.

Götz Müller stellt die Verbindung zu Lean her, insbesondere zum Gedanken der Reduzierung von Work in Process. Ruth Wächter bestätigt, dass insbesondere bei Scrum Lean-Gedanken bewusst integriert wurden, etwa in den Retrospektiven, die der kontinuierlichen Verbesserung dienen. Beide betonen, dass Lean-Prinzipien nicht auf die Produktion beschränkt sind, sondern auch in projektorientierten, wissensintensiven Umfeldern wie der Softwareentwicklung wirksam werden.

Ein großer Themenblock sind die Herausforderungen bei der Einführung von Scrum. Ruth Wächter beschreibt, dass agile Methoden vor allem Transparenz schaffen. Hindernisse, ineffiziente Strukturen und kulturelle Probleme werden sichtbar. Das erzeugt Handlungsdruck und kann Unruhe auslösen. Nicht alle Mitarbeiter begrüßen diese Transparenz, insbesondere wenn Leistungsunterschiede offengelegt werden. Je nach Unternehmenskultur fällt der Veränderungsprozess unterschiedlich intensiv aus.

Ein kritischer Punkt sind Metriken. Beide Gesprächspartner reflektieren die Gefahr, falsche Kennzahlen zu setzen. Wenn etwa Lines of Code oder Bug-Anzahlen als Maßstab dienen, werden Teams Wege finden, diese Kennzahlen zu erfüllen, ohne dass sich die tatsächliche Wertschöpfung verbessert. Die Messgröße bestimmt das Verhalten, nicht zwingend das gewünschte Ziel.

Als häufigsten Fehler bei der Scrum-Einführung benennt Ruth Wächter ein grundlegendes Missverständnis: Scrum wird als Lösung für Probleme betrachtet. Tatsächlich deckt Scrum Missstände auf. Verbesserungen entstehen erst durch die anschließende konsequente Bearbeitung dieser Defizite. Unternehmen, die nach der Einführung feststellen, dass zunächst mehr Probleme sichtbar werden, reagieren oft mit Enttäuschung oder Schuldzuweisungen. Besonders problematisch ist es, wenn Teams für Schwierigkeiten verantwortlich gemacht werden, obwohl strukturelle Ursachen zugrunde liegen.

Die Rolle der Führungskräfte ist dabei entscheidend. Führung darf weder in Kontrolle verharren noch sich vollständig zurückziehen. Führungskräfte behalten die Verantwortung für Richtung, Rahmenbedingungen und Kultur. Sie müssen Klarheit über Ziele und Spielregeln schaffen und eine konstruktive Fehlerkultur etablieren. Gleichzeitig gilt es, Selbstorganisation zu ermöglichen, ohne Orientierungslosigkeit entstehen zu lassen. Beide Extreme, Mikromanagement oder völliger Rückzug, sind hinderlich.

Zur Unterstützung von Führungskräften empfiehlt Ruth Wächter externe Begleitung durch erfahrene Berater oder Scrum Master. Zudem kann eine kleine Koalition engagierter Führungskräfte innerhalb des Unternehmens hilfreich sein, um sich gegenseitig zu reflektieren und zu stabilisieren. Für Entscheider ist eine gründliche Vorabklärung zentral: Warum soll Scrum eingeführt werden? Welches Problem soll gelöst werden? Ist das Produktumfeld überhaupt komplex genug für einen agilen Ansatz? Auch Pilotprojekte bieten sich an, um Erfahrungen im kleinen Rahmen zu sammeln.

Produktivitätsunterschiede innerhalb von Teams lassen sich nicht durch Agilität allein ausgleichen. Agile Methoden setzen grundsätzlich kompetente Entwickler voraus. Verbesserungen entstehen durch gegenseitiges Lernen im Team, durch Pair Programming und gezielte Weiterbildung. Teams können eigene Standards und Onboarding-Hilfen entwickeln, um neue Mitglieder schneller auf ein gemeinsames Niveau zu bringen.

Abschließend diskutieren Götz Müller und Ruth Wächter die Bedeutung von Standards. Trotz individueller Anpassungen braucht es stabile Prozessrahmen, um Energie zu sparen und Orientierung zu geben. Standards schaffen Rhythmus und entlasten, weil nicht jede Entscheidung immer wieder neu getroffen werden muss. Entscheidend ist, diese Standards konsequent anzuwenden und nicht vorschnell aufzuweichen. Kontinuität bildet die Grundlage für echte Verbesserung.

So entsteht ein differenziertes Bild: Scrum und Lean sind keine Wundermittel, sondern strukturierte Ansätze, die Transparenz schaffen, Verantwortung klären und kontinuierliche Verbesserung ermöglichen, sofern Führung, Kultur und Bereitschaft zur Veränderung zusammenwirken.

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

Artikel teilen auf ...