Der neue Scrum-Guide 2020 ist da: Was sind die 7 wichtigsten Neuerungen?

Kürzlich ist der neue Scrum Guide von Ken Schwaber und Jeff Sutherland in englischer Version erschienen.

Obwohl der Ursprung von Scrum schon weit bis in die 1990er Jahre zurück reicht, sind die ersten offiziellen Dokumente dazu erst 2010 entstanden.

Ein Ergebnis dieser Zeit war der erste offizielle englischsprachige Scrum Guide der den Rahmen von Scrum, die Spielregeln, Prinzipien, Artefakte und das Zusammenspiel des Scrum-Teams beschreibt.

Von da an wurde er in mehrjährigen Abständen immer wieder weiter entwickelt und in unterschiedlichste Sprachen übersetzt. Zum 30jährigen Jubiläum von Scrum ist die neuste Version des Guides erschienen.

Nachdem ich bereits 2016 bei der Überesetzung beteiligt war, habe ich mir auch die Version 2020 genauer angesehen und ins deutsche übersetzt: Deutsche Übersetzung des Scrum-Guide 2020

Doch was sind die wichtigsten Änderungen und spannendsten Neuerungen?


#1 „Zusammen stehen wir dahinter.“

Das erste das sofort in der Einleitung auffällt ist viel mehr „Spirit“ und der Fokus auf Gemeinsamkeit. Wenn auch in den letzten Jahren von Streit zwischen den beiden Autoren die Rede war, dann wurde dieser womöglich wieder besiedelt?

Kürzere Sätze, stärkere positive Emotionen

In den ersten Versionen des Scrum-Guides gab es sehr viele verschachtelte Sätze und die sehr positiven emotionalen Auswirkungen die die Arbeit mit dem Framework auslöst kam kaum herüber.

Das ist in der neuen Version anders: Die Sätze sind kürzer, emotional aufgeladner und viel klarer. Der neue Guide ist damit auch in englisch wesentlich besser verständlich.

Das Zuckerstück ist meines Erachtens dieser Satz:

Sprints are the heartbeat of Scrum, where ideas are turned into value.

Quelle: https://www.scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf

#2 Scrum nicht nur für Entwickler

Der Scrum-Guide spricht seit dem Anbeginn seiner Zeit von Entwicklern, aber spätestens seit der Digitalisierung und dem Wandel in der Fahreugindustrie ist klar das auch andere Industriebereiche diese Vorgehensweisen gebrauchen können.

„Wir verwenden das Wort „Entwickler“ in Scrum nicht, um auszuschließen, sondern um zu vereinfachen. Wenn dir Scrum einen Wert bringt, dann sieh dich damit unter dem Entwicklerbegriff mit eingeschlossen.“

Innoffizielle deutsche Übersetzung, https://www.patrick-koglin.com/wissen/fachwissen/agile-organisationsformen/der-scrum-guide-die-spielregeln-von-scrum/scrum-guide-2020-deutsche-inoffizielle-uebersetzung/der-scrum-guide-2020-intro/

Hierdurch wird wesentlich mehr Klarheit und eine größerer Anwendungskreis geschaffen.


#3 Klarheit darüber was Scrum ist und was es nicht ist

Der Guide glänzt mit einer messerscharfen Definition über Scurm:

„Scrum ist ein leichtgewichtiges Framework das Menschen, Teams und Organisationen hilft Wert durch schrittweise Lösungen für komplexe Probleme zu schaffen.“

Innoffizielle deutsche Übersetzung, https://www.patrick-koglin.com/wissen/fachwissen/agile-organisationsformen/der-scrum-guide-die-spielregeln-von-scrum/scrum-guide-2020-deutsche-inoffizielle-uebersetzung/der-scrum-guide-2020-scrum-definition/

…und beschreibt auch was Scrum nicht ist:

Das Scrum-Framework ist absichtlich unvollständig und definiert nur die Teile, die zur Implementierung der Scrum-Theorie erforderlich sind. Scrum baut auf der kollektiven Intelligenz der Menschen auf, die es verwenden.

Anstatt den Menschen detaillierte Anweisungen zu geben, leiten die Scrum-Regeln ihre Beziehungen und Interaktionen.

Inoffizielle deutsche Übersetzung, https://www.patrick-koglin.com/wissen/fachwissen/agile-organisationsformen/der-scrum-guide-die-spielregeln-von-scrum/scrum-guide-2020-deutsche-inoffizielle-uebersetzung/der-scrum-guide-2020-scrum-definition/

