Kaizen 2 go 295 : Transformation nachhaltig gestalten


 

Inhalt der Episode:

  • Transformationsgeschichte mit Ausgangspunkt und Verlauf
  • Was ist dann in der Folge passiert?
  • Was war die Folge daraus?
  • Welche Schlussfolgerungen hast Du daraus gezogen?
  • Wie würdest Du es heute anders machen?
  • Welche Empfehlungen kann man allgemein daraus ableiten?
  • Welche Voraussetzungen sind dafür nötig?
  • Wie bestimmt der Einstieg den weiteren Verlauf einer Transformation?
  • Was kann man tun, wenn man im Verlauf feststellt, dass irgendwas schiefläuft?

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 zukünftig per eMail erhalten.

Artikel teilen auf ...


(Teil)automatisiertes Transkript

Episode 295 : Transformation nachhaltig gestalten

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 aber Erdal Ahlatçı bei mir im Podcast-Gespräch. Er ist Gründer eines Software-Unternehmens und Experte im Bereich Agilität. Hallo Erdal.

Erdal Ahlatçı: Hallo Götz, danke für die Einladung.

Götz Müller: Ja, schön, dass du dabei bist. Ich habe schon ein kurzes Stichwort zu dir gesagt, aber stell dich gern nochmal in zwei, drei, vier Sätzen den Zuhörern vor und im Grunde bist du, glaube ich, ein Stück weit ja auch ganz zentraler Teil unserer Episode und der Geschichte dahinter, ja.

Erdal Ahlatçı: Ja. Also ich bin, gerade bin ich Geschäftsführer, Gründer von agyleOS, davor war ich Mitgründer von einer anderen Firma. Ich habe relativ spät angefangen zu studieren, mit 30, davor habe ich verschiedene Berufe gemacht, das heißt, ich kenne arbeiten in jeglicher Form, dann nach dem Studium, also ich habe Informatik studiert, war ich Softwareentwickler, Projektmanager, Produktmanager, Leiter IT, CTO, COO, CEO, also mehrere Rollen besetzt, und ich mache den Tech-Bereich und zu Agilität kam ich durch Scrum als Softwareentwickler und seitdem bin ich begeistert, und Scrum ist eine Methode, alle möglichen Methoden von Agilität begeistern mich und habe auch sehr viele Erfahrungen sammeln können in den letzten 15 Jahren.

Götz Müller: Ja. Jetzt haben wir heute ja, und ich glaube, der Titel drückt es schon aus, das Thema Transformation, das ist nicht die erste Episode über das Thema, aber das, was ich bei dir rausgehört habe, wo ich dich kennengelernt habe, ist es eben eine spannende Geschichte, was im Grunde unsere ganze Unterhaltung jetzt heute prägen wird, vielleicht zum Einstieg, wir haben ja heute das Thema Transformation und eben wie gestalte ich sie nachhaltig, und da, glaube ich, ist eben ganz wichtig, deine persönliche Erfahrung mit Transformationen, mit einer bestimmten Transformation ein bisschen zu beschreiben, damit die Zuhörer auch wissen, über was wir uns denn unterhalten, also was war der Ausgangspunkt und so ein paar Stichworte zum Verlauf dieser, ja, ich nenne es mal Transformationsgeschichte.

