ZURÜCK

Zuerst erschienen in der public Ausgabe 03-2021 

Ein Projektbericht von Arne Schneikart (ITZBund), Ute Wiesner (ITZBund), Katharina Schmitt und Maria Frick

 

Wie das EAGLE-Team des ITZBund bei der Einführung agiler Vorgehensweisen in der IT unterstützt. 

Montagmorgen, 9:30 Uhr. Das Telefon klingelt. Ich habe kaum den Anruf angenommen, da legt die Kollegin am anderen Ende der Leitung auch schon los: „Es ist unglaublich, wie kann man nur so starrsinnig sein?!“ Ich verstehe erst mal nichts, aber schnell stellt sich heraus, dass sich ein Mitarbeiter ihres Projekts weigert, die Software, die er entwickelt, zu dokumentieren. Schließlich brauche man das bei agiler Softwareentwicklung doch nicht.

Da ist er wieder, einer der vielen Mythen in agilen Projekten. Ähnliche Erfahrungen machen viele, die in vorderster Reihe agile Softwareentwicklung einführen und sich somit auf dem Weg einer agilen Transition befinden. Klar ist: eine Organisation wird nicht über Nacht agiler. Wissen muss aufgebaut, Erfahrungen müssen gemacht, Vorurteile und Hindernisse überwunden werden, denn der Weg ist das Ziel. Unabhängig davon, ob in einem Team mit fünf oder einer Organisation mit 2.500 Beschäftigten: Wenn agile Softwareentwicklung oder agile Arbeitsmethoden nachhaltig eingeführt und gelebt werden sollen, ist das aufwendig, kostet Zeit und führt temporär zu Leistungseinbußen. Warum? Weil es nicht leicht ist, alte, gelernte Verhaltensmuster abzulegen und gewohnte Kommunikations- und Prozessstrukturen zu durchbrechen. Weil Wandel und Veränderung in komplexen Umfeldern oft unterschätzt werden. Vor diesen und weiteren Herausforderungen bei der Einführung agiler Softwareentwicklung stand auch das Informationstechnikzentrum Bund (ITZBund). Als zentraler IT-Dienstleister der Bundesbehörden ist das ITZBund dafür zuständig, IT-Verfahren im Kundenauftrag zu entwickeln und zu betreiben. Die Antwort auf die vielfältigen Fragen, die sich durch die Transition zu agiler Softwareentwicklung ergeben, war EAGLE.

 

EAGLE steht für „Etablierung agiler Softwareentwicklung“ und ist der Name für ein Team, das seit 2017 selbstorganisiert, hierarchie- und bereichsübergreifend zusammenarbeitet. Es hat den Auftrag, agile Softwareentwicklung im ITZBund einsetzbar zu machen, und berät die agilen Entwicklungsteams des ITZBund sowie deren Kunden. Inzwischen geht die Beratung zu agilen Methoden und Praktiken auch über den Bereich der Softwareentwicklung hinaus, weil die Berührungspunkte mit anderen Bereichen größer und häufiger sind als gedacht. EAGLE besteht aktuell aus zehn Teammitgliedern, davon sieben interne Beschäftigte des ITZBund und drei externe Beraterinnen der msg. Die Zusammenarbeit zwischen EAGLE und msg besteht seit 2018. Alle Teammitglieder bringen circa 50 Prozent ihrer Zeit für die Arbeit im EAGLE-Team auf. Das Team versteht sich als Keimzelle der Agilität im ITZBund.

 

In diesem Projektbericht beschreiben wir den Weg des EAGLE-Teams von der organisatorischen Einführung bis zur Etablierung agiler Softwareentwicklung. Wir verstehen das als ersten Schritt und Teil einer agilen Transition, um die Flexibilität und Reaktionsfähigkeit der Organisation zu erhöhen. Die Einführung agiler Softwareentwicklung und die damit verbundenen Veränderungen breiten sich in konzentrischen Kreisen vom Individuum über Teams bis hin zur Organisation aus (siehe Abbildung 1).

 

Es fängt bei der Bereitschaft an

Beim agilen Arbeiten wird das klassische Command-and-Con-trol- Vorgehen durch den agilen Inspect-and-Adapt-Ansatz ersetzt. Das erfordert die individuelle Bereitschaft aller Beteiligten, Neues auszuprobieren und etablierte Verhaltensweisen zu hinterfragen. Es geht darum, kontinuierlich zu lernen – nicht nur am Anfang, sondern auch während man bereits auf dem Weg ist! Transition ist ein fortwährender Prozess – nicht geradlinig, sondern in Kreisen voranschreitend. Das Team und die ganze Organisation werden reaktionsfähiger, robuster und zukunftsfähiger. Das geschieht in vielen kleinen Schritten, Entscheidungen und Reflexionen.

 

