Kaizen 2 go 325 : Bottom-up Agile und Lean


 

Inhalt der Episode:

  • Was war der Auslöser dafür, dass Du Dich mit dem Thema “Bottom-up” beschäftigt hast?
  • Was sind typische Gründe, wenn eine Organisation nicht “will”?
  • Welche konkrete Vorgehensweise schlägst Du vor, wenn es generelle Vorbehalte gegen agile Prinzipien gibt?
  • Wer kann sollte das dann initiieren, um einerseits den organisatorischen Widerstand zu vermeiden und trotzdem einen notwendigen Nachdruck zu haben?
  • Welche Konsequenzen (Vorteile wie Nachteile) sind Dir bei Bottom-up-Initiativen begegnet?
  • Vor welchen “Dingen” sollte man zum Start erstmal die Finger lassen?
  • Was sollte bei wem an Vorwissen bzw. Vorerfahrung vorhanden sein, um den Bottom-up-Ansatz erfolgreich zu starten und fortzusetzen?
  • Gibt es dann einen Punkt, an dem man die “Sache” institutionalisieren kann/sollte? Wie erkennt man ggf. diesen Punkt und wie sollte man dann vorgehen?

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 325 : Bottom-up Agile und 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 Simon Stäuber bei mir im Podcast-Gespräch. Er ist Berater für Projektmanagement. Hallo Simon.

Simon Stäuber: Hallo Götz, danke für die Einladung.

Götz Müller: Ja, schön, dass du dabei bist. Ich habe jetzt schon ein kurzes Stichwort zu dir gesagt, ist natürlich ein sehr breites Feld, stell dich gern noch mal in ein paar Sätzen den Zuhörern vor.

Simon Stäuber: Ja, sehr gerne. Danke. Also, viele Firmen und andere Organisationen haben Probleme mit ihren Projekten. Zum Beispiel werden Termine nicht eingehalten oder es ist schwierig, Projekte gegeneinander zu priorisieren oder manchmal weiß auch niemand so genau, wer eigentlich wie viel auf welchen Projekten arbeitet. Und genau da setze ich an, mit meiner Firma dastus unterstütze ich beim Lösen genau solcher Probleme. Das heißt, ich optimiere, kurz gesagt, das Projektmanagement für Geschäftsführung als Berater und Coach, berate auch im ganzen Bereich Projektmanagement-Tools und gebe außerdem Trainings im agilen und klassischen Projektmanagement.

Götz Müller: Genau. Da war jetzt schon ein erstes Stichwort drin, über das wir uns heute unterhalten, nämlich „agil“, und zwar eben agil im Bottom-up-Kontext und da zum Einstieg die Frage: Typischerweise wird in meinem Weltbild, was Agilität angeht, das Thema ja eher von oben runter definiert und gesagt „Ich will haben“, was war für dich der Auslöser, dich mit gerade der anderen Richtung zu beschäftigen?

Simon Stäuber: Ja, in der Praxis, also genau genommen eigentlich oft in meinen Seminaren, bekomme ich relativ häufig die Frage „Das klingt ja alles super mit den agilen Methoden, ganz toll, würden wir auch gerne machen, aber was mache ich denn eigentlich, wenn ich eine Führungskraft habe, die das Ganze nicht unterstützt oder wenn ich ein Organisationsklima bei mir wahrnehme, was insgesamt eher erhaltend und bewahrend, man kann sagen irgendwie konservativ ist, also wo ich einfach Befürchtungen habe mit neuen Methoden und gerade mit dem Stichwort agil, da geht wahrscheinlich nichts?“ und ja, deswegen kam ich dann zu dem Thema.

Götz Müller: Ja, und das, so habe ich ja dich auch, in Anführungszeichen, kennengelernt, dass ich halt von dir einen Beitrag dazu gelesen habe und bei mir dann sofort eben es im Kopf Klick gemacht hat und ich habe gesagt „Ja, das ist im Grunde genau das gleiche Thema im Lean-Kontext“, wo ich halt manchmal ähnliche Situationen habe. Es will einer von unten rauf etwas machen und deshalb, du hast gerade schon gesagt, mal nachgefragt, was sind denn typische Gründe, die vielleicht auch eben die Menschen widerspiegeln, wenn eine Organisation nicht will?