Erdal Ahlatçı: Ja. Also, ich habe ja mit Scrum schon Erfahrungen gemacht habt als Entwickler und in der neuen Firma hatten wir zwei Entwicklerteams und es ist schnell gewachsen. Wir haben ursprünglich mit einem Entwickler angefangen, also das war ich selbst, dann haben wir weitere Entwickler eingestellt und dann waren wir zwei Teams. Das Problem war natürlich auch die Kommunikation mit Nicht-Entwickler-Teams, mit Projektmanagern und das war weit weg von Scrum und wir hatten eine Schulung, so klassisch angefangen, ich kannte schon Scrum, für die anderen haben wir einen externen Trainer geholt, zwei Tage, lief alles gut, alle waren begeistert und dann haben wir gesagt: Ok, wir arbeiten ab jetzt nach Scrum. Das Problem war aber, wenn … also das bringt nichts, wenn einzelne, isolierte Teams noch Scrum arbeiten, wegen der Abhängigkeit von anderen Teams. Und das hat halt immer gekracht, um Werbung für Scrum zu machen, haben wir einen Review Day organisiert. Das heißt, am Ende des Sprints gibt es ja ein Review, wir haben das Review Day genannt und haben alle anderen eingeladen, außerhalb der IT, die praktisch zum Review Day kommen. Wir haben so Plakate aufgehangen, haben Werbung gemacht, als so eine Party, wie so eine Keynote aufgebaut, dann haben die Entwickler präsentiert die Ergebnisse aus der IT und alle waren begeistert. Also eigentlich erwartet man ja von Software-Entwicklern nicht, dass sie gut präsentieren können, dass ist eher so Marketing. Und wir hatten auch viel Spaß, weil das war auch sehr schön, dass alle präsentiert haben, auch schüchterne System-Admins. Die ganzen Vorteile von anderen waren weg und alle waren dann so: „Was ist mit euch los, warum seid ihr so gut drauf? Ich habe Spaß und wie kann das denn sein?“ Und das war dann fast so ein Auftakt, wo die anderen, auch andere Bereiche gesagt haben, wir wollen auch agil arbeiten. So hat das Ding angefangen, dann haben wir auch einen weiteren externen Trainer eingeladen, dann haben wir so ein Transitionteam gehabt. Das ist ein Team, was für die agile Transformation zuständig und die haben auch dort gearbeitet, also mit Sprint, Review, Retro, und dann haben wir Stück für Stück alle Bereiche erstmal zu Agilität informiert, trainiert und Boards aufgebaut, dann haben wir praktisch ein Company Board gehabt, dann haben wir Quartalsplanning eingeführt, dann haben wir Joint Reviews eingeführt. Das heißt, am Ende des Sprints haben zuerst mal nur die Entwickler präsentiert, alle anderen, Marketing, Sales, Beratung, waren als Gäste eingeladen. Der zweite Teil war Nicht-IT-Teams, die präsentiert haben, werden danach auch eingeladen. Später haben wir das aufgehoben und gesagt, das ist ein Joint Review. Wir waren circa hundert Personen, eine Stunde, jeder, der präsentieren möchte, also es war auch kein Zwang, es wird sofort das präsentiert, was live ist, wurde präsentiert, das war dann fast schon ein Highlight, alle zwei Wochen war so ein Synch und dann wurde präsentiert und danach gab es dann Leadership-Pläne, weil das Leadership hat auch agil gearbeitet. Wir hatten auch so einen Sprint und wir haben das auch visualisiert. Wir hatten so ein eigenes Framework entwickelt, also ich habe zuerst SaFe angeguckt, LESS, Spot, aber ich habe gemerkt, das muss etwas eigenes sein, das zu uns passt, und zwar im Endeffekt ScaleScrum. Also wir haben praktisch von Scrum angefangen und geguckt, was machst von Scrum Sinn bei Marketing und was kann man weglassen, haben wir praktisch das visualisiert, an die Wand gehangen, eine Versionsnummer draufgeschrieben, weil die Organisation ändert sich ja und nach sechs Jahren hatten wir Version 6.3.1 und jede war drin. Das heißt, die Organisation war irgendwann auch so durchgetaktet mit Sprints und Agilität, das wir wirklich als Geschäftsführung wirklich extrem wenig Verwaltungsarbeit hatten. Die Teams waren alle selbst organisiert, auch Leadership haben wir natürlich geändert. Wir haben Hierarchien abgebaut, wir haben Leadership so definiert, dass praktisch das, wie die klassische Führungsaufgaben von einem Abteilungsleiter, derjenige muss entscheiden, was gemacht wird, wie etwas gemacht wird, mit welchen Methoden, das haben wir runtergebrochen, dass die Product Owner entscheiden, was gemacht wird. Das Team entscheidet, wie irgendwas umgesetzt wird. Der Scrum Master ist für die Prozesse zuständig und die klassische Führungskraft, wenn es noch eine gab, war für Strategie und andere Sachen zuständig. So haben wir praktisch alle entlastet, also diese klassische Führung, diese Angst bei so einer Transformation ist, dass alle denken „Jetzt wird Hierarchie abgebaut, ich werde gekündigt“. Das gab es bei uns nicht. Klar gab es auch Leute, die am Anfang einen Widerstand hatten, aber das lag hauptsächlich daran, dass sie nicht viel wussten, und das war natürlich sehr wichtig, also Transparenz, dass sie keine Angst haben.

Götz Müller: Mhm, okay. Also im Grunde höre ich auf jeden Fall raus, alles ist im Grunde wie im Bilderbuch so weit das, was du jetzt gerade geschrieben hast.

Erdal Ahlatçı: Ja, absolut.

Götz Müller: Und trotzdem würden wir ja jetzt nicht darüber sprechen, wenn dann irgendwas passiert wäre, woraus man ja etwas lernen kann, jetzt aus einer reinen Bilderbuch-Geschichte, davon gibt es viele, ich glaube, man kann eben aus Dingen mehr lernen, wenn mal etwas nicht funktioniert hat. Das heißt jetzt die Frage ganz einfach, wie ging es weiter? Was ist dann passiert?