#4 Scrum Theorie und Werte sind beständig geblieben

Nach wie vor basiert Scrum auf einer empirischen Vorgehensweise aus Transparenz, Beobachtung und Anpassung. Aber das „schlanke Denken“ ist in der Erwähnung hinzugekommen:

Scrum basiert auf Empirie und schlankem Denken. Empirie behauptet, dass Wissen aus Erfahrung und Entscheidungsfindung auf Basis dessen stattfindet was beobachtet wird. Lean Thinking reduziert Verschwendung und konzentriert sich auf das Wesentliche.

Inoffizielle deutsche Übersetzung, https://www.patrick-koglin.com/wissen/fachwissen/agile-organisationsformen/der-scrum-guide-die-spielregeln-von-scrum/scrum-guide-2020-deutsche-inoffizielle-uebersetzung/der-scrum-guide-2020-scrum-theorie/

#5 Keine Hierarchien innerhalb eines Teams, dafür „echte Führungskräfte“

Im Kapitel über das Scrum-Team wird nun näher auf Führungsrollen und Hierarchien eingegangen:

Innerhalb eines Scrum-Teams gibt es keine Subteams oder Hierarchien. Es ist eine zusammenhängende Einheit von Fachleuten, die sich jeweils auf ein Ziel konzentriert, das Produktziel.

Inoffizielle deutsche Übersetzung,https://www.patrick-koglin.com/wissen/fachwissen/agile-organisationsformen/der-scrum-guide-die-spielregeln-von-scrum/scrum-guide-2020-deutsche-inoffizielle-uebersetzung/scrum-team/

Wenn auch keine Hierarchie im Team gewünscht ist, spricht der Guide von „echten Führungskräfte“ im Hinblick auf den Scrum Master:

Scrum Masters sind echte Führungskräfte, die dem Scrum-Team und der größeren Organisation dienen.

Inoffizielle deutsche Übersetzung, https://www.patrick-koglin.com/wissen/fachwissen/agile-organisationsformen/der-scrum-guide-die-spielregeln-von-scrum/scrum-guide-2020-deutsche-inoffizielle-uebersetzung/scrum-team/

Das Kapitel über das Scrum Team nimmt neben den Scrum Events den meisten Raum des Guides ein und liefert umfassende Beschreibungen über die einzelnen Verantwortlichkeiten.

Besonders die dienende Rolle des Scrum Masters für die Organisation, dem Product Owner und dem Scrum Team wird umfassend erläutert.

Was hat sich geändert? Es ist nicht mehr die Rede von einzelnen Rollen. Das wird ein stückweit offen gelassen ob eine Person eine oder mehrere Rolle tragen kann. Beschrieben wird lediglich das ein Team aus einem Scrum Master, Product Owner und Entwicklern besteht.


#6 Hinweise auf verpasste Chancen

Aus der Begleitung von agiler Teams, weiß ich wie groß der Drang danach ist am Scrum Framework zu entwickeln statt am eigentlichen Produkt. Es ist ein Thema von Fokus und so sind in ganz vielen Teams sicherlich eine Menge individueller Scrum, Scrum-Kanban, Scrum-Spotifiy und was auch immer für Lösungen entstanden.

Der Scrum Guide weist jetzt ausdrücklich und mehrfach darauf hin, das durch solche Veränderungen am Rahmen mit entsprechenden Verlusten zu rechnen ist:

Das Versäumnis, Ereignisse wie vorgeschrieben zu betreiben, führt zu verpassten Beobachtungs- und Anpassungsmöglichkeiten.

Inoffizielle deutsche Übersetzung, https://www.patrick-koglin.com/wissen/fachwissen/agile-organisationsformen/der-scrum-guide-die-spielregeln-von-scrum/scrum-guide-2020-deutsche-inoffizielle-uebersetzung/scrum-events/

Und aus der Einleitung:

Das Kern-Design oder die Ideen von Scrum zu verändern, Elemente auszulassen oder nicht den Regeln von Scrum zu folgen verursacht Probleme und es limitiert die Vorteile von Scrum, möglicherweise wird es dann sogar nutzlos.