Simon Stäuber: Ja, da kann man, ich finde genau da kann man ganz, ob das jetzt das Thema Lean ist oder agil oder sonstige Veränderungen, ich treffe oft auf eine Eigenschaft, sagen wir dieser Organisationen, oder auf einen Zustand, nämlich der Veränderungsdruck ist teilweise einfach nicht groß genug. Also wenn ich dann keinen, wenn das Management keinen wirklich starken Drang wahrnimmt, sich zu verändern, dann können, ich sag mal untere, also untergeordnete Teams, Projektleiter*innen, Führungskräfte können dann alles mögliche probieren, wenn im Kopf von Management nicht angekommen ist, dass man sich eigentlich jetzt ändern müsste, dann haben sie es extrem schwer.

Götz Müller: Man könnte es im Grunde so ausdrücken, es geht ihnen noch zu gut.

Simon Stäuber: Es geht ihnen noch zu gut, und dann gibt es halt einzelne Personen, die sind halt eher, man kann sagen visionär vielleicht unterwegs, die denken „Okay, in Zukunft wird es aber vermutlich nicht mehr so gut gehen und dann könnte man heute schon gegensteuern“, aber gerade dieses vorhersehende Element oder solche Ideen, die haben es manchmal echt schwer. Und dann wollen die Personen aber natürlich trotzdem, ja, die sagen dann ja nicht „Okay, jetzt gebe ich auf und mache nichts mehr“, sondern wer so eine Energie mitbringt, der versucht das dann trotzdem zu machen im eigenen Unternehmen, oder sonst im Zweifelsfall geht er dann vielleicht. Und dann finde ich es natürlich immer erst schöner, wenn man es selber im Unternehmen dann probiert, anstatt gleich das Handtuch zu werfen.

Götz Müller: Ja, und auch da eben sehe ich eine ganz große Gemeinsamkeit, Lean Management, und wenn man sich mal die Ursprünge anguckt, wo es herkommt, Toyota und Co, die hatten ja auch heftigen Schmerz und wenn sie den nicht gehabt hätten, dann wäre nichts, vermutlich nichts passiert, zumindest erlebe ich es auch so, in meinem Lean-Kontext. Was sind jetzt Vorschläge, die du jemandem mitgibst, der halt vielleicht, in Anführungszeichen, einen persönlichen Schmerz hat, weil er sagt: „Es muss sich etwas ändern. Mein persönliches Arbeitsumfeld sieht nicht so aus, wie ich mir das vorstelle, jetzt die Firma wechseln, kommt vielleicht noch nicht in Frage.“ Was sind deine Vorschläge im agilen Kontext, aber ich glaube auch da lässt sich viel verallgemeinern nachher, wenn es halt irgendwelche, ohne dass wir das jetzt genau ausführen oder vielleicht im Verlauf des Gesprächs noch ausführen, halt Vorbehalte gibt, warum denn agil ein gutes Thema ist?