Erdal Ahlatçı: Also in der Organisation war es ja auch auf Personen aufgebaut, also die Erfahrung habe ich auch mit anderen gemacht, weil wie du es gesagt hast, weil wir so Agilität nach Bilderbuch gelebt hatten, gab es auch sehr viele Firmen, die uns besucht haben und mit denen Austausch hatten. Ich hatte auch Beratungsanfragen, habe ich auch gemacht. Was mir aufgefallen ist, in der Organisation und auch in anderen Organisationen, es ist immer auf bestimmte Personen aufgebaut, das heißt, in dem Fall war ich Treiber, wir hatten noch einen Agile Coach aus der Firma auch ausgewählt, also keinen Externen eingestellt, weil das waren wirklich auch gute Führungskräfte, die bestimmte Rollen übernommen haben und nachdem ein paar Leute weg sind, auch ich dann, hat das nicht mehr stattgefunden, weil bei so einer Fluktuation, wenn es auf einmal wächst, in der Regel gehen auch viele, und dann, glaube ich, siebzig, achtzig Prozent der Firma waren dann weg und in der Regel passiert immer das Gleiche, weil ich finde, diese Erfahrung habe ich oft gemacht, dass dann praktisch das ganze Wissen weg ist und dann kommen neue Leute, die, auch wenn sie agile Erfahrung haben, kennen sie das Unternehmen nicht, und diese ganzen Artefakte werden nicht mehr stattfinden, diese Kultur ist weg und vor allem die ganzen Rahmenbedingungen. Wir hatten ja praktisch ein eigenes Framework, wir hatten nicht mehr das Organigramm so klassisch hierarchisch aufgebaut und vieles ist dann weggebrochen und da ist mir auch aufgefallen, so eine nachhaltige agile Transformation kann nicht auf Personen aufgebaut werden, weil die Personen verlassen auch das Unternehmen. Gerade im IT-Bereich ist der Durchschnitt in Berlin unter zwei Jahren, das heißt, eine Mitarbeiter bleibt nicht mal zwei Jahre in einem Unternehmen. Und auch bei einem Agile Coach ist es oft so. Deswegen ist das, habe ich festgestellt, dass eine nachhaltige Transformation, also wenn die Organisation sich ändert, tatsächlich auch diese Visualisierung digital sein muss, auch diese KPIs, dass die dann einfach vorhanden sein muss, dass praktisch auch andere reinkommen, auch so dieses Umfeld haben. Also ich vergleiche das mit so einem Fußball-Spiel, also eine gesamte Mannschaft kann sich austauschen, aber die Spielregeln sind klar, es gibt ein Feld, es gibt bestimmte Maße, es gibt ganz klare Regeln, die dort stattfinden, dann kann ich auch sehr schnell sehen, ob jemand auch gut Fußball spielen kann. Aber wenn jedes Mal der gesamte Rahmen weg ist und wir nochmal anfangen, darüber zu reden, wie Fußball gespielt wird, das ist natürlich sehr schwierig, und tatsächlich passiert das auch bei Agilität, nochmal von vorne angefangen. Das ist so meine Erfahrung, die ich gemacht habe.

Götz Müller: Ja, das ist eine schöne Metapher im Grunde, wenn ich es auf Fußball übertragen würde, wird das Spiel neu erfunden, also Fußball an sich und dann braucht man sich nicht wundern, wenn dann vielleicht aus dem Fußballspiel ein Handballspiel, oder Völkerball oder sonst irgendwas und vielleicht ist irgendwann mal gar kein Ball mehr dabei.

Erdal Ahlatçı: Ja, vor allem, man könnte auch nicht erkennen, ob jemand noch gut Fußball spielen kann, weil ich habe ja selber Fußball gespielt, in so einem kleinen Hinterhof spielt man anders als auf so einem großen Feld und wichtig ist ja auch, also dass der Rahmen so ist, dass man auch erkennen kann, wie der Platz ist, ob jemand wirklich Fußball spielen kann. Dafür müssen halt die Rahmenbedingungen schon gesetzt sein und auch stabil sein.

Götz Müller: Ja. Gut, du hast mehrfach betont, es, ja, ich interpretiere es jetzt mal oder drücke es mit meinen Worten aus, es an Personen festzumachen, ist eine große Gefahr, habe ich rausgehört, die Frage ist natürlich dann und du hast andeutungsweise schon gesagt, ich möchte es noch ein bisschen vertiefen, weil ich glaube, das ist das, was den Zuhörern das meiste bringt: Ohne Menschen geht es ja trotzdem nicht. Das heißt, wie vermeide ich diese, ja, vielleicht immer latente Gefahr, dass es halt doch Personen sind, wie bringe ich denen, ja, vielleicht sogar bei, dass sie das Bestreben haben, sich überflüssig zu machen, ohne sich wirklich überflüssig zu machen? Vielleicht wollen sie ja die Firma trotzdem nicht verlassen, in Anführungszeichen, vielleicht gefällt es ihnen ja dort, auch wenn sie nicht so diese Schlüsselpersonen sind.