Die Teams als Keimzelle agiler Softwareentwicklung

Wo anfangen, wenn agile Methoden eingeführt werden sollen? Beim Management? Bei den Prozessen? Bei der Kultur? Bei den Tools? Wir wissen, dass man einer Organisation Agilität nicht einfach „überstülpen“ oder „verordnen“ kann. Versucht man es doch, das zeigen leidvolle Erfahrungen vieler Organisationen, läuft man Gefahr zu scheitern. Also haben wir nach einem „kleinen“ Einstieg ins Thema gesucht – und diesen im eigenen EAGLETeam als „kleinste Organisationseinheit“ gefunden. Leitmotiv dabei war der erste Satz des agilen Manifests:

 

„Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen.“

 

Command-and-Control-Ansatz ("Weisung und Kontrolle")

Heißt so viel wie nach vorne zu schauen und Ergebnisse festzulegen, um sie dann mithilfe von Plänen und Steuerungssystemen zu realisieren. Der Ansatz folgt zwei Annahmen:

1. Ergebnisse können im Voraus im Detail gesetzt werden und

2. Kontrollmechanismen können verwendet werden, um die Erreichung der gewünschten Ergebnisse zu steuern.

Aus der Annahme folgt eine Command-and-Control-Organisationskultur und -struktur, in der immer klar ist, wer was wann zu tun hat. Detailliert ausgearbeitete Prozesse, klare Vorgaben und Hierarchien regeln den Umgang miteinander.

Inspect-and-adapt-Ansatz ("Überprüfen und anpassen")

Heißt so viel wie empirische Prozessteuerung und meint die stetige Verbesserung (Anpassung) durch permanente Überprüfung.

Die erzielten Ergebnisse werden regelmäßig überprüft, ob sie der Erfüllung der gesetzten Ziele dienlich sind. Ziel der Prüfungen ist es auch, Feedback zur Zielerreichung zu erhalten, um daraus abzuleiten, wie das Vorgehen angepasst werden sollte, um das Ziel besser (oder ein besseres Ziel) zu erreichen.

 

 

Das war unser Startpunkt. Wir mussten nur „Software zu entwickeln“ durch „für das, was wir vorhaben“ ersetzen. Man kann andere nicht agil(er) machen, wenn man selbst nicht agil arbeitet. Also begannen wir als EAGLE-Team, agil zu arbeiten. Wie gut, dass wir von Beginn an bunt zusammengewürfelt waren – Expertinnen und Experten aus fünf Disziplinen der Softwareentwicklung, natürlich auch aus unterschiedlichen Linieneinheiten. Wir wählten Scrum als Framework aus, nach dem wir vorgehen wollten – nicht nach langer Untersuchung, sondern im besten Sinne des agilen Manifests als Experiment, ob und wie es funktioniert. Die Bereitschaft, sich auf Neues einzulassen, wurde also schnell getestet. Und hat sich bewährt. Nach einem zwischenzeitlichen Experiment mit Kanban arbeiten wir auch heute noch nach Scrum.

Innerhalb kurzer Zeit übernahmen auch erste Softwareentwicklungsteams dieses Vorgehen. Damit war klar: Im Kern setzen wir in der agilen Softwareentwicklung auf Scrum, wenn Teams beginnen wollen, agil zu arbeiten.

 

Learning: Veränderung und „Organisationsentwicklung“ finden auf Ebene der Teams statt! Teams sind die kleinsten Einheiten der Organisation. Teams sind der Ort, an dem die eigentliche Arbeit passiert und die Entscheidungen der täglichen Arbeit getroffen werden müssen, die die Organisation handlungsfähig machen. Effektive Organisationen bestehen aus effektiven Teams. Wann immer etwas Wirksames geschaffen wird, steckt die Arbeit eines oder mehrerer Teams dahinter. Veränderungen verbreiten sich von Team zu Team, wenn sie sinnvoll und hilfreich sind.

 

Kann das funktionieren? Wir brauchen Experimentierräume!