Simon Stäuber: Ja, es bietet sich eigentlich alles an, was irgendwie so klein ist, dass es normalerweise keine formale Genehmigung benötigt, also wo nicht zu meiner Chefin oder meinem Chef hinmuss und sagen muss: „Ich habe das und das vor, das kostet so und so viel, darf ich das tun?“ Zum Beispiel kann das, ich nenne einfach mal eine Liste von Dingen, die gut funktionieren in der Praxis. Das eine sind die sogenannten Daily-Standup-Meetings, also regelmäßige tägliche Meetings, kurzgehalten, bis zu 15 Minuten, nicht länger, wo ich mich abstimme im Team, klingt erstmal super trivial, aber allein durch so eine Methode kann ich Risiken und Blockaden im Projekt frühzeitig erkennen, alles im Team teilen, habe geteiltes Wissen dort, kann schon etwas in den Fluss bringen, kostet aber quasi nichts. Oder eine zweite Sache sind regelmäßige Retrospective Meetings oder auch kurz genannt Retros, im klassischen Wortschatz sind das Lessons-learned-Meetings. Es geht einfach darum, zu schauen, was habe ich für eine Situation, kann ich daran etwas besser machen, was ist gerade nicht so gut gelaufen, was können wir verstärken, also einfach eine Rückschau mit tatsächlicher Verbesserung und der Unterschied hier zum klassischen Projektmanagement ist, dass wir diese Retrospective Meetings ständig schon im Projekt durchführen. Das heißt, wir haben im Projekt etwas von den Verbesserungen. Das ist etwas, wenn ich es das erste Mal erzähle, dann sagen die meisten „Ja, nee, eigentlich nicht so spannend, und warum sollte man das tun? Das kommt aber vielleicht komisch an im Team.“, aber im Kern ist es eine der wichtigsten Sachen, die wir durch die Agilität mitbekommen haben, solche Retrospectives und können wahnsinnig viel in Projekte wirken, ohne dass da wirklich irgendwelche wirklich nennenswerten Zusatzkosten entstehen. Wir haben als drittes, die dritte Sache ist regelmäßiges Feedback einholen von seinen Auftraggebern, klingt auch erstmal trivial, ja, klar, spricht man mit denen, aber wirklich Feedback in dem Sinne einhole, dass ich etwas zeige, eine wirkliche Rückmeldung bekomme, die heißt „Finde ich blöd, finde ich gut, in die Richtung weiter“ und das sich ständig einzuholen ist auch harte Arbeit, macht auch nicht immer Spaß, dann so ein Feedback zu bekommen. Es ist natürlich viel einfacher, erstmal in seinem stillen Kämmerlein zu arbeiten, monatelang am besten vor sich hinzu, es dann zu zeigen, aber dieses agile Element, da ist auch ein Kernelement, die Sachen frühzeitig zu zeigen, also zum Beispiel schon nach vier Wochen, auch wenn man da sehr wenig erst zeigen kann und dann mit diesem Feedback weiterzuarbeiten. Das kann Projekte unheimlich beschleunigen und auch hier sage ich wieder, es kostet Überwindung, aber es kostet kein Geld und es kostet keine Genehmigung, die ich von höherer Stelle brauche und damit super qualifiziert für etwas, was ich einfach so mal ausprobieren kann und schauen kann, ob das meinem Projekt dann weiterhilft.

Götz Müller: Ja, an der Stelle begegnet mir dann immer wieder auch der Unterschied, den man, glaube ich, nochmal sich klar machen sollte, zwischen Auftraggeber und Nutzer und speziell, und ich habe es jetzt auch so rausgehört, ich bewege mich dann durchaus eben auch auf der inhaltlichen Ebene, also nicht so sehr auf der Projektmanagement-Ebene, so nach dem Motto „Wie bist du zufrieden, dass wir die Meilensteine einhalten?“, sondern eben auch mal mit einem Benutzer sprechen: „Wie gefällt dir denn das, was wir da jetzt gemacht haben in den letzten 4 Wochen?“

Simon Stäuber: Ja, ganz genau. Also es geht, ich mache mal ein Beispiel, ich will so für eine neu gegründete Organisation eine Website erstellen, dann kann ich natürlich Dinge programmieren und dann zeigen, aber ich kann auch Dinge ganz einfach erstmal grafisch darstellen in einer PowerPoint, die so aussieht wie eine Website, auch klickbar ist und die erstmal zeigen, und das kann ich innerhalb von kürzester Zeit tun und da kriege ich dann schon mal erste Rückmeldungen, ob das, was ich da erstellen möchte, überhaupt schmeckt, so als ganz einfaches Beispiel und das geht in allen möglichen, würde ich behaupten, eigentlich auch in allen Bereichen, dass man erstmal Konzepte aufzeigt, die aber trotzdem wie echt aussehen.