Inoffizielle deutsche Übersetzung, https://www.patrick-koglin.com/wissen/fachwissen/agile-organisationsformen/der-scrum-guide-die-spielregeln-von-scrum/scrum-guide-2020-deutsche-inoffizielle-uebersetzung/der-scrum-guide-2020-intro/

Möglicherweise erspart das einigen Scrum Mastern, Agile Coaches und Beratern die ein oder andere Diskussion darüber ob das Daily Meeting nun wirklich jeden Tag stattfinden muss oder ob man den Sprint-Zeitraum nicht doch möglicherweise verlängern oder offenlassen kann.


#7 „Jeder Sprint kann als kurzes Projekt betrachtet werden.“

In Diskussionen die ich mitbekommen habe war nicht ganz klar ob Scrum wirklich für Projekte geeignet ist.

Der Satz: „Jeder Sprint kann als kurzes Projekt betrachtet werden.“ verdeutlich es dabei ganz klar. Scrum kann als Container und Framework gesehen werden. Was schließlich an Aufgaben, Projekten oder Herausforderung dort durchgeschleust wird, ist im Grunde egal. Das können tägliche Routineaufgaben, Projekte oder Entwicklungsaufgaben sein.

Jegliche Planung und Umsetzung kann mit Scrum verbessert werden: besonders eben technologische Projekte im komplexen Umfeld. Das macht Scrum so wertvoll und nützlich.

Scrum kann den Projekterfolg und die Wirtschaftlichkeit von Projekten massiv steigern. Gleichzeitig sinken Risiken weil sie entweder früher transparent werden und darauf reagiert werden kann oder gar nicht eintreten. Die Qualität bleibt in der Regel gleich oder wird zunehmend besser.


Fazit und Zusammenfassung

Abschließend kann man sagen, das dieser Scrum Guide wieder durchaus gelungen ist. Da steckt viel Passion, Leidenschaft und Intelligenz drin. Das Scrum Team mit seinen Events steht dabei im Vordergrund. Formalismen und starre Regeln treten in den Hintergrund.

Daher ist es viel eher eine Anleitung für ein Komplexitäts-Management-Framework als eine Anleitung für Zusammenarbeit. Gelungen.

Danke Jeff Sutherland, Ken Schwaber und alle die mitgewirkt haben. Thank you.

Ich hoffe Sie konnten damit einen Einblick in die Neuerungen gewinnen?

Wenn Sie wollen, folgen Sie mir auf Social Media und nutzen Sie dort die Gelegenheit meine Beiträge zu kommentieren und zu teilen.


Patrick Koglin

Fortschrittskontrolle ist nicht gleich Leistungskontrolle

Wie gutes Controlling die erfolgreiche Umsetzung von digitalen Projekten ermöglicht verhindert

Dass das agile Mindset seit einigen Jahren von betriebswirtschaftlichen Leistungs- und Prüfmethoden durchfräst wird wie ein schweizer Käse lässt sich offenbar nicht mehr verleugnen.

Aber ich kann da allmählich nicht mehr wegsehen – so schlimm ist es. Das tut schon weh.

Ausserdem werde ich bei dem Thema wirklich sehr leidenschaftlich! Da hängt zu viel Herzblut in der Sache. Mein ITler- und Scrum-Berater-Herz schlägt da sozusagen: Längst werden Scrum-Methoden, Transparenz, Gruppendruck und agile Ansätze dazu genutzt um Mitarbeiter vermehrt zu mehr Leistung unter Druck zu setzen.

Im Industriezeitalter mag das alles gut funktioniert haben. Da konnte man vielleicht durch das Quentchen Druck die kurzfristige Motivation steigern. Aber heute? Wir leben in einem Informations- und Wissenszeitalter.

Was bedeutet das? Kaum ein Projekt wird alleine abgewickelt. Zusammenarbeit ist an der Tagesordnung. Die Komplexität ist sehr hoch. Niemand kommt mehr alleine voran. Das scheint einigen noch nicht ganz bewusst. Hier gelten neue Gesetzmäßigkeiten.

Leider verlieren Unternehmen jeglicher Größenordnung hier oftmals wertvolle Ressourcen wenn sie diese Hintergründe missachten. Die Folge sind oftmals innere Kündigung, Ellbogenmentaltität, egozentrisches Denken, verfehlte Gesamtleistung bis hin zu gesundheitlichen Ausfällen oder Unternehmenswechseln. Sie verlieren wertvolle Mitarbeiter die nicht so einfach ersetzt werden können. Außerdem sind damit oftmals Kosten und Zeitverluste verbunden. Vermeidbare Zusatzkosten.