Auch der Inspect-and-Adapt-Ansatz ist elementarer Bestandteil von Scrum. Daran haben wir uns orientiert. Wir probierten in geschützten Experimentierräumen unser eigenes Vorgehen und das von Pilotprojekten in der Softwareentwicklung aus, um festzustellen, ob das, was wir in der Theorie als gut und sinnvoll identifiziert hatten, auch praxistauglich ist. Auf diese Weise ist zum Beispiel der Leitfaden für agile Softwareentwicklung entstanden, der bis heute im ITZBund eingesetzt wird.

Allerdings mussten wir uns schon früh mit Herausforderungen auseinandersetzen, die später auch unsere agilen Softwareentwicklungsteams einholten: Wie können wir mit ausreichender Qualitätssicherung in jedem Sprint eine hohe Qualität sicherstellen? Wie und was soll in jedem Sprint dokumentiert werden? Wie laufen Absprachen und vor allem Entscheidungen im Team? Was passiert, wenn der Product Owner nicht in ausreichender Weise zur Verfügung steht? Wie häufig und wann sollten wir die Kundschaft, Anwenderinnen und Anwender einbeziehen? Wie leben wir die agilen Werte am besten, insbesondere den ersten Wert „Individuen und Interaktionen vor Prozessen und Tools“, ohne ständig Diskussionen über Technik und Tools führen zu müssen?

Diesen Herausforderungen haben wir uns mit Mut, Offenheit, Selbstverpflichtung und Respekt (vier der fünf Scrum-Werte) gestellt und uns immer dann mit den Herausforderungen beschäftigt, wenn sie tatsächlich eintraten (im Sinne des Fokus – des fünften agilen Scrum-Wertes). Wir haben uns also eng an dem agilen Manifest und dem Scrum Guide orientiert. Und es ging viel: Kommunikation auf Augenhöhe – sowohl untereinander als auch zwischen Projektteams und Kunden in den agilen Projekten. Austausch mit anderen Projekten und sogar anderen Organisationen, um schneller zu lernen und an Erfahrungen zu partizipieren. EAGLE ist dabei ein Katalysator, der dieses Wissen allen Beschäftigten des ITZBund zugänglich macht.

Bald zeigte sich, dass nicht nur wir im EAGLE-Team in Bewegung waren, sondern dass sich auch in der Organisation des ITZBund etwas zu bewegen begann. Unsere Arbeit wirkte und zog erste Kreise. Das Interesse stieg, Skepsis und Zweifel gab es dennoch auch. Durch unsere regelmäßigen Reviews und Retrospektiven haben wir innerhalb der Experimentierphase immer wieder Anpassungen an unserem Vorgehen im EAGLE-Team und am Leitfaden für die agilen Teams vorgenommen. Das Feedback von außen und die selbstkritische Reflexion verhalfen uns zu besseren Konzepten und Ideen.

 

Learning: Zu Beginn einer Transition braucht es immer Experimentierräume!
Mit Lern- und Experimentierräumen haben wir im ITZBund Räume und Formate geschaffen, in denen wir prototypisches Vorgehen und Lösungen austesten und optimieren konnten, insbesondere für die agile Softwareentwicklung. Wir trauten uns zu experimentieren und reflektierten regelmäßig, ohne Fehler zu verurteilen. Vielmehr lernten wir gemeinsam aus Fehlern, wie wir unsere Ziele besser erreichen können. Und wir lernten, dass es nicht den einen besten Weg für alle gibt, sondern dass jedes Team in einem gewissen Rahmen selbst herausfinden muss, welcher Weg der beste ist. Auf diese Weise konnten wir gemeinsam Neuland erkunden.

 

Wenn sich Experimente als Standard etablieren

Um unsere Erkenntnisse aus den agilen „Experimenten“ als Orientierungsgeber möglichst vielen Beschäftigten zugänglich zu machen, haben wir begonnen, sie zu standardisieren. Mit dem Standard steckten wir einen Rahmen für agile Teams ab und legten die Verantwortung für die Ausgestaltung einzelner Arbeitsabläufe in die Hände dieser Teams. Entstanden ist ein für Behördenverhältnisse schlanker Leitfaden „Agile Softwareentwicklung im ITZBund“, der neben der Verpflichtung auf einen Start mit Scrum wichtige Erläuterungen zu spezifischen Rahmenbedingungen im ITZBund enthält – mehr nicht.

 

