BJA PODCAST

BERATUNG JUDITH ANDRESEN

Agil agil werden (Judith Andresen & Stefan Hilmer)

In dieser Episode mit Stefan Hilmer geht es um Agilität im Projektmanagement. Er erläutert, wie Design Thinking und Kanban die Effizienz erhöhen und betont die zentrale Rolle des Mindsets für eine erfolgreiche Transformation.

10.09.2024 28 min

Zusammenfassung & Show Notes

In dieser Episode des Podcasts von Judith Andresen sprechen wir mit Stefan Hilmer, einem Experten für Agilität und Projektmanagement, der derzeit als Professor an der Nordakademie tätig ist. Stefan bringt seine Erfahrungen als ehemaliger Berater mit, um das Thema "Agil werden" umfassend zu beleuchten. Dabei betonen wir, dass Agilität nicht bloß ein theoretisches Konzept ist, sondern durch praktisches Erleben und kontinuierliches Lernen erreicht werden kann. Wir beginnen mit der Diskussion über die Herausforderungen, denen sich Organisationen gegenübersehen, wenn es darum geht, agil zu werden. Oftmals sind Unternehmen gut im Planen, aber weniger motiviert, die notwendigen Veränderungen aktiv umzusetzen. Stefan teilt ein Praxisbeispiel, in dem Design Thinking eingesetzt wurde, um in einem Softwareentwicklungsunternehmen die Effizienz zu steigern. Obwohl die Scrum-Teams in der Entwicklung florierten, war die Erwartung an schnellere Markteinführungen durch die Führungsetage nicht erfüllt worden. Stefan beschreibt, wie sie mittels Design Thinking eine Problemsituation analysierten, um darauf basierend Lösungen zu entwickeln und durch Simulationen verschiedene Ansätze zu testen. Durch diesen kreativen und iterativen Prozess konnten die Teams Erfahrungen sammeln und vor allem das Prinzip "Win or Learn" in der Praxis erleben. Indem sie verschiedene Agile-Frameworks wie Scrum of Scrum und SAFE ausprobierten, wurde schnell klar, welche Lösungen für das Unternehmen am besten geeignet waren. Die Herausforderungen, die aus den Simulationen hervorgingen, wurden ehrlich reflektiert und flossen in die Entscheidungsfindung mit ein. Ein weiteres zentrales Thema ist die Anwendung von Kanban zur Förderung der Teamentwicklung und der psychologischen Sicherheit innerhalb der Teams. Stefan erklärt, wie die Visualisierung und das Limitieren von Arbeit im Prozess (WIP) dazu beitrugen, den Fokus zu erhöhen und Teammitglieder dazu zu ermutigen, sich aktiv in den gemeinsamen Prozess einzubringen. Wir erörtern die Unterschiede zwischen Scrum und Kanban und betonen die Wichtigkeit, dass die gewählte Methode tatsächlich zu den Bedürfnissen und Herausforderungen der Organisation passen muss. Stefan und ich sind uns einig, dass der wahre Schlüssel zur Transformation nicht nur in den Methoden selbst liegt, sondern vor allem im Mindset der Teammitglieder. Vertrauen, Zusammenarbeit und die Bereitschaft, Verantwortung zu übernehmen, sind essential, um eine agile Kultur zu etablieren. Zum Schluss ermutigen wir die Zuhörer, genau darüber nachzudenken, wie sie sich und ihre Organisationen Schritt für Schritt agiler gestalten können, und die Wichtigkeit, solche Veränderungen von Anfang an durch agile Denkweisen zu unterstützen. Diese Episode bietet wertvolle Erkenntnisse und praktische Anregungen, wie Organisationen sich erfolgreich auf den Weg der Agilität begeben können, und dass es dabei stets auf das individuelle Vorgehen und die spezifischen Herausforderungen ankommt.

Transkript