Beispiele dafür wie alte Management-Methoden mit modernen Scrum-Ansätzen kombiniert werden sind Artikel wie diese: Wie gutes Controlling die erfolgreiche Umsetzung von Softwareprojekten ermöglicht

Keine Sorge. Ich kenne den Autor nicht und um ihn geht es auch gar nicht in diesem Artikel. Er ist sicherlich ein erfolgreicher CEO.

Viel mehr möchte ich daran aufzeigen das dies ein schönes Beispiel dafür ist, wie das agile Mindset mehr und mehr durch den Mixer gequirlt wird. Dabei entsteht alles andere als ein wohlgeformtes Teamsystem.

Ganz im Gegenteil. Das Resultat sind oftmals faule Kompromisse die der Entfaltung von Selbstorganisation, Selbstmotivation und Teamperformance oftmals im Wege stehen.

Warum ist das so?

„Wir wollten Fortschritt messen, statt Leistung“

Da ist ein feiner und kleiner Unterschied zwischen der Messung von Leistung nach alten Management-Leitlinien und der Fortschrittskontrolle nach Scrum:

Fortschrittskontrolle nach ScrumLeistungskontrolle nach Management-Methoden
* Misst die Teamleistung in Relation auf selbst gesteckte Ziele, Schätzungen und agile Planung
* Stärkt den Teamgedanken
* Macht geleisteten Fortschritt sichtbar wo manchmal nicht unbedingt ein sichtbares Ergebnis vorliegt (z. B. Behebung eines Software-Fehlers oder Nutzung einer neuen Online-Software)
* Oftmals losgelöst von Bonus- und Anreizsystemem
* Dient zur Überprüfung ob die Planung realistisch war
* Dient dazu die Planung kontinuierlich zu verbessern
* Dient zur Erkennung von Abweichungen, aufkommenden Sonderwünschen, technischen Problemen oder organisatorischen Schulden
* Dient zur frühzeitigen Anpassung der Planung
* Steigert die persönliche Motivation
* Erhöht die Kommunikation über Wertschöpfung
* Steigert den Stolz auf die eigene Arbeit
* Dient oft der persönlichen Leistungsmessung
* Sollte den Ertrag steigern und die beste Herstellungsmethode finden (ist längst überholt)
* Oftmals gekoppelt an persönliche Ziele, was zu mehr Egoismus im Team führt
* Dient oft zum Vergleichen von Leistung in Teams um künstliche Konkurrenz zu schaffen (die es eigentlich gar nicht gibt)
* Verlangt typischerweise nach Status und Reports zur frühzeitigen Eskalation
* Führt oftmals zu Mikro-Controlling durch Führungskräfte – was die Selbstorganisation, Selbstverwirklichung und Teamarbeit oftmals stört
* Senkt häufig das Vertrauen, den Mut einzelner und das Engagement der eigentlichen Leistungsträger
* Ist rechtlich und arbeitsrechtlich oftmals grenzwertig
* Senkt meistens die Motivation

Wir können nicht von außen kontrollieren und Selbstorganisation erwarten…

Das ist ein bisschen wie das Experiment mit Schrödingers Katze. Kennen Sie das? Ein echter Klassiker den ich hier auffahre. Das sollten Sie mal lesen, falls sie das noch nicht kennen. Auch die Kopenhagener Deutung dazu.

Ich behaupte also jetzt einfach mal: Sie wissen also von außen nicht ob sich ein Team (gut) selbstorganisiert oder nicht. Und dazu stelle ich die These auf, das die Selbstorganisation immer dann kollabiert, wenn man von außen beginnt die Leistung zu kontrollieren. Vor allem wenn es um die Einzelleistung – also die Performance einer einzelnen Person geht. Dann erst Recht. Dann kippt das System. Immer!

Der Kniff ist eigentlich der: Schauen Sie nicht im Detail hin – in die Kiste oder in das Team – und vertrauen einfach darauf das geliefert wird, dann bleibt die Katze sicher am Leben wird sicher nach besten Möglichkeiten geliefert.

Einzelleistung muss zudem nicht gemessen werden