Learning: Es braucht einen organisationalen Rahmen, in dem sich alle flexibel bewegen dürfen. Wenn alle wissen, was sie dürfen, was möglich ist, welche Arbeitsmittel zur Verfügung stehen, und außerdem Transparenz über Sinn, Zweck und Ziel der Aufgaben besteht, finden alle ihre eigenen passenden Arbeitsabläufe. Jedes Team darf in einem gesetzten Rahmen selbst herausfinden und experimentieren, was der beste Weg ist.

 

Funktionierende Praktiken festigen

Agile Projekte müssen nicht alle Erfahrungen zwingend selbst machen. Sie dürfen auf den Erfahrungen von EAGLE und der Pilotprojekte aufbauen. Diese Erfahrungen haben wir in sieben wirksamen Praktiken gebündelt:

• Agil sein und vorleben: Man muss das agile Vorgehen selbst authentisch vorleben. In EAGLE haben wir viele Schmerzen der Organisation am eigenen Leib erfahren. Unser Mantra war stets: Practice what you preach. Man kann nicht theoretisch coachen, wie andere agil arbeiten sollen, wenn man es selbst nicht erlebt hat und lebt. Wir haben selbst Scrum, Kanban und Design Thinking ausprobiert, um die Methoden hautnah zu erleben.
• Klare Ausrichtung: Wir geben uns jährlich eine explizite Mission, Vision und Ziele in einem Konsententscheid1 und überprüfen diese in regelmäßigen Abständen. Um uns nicht in der Masse der Anfragen, Aufträge und Ideen zu verlieren, stellen wir sie in den Sprint Plannings und Teamtreffen immer wieder in den Fokus. So bleiben wir wachsam auf Kurs oder verändern den Fokus bewusst, wenn es notwendig ist.
• Interdisziplinarität im Team: Das EAGLE-Team ist interdisziplinär zusammengesetzt. Wir arbeiten crossfunktional, hierarchie- und bereichsübergreifend und legen viel Wert auf Teambuilding. Die unterschiedlichen Expertisen und Blickwinkel sind notwendig, um auch die diversen Erwartungen, Denkweisen und Rahmenbedingungen im ITZBund zu verstehen und zu berücksichtigen. Das EAGLE-Themenspektrum ist sehr breit, und wir haben den Anspruch, dass alle vieles können – aber nicht alles.
• Verantwortung übernehmen: Das Thema Verantwortung begleitet uns schon lange. Wir wollen, dass alle Teammitglieder mehr Verantwortung übernehmen, und gleichzeitig die Zuständigkeiten reduzieren. Bei uns im Team gibt es keine Stellen und Positionen (Hierarchien), sondern Rollen und Expertisen. Das Denken in Rollen unterscheidet uns von anderen Teams in der Organisation, bei denen zumeist in Positionen gedacht wird.
• Effektivität im Team: Unsere EAGLE-Meetings folgen den Scrum-Events, das heißt, wir machen Plannings, Dailies, Reviews und Retrospektiven im zweiwöchentlichen Rhythmus. Zusätzlich treffen wir uns zu festen, selbstorganisierten Arbeitsterminen. Bei der Aufgabenerledigung setzen wir oft und gerne „Pairing“ ein (entlehnt vom „Pair Programming“ der agilen Softwareentwicklung). So entstehen bessere Ideen, Wissen wird geteilt und die Arbeit macht mehr Spaß. Wir arbeiten auf Augenhöhe ohne Hierarchien oder Silos. In den Meetings sind wir stets auf der Suche nach der richtigen Entscheidungsform und wechseln meist zwischen Mehrheitsentscheid, konsultativem Einzelentscheid und Konsentverfahren.
• Führungskräfte-Commitment schaffen: Agilität als Graswurzelbewegung stößt schnell an organisatorische Grenzen. Aber Agilität kann auch nicht von oben „diktiert“ werden. Ohne die Unterstützung der Führungskräfte geht es nicht. So ziehen alle noch stärker am selben Strang.
• Good Practices teilen: In einer unserer ersten Besuche bei einer anderen Behörde wurden wir mit dem Spruch „Teilen macht reich“ empfangen. Das hat uns geprägt. Die in unseren fortlaufenden Experimenten gesammelten Erfahrungen stellen wir möglichst vielen Beschäftigten in verschiedenen Formaten zur Verfügung: projekt- oder kundenspezifische Beratungen, ein umfangreiches Wiki, unsere regelmäßigen Communities of Practices (CoPs), Scrum-Schnupperkurse oder die „Agile Academies“, eine Vortragsreihe zur Vertiefung bestimmter agiler Themen.

 