Götz Müller: Jetzt ist ja bottom-up eine Frage der Definition, top-down ist immer relativ einfach, eine Spitze gibt es nur eine. Wenn ich nach unten gucke, wird es nicht immer breiter und da dann die Frage, gibt es da Unterschiede, wer so etwas initiiert. Ich denke jetzt mal primär, einerseits der Projektleiter, der Projektmanager, aber vielleicht hat auch Projektmitarbeiter, -mitarbeiterinnen, gibt es da einen Unterschied und wenn ja, welchen und was ergibt sich daraus?

Simon Stäuber: Ja, ich würde schon sagen, es sollte im Projekt jemand tun, der auch die Verantwortung hat, also zum Beispiel jetzt Projektleiterin oder Projektleiter? Ich habe auch immer mal wieder gesehen, dass Initiativen aus dem Team kamen, allerdings haben sich dann üblicherweise die Leute im Team, ja, irgendwie, ich sag mal Budgetgeber oder andere gesucht, die dann zumindest, sagen wir mal, jetzt zum Beispiel eine Projektleiterin oder ein Projektleiter einsetzen konnten, die diesen Geist mitgebracht haben und gesagt haben: „Okay, wir probieren jetzt mal bestimmte Sachen aus.“ Ich glaube, also das ist dann, glaube ich, zu weit bottom, wenn ein einzelnes Teammitglied das probiert. Also dann, ja, das ist dann sehr, sehr steinig der Weg. Also die suchen dann schon noch eine kleine Ebene höher, versuchen da das Commitment dann zu bekommen.

Götz Müller: Oder, ja, im Sinne von macht es Sinn, seinen Projektleiter anzusprechen? Oder sollte man vielleicht den überspringen? Was sind eventuell auch Vor- und Nachteile?

Simon Stäuber: Ja, das … also es kann manchmal drängen Teams natürlich darauf und sagen, sie brauchen dann einen anderen Projektleiter. Man kann mal sagen, was, ich meine, wenn wir jetzt sagen, was ist der Vorteil eigentlich von so Bottom-up-Initiativen? Das ist ja eigentlich, dass die Teams selber. Handeln kommen. Es ist eine erhöhte Selbstwirksamkeit. Das ist nicht, dass man nicht wartet, welche Methode darf man jetzt verwenden, wie soll man es tun, sondern dass man halt selbst überlegt „Okay, das gefällt uns, daran wollen wir arbeiten“ und da gehört ein Stück weit auch dazu, dass die Teams dann sich auch ihre eigenen Projektführungskräfte suchen, also dass man sagt „Okay, wenn jetzt der Projektleiter, wenn er partout da nicht mitgehen möchte, dann drängen wir halt darauf, schauen, dass wir einen anderen bekommen, der das dann unterstützt, was wir wollen.“. Das kann natürlich eine hohe Dynamik auch entwickeln, wenn jetzt ein, sagen wir, ein zwölfköpfiges Entwicklungsteam sagt „Mit dem Projektleiter, der Projektleiterin kommen wir nicht zurecht, wir brauchen da jemand anders, der anders tickt“, dann, ja, dann passiert das meistens auch. Das ist, so habe ich das erlebt. Weil die einen sehr hohen, natürlich auch sozialen Druck dort ausüben und sagen „Sonst können wir nicht arbeiten.“ und wenn man, ja, was soll ich sagen, wenn man noch höher geht, dann wird es schnell natürlich schwierig, weil auf der Teamebene, ohne dass man dann schon Sachen gemacht hat, häufig ein wirklicher Nachweis fehlt, warum man mit der neuen Methode, warum man anders arbeiten möchte, wenn man jetzt als, man überspringt jetzt als Entwicklungsteammitglied, überspringt man die Projektleitungsebene, ist auf der Ebene Management von der Projektleitung und die Ebene möchte dann ja meistens irgendwelche Nachweise haben, dass meine neue Methode tatsächlich gut ist und das kriege ich als Teammitglied meistens nicht hin, ohne dass ich mit der Projektleitungsebene zusammenarbeite, die Erfahrungen hat in solchen Metriken.