Judith Andresen
00:00:33
Herzlich willkommen. Wir sind im Podcast der Beratung Judith Andresen. Heute ist bei mir Stefan Hilmer und bevor Stefan sich vorstellt, ein paar Worte zu mir. Ich bin Judith Andresen, Agile Coach und agile Organisationsentwicklerin und ich freue mich heute sehr auf den Podcast zum Thema Agile Agile werden. Stefan, herzlich willkommen.
Stefan Hilmer
00:00:56
Ja, vielen Dank erst einmal für die Einladung. Ich freue mich heute hier zu sein. Mein Name ist, wie ja jetzt schon gehört wurde, Stefan Hilmer. Ich bin inzwischen Professor an der Nordakademie und unterrichte dort Agilität und Projektmanagement. Das tue ich aber erst seit kurzem. Bis Ende letztes Jahr war ich noch als Berater unterwegs, damals für die Firma Adesso. so. Das habe ich 20 Jahre lang gemacht. Und am Ende hat sich dieses Prinzip Agil, Agil werden bei mir herausgestellt, dass ich zusammen mit meinem Kollegen Henrik Stapel auch dann herausgearbeitet habe.
Judith Andresen
00:01:42
Ja, ich kenne das, wir sagen im Handeln lernen und sind der festen Meinung in der Beratung Judith Andresen, dass man nur agil werden kann, wenn man das erfährt, also nicht erdenkt. Wir sagen auch Veränderung erdenkt man nicht, Veränderung erleben wir und in diesem Sinne freue ich mich total, dass auch die Motivation heute für meinen Podcast, nämlich an der Stelle viel darüber zu erzählen, wie eigentlich ins echte Machen kommen geht, weil Organisationen sind häufig gut im Planen und nicht so gut im Reinladen und Stefan hat da auch zwei Beispiele mitgebracht, wie man sich gut reinladen kann und darauf freue ich mich sehr, dass wir die heute besprechen können.
Stefan Hilmer
00:02:27
Ja, ich denke auch, das ist gar nicht so der große, Raketentechnik-Ansatz, sondern es ist einfach nur, dass man sich dieses Prinzip bewusst machen muss und je öfter man sich das bewusst macht, umso leichter fällt es einem dann nachher. Umso leichter fallen dann agile Veränderungen.
Judith Andresen
00:02:47
Genau. Manchmal stehen da ja Organisationsmuster gegen, weil wir ja gerne Dinge planen und gerne auch rational vorher erfassen und so ein, in vielen Organisationen erlebe ich, dass so in Inkrementen arbeiten, also mit so einer Kleinigkeit, die schon liefert, dass das, wahnsinnig nach vorne schiebt und dieses Aha-Erlebnis, warte, Inkremente ist gar kein Meilenstein, sondern das ist tatsächlich etwas, was schon tut und das macht was erfahrbar. Darum geht es, glaube ich, auch in deinem ersten Beispiel, weil da habt ihr Design Thinking ja benutzt, um Organisationsentwicklungsfragen zu klären und da spielen Simulationen mit einmal eine Riesenrolle und ich würde sagen, da wurden Inkremente geliefert. Stefan, magst du mal ein bisschen was erzählen?
Stefan Hilmer
00:03:36
Ja, das war tatsächlich so. Wir reduzieren das immer auf das Beispiel. Wir haben Design Thinking als Ansatz gewählt in einem Unternehmen, das Software entwickelt und ja, ein relativ kleines mittelständisches Unternehmen an einem umkämpften internationalen Markt, das so mit vier Scrum Teams arbeitet. Also Scrum haben die schon eingeführt, um da Software zu entwickeln und ihre Produkte zu entwickeln. Und die Entwickler und die Entwicklungsabteilung, Product Owner, sind auch alle sehr zufrieden. Das läuft alles super. Nur kommt so ein bisschen Kritik aus Vertrieb und Vorstand, wo man die versprochenen Gewinne durch die Agilität noch nicht so realisiert sieht oder sah. Das heißt, dass dort eben dieses Time-to-Market, dieses viel schneller werden und viel schneller neue Produkte an den Markt zu bringen, das war nicht erreicht worden. Und ja, das war eigentlich dann eine Problemsituation. Und wenn ich mit einer Problemsituation dastehe, dann war zu uns Design Thinking der Ansatz der Wahl, wie man da relativ schnell rankommt.
Judith Andresen
00:05:03
Genau. Und dann habt ihr ja etwas gemacht, was ich total schön finde, nämlich ihr habt simuliert, also simulieren ist ja eine Form von ins Handel kommen und Dinge erleben, um auszuprobieren, ob bestimmte Strukturen funktionieren. Ja. Magst du mal erzählen, was ihr simuliert habt und wie ihr simuliert habt?
Stefan Hilmer
00:05:24
Ja, bevor wir zur Simulation gekommen sind, haben wir natürlich erst mal versucht zu verstehen, dieses Problem zu verstehen und dieses Problem zu erfassen. Haben mit den Teams Retrospektiven begleitet, haben Interviews gemacht mit dem Vorstand, sind dann in die zweite Phase des Design Thinkings gegangen, haben Beobachtungen gemacht, haben uns angeschaut, wie die Teams arbeiten. Tatsächlich Interviews auch nochmal mit den Scrum Mastern und Product Ordern geführt und sind da dann eben auf den Weg gekommen, dass wir in der dritten Phase beim Definieren der Sichtweisen vor der Simulation auch erstmal eine systemische Aufstellung versucht haben.
Judith Andresen
00:06:05
Dass wir versucht haben.
Stefan Hilmer
00:06:06
Die Teams in so Workshops untersuchen zu lassen, wo sie stehen, wie sie sich fühlen und dabei haben wir erstmal festgestellt, dass die Teams weit auseinander sind. Also nicht räumlich, sondern auch so von ihrer Entwicklungsarbeit, von ihrem Austausch, von ihrer Kommunikation, das war so relativ schnell zu erkennen und deswegen war der Ansatz da, wir müssen das Problem lösen, indem wir irgendwie besser die Teams integrieren und zusammenbringen. Der vierte Schritt ist Design Thinking, das Ideen finden, führte relativ schnell zu Lösungsansätzen, Wenn 40 Agilisten zusammensitzen und sagen, wir müssen Scrum-Teams näher zusammenbringen, dann ist klar, dass die Vorschläge ganz schnell kommen und die waren dann auch schnell da. Das war Scrum of Scrum, Large-Scale Scrum, also Less- und Scaled-Age-Framework, also SAFE. Und da setzen wir dann an mit der Simulation, um zu erproben, welcher dieser Ansätze am besten ist oder am besten in dieser Situation geeignet ist. Und da waren dann die vier Prototypen, die wir über die Simulation versucht haben zu erreichen. Also relativ einfach durchzuführen gewesen an der Stelle, gerade bei der Scrum-of-Scrum-Lösung. Wir haben das SOS-Board dann einfach mal simuliert, haben gesagt, jedes Team schickt seine Entsandten und wir versuchen mal dort gemeinsam die Abstimmung untereinander zu beschleunigen. Das hat aber leider nicht so gut funktioniert Die Abgesandten waren gar nicht so informiert, dass sie zu allem Rede und Antwort stehen konnten Sodass wir SOS relativ schnell verwerfen konnten, Die größere Aktion, die nächste, war dann das Simulieren von Safe, Safe bietet ja in seiner unendlichen Breite auch den Einsatz für die Safe-Einführung die Roadmap, die da vorgeschlagen ist. Und da haben wir dieses Go-Safe angesetzt und haben simuliert so ein erstes Meeting und sind dann aber relativ schnell zu dem Schluss gekommen, dass es nicht passte, dass wir die ganzen Rollen, die da zu besetzen waren, gar nicht besetzen konnten. Also, dass wir diese Lean Agile Change Agents gar nicht gefunden haben, die wir hätten versuchen können auszubilden. Und auch da war relativ schnell klar, dass unser Ansatz safe vielleicht für dieses Problem zu groß war. Und das Dritte, was wir dann versucht haben, Balles?
Judith Andresen
00:08:59
Warte, bevor wir da einhaken, würde ich kurz noch anmerken, de facto habt ihr Win or Learn geübt, ne? Also so als agiles Prinzip, also wir probieren das mal aus und gucken, was passiert. Und dann habt ihr rausgekriegt, also entweder einen fachlichen Erfolg rausgekriegt oder gesagt, das ist es nicht aus den und den Gründen. Und das finde ich halt hochgradig spannend an dieser Taktik, Organisationsentwicklung über Design Thinking zu machen. Ich kenne das auch, dass wir über Simulationen viel erreichen, weil die Leute sehr unmittelbar an dem Thema sind und auch gleich so agile Prinzipien nochmal auf einem anderen Level neu lernen. Und da würde ich jetzt hier so Win or Learn benennen. Siehst du das auch so?
Stefan Hilmer
00:09:42
Ja, das trifft das zu. Gerade so, wie ich es jetzt versucht habe, auch zu erzählen, passt das sehr gut dazu. zu. Wir haben uns damals schon versucht, die Simulation erst durchzuführen und sie dann zu bewerten. Wir haben nicht immer gleich den Schuss gemacht, auch wenn es darauf hinaus lief, dass wir gerade bei Safe relativ schnell gemerkt haben, dass das für vier Teams nicht unbedingt die passende Größe ist und für so ein kleines Unternehmen auch nicht unbedingt die passende Größe ist. Aber ansonsten gebe ich dir vollkommen recht, Der Ansatz ist schon mit WinLearn gut beschrieben.
Judith Andresen
00:10:26
Mhm. Ihr habt ja jeweils versucht, ein Framework komplett über die, also sozusagen einzelne Teile zu prüfen, ob das Framework überhaupt passen könnte. Wir machen das auch relativ häufig so, dass wir nur einzelne Methodenbausteine sozusagen, aussimulieren und sagen, naja, wir können ja das noch machen, das gibt es zum Beispiel in Save, also Big Room Plan ist zum Beispiel so ein Thema, das sich in vielen Organisationen anbietet, dass man das macht und ganz viel auch safe aber sonst weglässt, weil das halt, Schon viele Rollen beinhaltet, wie du gerade gesagt hast, und wahnsinnig viele Artefakte, wo ich manchmal das Gefühl habe, da versucht man auf der einen Stelle direkt zu kommunizieren und auf der anderen Stelle bürokratisiert man total. Total, aber ihr hattet schon so ein Gefühl von, also wir versuchen hier so ein ganzes Framework einzuführen über eine Simulation oder ging es darum, Schlüsselmomente aus den jeweiligen Frameworks rauszupoolen, zu sagen, die probieren wir aus?
Stefan Hilmer
00:11:36
Nein, das haben wir gar nicht erst ausprobiert. Wir haben das direkt, so wie du schon sagtest, von so einem ganzheitlichen Ansatz ausgehend. Das liegt natürlich auch daran, wenn wir Scrum auf Scrum ausprobiert haben, da kannst du ja nicht viel, was du rausnehmen kannst.
Judith Andresen
00:11:51
Das ist wirklich sehr schlank. Aber bei Less und Safe würde mir schon das eine oder andere einfallen, was man rauslassen kann.
Stefan Hilmer
00:12:00
Wäre dann auch soweit gewesen. Ich glaube auch nicht, dass wir dann Less mit allen Facetten eingeführt haben. Letztendlich, da bleibt ja immer mal irgendwas übrig. Aber der ganzheitliche Ansatz von Les hat nachher so gut gepasst, dass man da so das Weiteste übernommen hat. Man kam aus Scrum, da war der Weg gegeben. Es waren ausschließlich Scrum-Teams unterwegs, also das passte dann schon relativ gut.
Judith Andresen
00:12:29
Genau, das passt dann auch ganz gut. Und das Schöne war dann… Entschuldige, bitte mach du.
Stefan Hilmer
00:12:34
Nee, mach du erst.
Judith Andresen
00:12:36
Was ich an dem Ansatz halt total mag, ist, dass es einen Backlog gibt und dass man irgendwie so wirklich Leute zwingt in die Zusammenarbeit über die Teams hinweg.
Stefan Hilmer
00:12:50
Ja, und was natürlich auch ist, dass es deutlich schneller ist, weil wir bleiben in den Sprintzyklen, die wir von Scrum kennen. Wir fügen nicht drei Zyklen zusammen und bauen noch einen davor, sondern wir bleiben in dieser Nelligkeit. Das ist allgemein vielleicht ein Vorteil von Less, aber das Ding ist ja immer, welches Framework ich auch nehme, es muss immer zu dem Team passen, es muss zu den Leuten passen, es muss zu dem Produkt passen.
Judith Andresen
00:13:19
Genau. Und die Methode muss zum Problem passen, ne? Genau. Genau. Okay.
Stefan Hilmer
00:13:25
Und das haben wir dann auch festgestellt, weil wir das eben simuliert haben. Da haben wir also einen vergangenen Sprint genommen und haben dann dieses Planning 1 gemacht, die Review gemacht und hinterher sogar noch die Overall Retrospektive gemacht. Und da war eigentlich klar, worauf es hinausläuft. Also im Planning haben die sich so viel ausgetauscht, das Planning war im Termin weit überzogen, aber das haben wir akzeptiert. Und in der Review haben sie sich alle alles angeschaut und sie haben selber festgestellt, schon in der Overall-Retrospektive, dass sie noch nie so viel von den anderen Teams verstanden haben, jeweils wie an diesem Tag. Und ja, da war die Entscheidung dann relativ schnell klar.
Judith Andresen
00:14:15
Genau. Das ist ja, finde ich, auch die Magie in Safe, in Big Room Planning, wenn das gelingt, also wenn man das gut hinkriegt, dieses Messeszenario, dann ist das halt schon cool, weil da Leute wirklich voneinander wissen. Und gleichzeitig braucht es halt auch ein bisschen Masse, finde ich, damit es gut funktioniert. Und so, ich kann mir gut vorstellen, dass mit vier Teams dann eher die Lösung in LESS gelegen hat. Ja, aber ich finde halt total geil, dass ihr an der Stelle quasi Design Thinking benutzt habt und Simulationen, um agil, agil zu werden.
Stefan Hilmer
00:14:50
Ja, genau. Da lag auch der große Vorteil. Die haben in der Simulation halt LES dann schon kennengelernt. Die wissen schon ziemlich, wie es funktioniert und die Einführung ist dann nur noch ein kleiner Schritt.
Judith Andresen
00:15:04
Und wir haben sie schon alle erreicht.
Stefan Hilmer
00:15:07
Und natürlich kommt der große Vorteil dazu, dass alle daran beteiligt waren oder sich daran beteiligen konnten und keiner irgendwie überstimmt wurde, sondern das so ein ziemlich einhelliges Ergebnis war. Die Alternativen ausprobiert waren, wo man sehr sicher war mit dem, was man da einführt.
Judith Andresen
00:15:28
Ja, also wir machen das auch bei, insbesondere bei IT-fernen Teams, dass wir sogar noch den Schritt davor, also wenn es um einzelne Teams geht, dass wir sowas wie Kanban, Design Thinking, Scrum, da haben wir jeweils Simulationen, damit wir sehr früh mit Teams da uns reinspielen können. Und damit es keine theoretische Debatte über das richtige Tooling und die richtige Methodik gibt, sondern dass Leute einfach sagen können, das fühlt sich für unser Thema genau richtig an und dann kann man es halt auch nochmal rein simulieren in Fachlichkeit. Und das, finde ich, ist echt das Mittel der Wahl, weil Leute dann auch lernen können, wir machen kurze Lernzyklen, wir nehmen das wahr, was wir tun, wir lernen daraus, wir passen uns das so an. Das ist halt, finde ich, total großartig, wenn man iterativ, inkrementell Lernen schon in der Einführung übt. Und zwar nicht theoretisch, sondern praktisch.
Stefan Hilmer
00:16:27
Ja, genau. Agil, agil auch erleben, neue Methoden erleben von vornherein. Auch immer wieder sehen, dass das funktioniert. Das ist das, was dahinter steckt und was die großen Vorteile daraus bringt.
Judith Andresen
00:16:44
Jetzt gibt es ja so Leute, die sagen, wir müssen das auch die ganze Zeit erklären und immer noch so ein Ratio-Part dabei haben mit einem, das ist Win or Learn, hier sind Inkremente, hier sind Iterationen, hier sind Lernzyklen. Habt ihr das deutlich gemacht oder es gibt ja die andere Fraktion, die sagt, komm, lass uns das einfach ausprobieren und dann wächst schon das Bewusstsein darüber? Darüber, wie sehr war die Erklärbär dabei und warum? Also das ist ja eine Entscheidung wahrscheinlich, Erklärbär zu sein oder nicht.
Stefan Hilmer
00:17:23
Ja, also die Design Thinking dann vorher so vorzustellen, das haben wir eigentlich gar nicht gemacht. Wir waren uns dessen irgendwie relativ schnell klar, dass wir das so machen sollten, Aber jetzt irgendwie Folien auflegen und den Zyklus da erklären oder so, das haben wir bewusst weggelassen. Wir haben schon nachher relativ schnell gemerkt, dass wir bei den Methoden, also bei den Frameworks sehr viel erklären müssen und sehr viel. Irgendwann ist es dann auch ein Overload. Hinterher haben sie es natürlich alle gewusst und spätestens jetzt, wo wir das so erzählen, wird es die Meinung der anderen vielleicht auch bewusst werden, aber... Und ansonsten haben wir nicht versucht, da auf den Methoden dann zu intensiv umzuhören.
Judith Andresen
00:18:12
Ja, das kann ich nachvollziehen. Also ich bin auch eher für die praktische Erfahrung, also für erfahrungsbasiertes Lernen, um dann im Zweifelsfalle nochmal nachzuerklären. Also ich finde zum Beispiel, wenn ich jetzt nicht in Frameworks bin, also nicht in skalierten Frameworks, sondern einfach in der Projektmethode als solches, dann ist ja oft ein Daily vorgesehen und dieses, dass das aktive Störungssuche ist, dass das die Stelle ist, um Austausch und Kommunikation und auch Störungsbewältigung hinzukriegen und auch Zusammenarbeit. Ich finde, das kann man halt erklären, wenn es soweit ist. Und dann muss man sich fragen, stellt sich das einfach ein oder genügt es das, dass die Beteiligten anders handeln? Da finde ich, braucht es einen guten Blick drauf, was es braucht. Aber ich gehöre halt nicht zu den Leuten, die da aktiv reingehen, weil im Zweifelsfalle hat man dann wieder eine theoretisierende Debatte, ob man das wirklich braucht oder nicht. Und ich finde immer schöner, wenn Leute ihre Erfahrungen machen.
Stefan Hilmer
00:19:16
Ja, das sehe ich genauso, also so spät wie möglich, aber das ist eben auch da wieder total situationsabhängig. Es gibt Sachen, da kommt man gar nicht dran vorbei. Das führt mich jetzt fast schon zu unserem zweiten Beispiel, wo wir die Teamentwicklung, also letztendlich diese vier Teams etwas später in der Teamentwicklung begleitet haben und die Teamentwicklung dann abgebildet haben auf Kahnbahn. Eigentlich relativ einfach und sieht man ziemlich häufig. Aber wenn man dann anfängt, mit Kahnbahn diese Teamentwicklung zu machen, damit die Visualisierung auch für die Teams zu machen, dann muss man den Teams auf Kahnbahn erklären. Da kommt man nicht dran vorbei.
Judith Andresen
00:20:00
Ja, genau, weil für viele ist ja Kahnbahn erst mal nur die Wandzeitung. Und die Magie fängt ja an, wenn man sich um zum Beispiel das WIP kümmert. Also die Grenze, die Anzahl deiner offenen Arbeit ist halt wahnsinnig, wichtiger und mächtiger Faktor. Und ich finde, das muss man halt klarkriegen. Also der Fokus, den Kanban da liefert, den auch wirklich zu nutzen. Und was habt ihr rausgekriegt? Welchen WIP benutzt ihr in Organisation und Entwicklung?
Stefan Hilmer
00:20:34
Wir haben uns darauf geeinigt, einen Prozess abzubilden, der letztendlich zu Idee, Planung, Umsetzung, Reflexion und dann eben dann oder fertig beinhaltet. Und wir haben uns natürlich darauf geeinigt, die Umsetzung zu machen, weil es war uns wichtig, dass in den Teams nicht so viele Sachen gleichzeitig passieren. Das ist so der Ansatz dabei, der am einfachsten macht, aus unserer Sicht jedenfalls. Allerdings haben wir den auf 1 limitiert und das war wahrscheinlich ein bisschen zu stark. Aber wir wollten auf der anderen Seite auch nicht mehrere Umsätze gleichzeitig haben, die sich gegenseitig beeinflussen. Und da war dann der Ansatz, herzukommen von diesem Ansatz, jedes Team ist anders. Und haben dort gesagt, okay, wir führen da noch mehr Ebenen ein. Und zwar, was in der Teamentwicklung entwickelt werden kann. Und haben uns darauf geeinigt, also Maßnahmen zu unterscheiden zwischen Maßnahmen, die der Leistung des Teams dienen und Maßnahmen, die der Kultur dienen und Maßnahmen, die der psychologischen Sicherheit dienen. Also Sicherheit. erhalten. Und das haben wir auf den Bordern auch in Swimlanes unterteilt und haben dann etwas angesetzt, was uns da, vorher auch noch nicht so bekannt war, was ich also auf jeden Fall nicht so kannte, aber wir haben das Limited Work in Progress angesetzt pro Swimlane. Haben also gesagt, wir lassen dann drei Stück zu, aber jeweils nur in einer Swimlane.
Judith Andresen
00:22:23
Das ist ja auch eine Form, um Fokus zu schaffen. Ja, genau.
Stefan Hilmer
00:22:27
Genau, dass man dann eben nicht zwei Maßnahmen hat, die sich gegenseitig beeinflussen und man dann auch den Erfolg gar nicht mehr wahrnehmen kann oder so.
Judith Andresen
00:22:35
Ja, das ist ja, genau. Wichtig, datenbasiert zu arbeiten. Das war der Ansatz dabei. Ja, genau. Ja. Das finde ich sowieso an Kanban total fantastisch, dass es da so leicht messbare Kennzahlen gibt, mit denen man wahnsinnig viel anfangen kann. Also ich finde halt sowas wie, sich die Lead-Time anzugucken in einem Kanban-Prozess und mal zu gucken, was passiert. Insbesondere in der Organisationsentwicklung finde ich halt total schön. Wir erleben das oft, dass Organisationen eher in so einen Scrum-Prozess möchten, weil sie dann einfach so ein Gefühl haben von mehr Tickets und auch so ein Gefühl von beschäftigt sein, glaube ich, und rührig sein. Und da finde ich, muss man wirklich gucken, was da mehr nutzt. Also ob es mehr nutzt, Fokus zu haben oder viele Kleinigkeiten gleichzeitig zu bedienen und das durchzuorchestrieren, was man ja gut mit Scrum kann. Und da hilft auch im Zweifelsfall ein hartes A-B-Testing, um rauszukriegen, welche Methode da die richtige ist für die jeweilige Organisation.
Stefan Hilmer
00:23:48
Das stimmt auf jeden Fall. Und vor allen Dingen sollte man das auch für die jeweilige Organisation entscheiden. Ich bin mal einem Beraterkollegen begegnet, der sagte, naja, ich hoffe, du hast jetzt auch langsam festgestellt, dass Kanban besser ist als Scrum. Und ich stand dem da so gegenüber, völlig hilflos und habe dann so genickt, naja. Aber es ist halt so.
Judith Andresen
00:24:12
Ja, das Problem muss halt zur Methode und die Methode zum Problem passen. Und manchmal kann man richtig und manchmal squammen richtig, manchmal Design Thinking und manchmal Design Sprints und manchmal noch was ganz anderes. Und das finde ich ist, und vielleicht auch manchmal wirklich die Hands-on-Methode. Also ich kenne viele Organisationen, die sehr erfolgreich sich aus beliebigen Methoden, was zusammengeschnitzt haben mit Methodenbausteinen, das für sie erfolgreich ist und mit dem sie durchkommen. Da kann man dann einen Namen für vergeben oder man kann es auch lassen. Wichtig ist halt, dass das Problem gelöst wird und dass die Methode dazu passt.
Stefan Hilmer
00:24:52
Ja. Und häufig ist es gar nicht die Methode, die das Problem löst, sondern das Mindset, dass ich das Bewusstsein kriege, dass ich nicht alleine in meinem Unternehmen arbeite, sondern in meinem Team arbeite. Und dass ich gemeinsam Ziele verfolge und alleine agil vorgehe und auch Fehler machen darf und dass ich auch Sachen ausprobiere, um daraus zu lernen.
Judith Andresen
00:25:16
Und auch in die Verantwortung gehen kann und dass das okay ist, dass man sich traut. Und dann sind wir halt bei den wichtigen Themen, also Vertrauen, Zusammenarbeit, Zutrauen, Lernen. Das alles steckt für mich da drin. Und die Frage ist halt, finde ich was, oder findet die Organisation was, was methodisch die stützt, genau dahin zu kommen?
Stefan Hilmer
00:25:40
Ja. Ja.
Judith Andresen
00:25:41
Okay.
Stefan Hilmer
00:25:42
Ganz genau.
Judith Andresen
00:25:44
In diesem Sinne haben wir, glaube ich, zwei Beispiele besprochen über, wie man agil werden kann. Und gibt es noch etwas, was du ganz zum Schluss dir unserer Hörer-Innenschaft mitgeben möchtest?
Stefan Hilmer
00:26:05
Ja, dass man das, wenn man das nicht schon verinnerlicht hat, tatsächlich überlegt. Also egal, wie die Veränderung aussehen soll, egal auf welchem Punkt man startet, sich auch für die Veränderung schon Gedanken zu machen, wie ich das agil bewältigen kann. Das erleichtert einem das Leben ungemein.
Judith Andresen
00:26:23
Genau. Das sehe ich genauso. Ich finde, sich zu verändern als Organisation ist immer eine komplexe Aufgabe und da helfen agile Methoden wahnsinnig. In diesem Sinne, Stefan, ich danke dir für diesen kurzen Einblick und freue mich auf ein weiteres und nächstes Mal im Podcast. Dazu demnächst mehr, meine lieben HörerInnen. Und wir sehen uns. Nein, wir sehen uns und die anderen hören uns. Bis dann. Tschüss.
Stefan Hilmer
00:26:50
Tschüss und vielen Dank, dass ich da sein durfte.