Learning: „Inspect-and-Adapt“ ist die Kernkompetenz der agilen Transition! 
Tradierte Arbeitsprozesse sind durch die, oft langwährende, Suche nach der „perfekten“ Lösung gekennzeichnet. Agile Arbeitsweisen suchen eine ausreichende Lösung, die schnell implementiert und dann kontinuierlich verbessert wird. Dafür brauchen wir Reflexions- und Anpassungsfähigkeit. Indem man sich regelmäßig auf das Ziel rückbesinnt und das bereits Erreichte mit diesem abgleicht, indem man reflektiert und sich immer wieder selbstkritisch hinterfragt, verhindert man, sich in Routine zu verlieren oder einen falschen Pfad einzuschlagen. Der stets vorhandene Wille, es anders und besser zu machen, ist der Treiber der agilen Transition.

 

Der kommunikative Wellenbrecher namens "Darf man das?"

Eine der größten Herausforderungen, die uns immer wieder begegnet und unser „Kreiseziehen“ bricht, ist die Frage „Darf man das?“ Während Entwicklungsteams das agile Vorgehen ausprobierten und ihren eigenen Weg fanden, gab es natürlich auch viele Fragen. Wo liegen die Grenzen, was darf ein agiles Team und was nicht? Mutmaßlich wird keine andere Frage so oft von Betroffenen und Beteiligten einer agilen Transition gestellt.

Ein Beispiel macht es deutlich: Als die Entscheidung anstand, ob ein Softwareentwicklungsprojekt agil oder „klassisch“ (wir nennen es inzwischen „linear“) durchgeführt werden soll, wurde die Frage gestellt: „Darf das Vorhaben agil umgesetzt werden, wenn in den Gemeinsamen Geschäftsbedingungen (GGB) des ITZBund das V-Modell XT vorgeschrieben ist?“

Um hier Klarheit zu schaffen, haben wir sowohl das V-Modell XT Bund als auch die GGB angepasst und das Thema Agilität integriert. Die Frage nach dem Dürfen ist häufig zentral in agilen Transitionen, da sie auf allen Ebenen und Dimensionen einer Organisation ganz unterschiedliche Auswirkungen hat. Weitere Beispiele für Fragen nach dem Dürfen sind:

• Darf ich als Mitarbeiterin oder Mitarbeiter oder als Team eine Entscheidung treffen oder muss das die Führungskraft tun?
• Dürfen wir direkt den Kunden (Product Owner) anrufen, wenn wir eine Frage haben
• Darf ich mit Beschäftigten eines anderen Bereichs sprechen oder muss das über die Bereichsleitungen gehen?

Wichtig ist, dass die Beteiligten ermutigt werden, die Fragen zu stellen, da sie damit Interesse am Thema zum Ausdruck bringen. Mit der Beantwortung der Fragen und im Austausch miteinander lässt sich vieles regeln. Agiles Arbeiten bedeutet nicht zwingend, existierende Regeln mutwillig zu brechen, sondern diese infrage zu stellen und dann zu ändern.

 

Learning: Es braucht stetige Kommunikation zwischen Keimzelle und Organisation!
Wir fragen aktiv nach, was die Bereiche und Hierarchieebenen des ITZBund und seiner Kunden brauchen und stellen uns deren Fragen. Wir tragen viel von unserem Wissen und den Erfahrungen ins Haus, holen uns aber Feedback und Rückmeldungen darüber, wo die Vorhaben stehen und wie sie aktuell unterstützt werden könnten. Fragen zeigen, dass bei den Beschäftigten etwas in Bewegung ist. Sie beginnen, sich mit den Änderungen zu beschäftigen und transferieren die Veränderung auf ihre Verantwortungsund Tätigkeitsbereiche. Das ist gut.

 

Die Rolle von Rück- und Ausblick: Reflexion und Vision