Erdal Ahlatçı: Na ja, ich gebe mal wieder ein Beispiel mit anderen Bereichen, also zum Beispiel Vertrieb im Unternehmen, also ich meine Vertrieb gibt es ja schon immer seitdem es Firmen gibt und es gab ja auch, früher wurde auch ohne Software gearbeitet, ohne Digitalisierung, da gab es auch den Vertriebsleiter, der dieses Team motivieren und irgendwie lief es, aber wenn dann skaliert worden ist, dann hat es nicht mehr funktioniert. Inzwischen gibt es CRM-Tools, das heißt, auch wenn bestimmte Leute gehen und neue Leute fangen an, dann sehe ich, wo sind meine Leads, wie werden Leads qualifiziert, wie findet Vertrieb statt. Das heißt, ich kann mich, also jedes Unternehmen ist auch anders, aber ich habe halt alles schon auch so da, ich kann’s ja trotzdem ändern und das ist halt auch, was man machen kann. Auch bei Agilität muss zwangsläufig sich einfach die Organisation strukturell ändern. Agilität ist nicht nur so, wie ein Team arbeitet, sondern das ist ein ganz anderes Denken und Handeln im gesamten Unternehmen. Der erste Schritt wäre schon mal, die Organisation anders zu visualisieren, um sichtbar zu machen und es muss natürlich digital sein, wir hatten das damals auch an die Wand gehangen, hat irgendwie funktioniert, wie gesagt, das kann man auch nicht so ändern und das ist auch nicht so nachhaltig. Damit fängt es schon mal an, damit auch später auch die Änderungen stattfinden können und neue Leute sofort sehen können, wie ist jetzt die agile Organisation aufgebaut, also wie kommuniziert Produktteam mit den Entwicklern, gibt es in jedem Team einen Product Owner oder ist das Produktteam zusammen ein Product Owner, gibt es Produktmanager oder nur Product Owner? Das sind erstmal so die Rahmenbedingungen, die dargestellt werden müssen und auch sichtbar ist, welche Teams machen was von Agilität. Also zum Beispiel, es macht keinen Sinn, dass ein Marketingteam Komplexitätschats mit Poker, das macht ja gar keinen Sinn, weil die haben ja keine komplexen Aufgaben, sondern viele Aufgaben. Dann macht Kanban mehr Sinn. Oder gibt es einen Delegation Board? Und so weiter. Und das kann man alles visualisieren und auch so, ich nehme da entweder Scrum-Checklists oder agile Checklists, um auch sichtbar zu machen, in welchem Team gibts dieses Artefakt, also muss nicht unbedingt sein. Daily Standups kann Sinn machen, jeden Tag, bei anderen macht es weekly Sinn und das ist halt gut, wenn man das visualisiert und bei Klick sofort sehen kann, damit ich weiß, die machen das, ich kann da mal auch ändern und sagen, was passiert dann. Dafür brauch ich halt auch bestimmte Umfragen und das wird auch immer wieder gemacht, bei Unternehmen, die nicht nachhaltig sind, aber es sind halt einmalige Sachen, da wird das am Anfang gemacht, dann wird es irgendwie ein paar Monate später nochmal gemacht, aber ich sehe den Progress nicht und also in der Firma, die wir jetzt gegründet haben, das war aus der Not entstanden, weil wir damals so eine Software nicht hatten, ist genau so, dass auch die Teams das auch selber machen können, dass die Dashboards haben und auch alles sehen können. Also wir hatten in der letzten Firma alles an der Wand gehabt, Jahresplan zum Beispiel. Das ist sehr, sehr wichtig. Es gibt sehr komplizierte Sachen, aber eigentlich geht es ja darum, dass einzelne Teams wissen wollen, in dem Sprint, die arbeiten an einer Aufgabe, die wollen ja nur wissen, warum mache ich das, was ist der Sinn dahinter. Das muss möglich sein, mit einem Klick zu sehen, wo hängt das zusammen. Wo ist der Zusammenhang von einem Jahres-, Quartalziel, weil das ist eine Haftigkeit. Viele Teammitglieder sind frustriert, weil sie irgendwas machen, dann wird ein Sprint abgebrochen oder umpriorisiert. Das könnte natürlich ein Product Owner vorarbeiten, aber es fehlt das große Ganze und nachhaltig ist für mich, wenn praktisch alle ähnliche Informationen haben. Das hast, wenn ich die gleichen Informationen habe wie das Ziel-Level, dann bin ich mehr motiviert und am Arbeitstag selbstorganisiert, weil ich kann ja nicht selbstorganisiert arbeiten, wenn ich praktisch einfach so Sachen einen Teamleiter oder jemand anderen fragen muss. Also das ist so sehr wichtig, dass es halt eben nicht auf Personen irgendwie aufgebaut ist, weil wenn jetzt mir ist neue Personen reinkommen, die haben das alles digital und in der Software, dann sehen sie, wie diese Organisation aufgebaut ist. Wie sind die Jahresziele? Wie sind die Artefakte, bestimmte Umfragen wie psychologische Sicherheit, wie sieht das aus. Und ich kann einfach da miteinsteigen und weiter die Organisation ändern, aber ich muss nicht noch mal von vorne anfangen, weil es gibt irgendwie in Confluence irgendwas, dann gibt's ein Miro-Board. Das ist einfach so durcheinander, dass einfach tatsächlich gerade Agilität, also für so Transformation wird extrem viel Geld ausgegeben, aber es wird dann praktisch vergessen, wie man das praktisch nachhaltig darstellen kann, visualisieren und messbar machen kann, also managebar. Das ist ein bisschen schade, weil davon hängt es auch ab. Das ist so, im Kurzen dargestellt mal, wie man es anders machen kann.

Götz Müller: Ja, ich höre jetzt, wenn ich das halt durch meine Prozessbrille betrachte und du hast das Stichwort selber auch genannt, es müssen halt stabile Prozesse da sein und jetzt würde ich fast so weit gehen, zu sagen, in einem Produktionsumfeld, und ich selber habe auch mal ein früheres Leben als Software-Entwickler gehabt, und die große Herausforderung in der Software-Entwicklung ist halt im Vergleich zu einer Hardware-Entwicklung, und das habe ich, weil ich da auch an einer Schnittstelle tätig war, habe ich das immer ganz deutlich gemerkt und wir haben das auch damals diskutiert, wenn ich halt eine Hardware, also eine gedruckte Leiterkarte produzieren will, dann muss ich halt bestimmte Regeln einhalten, damit ich es überhaupt produzieren kann, während eine Software, da ist die Produktion halt, die Software-Entwicklung und danach kommt in Anführungszeichen nichts mehr und deshalb, das haben wir damals, und das ist jetzt schon zwanzig plus Jahre her, das haben wir damals so in der Reflexion, das war noch weit vor agil, ist uns das klar geworden, ja, deshalb tut man sich in der Software-Entwicklung so schwer und das habe ich jetzt bei dir noch mal ganz deutlich rausgehört, wie wichtig diese stabilen Prozesse sind, eben jetzt im Scrum, agilen Umfeld, was ja auch ein Framework, ein Prozess-Framework letzten Endes darstellt, kann man doch so ausdrücken, oder?