Götz Müller: Kann man von Konsequenzen in irgendeiner Form auch reden, die bei Bottom-up-Initiativen mal, in Anführungszeichen, im klassischen Sinne, dass es halt ein Projektleiter initiiert, der vielleicht bei dir eine Projektmanagement-Ausbildung gemacht hat, kann man von Konsequenzen reden, Konsequenzen im Sinne von Vor- und Nachteile?

Simon Stäuber: Ja, also dieses, ich habe eben schon mal das Stichwort Selbstwirksamkeit, angesprochen. Also das ist ein sehr positives Momentum, was da mit so Teams passiert, die selbst Initiative ergreifen, die sagen „Ich will jetzt, wir wollen auf eine bestimmte neue Art arbeiten“, also irgendwie, Stichwort agil, Scrum, sagen wir mal, und sie wollen das jetzt unbedingt machen und wenn das dann passiert, dann ist das erstmal eine sehr starke positive Emotionen, was in dem Moment passiert. Ich hab dann zum Beispiel auch mal gesehen, ich habe ein Team mal als Scrum Master begleitet, das wollte halt unbedingt nach Scrum arbeiten und wollten dann natürlich auch ein agiles Board, wo man alle Aufgaben schön aufgelistet, sich dann virtuell auch zum Remote-Arbeiten, wollten so etwas haben, dann hat sich in der Firma der Betriebsrat dann gesperrt gegen professionelle Tools wegen Bedenken wegen Tracking von Mitarbeitern et cetera, und dann haben die halt das erst mal in Excel umgesetzt, da hat das Team sein Board in Excel gemacht, was natürlich sehr hässlich aussah, aber sie hatten das Board und da war so viel Energie da, das musste dann da sein und dann haben wir das so gemacht und später kam das richtige Tool dann, durch die Energie, die das alles entwickelt hat. Aber es auch ganz klare Nachteile. Der eine ist, dass das häufig dann auf Teamebene ja sehr gut funktioniert, dass man sich einigt, man möchte neu arbeiten, alles erstmal so weit, alle gucken in die gleiche Richtung, aber das Problem sind die Schnittstellen. Ich habe ja immer noch andere Teams, mit denen ich irgendwie zu tun habe, also ich habe bisher keine Firma kennengelernt, die wirklich so ein autarkes Team hat, das ein Produkt oder Service alleine entwickeln kann. Man hat eigentlich immer irgendwelche Schnittstellen. Und da kann es dann sein, dass durch die neue Arbeitsweise einfach das gegenseitige Verständnis und auch die gegenseitige Sprache, Begriffe fehlen dieser anderen Abteilung. Ich habe zum Beispiel mal einen Software-Entwicklungsprojekt begleitet, das dann agil gearbeitet hat und den Kollegen war aber irgendwann klar, das Ganze muss dann irgendwann in den Service und der Service war halt eine andere Abteilung, die hatten ihren Standardvertrag, da war alles im Detail minutiös geregelt und das war dann sehr schwierig da für dieses Team, das quasi aus einer neuen Welt kam, mit dem Team aus der alten Welt diesen Vertrag zu verhandeln. Das war sehr, sehr schmerzhaft und ist definitiv ein Nachteil, Schnittstellenmanagement wird komplexer.

Götz Müller: Ja, das kann ich mir sehr gut vorstellen. Andererseits, wenn ich es mal im Servicebereich auf Schwäbisch, verschmeckt habe, dann lerne ich ein Stück weit, glaube ich, auch eben, dass ich ja viel früher Einfluss darauf habe und dass mir nicht hinterher, so kenne ich es jetzt auch aus dem Produktionskontext raus, irgendwas über den Zaun geworfen wird, so nach dem Motto „Produziert das mal“ oder „Mach halt mal den Service dafür“ und im Grunde lernt man es da erst kennen. Gut, jetzt haben wir ein bisschen über Nachteile gesprochen, gibt es auch Dinge, wo du sagst: „Boah, hier wirklich nur mit der ganz spitzen Zange oder die Finger wirklich weglassen?“