Kontinuierliche Kommunikation sorgt dafür, dass wir Feedback zu unserem Tun bekommen. Aktives Nachfragen und die Reaktionen auf unsere Angebote – all das ist Feedback. Um dieses Feedback in Handeln zu übersetzen, ist Reflexionsfähigkeit vonnöten. Im agilen Arbeiten gibt es viele mögliche Feedbackinstrumente. Wir legen großen Wert auf den Austausch und die gemeinsame Reflexion bei uns im Team: Zweiwöchentliche Retrospektiven decken ungenutzte Potenziale in der Zusammenarbeit auf. Alle sechs Wochen zeigen wir in Reviews allen Interessierten des ITZBund, woran wir gerade arbeiten, und holen uns Feedback ein. Wir führen in jedem Quartal einen zweitägigen Teamworkshop durch, bei dem wir an unseren Themen arbeiten. Neben den Beratungsgesprächen, die wir mit den agilen Projekten führen, geben wir dem ITZBund einmal im Jahr die Möglichkeit, an einer groß angelegten Umfrage zum agilen Arbeiten im ITZBund teilzunehmen. Für das ITZBund wie auch seine Kunden richten wir mit den „Agilen Tagen“ eine eigene Konferenz aus, in der sich die Teilnehmenden über agile Softwareentwicklung und Agilitätsthemen informieren und mit uns in den Austausch treten können. Wir versuchen, so nah wie möglich an den Bedürfnissen der Organisation zu sein, um herauszufinden, ob die Dinge, die wir tun, auch die tatsächlichen Probleme adressieren. Durch diese vielfältigen Kurskorrektur-Werkzeuge können wir mit einiger Sicherheit sagen: Ja, wir fahren in die richtige Richtung!

 

Learning: Es braucht Zeit und Raum für Reflexion und Adaption.
Auch wir haben Linientätigkeiten und andere Aufgaben, die unser Tagesgeschäft bestimmen. Doch auch wenn wir uns gehetzt fühlen, nehmen wir uns die Zeit und den Raum, offen über uns und unsere Zusammenarbeit im Team zu sprechen. Denn nur, wenn unsere Zusammenarbeit und unser Teamgefüge stimmig sind, sind auch unsere Leistungen und Beratungsangebote stimmig.

 

"To be continued ..."

Natürlich läuft bei EAGLE noch nicht alles von allein, und wir sehen schon jetzt am Horizont einige neue „Wellenbrecher“. Insbesondere die nachfolgenden Themen der agilen Transition beschäftigen uns aktuell und zukünftig:

• Das Erarbeiten von wirksamen Steuerungsmöglichkeiten (Controlling) von agilen Entwicklungsprojekten für das Management und damit eine Erhöhung der Akzeptanz von agiler Entwicklung
• Das Verankern bereichsübergreifender Zusammenarbeit über agile Softwareentwicklung hinaus – Stichwort „DevOps“ und „Agiles Arbeiten“
• Die Weiterentwicklung des Verständnisses für Agilität und der agilen Fähigkeiten im ITZBund und bei seinen Kunden („agiles Mindset“)

Wir richten für uns und die Organisation einen Handlungsrahmen ein, der Anpassungen zulässt und sicherstellt, dass die Menschen in Kontakt kommen und miteinander die beste Lösung finden. Dies geschieht, ohne dabei detailliert vorzugeben, wie die Beschäftigten handeln sollen oder die Organisation auszusehen hat. Es kommt jederzeit auf die richtige Balance zwischen Standardisierung und Offenheit an. Und die größte Hilfe dabei ist, wenn Agilität auch wirklich gelebt wird – auf der Teamebene der Transitions- und Entwicklungsteams und auf der Organisationsebene der Referate und Abteilungen.

 

Fazit

Zu Beginn einer agilen Transition braucht es Pioniere, die bereit und frei sind, sich mit ihren Teams mutig der Herausforderung zu stellen, auch wenn vielleicht vieles noch unklar ist. Diese Pioniere melden sich freiwillig, selbst wenn sie wissen, dass sie viele Herausforderungen meistern müssen. Denn ihnen ist bewusst, dass sie wichtige Arbeit leisten, von der andere profitieren. Dem neuen Mindset von Inspect-and-Adapt muss Raum und Zeit gegeben werden, um in den Organisationen anzukommen. Durch stetiges Vorleben und Transparenz können Vorbilder geschaffen werden, die zeigen, dass und wie es geht. Stehen existierende Rahmenbedingungen tatsächlich im Weg, können diese durchaus geändert werden, damit jedem klar wird: Ich darf das. Die Experimentierräume sowie die dazugehörige Lernkultur geben den Teams den notwendigen Mut, den ersten Schritt auf der agilen Reise zu tun: einfach mal machen. Und dieses Mindset ist das, was die (agile) Organisation der Zukunft auszeichnet.

 

Mehr zum Thema Agiles Arbeiten lesen Sie hier

Mehr lesen

 

 

Quelle 

¹https://digitaleneuordnung.de/blog/konsent (abgerufen am 08.12.2021).