Erdal Ahlatçı: Ja, kann man ausdrücken, ja.

Götz Müller: Ja, sehr spannend und ich glaube, das ist das auch, wenn ich es halt übertrage, jetzt wieder in den Lean-Kontext, wo es genau die gleichen Effekte gibt, dass es halt an Personen hängt, eine Lean-Transformation, da habe ich zwar vielleicht einerseits, wenn ich jetzt ein produzierendes Unternehmen bin, habe ich vielleicht stärker diese Produktionsprozesse, aber diesen, nennen wir es mal Meta-Prozess, wie gehe ich denn mit Lean und Co um, dass ich überhaupt so etwas habe, da werde ich den Verdacht nicht los, und jetzt in unserer Unterhaltung ist es noch stärker geworden, dass man sich die Gedanken so nicht macht, während und da, glaube ich, kann man wieder aus dem agilen Scrum-Kontext wieder etwas lernen, dort schon drauf geachtet wird, dass ich eben den Scrum-Guide zum Beispiel einhalte, um mal ein Stichwort zu nennen, weil da jemand festgestellt hat, ja, wenn ich mich daran halte, tue ich mich leichter, wie wenn jeder, im Grunde des Rad, oder bei der Fußball-Metapher, das Spiel neu erfindet.

Erdal Ahlatçı: Ja, also bei mir ist, also mir ist es auch sehr wichtig zu wissen, das geht gar nicht, dass es irgendwie starre Regeln gibt, das ist gar nicht, was ich meine. Es geht ja darum, dass man erst mal so bestimmte Rahmenbedingungen hat und da sich weiterentwickeln kann. Das kann sich ändern, also Fußball ist ja vielleicht zu starr, was das Fußballfeld angeht, aber bei, klar, bei Produktion, ich habe, ja, also ich habe am Fließband gearbeitet, ich habe bei BMW am Fließband gearbeitet, wo man alle zwei Minuten ein Auto, das ist ja wirklich Produktion ohne Ende, da kann man nicht viel bewegen. Es geht hier darum, dieses Inspect und Adapt ist ja sehr wichtig, das sollte man machen, aber das muss auch so geregelt sein, dass es auch möglich ist. Also mir geht es hier wirklich darum, dass man diese Möglichkeit hat, das zu machen. Dafür müssen erstmal die Rahmenbedingungen definiert sein, also kann ich das machen und beim Ausprobieren, die Teams wollen ja ausprobieren, die können mehr ausprobieren und dann anpassen, wenn sie auch Informationen überall haben. Gerade bei Software ist es ja sehr komplex. Ich weiß es noch nicht, ich kann auch teilweise nicht schätzen, ich kann’s nicht in Zeiteinheiten sagen und deswegen kann ich hier nur eine Referenz ein bisschen nach Komplexität schätzen, aber um sich permanent zu verbessern, brauche ich ja auch Information, Also bei Software-Entwicklung ist es auch sehr wichtig, wer ist im Team, also ist die Teamkommunikation an sich sehr gut. Und das kann bei Umfragen helfen, bei Feedback-Möglichkeiten helfen. Dann ein anderes Problem, ist die Fähigkeiten der einzelnen Mitglieder im Team wird oft von HR gemacht. Die HR-Leute stellen andere Menschen ein, die denken zu wissen, wer Senior, wer Junior ist und die meisten Probleme sind bei Software, was ich gesehen habe, ist die Kommunikation im Team und die fehlenden Skills und auch eine Angstkultur und deswegen, das bringt ja nichts, so wie ich jetzt Agilität feststelle, aber die Rahmenbedingungen nicht dafür habe und da kann man jetzt wieder sagen, okay, das ist jetzt gute Führungskultur, die Menschen sind das, aber dafür gibt es ja keine Garantie, aber ich kann's mit einer Skill-Matrix, was ein Tool für das Team ist, das so visualisieren, dass das Team selbst einschätzt und erstmal irgendwie sechs Leute kommen zusammen und sagen, wir sind irgendwie Fullstack-Entwickler, Backend, Frontend, dann gucken wir mal, wer kann im Frontend bestimmte Sachen, wer im Backend und eine Selbsteinschätzung. Oft heißt es dann aber, bei so einer Selbsteinschätzung kann es ja sein, dass sie sich irgendwie verschätzen. Das kann sein, aber andersrum ja auch, aber nach zwei Runden, spätestens nach ein paar Sprints kommt man noch mal zusammen im Team und dann guckt man sich dann, wenn man sich so immer noch näherkommt, das Team weiß dann auch, welches Skills in dem Team fehlen und kann dann praktisch selbstständiger entscheiden. Das sind so für mich Rahmenbedingungen, damit das Team praktisch auch etwas ändern kann und für Software ist es sehr wichtig, das Team braucht so viele Informationen wie möglich, damit sie immer wieder etwas ausprobieren können, das bewerten werden können, dann noch mal ausprobieren können und das ist so eine Skill-Matrix. Das ist ein Tool, das machen auch einige Teams mit so Zetteln, aber auch mit einer Software, die das für die Teams so einfach macht, auch den anderen Teams zeigt, vielleicht noch weiter geht und so eine Skill-Datenbank aufbaut, mit, wie gesagt, immer sehr wichtig, mit Selbsteinschätzung der Teams, dass man auch schnell Hilfe holen kann. Das heißt, wenn ich in einem Problem nicht weiterkomme, dann muss ich nicht sagen, wir brauchen hier einen Experten, sondern einfach selbstständiger guckt. Wir haben zum Beispiel bei AgyleOS in unserer Software so eine Skala, dass man sehen kann bei einem Skill praktisch sehen kann, wer hat diesen Skill am meisten oder auch bei Personen, wer ist der Erfahrenste im Unternehmen, in der Organisation. So kann ich selbständig, auch Hilfe holen.