Simon Stäuber: Ja, das ist auf jeden Fall das ganze Thema Skalierungen, teilweise sind ja, werden ja Produkte nicht von einer schönen, ich sag mal, kleinen Teamgröße von 10 bis 12 Leuten entwickelt, wo man alles gut abstimmen kann, sondern es geht deutlich größer zu und da würde ich persönlich nicht gleich agil mit diesem kompletten Team-Setup starten, sondern wirklich versuchen mit kleineren Einheiten, Teams bis 12 Leuten, das Ganze zu beginnen und dann später größer werden, weil mit zunehmender Größe ist die Gefahr des Scheiterns einfach deutlich höher, also meiner Meinung nach, egal welche Methode ich verwende, es sind einfach deutlich mehr Menschen, deutlich mehr Stellschrauben, alles, ja, kann irgendwie oder es gibt mehr Parameter, die darauf Einfluss nehmen können, dass irgendetwas schief geht und dann ist meine Methode vielleicht nachher verbrannt, auch wenn es gar nicht an der Methode liegt, einfach nur daran, dass ich da gleichzeitig mit 100 Leuten starte. Und darum würde ich das lieber nicht machen, wenn ich es ernst meine.

Götz Müller: Ja, und auch da sehe ich wieder eine ganz große Gemeinsamkeit zum Lean-Kontext, da ist so das Stichwort Pilotbereich, Pilotprojekte, wenn ich jetzt wieder in Richtung Projektmanagement gucke, um halt einfach auch eigene Erfahrungen erst zu machen, wenn man ja ganz genau wüsste, wie man es denn machen muss, dann würde man es wahrscheinlich schon ewig so machen. Was würdest du sagen, ich meine, kaum einer beginnt mit dem Thema Bottom-up jetzt an der Stelle, ja, weil er schlecht geträumt hat, sondern er wird sich, er wird irgendeinen wahrgenommenen, gefühlten Schmerz haben, in Anführungszeichen, und sich vielleicht informieren, was sollte man sich an Vorwissen, an Vorerfahrung holen, bevor man den Fuß ins kalte oder ins heiße Wasser unter Umständen steckt?

Simon Stäuber: Ja, das ist eine Antwort, die natürlich wieder die, die es betrifft, bestimme ich gerne hören, aber es hilft wie immer, wenn man jemanden dabei hat, der es schon mal gemacht hat und das ist in den Praxisfällen ja im Normalfall dann leider nicht gegeben, weil man da ein Neuland dann betritt in der eigenen Organisation und ich kenne das natürlich so, also natürlich, weil ich selbst als Externer da auch schon viel unterwegs war, dass man dann einen Externen holt, der einem das erstmal zeigen kann, wo man das Wissen sich dann ins Unternehmen holt, man kann natürlich genauso gut jemanden einstellen, das dauert erfahrungsgemäß dann halt einfach ein bisschen länger, aber geht natürlich auch genauso gut, und dass sich nur selbst anlesen, Podcast hören et cetera, das ist auch natürlich auch okay, aber dann verzichte ich halt auf ein Erfahrungsschatz, Erfahrungsvorsprung, den mir jemand, der das schon mal gemacht hat, einfach schnell mitgeben kann. Also ich würde dann halt mehr Fehler selbst machen müssen, die ich sonst nicht gemacht hätte. Das ist das Problem dann dabei.

Götz Müller: Aber ich glaube, ein Stück weit hilft es eben, ja, von anderen Fehlern auch zu lernen. Man muss nicht notwendigerweise jeden Fehler, glaube ich jetzt, da gibt es auch so einen schlauen Spruch, den kriege ich jetzt bloß nicht zusammen, man kann ja auch aus anderen, von Fehlern anderer lernen.

Simon Stäuber: Ganz genau, ja. Das meint das.