Die meisten Menschen die eine schlechte Performance haben, wissen übrigens üblicherweise das ihre Leistung (momentan) schlecht ist. Man muss es ihnen nicht fortwährend sagen oder sie wie kleine Kinder kontrollieren. Viel cleverer hingegen ist zu schauen was benötigt wird, damit Einzelleistung und Motivation wieder steigt. Da sind wir dann bei Servant Leadership (dienende Führung).

Das können Prozesse, Rahmenbedingungen oder auch rein menschliche Aspekte sein.

Nur sehen Sie den Unterschied? Das eine steigert Motivation, Selbstorganisation und Selbstverantwortung, das andere reduziert und vernichtet sie.

Software- und digitale Projekte müssen also nicht detailliert kontrolliert, sondern viel mehr dienlich unterstützt werden.

Wieder ein Unterschied, der einen Unterschied macht: Dienende Unterstützung führt zu Wachstum und Entwicklung, Kontrolle zu Duckhaltung, Demotivation und Rechtfertigung.

Ich bin gespannt auf die Diskussionen auf Twitter und Social Media dazu!

Viel Spaß und eine gute Entscheidung bei der Frage: unterstützen oder kontrollieren?

Patrick Koglin, Experte für Selbstorganisation, agile Teamarbeit und Scrum-Mindset

Die Reise zu selbstorganisierten Teams

Selbstorganisierte Teams sind ein Zauber der neuen Arbeitswelt. Der Ansatz zu agilen selbstorganisierten Teams hat sich in den letzten 30-40 Jahren ständig weiterentwickelt und seinen Ursprung einst als man sich damit näher auseinandergesetzt hat warum eigentlich so viele Software- und IT-Projekte scheitern. Dieses Problem konnten und wollten selbstorganisierte Teams lösen.

„Selbstorganisation“ ist eine Kraft die man mit passenden Rahmenbedingungen und solider Führung erwecken, ermöglichen, befähigen und rauskitzeln muss.

Magic Teams: Sicherer Rahmen für zielgerichtete Projekt-Teams

Als Experte für agile Transformation, möchte ich in diesem Artikel mehr Informationen über die typische Reise zu selbstorganisierten Teams rausgeben. Ich habe diesen Veränderungsprozess 2016 das erste Mal mit einem mittelständischem Software-Unternehmen (150 Mitarbeiter, 6.000 Kunden) durchgeführt und seit dem mehr als 250 Personen thematisch geschult. Seit mehr als zehn Jahren beschäftige ich mich mit dem Leitgedanken agiler Führung und selbstorganisierter Teamarbeit.

2018 habe ich dazu mein Buch „Magic Teams Sicherer Rahmen für zielgerichtete Projektteams“ mit weiteren Details, Tools, Anregungen und Prinzipien veröffentlicht.

Dieser Artikel gibt ergänzend dazu eine grobe Richtung, ersetzt aber bitte keine Umsetzung vor Ort. Dafür ist das Thema zu individuell. Es kann nur eine Anregung sein. Man darf nicht glauben, das man einen derart komplexen und schwierigen Changeprozess auf Basis eines Blogartikels durchführen kann.

In diesem Artikel erfahren Sie Details über die Transformation zu selbstorganisierten Teams. Sie lernen die fünf Phasen der agilen Transformation kennen und können daraus schon einen ersten Überblick gewinnen wie man inhaltlich vorgehen kann.

Der Artikel setzt voraus dass Sie sich zumindest grundlegend mit der Thematik und den Begriffichkleiten auskennen.

Wie funktioniert „agile Transformation“?

Die Transformation zu selbstorganisierten agilen Teams verläuft in der Regel ähnlich wie Veränderungsprozesse im persönlichen Bereich und kann den typischen 5 Phasen der Veränderung folgen:

  1. Bewusstsein
  2. Verständnis
  3. Loslassen
  4. Neuorientierung
  5. Tun

Diese Schritte kann man als „hidden Agenda“ hinter einem Changeprozess sehen. Der Prozess selbst kann typischerweise in folgende Phasen unterteilt werden:

Phase 1: Analyse vor Ort

In aller Regel findet eine Bestandsaufnahme durch einen externen Berater, Agile Coach oder Consultant statt der sich zunächst einen Überblick zum Status Quo verschafft.

Hier können Team-Befragungen, Einzel-Interviews, Checklisten oder Beobachtungen mit zielgerichteten Fragen vor Ort zum Tragen kommen.