Götz Müller: Mhm, ja. Gut, jetzt haben wir uns ein bisschen, oder nicht nur ein bisschen, sondern ein bisschen mehr darüber unterhalten, was schief gehen kann und wie man erste Punkte, ich möchte mal sagen, vermeiden kann, wenn es denn aufgetreten ist und um es jetzt vielleicht ein bisschen auf eine, wie soll man das ausdrücken, vielleicht auf eine höhere Ebene zu bringen, auf eine Meta-Ebene zu bringen, was kann ich am Anfang tun, also im Grunde, bevor ich mit einer Transformation gestartet habe oder wenn ich, ja, eben noch am Anfang stecke, was kann ich da schon tun, um dann speziell diesen Punkt, den wir immer wieder diskutiert haben, dass nicht von Personen abhängig zu machen, wie kann so etwas von Anfang an gelingen?

Erdal Ahlatçı: Ja, ich glaube auch von Anfang erstmal, den Ist- Zustand auch zu visualisieren und damit auch loslegen, damit ich eben auch den Fortschritt auch sehen kann. Also tatsächlich mit den gleichen Methoden loslegen, also das ist auch, was ich immer empfehle, weil das ist auch, wenn wir AgyleOS präsentieren, kommt immer das Argument: Ja, wir sind ja noch nicht so weit. Also das, was du gesagt hast. Wir müssen erstmal praktisch agil werden, dann können wir das nutzen, aber das ist falsch, weil im Endeffekt will ich ja auch sehen, hat die Transformation auch etwas gebracht, wenn ich den Anfangszustand nicht weiß, kann ich auch nicht später sagen war das gut, was wir gemacht haben. Also im Endeffekt, ob das jetzt Skill-Matrix ist, die Visualisierung der Organisation, auch wenn es jetzt ein Organigramm ist, das kann man ja auch ein bisschen anders visualisieren und sagen: Jetzt haben wir einen Abteilungsleiter, der ist dafür zuständig. Das heißt, ich mache da einen Schritt, also das ist auch Inspect und Adapt auch bei der Transformation so vorzugehen. Also wirklich zu sagen, okay, wir haben jetzt einen Sprint gemacht, die Organisation ein bisschen verändert, gehen wir in die Retro, gucken, was hat sich verändert und das digitale einfach zeigen, das kann ich von Anfang an machen, tatsächlich auch diese ganze Visualisierung von Anfang an zu beginnen, damit man auch sagen kann, wohin geht es. Also wir haben vor kurzem auch den Namen der Firma, das ist ein ziemlich große Unternehmen, wir haben Forschungsarbeit gemacht, wirklich Wissenschaftler eingeladen und gesagt, wir wollen agil werden, wollen aber auch wissen, bringt das etwas, sie haben alle KPIs erhoben, zuerst mit Wasserfall und dann, wenn ein paar Teams agil geworden sind, dann verglichen, dann konnten sie ganz genau sagen, 30% gestiegen, 20% da, auch mehrere Betrachtungsweisen, angefangen von den Menschen im Unternehmen, also von HR bis Produktivität bis Qualität, weil das ist auch so meistens immer leicht gesagt, dass man sagt ja, wenn wir agil sind, wird alles besser. Aber es gibt ja, ich meine, ich finde also man sollte nicht agil werden, um irgendwie noch mehr Performance zu zeigen, sondern eigentlich, weil man Lust darauf hat, weil es einfach auch mehr Qualität ist, aber man kann das auch messen und dafür müssen wir erst mal wissen, was habe ich jetzt und wo will ich überhaupt hin und das kann man von Anfang an auch machen.