Götz Müller: Ja, gut. Jetzt haben wir, du hast vorhin das Stichwort Skalierung gesagt. Das heißt, jetzt nehmen wir mal an, Dinge laufen gut, meine Bottom-up-Initiative fällt nicht negativ aus, um es mal ein bisschen flapsig auszudrücken, fällt nicht negativ auf, vielleicht spricht es sich aber rum, so nach dem Motto „Hey, die machen da irgendwas und plötzlich gibt es bessere Ergebnisse.“, gibt es irgendwo einen Punkt, wo man sagt, ab jetzt sollte ich vielleicht, in Anführungszeichen, den Spieß umdrehen und jemanden noch stärker auf meine Seite ziehen, um eben Top Down vorzugehen? Und wenn es diesen Punkt geben sollte, wie erkenne ich ihn und was mache ich denn dann, wenn ich jetzt erkannt hab, jetzt bin ich an dem Punkt, wo ich vielleicht aus diesen eigenen Kräften auch vielleicht an eine Art von, ja, Decke stoße?

Simon Stäuber: Ich bin ein Freund von Metriken, das heißt, ich finde, sobald belastbare Zahlen da sind, also dass man wirklich beweisen kann, mein Projekt läuft jetzt besser als andere vergleichbare Projekte im Unternehmen, das ist, finde ich, so der Königsweg, dann kann ich natürlich zum Management gehen und sagen „Hey, schaut mal hier, ich bin jetzt 10% günstiger“ oder die Kundenzufriedenheit ist 20% höher oder was ich auch immer für KPIS dann habe, die gerade wichtig sind im Unternehmen und da kann man natürlich nein gesagt werden, aber es fällt dann dem Management natürlich extrem schwer, wenn ich wirklich so einen Beweis habe. Ja, sonst, dass die eigenen Teams zufriedener sind, das ist eigentlich mehr so eine, das passiert schnell mit agilen Methoden, das einfach die Projektteams selber zufrieden sind, aber das heißt nicht unbedingt, leider, dass die Projekte besser laufen. Also sollte ich von Anfang an schauen, dass ich auch Zahlen erhebe, die wirklich die Projektgüter, also wie läuft mein Projekt von Terminen her, vom Budget her, von Kundenzufriedenheit her, dass ich solche Metriken erhebe, also Nullmessungen mache und dann später wieder messen, oder vielleicht habe ich sehr viele Vergleichsdaten mit anderen Projekten, die parallel laufen, das wär natürlich das Beste und, ja, mit diesen Zahlen dann, wenn ich, sobald ich die habe, kann ich natürlich, kann ich quasi an die Öffentlichkeit gehen und sagen: „Hey Leute, schaut mal, das ist doch super, so sollten eigentlich auch alle anderen arbeiten.“

Götz Müller: Mhm, ja und da kommt jetzt in mir das Six-Sigma-Thema hoch, das kann man im Grunde gar nicht früh genug anfangen, weil hinterher sich Zahlen zu besorgen, speziell im Projektkontext wird natürlich schwierig, weil man die Uhr ja nicht zurückdrehen kann.

Simon Stäuber: Ganz genau, ja.

Götz Müller: Und schaden im Grunde kann es auch nicht. Man wird nicht dümmer dabei, um es mal so auszudrücken, wenn man sich von Anfang an Gedanken macht, weil sich eben da, im Projektmanagementkontext besonders, eben Dinge nicht in der Form reproduzieren lassen.

Simon Stäuber: Ja, und dann, also kann halt auch sein, man hat dann Ergebnisse, die man erst mal nicht so mag irgendwie, läuft es vielleicht gar nicht so viel besser oder irgendwie auch nur gleich gut, aber dann, okay, dann hat man auch die Zahlen, kann man rangehen, nachbessern, wieder messen, bis man halt dort ist und dann kann man genau diesen Weg hier auch dem Management zeigen. Das ist auch dann ja ein schöner Weg, den man zeigen kann, eine schöne Geschichte.

Götz Müller: Gut, jetzt, um den Bogen ein bisschen zu schließen noch mal, so ein bisschen eine Zusammenfassung noch mal. Wenn ich mir, wenn ich also irgendwie als verantwortliche Person in einem Projektkontext eine Art von Schmerz verspüre, aber jetzt nicht wahrnehme, dass jemand anders, der das entscheiden kann, auch den Schmerz hat, wie sollte ich anfangen, was sollten meine ersten Schritte sein, um eben diese Bottom-up-Initiative möglichst erfolgreich zu gestalten?