Phase 2: Konzeption des Change

In der zweiten Phasen geht es dann darum zu schauen was benötigt wird um das agile Mindset ins Team zu integrieren. Das ist im Grune die Change-Konzeption die meist vor der Umsetzung mit Auftraggbern, Geschäftsführung und Führungskräften besprochen wird.

Ihaltlich geht es in dem Change-Konzept beispielsweise um folgende Fragen:

  • Welche Strategien sind erforderlich?
  • Welche Konzepte müssen erläutert werden?
  • Welche Strukturen müssen etabliert werden?
  • Welche Rollen und Verantwortlichkeiten müssen definiert werden?
  • Welche Motivationsfaktoren gibt es für einzelne?
  • Welchen Zusatznutzen kann es noch geben?
  • Wie genau kann die Selbstorganisation gefördert werden?
  • Was braucht es für die erfolgreiche Umsetzung?
  • Welche Randbedingungen gibt es?

Phase 3: Vermittlung des Konzepts und der Inhalte

In der dritten Phase wird schließlich das Konzept umgesetzt, das agile Mindset vermittelt und die notwendigen Grundpfeiler gesetzt.

Die Vermittlung kann durch „Training on the job“ und Live-Trainings stattfinden.

Dabei ist es ratsam ein Team mindestens einen Arbeitstag, besser zwei in den Grundlagen gemeinsam und unter Berücksichtigung der individuellen Ziele im Unternehmen zu schulen.

Phase 4a: Adapter und Brücken bauen

In aller Regel haben Teams individuelle Pflichten gegenüber Kunden, anderen Teams, Gesetzgebung oder anderen Kollegen im Haus. In der vierten Phase wird daher geschaut welche technischen, regulatorischen oder organisatorischen Aspekte berücksichtigt werden müssen um diese Pflichten zu erfüllen.

Dieser Teil kann in der Regel kann je nach Unternehmen entsprechend umfangreich sein.

Phase 4b: Moderation und Klärung von Konflikten (optional)

Im Rahmen des Changeprozesses kann es immer wieder zu Mißverständnissen oder Konflikten kommen. Die müssen lösungsorientiert und bestmöglichst ohne faule Kompromisse geklärt werden.

Es empfiehlt sich das Dritte durchführen zu lassen die sich mit entsprechende Produktions-, Digitalisierung- oder Webentwicklungstechnologien auch auskennen. Optimalerweise tut das derjenige der die agile Transformation konzeptioniert und begleitet hat – entsprechende Moderationserfahrung vorausgesetzt.

Phase 5: Feinschliff und Abrundung

Die vorherigen Phasen dauern je nach Team 4-12 Wochen. Wenn diese Arbeiten erfolgreich abgeschlossen sind, der Prozess gut läuft und alle Meetings und Rollen entsprechend etabliert sind, kann man nochmal schauen an welchen Punkten möglicherweise nachgebessert werden muss.

Dazu dienen neben informellen Kommunikationskanälen üblicherweise fest etablierte Retrospektiven.

Zusammenfassung

Der Weg zu selbstorganisierten Teams erfordert auf den ersten Blick nicht mehr als den oben dargestellten Bewusstseinsprozess und die (erfolgreiche) Umsetzung dieser fünf Phasen:

  1. Analyse vor Ort
  2. Konzeption des Change
  3. Vermittlung des Konzepts und der Inhalte
  4. Moderation und Klärung von Konflikten (optional)
  5. Feinschliff und Abrundung

Das ist zumindest der theoretische Teil.

Die praktische Umsetzung stellt die meisten Beteiligten oftmals vor große Herausforderungen. Daher ist es empfehlenswert auf einen ausgebildeten Changebegleiter, Coach oder Experten für agile Transformation zurückzugreifen der dies professionell und gelassen angehen kann.

Es sollte jemand sein der entsprechende Expertise für die vorliegenden Prozesse, das agile Mindset und vor allem für die Menschen mitbringt. Nehmen Sie bei weiteren Fragen oder Bedarf gerne Kontakt mit mir auf.

Vielen Dank für das Lesen dieses Artikels

Wenn Ihnen dieser Artikel etwas gebracht hat, dann freue ich mich auf entsprechende Reaktionen auf Social Media, Verlinkung und/oder namentliche Zitierung.

Patrick Koglin, Experte für Veränderungsprozesse, agiles Mindset und Digitalisierung