Götz Müller: Ja, jetzt finde ich es spannend. Du hast in deinen letzten Sätzen den Begriff im Grunde Zustand verwendet, also ich bin agil als Unternehmen, das würde ich eben als eine Zustandsbeschreibung betrachten und ich entsinne mich an die Situation, das ist schon ein paar Jahre her, da hatten wir einen Lean-Stammtisch hier in Stuttgart und da haben wir über die Frage diskutiert „Wann ist ein Unternehmen lean?“, also im Sinne eines Zustands, wann bin ich denn, ja, angekommen vielleicht und wir sind dann sehr schnell zu dem Punkt gekommen, wo wir gesagt haben, wenn ich glaube, ich bin lean, dann habe ich im Grunde schon verloren, weil dann jede Veränderung zum Stillstand kommt. Ich bin es ja, ich bin ja irgendwo angekommen und jetzt die Frage an dich als jemand, der im agilen Umfeld sehr, sehr zuhause ist. Gibt es im agilen Kontext auch so etwas, dass man im Grunde vorsichtig sein muss, ich drück’s mal auch wieder ein bisschen vorsichtig aus, zusagen „ich bin …“ oder geht es nicht auch, nicht zu unterschätzen wichtig darum „ich werde …“

Erdal Ahlatçı: Ja, also so ein Zustand von Agilität, dass wir sagen, wir sind agil, würde ich sagen, gibt’s nicht so. Also man könnte sagen „Wir sind agil“ kann ich sagen, wenn ich beweisen kann, zeigen kann, dass ich auf eine Veränderung reagieren kann, also proaktiv oder reaktiv und die Veränderung zu meinem Vorteil machen kann, dann bin ich agil, aber es kann sich ja auch ändern, das heißt, es ist ja ein permanenter Zustand, wie ich am Anfang gesagt hatte, wir hatten unserem Framework Versionsnummern gegeben, weil die Organisation hört nie auf, sich zu verändern und die Veränderung ist ja jeden Tag, deswegen kann ich nicht sagen, wenn ich heute agil reagiert habe „Wow, da haben wir es jetzt gut gemacht.“, dann kann sich da später etwas ändern. Es geht ja nur darum, ist die Organisation, die Teams in der Lage, auf so eine Veränderung zu reagieren und diese Veränderung zu ihrem Vorteil zu machen. Das ist diese permanente Frage und auch kann ich praktisch iterativ ein Problem lösen und diese ganzen KPIs, es geht ja nicht darum, dass man einen Zustand dann erreicht und dann sagt „Endlich ist es so weit.“, es geht darum, dass man wie in so einem Flugzeug auch Cockpits hat, dass ich weiß, wohin ich fliege. Also es gibt natürlich ein Ziel, das ist klar, aber der Weg kann sich da ändern, aber das ist kein Ziel, wo ich irgendwo ankomme. Agilität ist auch kein Ziel. Ich habe meine Ziele, die ich mit Agilität besser erreichen möchte, aber es geht hier wirklich darum, irgendwie so kontinuierlich zu verbessern. Also ich möchte sehen, es gibt immer Retros und die Idee von Retros ist ja, einfach eine sehr lernende Organisation zu werden, aber ich möchte sehen, ist das auch so. Das heißt, wir haben jetzt, ich kenne das aus Erfahrung, es werden Retros, das ist ein super Retro, die Atmosphäre ist sehr gut, es werden Actions definiert, was zu machen ist, was besser werden muss und dann würde ich mich interessieren, zu sagen: Okay, wir haben jetzt ein Jahr, zwei Jahre gemacht, sind wir dann besser geworden? Mit besser geworden meine ich: Sind wir jetzt in der Lage, dass wir das immer, was wir immer gesagt haben, das können wir besser machen, haben wir uns das vorgenommen und haben wir das auch geschafft, weil es geht ja darum, dass auch die Organisation sich verbessert mit der Zeit und ich bin ein großer Fan davon, mit wenigen Menschen viel zu erreichen, das macht mehr Spaß als immer mehr Leute einzustellen ist. Die Firmen, die sehr schnell wachsen, die stellen auf einmal hunderte Leute ein und oft wissen sie gar nicht, was sie wollen, sondern erstmal alle einsammeln, gerade Tech Companies und je mehr es sind, desto mehr Komplexität und ich habe die Erfahrung gemacht, je agiler ich geworden bin, desto weniger, also wir haben niemanden gekündigt, sondern wir haben nicht mehr so viele einstellen müssen, weil die Einstellung ist ja so typisch HR, irgendwie geht nichts voran, vielleicht brauchen wir andere, statt zu sagen, vielleicht machen wir, also vielleicht sind wir nicht agil genug. Das heißt, es hört nicht drauf, aber es ist immer so, je agiler das Team ist, desto schneller kann ich adaptieren und darum geht es einfach, den Zustand zu gucken, aber nicht vom Endzustand, sondern eher zu sagen, ok, wie entwickelt sich das gerade, weil es kann auch wieder schlechter werden und das ist auch menschlich und das ist auch gut so, damit ich mich wieder verbessern kann, darum geht es eigentlich.

