Gute Prozesse sind nicht schlank (kostenoptimiert), sie sind gesund und vital. Das ist ein großer Unterschied. Was sind gesunde Prozesse? Ich persönlich finde die Unterscheidung auf Basis der zwei Dimensionen Flexibilität und Effektivität sehr spannend und zutreffend. Auf Basis dieser Differenzierung ist ein erster Gesundheitscheck möglich. Diesen Gesundheitscheck hatten wir bereits in einem Blogartikel im Oktober 2021 vorgestellt. Gesunde Prozesse sind effektiv und flexibel, nicht kosteneffizient und im kleinsten Detail durchnormiert. Sie helfen uns, das richtige, das gewünschte Ergebnis zu erzielen und bieten uns ausreichend Flexibilität, um ggf. auf Besonderheit reagieren zu können, ohne den Erfolg zu gefährden.
Dieser erste Gesundheitscheck hilft bei der Einordnung unserer Prozesse und Abläufe, hilft uns aber nicht bei der Analyse der Prozesse selbst weiter. Wir wissen zwar jetzt, welche Prozesse gesund und ungesund ist und können einschätzen, welche der Prozesse wir uns näher anschauen sollten, wissen aber noch nicht, wie wir einen ungesunden Prozess gesunden lassen können.
Ich weiß, im agilen Umfeld hört man das Wort „Standard“ und Prozess ungern. Standard klingt nach Gängelung fehlender Anpassungsfähigkeit. Zu Unrecht, wie ich finde. Standards sind per se nichts Schlechtes. Ganz im Gegenteil. Jedes agile Managementrahmenwerk wie Scrum oder Kanban setzt Standards. Und zwar bewusst. Und diese Standards in Form von Dailys, Retrospektive, Review, Sprintlänge basieren auf empirischen Beobachtungen.
Wikipedia definiert den Begriff wie folgt:
Ein Standard ist eine vergleichsweise einheitliche oder vereinheitlichte, weithin anerkannte und meist angewandte (oder zumindest angestrebte) Art und Weise, etwas zu beschreiben, herzustellen oder durchzuführen, die sich gegenüber anderen Arten und Weisen durchgesetzt hat oder zumindest als Richtschnur gilt.
Warum haben Standards einen solch schlechten Ruf? Ich denke, dass dies unter anderem darauf zurückzuführen ist, dass wir häufig mit „schlechten“ Standards zu kämpfen haben. Schlechte Standards und Prozesse unterliegen dem Denkfehler, man müsse den Mensch als Ausführenden standardisieren. Schlechte Standards behandeln daher Menschen wie Dinge. Gute Standards sehen im Gegensatz dazu den Menschen als das ausführende und bestimmende Element.
Die Standardisierung unterstützt den Menschen dabei, indem sie die Gründe für das Gelingen absichern. Gute Standardisierung soll sicherstellen, dass wir die Dinge, wir brauchen, um unsere Arbeit leisten zu können, schnell und einfach wiederfinden. Sie wirkt entlastend. Genau dann, wenn wir sie brauchen. Es geht um das Absichern der Gelingensbedingungen. /Anmerkung 1/
Wir können Sachen/Dinge standardisieren, aber nicht den Menschen. Er ist derjenige, der bestimmt, wie die Dinge passieren und was die Dinge tun. Der Mensch gestaltet, die Dinge helfen ihm dabei. Gelegentlich kommt es mir vor, dass wir dazu neigen (in Europa/USA), den Menschen im Prozess bestimmen zu wollen, statt uns auf die Rahmenbedingungen und Hilfsmittel zu fokussieren. Vielleicht resultieren hieraus die Auswüchse einer fast krankhaften Effizienzfixierung, wie sie Gunter Dueck 2020 in einem Buch beschrieben hat. /Anmerkung 2/ Ein guter Standard ist daher ein Referenzpunkt, der Reflexion erlaubt und Lernen erlaubt. Er ist nicht in Stein gemeißelt (wie es häufig leider verstanden wird), sondern wird beständig an neue Erkenntnisse aus der Reflexion angepasst, um die Bedingungen des Gelingens zu sichern.
Standards erzeugen daher auch Verbindlichkeit. Wir können uns darauf verlassen, dass das Daily immer zu gleichen Zeit am gleichen Ort stattfindet. Und wir können uns darauf verlassen, dass alle Teammitglieder zum Daily erscheinen. Wir wissen, dass eine Iteration eine einheitliche Länge hat und können verlässlich planen. Wir wissen, dass wir am Ende jeder Iteration ein fertiges Teilprodukt liefern, für das wir Feedback bei unseren Anspruchsgruppen einholen können.
Gute Standards liefern uns einen Referenzpunkt. Eine Vergleichsmöglichkeit, mit der wir die Realität abgleichen können. Sie ermöglichen uns das Lernen als Team und Organisation. Sie sind nicht für alle Zeit in Stein gemeißelt und definiert, sondern sie passen sich an. Sie passen sich an die Menschen an, die mit diesen Arbeiten, weil sie dazu da sind, die Menschen zu unterstützen und ihnen dabei zu helfen, die Gelingensgründen zu sichern. Wenn der Standard nicht mit unserer beobachtbaren Realität übereinstimmt und nicht dazu beiträgt, dass uns unsere Arbeit gelingt, dann passen wir den Standard an unsere Erkenntnisse an. Damit wir dies auch tun können, brauchen wir regelmäßige Reflexionsschleifen und machen unsere Standards – auch die Impliziten – explizit, sodass wir in der Lage sind, diese immer wieder zu hinterfragen und weiterzuentwickeln. Auf Basis unserer Erkenntnisse über die Gründe für das Gelingen. Ich hatte bereits Scrum als Beispiel zu Beginn erwähnt, hier gibt es am Ende jeder Iteration die Rückkopplungsschleife in Form eines Review und der Retrospektive.
Der Scrumleitfaden wurde von Beginn an von der Gemeinschaft der Anwender beständig weiterentwickelt und an die neuen Erkenntnisse für die Gelingensbedingungen angepasst. /Anmerkung 3/ Der Standard passt sich an die Bedürfnisse der Anwender an. Nicht umgekehrt. Und das Erstaunliche dabei ist, dass der Standard in all den Jahren nicht „aufgebläht“ wurde, sondern – auch dies gehört zu einem guten Standard dazu – immer auf das Wesentliche fokussiert geblieben ist. Vergleichbar mit Kanban, dass mit einen evolutionären, sich beständig weiterentwickelnden Ansatz verfolgt, bei dem die regelmäßige Reflexion der Standards Teil des Verständnisses ist. /Anmerkung 3/
Das Geheimnis, das eigentlich keins ist, liegt darin, die Frage aufzuwerfen, was wollen wir erreichen? Und danach erst die Frage aufzuwerfen, wie wir möglichst einfach genau dieses Ziel erreichen. Was brauchen wir wirklich, um das Ziel zu erreichen? Was brauchen wir nicht? Was trägt wirklich zu Gelingen unseres Tuns bei und was nicht.
Wenn wir die Erkenntnis in unseren Alltag – auch jenseits von Scrum und seinen Anwendungsfeldern – integrieren wollen, bedeutet dies, unsere Prozesse und Standards aus Sicht dessen zu betrachten, was wir als Ergebnis erreichen wollen und was wir als die Ausführenden und Gestaltenden dafür brauchen, um dieses Ergebnis zu erzielen. Was davon trägt dazu bei? Was können wir weglassen? Und genau die Dinge zu identifizieren, die dazu beitragen, dass wir brauchen, um gute Ergebnisse zu erzielen. Diese sichern wir dann als Standard ab und stellen unseren Standard regelmäßig auf den Prüfstand beispielsweise mit einer Verbesserungsiteration (im Sinne der Verbesserungskata) 😉.
Anmerkungen
/1/ Mari Furukawa-Caspary: Lean auf gut Deutsch, Band 1 und 2, Books on Demand, 2015
/2/ Gunter Dueck: Heute schon einen Prozess optimiert?, Campus 2020
Eigentlich müsste es ein Grund zur Freude sein. Agilität ist auf dem Vormarsch. Sie zu fördern, das Wissen und Können auf eine breite Basis zu stellen und auch in die öffentliche Verwaltung zu tragen, ist schließlich eine Herzensangelegenheit des Forums Agile Verwaltung. Und doch treibt mich eine Sorge um. Dies Sorge, dass wir das „agile Pferd“ zu Schande reiten. Was ich beobachte, ist ein „bloßes Kopieren“ der Methoden, ohne den tieferen Sinn der Prinzipien, die dahinterstehen, zu ergründen, zu reflektieren. Und dies löst bei mir ein Deja-vu aus.
Vielleicht erinnert sich noch der eine oder andere – es sind immer hin gut zwei bis drei Jahrzehnte her, als Toyota mit seinem Toyota Production System (TPS) das große Vorbild – nicht nur für die Automobilindustrie – war. Alles sollte schlanker, effizienter werden. Und deshalb wurden die „Methoden“, die Toyota so erfolgreich gemacht haben, häufig unreflektiert übernommen, ohne ein vertiefendes Verständnis hinter den Prinzipien zu entwickeln. Der Erfolg stellte sich oft nicht so ein wie erhofft. Eingeweihte ahnen, etwas Entscheidendes wurde vergessen. Nicht das „Werkzeug“ war entscheidend, sondern die Art und Weise, wie das Werkzeug eingesetzt und weiterentwickelt, adaptiert wurde – basierend auf wenigen Prinzipien. Prinzipien, die sich auch in dem wiederfinden, was wir heute Agilität nennen. Denn interessanterweise ging es Toyota selbst nicht vorrangig um betriebswirtschaftliche Kostenoptimierung, sondern „handwerkliches Können“, wie ich vor Kurzem von einer Kennerin der Materie, Mari-Furukawa-Caspary[1], lernen durfte.
Der Blick auf Agilität wird – nach meiner Beobachtung – immer öfter auf Methoden und Erfolgspraktiken verkürzt, die vermeintliche Blaupausen für die Agilisierung von Organisationen liefern. Die vermeintliche Effizienz der agilen Ansätze rückt in den Fokus und dient viel zu häufig als Begründung für Agilität. Agilität und die agilen Ansätze werden zu vermeintlichen Wundermethoden, die man nur „kopieren“ muss, um Probleme moderner Organisationen in einer komplexen Welt zu lösen. Unreflektiert und ohne hinter die Prinzipien zu schauen, wird zum Beispiel Scrum (oder ein anderes agiles Rahmenwerk) eingeführt. Verbunden mit der Hoffnung, effizienter, kostengünstiger zu werden (ja, auch Verwaltung muss Kosten reduzieren, effizient sein). Natürlich immer mit Blick auf Beispiele gelungener Praxis aus anderen Organisationen, die man zu kopieren sucht. In großen Unternehmen setzt man immer häufiger auf Skalierungsrahmenwerk als Blaupausen wie SAFe[2] und Spotify-Model, um die Gesamtorganisation moderner und agiler zu machen. Meist, um sich dann zu wundern, warum es dort funktioniert hat und bei einem selbst nicht. Ein Trend, der zum Glück noch nicht in der öffentlichen Verwaltung in der Fläche angekommen ist. Aber sicher mit Sicherheit noch kommen wird.
Mit meiner Beobachtung bin ich nicht allein. Unter anderem gibt es die Diagnose „Zombie Scrum“ für Projekte, die zwar beanspruchen, Scrum zu praktizieren, aber in denen mit Blick auf die Prinzipien und Werte die gelebte Wirklichkeit erschreckend oft eine andere ist. Es steht zwar Scrum auf der Verpackung und das Regelwerk wird offenbar eingehalten, aber die Prinzipien dahinter werden kaum praktiziert. Die Autoren des Buchs Zombie Scrum Survival Guide führen diesen Zustand auf ein mangelndes Verständnis der Sinnhaftigkeit der zugrundlegenden Prinzipien und Werte hinter der vermeintlichen Methodik zurück. Die Symptome, die sie benennen, beziehen sie zwar auf Scrum geführte Projekte, sie lassen sich durchaus auf Agilität im Allgemeinen (sie finden sich zum Beispiel ähnlich als „Fehlmuster“ – Anti-Pattern – unter anderem im Kanban Maturity Model[3] wieder) übertragen:
Die Bedürfnisse der Anspruchsgruppen sind kaum bekannt und werden nicht wirklich berücksichtigt. Kaum jemand macht sich die Mühe zu erkunden, was diese wirklich brauchen. Prozesse, Abläufe und Arbeitsweise werden nicht nach deren Bedürfnissen ausgerichtet und weiterentwickelt, sondern aus Sicht der Bedürfnisse der bürokratischen Organisation [Kleine Randnotiz: auch sie ist kein Selbstzweck, mutiert aber gerne dazu].
Echtes iterativ-inkrementelles Arbeiten mit kurzen Feedbackzyklen findet nicht wirklich statt, so dass kaum konstruktives Feedback von den Anspruchsgruppen generiert wird und die „Wertschöpfung“ ausbleibt. Nicht die Lösung des Problems der Anspruchsgruppen steht im Fokus, sondern der „Selbstzweck“ der Organisation.
Echte kontinuierliche Verbesserung und Weiterentwicklung der Prozesse und der Ergebnisse findet nicht oder kaum statt. Es wird auf bewährte Praxis gesetzt, statt gezielt durch Experimente neue Ansätze zu erkunden und die Organisation nach den Bedürfnissen der Beteiligten auszurichten.
Agile Teams werden nicht zur Selbstorganisation befähigt. Dabei ist dies das ureigene Bestreben des agilen Weges, die Problemlösungsfähigkeit im Sinne der Experten innerhalb eines gegebenen Korridors und Ziels zu stärken und so die Reaktionsfähigkeit der Organisation auf sich verändernde Bedingungen zu erhöhen.
Mit einer der Grund hierfür ist, dass die Agilität mit Methodik gleichgesetzt wird und der Fokus zu sehr auf einer methodischen Sicht liegt, während die zugrunde liegenden Prinzipien bei der Umsetzung agiler Ansätze vernachlässigt werden. Eine regelmäßige reflektierte Auseinandersetzung mit dem Weshalb und mit den Grundlagen ist sehr hilfreich, dem entgegenzuwirken. Auf das Kopieren von erfolgreicher „Implementierungen“ im Sinne von Best Practice zu setzen, vernachlässigt, dass Organisationen selbst hochgradig komplex sind und trotz aller Ähnlichkeiten die entscheidenden Faktoren nicht die offenkundigen sind, die man an der Oberfläche sieht. Das sollte uns bereits durch die missglückten Adpationsversuche der Vergangenheit bewusst sein.
Wer sein Pferd nicht gut kennt und es nicht entsprechend hegt und pflegt, der reitet es zu Schande und kommt letztendlich nicht ins Ziel. Das gilt auch für die Agilität. Es liegt an uns, es nicht so weit zu kommen lassen.
[1]Mari-Furukawa-Caspary: Lean auf Gut Deutsch, Band 1, Books on Demand, 2016
[2]Ich bin kein großer Freund von SAFe als Rahmenwerk für die Skalierung von Agilität. Meines Erachtens ist unnötig kompliziert. Persönlich ziehe ich Kanban mit seinem evolutionären Ansatz vor, da es stärker darauf ausgerichtet, bestehende Strukturen zu nutzen und diese evolutionär weiterzuentwickeln.
[3] David J. Anderson/Theodora Bozheva: Kanban Maturity Model – Handbuch für Agilität, Resilienz und Neuausrichtung, dpunkt-Verlag 2021. Das Buch ist allerdings nicht für den Einstieg in die Kanban-Materie geeignet, sondern wendet sich an fortgeschrittene Anwender, die ihre Kenntnisse vertiefen wollen. Für den Einstieg in die Materie Kanban empfehle ich gerne Mike Burrows: Kanban – Verstehen, Einführen und Anwenden, dpunkt Verlag, 2015
Vor längerer Zeit bin ich zufällig im Blog von Stefan Wolpers über eine Idee gestolpert: Die Meta-Retrospektive.
Worum geht es genau? Der Scrum Guide definiert zum Ende jedes Sprints ein Ereignis, dass sich Retrospektive nennt. Die Retrospektive dient der Reflexion der Zusammenarbeit im Team. D. h. externe Teilnehmer sind nicht eingebunden. So wird ein sicherer Raum geschaffen, der es dem Team erlaubt, offen über die Herausforderungen, Schwierigkeiten und Defizite im operativen Tun zu sprechen und Verbesserungsmaßnahmen zu entwickeln. Die Anspruchsgruppen außerhalb des Teams sind in aller Regel über den Review in den Prozess eingebunden. Allerdings wird im Review über die Ergebnisse des Sprints gesprochen und reflektiert und nicht über die Zusammenarbeit zwischen Team und Anspruchsgruppen. Diese würde den Rahmen des Reviews sprengen, der dazu dient, konkretes Feedback zum Sprintergebnis zu generieren, dass bei der Planung des Folgesprints einfließen soll.
Was fehlt, ist ein Rahmen, in dem das Team mit Vertretern der Anspruchsgruppen gemeinsam reflektiert, wie die Zusammenarbeit zwischen Team und Interessensgruppen – also den diversen Anspruchsgruppen – funktioniert. Gerade diese Schnittstellen zu den verschiedenen Anspruchsgruppen können in der Praxis erhebliche Probleme und Reibungen erzeugen, die die Produktivität das Teams schmälern. Insbesondere dann, wenn ein agiles Team in eine – eher „klassische“ Umfeldstruktur eingebunden, die mit der agilen Arbeitsweise noch nicht vertraut ist, eine nicht zu unterschätzende Herausforderung. Genau hier kann eine Meta-Retrospektive die Lücke schließen.
Die Herausforderung besteht meist darin, dass der Teilnehmerkreis einer Meta-Retrospektive schnell sehr groß werden kann. Wie haben es nicht mit einem klar abgegrenzten Team mit maximal 9 Personen zu tun, sondern mit einem deutlich größeren Kreis von Personen. Schnell kommt man auf einen Teilnehmerkreis 15 und mehr Vertretern der unterschiedlichen Fraktionen. Da es in einem großen Plenum mit mehr als 8 Personen schwierig ist, produktiv ergebnisorientiert zu arbeiten, bieten sich – auf Gruppenarbeit basierende – Moderationstechniken an. Die Meta-Retrospektive sollte daher sehr gut vorbereitet sein und von einem erfahrenen Moderator begleitet werden, der auch die Fallstricke entsprechender Gruppendymamiken einordnen kann.
Auch bei der Meta-Retrospektive bietet sich an, sich an den fünf Phasen einer Retrospektive zu orientieren. Die Eröffnung erfolgt dann zum Beispiel im Plenum über ein Stimmungsbild in Form eines Raumdiagramms. Danach werden Gruppen bis zu acht Personen gebildet, die in die Phasen 2 und Phasen 3 jeweils reflektieren. Die Aufgabenstellung orientiert sich meist an den den entsprechenden Fragestellungen, wie wir sie in der Team-Retrospektive zur Anwendung bringen: Wobei der Fokus insbesondere auf der Zusammenarbeit liegt.
Hilfreiche methodische Ansätze finden sich zum Beispiel im Methodenkoffer der Liberating Structurs. Aber auch die Bearbeitung mit Großgruppenmoderationstechniken wie World Café bietet sich an. Da Meta-Retrospektiven aufwendiger sind, macht es wenig Sinn, sie in derselben Häufigkeit stattfinden zu lassen, wie im Falle einer Team-Retrospektive. Trotzdem bietet sich an, diese regelmäßig durchzuführen, beispielsweise einmal im Quartal oder beim Erreichen eines „Meilensteines“. Es gibt immer etwas, was man verbessern und weiterentwickeln kann – auch in der Zusammenarbeit.
Agile Strategie in der Verwaltung – Teil 1 – Status Quo
Über sein Zitat, „Wer Visionen hat, soll zum Arzt gehen“, ärgerte sich Helmut Schmidt viele Jahre lang. Später sagte er, „Es war eine pampige Antwort auf eine dusselige Frage“. Natürlich hatte Helmut Schmidt sehr klare Zielvorstellungen und wusste nur allzu genau, was er wollte und was nicht. Wozu das Fehlen eines klaren Zielbildes führt, können wir derzeit mit Schmerzen beim britischen Brexit beobachten.
Was hat das mit der Verwaltung zu tun? Ich habe im Laufe meiner beruflichen Laufbahn eine ganze Menge Zielbilder, Leitbilder und Strategien in den Verwaltungen gesehen, leider fehlte hier fast immer ein Erfolgsfaktor: die Antwort auf eine ganz entscheidende Frage „Warum machen wir das Ganze überhaupt?“
„Was hat Lean Management, agile Methoden und Unternehmensdemokratie – das verträgt sich doch alles nicht mit einem öffentlichen Auftrag“, war vor nicht allzu langer Zeit eine Aussage, die zu hören bekam, als ich in einem Gespräch auf das Forum Agile Verwaltung gekommen bin. Ist dem wirklich so? Wir vertreten beim Forum Agile Verwaltung eine gegensätzliche These und meinen sogar, dies unmittelbar aus der Praxis untermauern zu können. Anhand einer typischen öffentlichen Aufgabe wohlgemerkt: den Feuerwehren. Die Feuerwehr gehört zu den kommunalen Pflichtaufgaben (entsprechende landgesetzliche Regelungen in den jeweiligen Bundesländern – die sogenannten Feuerwehrgesetze regeln diese). Damit gehört die Feuerwehr zu den Aufgaben, die eine Stadt oder Gemeinde erfüllen muss und auch tatsächlich auf sehr hohem Niveau in aller Regel erfüllt. Und was noch viel erstaunlicher ist, die Kommunen erfüllen die Aufgabe mit Freiwilligen Feuerwehren, die sich dabei auf Freiwillige, soll heißen: ehrenamtlich tätige Männer und Frauen, stützen, die hierfür ihre Freizeit opfern.
Schauen wir uns einmal die Freiwillige Feuerwehr näher an. Was nämlich vielen gar nicht bewusst ist, sind eben diese ein Lehrstück dafür, wie öffentliche Aufgabenerfüllung mit den Ideen agiler Verwaltung harmoniert. Auf den ersten Blick haben wir es bei den Freiwilligen Feuerwehren mit straffen und hierarchischen Strukturen zu tun. Doch der Eindruck täuscht.Weiterlesen „Lean, Agile und Unternehmensdemokratie – was hat das mit öffentlicher Aufgabenerfüllung zu tun?“
Oft taucht die Frage auf, was ist eigentlich Agilität. Nun, es gibt keine einfache Definition. Zumindest nicht in dem Sinne, wie wir den Begriff im Forum Agile Verwaltung verstehen. Agile ist für uns eine Geisteshaltung. Eine Geisteshaltung die Basis des agilen Manifests (der Softwareentwicklung) und den dort definierten 12 Prinzipien basiert. Wenn der Begriff Agilität aus der Softwareentwicklung stammt, was hat dies mit der öffentlichen Verwaltung zu tun? Dieser Frage müssen wir uns des Öfteren stellen. Werfen wir daher einen kurzen Blick auf das agile Manifest
Das Agile Manifest
Die Komplexität, mit der wir zu kämpfen haben, gewinnt täglich an Fahrt. Sie ist nicht neu. Sie war schon immer da. Neu ist aber, die extrem hohe Veränderungsgeschwindigkeit, mit der wir uns zunehmend auseinandersetzen müssen. Noch während wir Entscheidungen beraten, verändert sich die Faktenlage und wir müssen wieder umdenken. Diese Veränderung trifft nahezu alle Branchen, so auch die öffentliche Verwaltung. Weiterlesen „Was ist Agilität? – Eine Einführung in das Agile Manifest“
Die Kernaussage: Es gibt einen Paradigmenwechsel. War es vorher noch das Bild einer Maschine mit Planung und Kontrolle, so sehen sich Organisationen heute zunehmend als lebendiger Organismus, der einem schelle Wandel effektiv folgen kann. Dabei sieht Frederic drei wesentliche Dinge, die anders sind: Weiterlesen „Wenn das Organisationsmodell von Buurtzorg dem Dalai Lama gefällt …“
Der deutsche Ordnungssinn ist weltweit bekannt. Und wir sind bekannt dafür, dass wir alles regeln. Es muss ja schließlich alles seine Ordnung haben und jeder muss wissen, was er zu tun hat. Dabei sollen Dinge geregelt werden, die eventuell und vielleicht irgendwann einmal relevant sein können. Aus meiner Sicht keine gute Idee und sogar fatal oder anders ausgedrückt, alles in die Zukunft hinein detailliert regeln zu wollen, hinterlässt Chaos und Unverantwortlichkeit. Es ist kontraproduktiv.
Systemische Fragen liefern eine einfache Möglichkeit, agile Haltungen in auch traditionellen Branchen zu stärken.
Jeder will agil werden! Logisch, muss ja, wegen der Digitalisierung und so. Diese Sichtweise kommt zunehmend in den Chefetagen an. Agiles Management, Innovationsfähigkeit, Dynamik sind nicht nur en vogue, sondern in Zeiten des gesellschaftlichen Wandels notwendige Bedingungen für das Überleben von Organisationen. Gerade jedoch, wenn wir uns in eher traditionellen Branchen wie der Verwaltung oder der Sozialwirtschaft bewegen, stellt sich die Frage, wie die Mitarbeitenden „an der Basis“ mehr Selbstorganisation und Eigenverantwortung in ihrem Arbeitsbereich leben können. Hier ist die Herangehensweise, agiles Management, Führung und systemische Fragen zu verbinden, zielführend. Weiterlesen „Systemische Fragen, Führung und agiles Management“
, für seine 20-minutige Erklärung vor seiner Heiligkeit, dem Dalai Lama, darüber, welche Transformation gerade in unseren Unternehmen stattfinden.
Agile Verwaltung 