Simon Stäuber: Also ich würde, also jetzt angenommen ich bin eine Person, wo ich in einer Position bin, wo ich auch Verantwortung fürs Projekt übernehme und Einfluss habe, würde ich wirklich mit wenigen, am besten erstmal nur einem kleinen agilen Element starten. Ich mache zum Beispiel, dass ich regelmäßige Retrospective Meetings mache, also regelmäßig im Team schaue, was können wir verbessern. Das mache ich dann halt nicht viel früher einmal nach dem Projekt, sondern wir machen das alles vier Wochen und lassen das direkt einfließen in den Projektalltag. Und dann erstmal probieren, schauen und so andere Elemente dazu holen, nicht zu viel auf einmal, immer nur etwas, was gut verdaubar ist, was anschlussfähig ist ans Team. Immer schauen, was hat das für Auswirkungen und wenn es die Zusammenarbeit und die Ergebnisse verbessert, umso besser, dann einfach weitermachen.

Götz Müller: Ja, im Grunde dieser klassische Spruch von einem Elefanten, wie man ihn halt, ich meine, die agile Welt, das ist ja schon ein großer Brocken und ich glaube, das kann durchaus, ja, sogar fast eine Chance sein, in diesem erzwungenermaßen, in diesem Bottom-up, mit einem kleinen Päckchen anzufangen und nicht gleich den ganz großen Bissen und dann den Mund zu voll zu nehmen, zu haben.

Simon Stäuber: Ja, das ist, vielleicht gilt das auch generell fürs Change Management. Ich finde immer das beste Change Management ist das, wo Kolleginnen und Kollegen nach ein paar Monaten sagen „Ach, ich wusste gar nicht, dass wir ein Change gemacht haben“, aber schon tagtäglich anders arbeiten.

Götz Müller: Ja, aber da, in dem Kontext, so erlebe ich das auch wieder im Lean-Umfeld, auch da wieder das Thema, vielleicht im übertragenen Sinne, Metriken früh anzufangen, sich Dinge zu merken, aufzuzeichnen, um dann nicht irgendwann in diese Gewohnheit, reinzukommen und selber gar nicht mehr wahrzunehmen, wie viel besser man geworden ist.

Simon Stäuber: Ganz genau. Also ich selbst jetzt als Verantwortlicher ich muss mir natürlich im Klaren sein, was tue ich und die Metriken haben, eigentlich so ähnlich wie bei der Lean-Startup-Methode, ja, ich messe ständig und gucke, ob der Weg der richtige ist und sonst gehe ich in eine andere Richtung.

Götz Müller: Ja, und auch da eben wieder jetzt, ich meine, du hast den Begriff Lean Startup genannt, ich meine, der kommt ja nicht von ungefähr, auch da sehe ich eben sehr, sehr viele Gemeinsamkeiten und du hast es auch angedeutet, im Grunde ist es einfach der Change an sich, die Veränderung an sich, ob da jetzt agil drüber steht, ob da jetzt Lean drüber steht oder irgendetwas ganz anderes, es sind immer wieder die gleichen Themen und es sind immer wieder die gleichen Dinge, die hilfreich sind und immer wieder die gleichen Dinge, die auch Hürden darstellen. Gut, Simon, ich fand, das war eine spannende Unterhaltung. Es hat mir wieder bestätigt und dem einen oder anderen Zuhörer hoffentlich auch, dass zwischen agil und Lean gar nicht so viele Unterschiede sind und wenn man sich von der rein, nennen wir es mal inhaltlichen, Ebene etwas löst, sondern eben auf diese Veränderungs-, allgemeinen Veränderungsthemen schaut, dann findet man da viele Gemeinsamkeiten und ich glaube eben, man kann viel auch von anderen Erfahrungen lernen und deshalb danke ich dir für deine Zeit.

Simon Stäuber: Danke, Götz.

Götz Müller: Das war die heutige Episode im Gespräch mit Simon Stäuber zum Thema Bottom-up Agile und Lean. Notizen und Links zur Episode finden Sie auf meiner Website unter dem Stichwort 325.

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.