Götz Müller: Ja und ich greife mal deine Metapher des Flugzeugs auf. Einerseits ist, sagt man ja immer so schön, im Grunde ist Flugzeug, wenn es mit Autopilot fliegt, ist die ganze Zeit vom Kurs ab und der Autopilot oder auch der Pilot, der Mensch steuert es wieder auf den Kurs zurück und dann lande ich irgendwann, dann komm ich also an, an meinem Zielflughafen, aber jetzt ist ja auch nicht so, dass ich jetzt das Flugzeug in den Hangar schieben und dort bis zum Sankt-Nimmerleins-Tag stehen lasse, sondern ich werde ja wieder losfliegen. Und ich mache vielleicht eine Wartung zwischendurch, dass das Flugzeug weiterfliegen kann, dass nicht irgendwas kaputt geht, aber im Grunde ist das Flugzeug, bei Schiffen sagt man es ja auch, Schiffe sind nicht für den Hafen da und das Flugzeug ist nicht für den Flugplatz da, sondern das Flugzeug ist da, um zu fliegen, also ständig unterwegs zu sein und im Grunde würde ich sagen kann, ich kann ich das auf Organisationen und deren Entwicklungen eins zu eins übertragen.

Erdal Ahlatçı: Ja, und das Cockpit ist sehr wichtig, damit ich eben weiß beim Fliegen, also fliegen ist leicht, wenn man in der Luft ist, aber es ist eigentlich sehr kompliziert und wenn man nicht Pilot ist und diese ganzen Messgeräte im Cockpit kennt, wird man erschlagen, aber das ermöglicht, dass man irgendwie beruhigt sitzen kann, also wenn ich in einem Flugzeug sitze und in dem Cockpit keine Messdaten sehen würde, würde ich eher mir mehr Sorgen machen.

Götz Müller: Ja, sehr spannend, sehr spannend. Vielleicht so ein bisschen als eine Frage zum Abschluss: Was, wenn jetzt jemand, vielleicht von den Zuhörern, in irgendeiner Form von Transformationen drinsteckt und merkt vielleicht, hat vielleicht jetzt in unserer Unterhaltung die ersten Warnzeichen für ihn selber rausgehört, was kann ich jetzt tun, wenn ich merke, irgendwas läuft schief? Was wäre so dein Tipp zum Abschluss an jemanden, der in so einer Situation steckt und damit unzufrieden ist? Was kann er tun?

Erdal Ahlatçı: Also immer das große Ganze sehen. Also ich merke das immer, wenn ich irgendwie in einem Unternehmen bin und die sagen „Wir sind agil. Wir arbeiten agil.“, dann sage ich: „Zeig doch mal.“ Dann zeigen sie oft halt so diese Boards mit bunten Zetteln oder sowas und wenn es so ein bisschen chaotisch ist, dann heißt es immer: „Ja, wir sind in einer Transformationsphase, das ist so eine Baustelle.“ Also ich würde wirklich auch wieder, ich wiederhole mich gerne, erstmal visualisieren, damit ich weiß, wie kann das sein. Weil wie gesagt, es gibt nicht … also es ist wirklich schlimm für jemanden, der diese Transformation verantwortet, irgendwie festzustellen, wo das hakt, wenn ich das große Ganze nicht sehe. Ich würde sofort anfangen, zu visualisieren, ein paar Experten fragen, gern auch AgyleOS, da kann man auch mal gucken, weil ich brauche ein Tool dafür. Also die gleiche Frage wäre, wenn ich merke, unser Vertrieb läuft nicht, das ist ja sehr klassisch, der Chef sagt „Wie kann das sein, unsere Verkaufszahlen gehen runter“, wie guckt man das, indem man einfach Zahlen nimmt, guckt, warum haben wir die Gründe verloren, also Daten, Daten, Daten. Auch bei Agilität und agiler Transformation. Also immer wieder zu behaupten, dass ist ja ein Mindset und es fehlt am Mindset finde ich schlimm, weil das wird ja, also Menschen werden so denunziert als hätten sie nicht die richtige Gesinnung. Das finde ich fatal, weil ich glaube, jeder Mensch ist in der Lage eigentlich zu arbeiten. Das ist die Aufgabe von dem Unternehmen, dafür zu sorgen, und das kann man visualisiert und messen, also wo man geradesteht und das würde ich empfehlen. Tatsächlich faktenbasierte Entscheidungen zu treffen, wirklich die Fakten zu ermitteln, woran es hängt.

Götz Müller: Ja, sehr spannend. Im Grunde in jedem Satz, auf die eine oder andere Art und Weise, habe ich bei dir Dinge rausgehört, die man eben eins zu eins auf Lean und alles was dazugehört übertragen kann. Deshalb, Erdal, ich danke dir für deine Zeit, ich fand das eine spannende Unterhaltung mit jemanden, in Anführungszeichen, von der anderen Seite, aus einem ganz anderen Kontext und ich bin mir ziemlich sicher, dass der ein oder andere Lean-Zuhörer da viele Inspirationen bekommen hat, die er auf sein eigenes Umfeld übertragen kann. Deshalb noch mal vielen Dank für deine Zeit.

Erdal Ahlatçı: Ja, danke auch und ich bin auch immer mehr neugierig auf die Lean-Welt. Ich glaube, ich werde mich auch jetzt damit mehr beschäftigen.

Götz Müller: Das war die heutige Episode im Gespräch mit Erdal Ahlatci zum Thema Transformation nachhaltig gestalten. Notizen und Links zur Episode finden Sie auf meiner Website unter dem Stichwort 295.

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.

Hinweis: Ich behalte mir vor, Kommentare zu löschen, die beleidigend sind oder nicht zum Thema gehören.