Krisenkommunikation

Bild: Flickr / Katjung - CC BY-SA 2.0

Zu den interessanteren Medienbeiträgen der letzten Zeit gehört ein Interview mit dem Psychologen Reiner Kemmler zum Thema Krisenkommunikation auf Flughäfen. Auf den ersten Blick erscheint das Thema sehr spezifisch, auf den zweiten Blick finden sich aber viele Parallelen zur Agilität: eine bereits komplexe Ausgangssituation, unerwartete Geschehnisse mit zum Teil grossen Auswirkungen, autonom und unkoordiniert vorgehende Akteure, etc. Vieles lässt sich auf andere grosse Unternehmenen und Behörden übertragen.

Der Ausgangspunkt: die Krise

Wo Komplexität zu finden ist, da gibt es auch Krisen, das ist fast schon ein Naturgesetz. Ausfallende Flüge und gestandete Passagiere sind da nur ein Beispiel, andere wären insolvent gehende Geschäftspartner, disruptive Umwälzungem am Markt oder in der Technik, offensichtlich werdende Fehlplanungen, sich ändernde gesetzliche Rahmenbedingungen, Wirtschaftskrisen und vieles mehr. Sie alle stellen die betroffenen Organisationen vor grosse Herausforderungen, von denen es hier um eine gehen soll: wie kann die Krise so kommuniziert werden, dass Märkte, Mitarbeiter und Kunden beruhigt werden statt durch Panikreaktionen alles zu verschlimmern?

Verstärkung der Krise durch fehlendes Reaktionsvermögen

Es ist ein unschöner Klassiker: über Jahre werden Abäufe so auf Effizienz getrimmt, dass jeder Mitarbeiter zu fast hundert Prozent ausgelastet ist und fast jeder Prozess auf dem kritischen Pfad verläuft. Dass eine hundertprozentige Auslastung schlecht ist zeigt sich im Krisenfall - die für eine schnelle Reaktion notwendigen Kapazitäten und Freiräume wurden wegrationalisiert, jeder Zusatzaufwand führt zu Überlastung, Rückstauungen und Stillstand. Und wenn sich die Arbeit erst aufgestaut hat kann sie nur durch Überstunden wieder abgebaut werden, mit den bekannten Folgen: Übermüdung, Frustration, dadurch überhastete und fehlerhafte Kommunikation, die dann noch mehr Aufwände verursacht.

Herrschaftswissen und Flurfunk

Irgendwann ist es offensichtlich - sensible Informationen können während und nach ihrer Bekanntgabe nicht mehr ausreichend genug kommunikativ begleitet werden um Unruhe und Fehldeutungen zu vermeiden. Häufig führt das zu der Entscheidung, dass so lange mit der Bekanntgabe gewartet wird bis man glaubt die Lösung gefunden und umgesetzt zu haben. Allerdings ist das in der Regel nicht möglich, irgendwo sickern immer Teilinformationen durch, verbreiten sich, werden schlimmstenfalls aufgebauscht und sorgen für Misstrauen gegenüber offiziellen Verlautbarungen. Selbst wenn jetzt offen kommuniziert werden würde, gäbe es den Verdacht, dass Informationen zurückgehalten werden.

Endstadium: aus der Krise wird Chaos

Letztendlich treten genau die Gruppendynamiken und Absetzbewegungen auf die man vermeiden wollte. Verunsichert von der schwerfälligen und intransparenten Kommunikationspolitik versuchen Kunden, Partner und Mitarbeiter sich vorsorglich in Sicherheit zu bringen. Aufträge werden storniert, Projekte nicht verlängert, statt für das gemeinsame Ziel wird nur noch für die eigene Absicherung gearbeitet, ganze Abteilungen beschliessen "zu überwintern" bis sich die Situation beruhigt hat. Beruhigende Verlautbarungen werden grundsätzlich nicht mehr geglaubt sondern als Vertuschungsversuche interpretiert. Schlimmstenfalls setzt sich die Situation im kollektiven Gedächtnis der Organisation fest und belastet die Zukunft.

Aber wenn nicht so - wie dann?

Im Grunde durch die Umkehrung der oben genannten Antipattern. Statt die gesamt Organisation bis ins letzte Eck durchzuoptimieren müssen freie Kapazitäten vorhanden sein die auch kurzfristig Kommunikationsaufgaben übernehmen können sobald es nötig ist. Ein passender Vergleich wäre ein Feuerwehrmann, bei dem die Brandbekämpfung auch nur einen kleinen Teil der Arbeit einnimmt. Des weiteren empfiehlt sich grösstmögliche Offenheit von Anfang an. Klar und offen zu zu kommunizieren, dass es eine Krise gibt mag zwar zu Beginn schmerzhaft sein, das dauerhafte Misstrauen das sich aus dem Zurückhalten von Informationen ergibt ist aber langfristig um ein Vielfaches verheerender. Und wenn klar ist, dass Reaktionen möglich sind und bereits stattfinden verliert die Ungewissheit viel von ihrem Schrecken. Es ist ein Allgemeinplatz aller agilen Vorgehensmodelle - wenn man in der Lage ist kurzfristig auf Veränderungen zu reagieren ist es unkritisch wenn sich die Realität anders entwickelt als geplant.

Natürlich muss dafür auch die Gesamtorganisation zu Reaktionen in der Lage sein und nicht nur die Kommunikationsabteilung. Das ist aber dann ein Thema für sich.

Planning Poker

Bild: Wikimedia Commons / Rachmaninoff - CC BY-SA 4.0

Wer bereits Zeit in einem Scrum-Projekt verbracht hat wird das Bild kennen. Irgendwo stellt ein Product Owner eine Idee vor und bittet sein Entwicklungsteam um eine Aufwandsschätzung. Kurz darauf halten die Teammitglieder Karten oder Mobile Apps mit Zahlen darauf hoch und nehmen so die Schätzung vor. Da immer wieder nach dieser zunächst merkwürdig aussehenden Methode gefragt wird kommt hier eine Erläuterung dazu, zum so genannten Planning Poker.

Zunächst einige Kontextinformationen: mit Planning Poker werden normalerweise Story Points geschätzt. Story Points sind personenunabhängige Aufwandseinheiten und nicht mit Stunden und Tagen gleichzusetzen, mehr zu ihnen steht hier und hier. Und Planning Poker ist kein offizieller Teil von Scrum, man könnte es also auch weglassen. Es wird allerdings trotzdem von fast jedem Scrum Team genutzt, da es sich sich als good Practice durchgesetzt hat (mehr dazu hier).

Zur Anwendung: normalerweise werden alle Teammitglieder aufgefordert ihre Schätzung (Karte) in Ruhe auszuwählen, sie noch nicht zu nennen und zu warten bis auch die anderen damit fertig sind. Dann werden die Karten gemeinsam aufgedeckt. Dadurch wird vermieden, dass ein Meinungsführer die anderen bewusst oder unbewusst beeinflusst, die Schätzung ist dadurch repräsentativer.

Da die von den Teammitgliedern geschätzten Werte normalerweise nicht identisch sind kann im nächsten Schritt versucht werden ein einheitliches Verständnis zu erzielen. Immer wieder anzutreffen sind an dieser Stelle Mehrheitsentscheidungen oder Durchschnittswerte, wodurch aber Potential verschenkt wird. Besser ist es, wenn die oberen und unteren Grenzwerte erläutert werden, die Teammitglieder kommen dadurch oft zu Einsichten die sie selbst nicht gehabt hätten.

Neben diesen beiden sehr häufigen Vorgehensweisen gibt es auch weitere, die immer wieder anzutreffen sind. Manche Teams führen für die selbe Anforderung mehrere Schätzrunden nacheinander durch, bis alle die selbe Zahl hochhalten, andere nehmen alle Schätzungen ab einer bestimmten Punktezahl zum Anlass die jeweiligen Anforderungen kleinzuschneiden, wieder andere haben Joker-Karten, mit denen sie einen Experten konsultieren können, etc., etc.

Was all diesen Techniken geimeinsam ist: neben dem Ermitteln des (abstrahierten) Aufwandes steht beim Planning Poker auch ein zweites Ziel im Mittelpunkt - das bessere Verstehen der Anforderung. Die verschiedenen Anwendungsfälle der Karten können dafür sorgen, dass die Ideen des Product Owners gründlicher diskutiert und hinterfragt werden als es normalerweise der Fall wäre. Alleine das ist schon ein Mehrwert.

Agile Roadmaps

Zu den klassischen Planungsinstrumenten gehören die so genannten Roadmaps. bei ihnen handelt es sich (vereinfacht gesagt) um einen Zeitstrahl auf dem verschiedene Fertigungsschritte und -phasen nacheinander und parallel zueinander angeordnet sind. Dieses Instrument hat unverkennbare Stärken: man kann planen was wann gemacht werden soll (ggf. auf dem kritischen Pfad), kann sequentielle Abhängigkeiten darstellen und den Fortschritt überprüfen. Wie viele anderen Planungswerkzeuge ist es aber auch denkbar unflexibel.

Roadmaps gehen immer von einer einzigen Ablauf-Reihenfolge aus, der die man für die ideale hält. Dass es mehrere Varianten geben kann von denen jede ihre Vor- und Nachteile hat geht dabei unter. Auch ist es in der Regel schwierig nachträgliche Änderungen vorzunehmen, und zwar nicht nur da diese den vorgegebenen Zeitplan durcheinanderbringen würden - alleine die Rechtfertigungen und Schuldzuweisungen dafür, dass der ursprüngliche Plan eben doch nicht ideal war, rauben Zeit und Energie.

Eine flexiblere Variante könnte sich an den Streckenempfehlungen der gängigen Karten- und Navigationsdienste orientieren. Gibt man in ihnen Start- und Zielpunkt ein erhält man verschiedene Optionen zwischen denen man wählen kann. Im Fall des oben gezeigten Screenshots bietet etwa die südliche Route in der Mitte noch eine Alternativstrecke, die nördliche aber nicht. Und während die nördliche und die mittlere Route mehrere grosse stausgefährdete Stellen haben hat die südliche nur wenige, führt dafür aber an mehreren Baustellen vorbei. Die Parallelen zu einer Projekt- oder Produktplanung sind offensichtlich.

Durch die frühen oder späten Abzweigungen lassen sich frühe oder späte Architekturentscheidungen symbolisieren, Systeme oder Teams mit begrenzter Bearbeitungskapazität stellen staugefährdete Stellen dar und Systeme an denen auch andere Teams und Projekte arbeiten sind Baustellen. Und sind derartige Faktoren transparent lassen sich auch andere Informationen zu ihnen in Bezug setzen. Nocheinmal zum Screenshot oben: die Südstrecke hat zwar eine etwas kürzere voraussichtliche Fahrtzeit (Projektdauer), durch die Baustellen aber auch ein ungleich höheres Risiko, dass etwas Ungeplantes passiert. Ist der Zeitgewinn dieses Risiko wert? Eine interessante Frage.

Man sieht: die flexiblere Roadmap bietet nicht nur alternative Wege, die ggf. auch eine spätere Umplanung ermöglichen, sie bietet zu den Varianten auch Kontextinformationen, die eine wesentlich differenziertere Abwägung ermöglichen als die klassische, lineare Roadmap. Und die Visualisierung in einer Form die fast jedem Menschen aus seinem Alltag bekannt ist bietet dazu noch einen wesentlich höheren Erkennungs- und Erinnerungswert. Auch das sollte nicht unterschätzt werden.

Dass diese Form der Planung nicht häufiger verwandt wird hat übrigens einen zentralen Grund: sie lässt sich kaum in Powerpoints und Planungstools darstellen sondern praktisch nur auf einer physischen Wand. Und Planung die nicht auf Powerpoints passt ist in vielen Organisationen keine richtige Planung. Das wäre aber ein Thema für sich.

Killing the Monster Merge

Eine enthusiastisch vorgetragene Einführung in das Thema Continuous Integration, und dazu noch eine die mit relativ wenig technischem Verständnis nachvollziehbar ist. Zwar mit einem kleinen Werbeblock ganz am Ende, aber den muss man sich ja nicht ansehen.

Lernen, wie man nein sagt

Grafik: Pixabay / Geralt - CC0 1.0

Zu den wichtigsten Dingen die man lernen muss wenn man beginnt agil zu arbeiten gehört das "Nein"-sagen. Nur wenn man nicht mehr Arbeit beginnt als man beenden kann wird sie in vertretbarer Zeit fertig, nur wenn man nicht jeden Feature-Wunsch umsetzt vermeidet man kaum noch erweiterbare Bloatware, etc., etc. Das große Problem: viele Menschen haben das nie gelernt, zumindest im beruflichen Kontext nicht.

"Ein Nein akzeptiere ich nicht als Antwort" ist eine beliebte Management-Floskel, die man vom Kleinunternehmen bis zum Grosskonzern immer wieder findet. Die Mitarbeiter solcher Firmen lernen irgendwann, dass das Nein-sagen nur zu Eskalation, Druck und Stress führt und lassen es einfach. Stattdessen wird unkritisch fast alles abgenickt und zugesagt, selbst wenn diese Zusagen völlig unrealistisch sind. Erst kurz vor Schluss gibt es dann die Rückmeldung "Ging doch nicht".

Selbst wenn in diesen Kontexten ein Kulturwandel stattfindet in dem die Ablehnung unrealistischer und nicht zielführender Anforderungen möglich und erwünscht ist, tun viele Mitarbeiter sich schwer die jahrelange berufliche Sozialisation zu überwinden und sagen doch immer wieder Dinge zu, die bei realistischer Betrachtung eigentlich abgelehnt werden müssten. Wenn man es nicht gewohnt ist kann das Nein-sagen etwas sein was man wieder lernen muss.

Eine Methode die ich vor kurzem bei einem der von mir gecoachten Teams kennengelernt habe hat mir aufgrund ihrer Einfachheit gefallen: gegen Ende einer Retrospektive verteilte der Scrum Master fünf "Nein-Karten" an jedes Teammitglied. Die damit verbundene Übung - während des Sprints in fünf relevanten Situationen Nein sagen, die Situation auf der Karte notieren und in der nächsten Retrospektive vorstellen.

Als Effekt kommt es nicht nur dazu, dass mehr nicht zielführende Anfragen abgelehnt werden, die Teammitglieder bekommen auch Übung darin es zu tun. Und dadurch, dass die jeweiligen Situationen in der Retrospektive besprochen werden können, kommt auch eine Kommunikation darüber in Gang, wie man Ablehnungen ausspricht, welche Reaktionen darauf entstehen können und wie man mit denen konstruktiv umgeht. Auch das gehört nämlich zum Nein-sagen dazu.

Kommentierte Links (XXXIX)

• SZ: Einschaltquoten waren gestern

  Einer der ursprünglichen Gründe für die Entwicklung agiler Frameworks sind die sich ständig ändernden Wünsche und Bedürfnisse der Kunden, bzw. der Nutzer. Nur um diesen zeitnah gerecht werden zu können wurden Sprints, Daily Standups, User Stories, etc. überhaupt erfunden. Das weitergedacht ist der folgerichtige nächste Schritt ein Service der sich ohne Entwicklungsaufwand selbst an die Kundenbedürfnisse anpassen kann, und das nicht einmal sondern immer wieder. Die in diesem Artikel beschriebenen personalisierten Streaming-Angebote sind ein solches Angebot und dürften damit das sein, was man als "agiles Produkt" bezeichnen könnte.
  

• Steve Denning: How Agile Helped Elect Donald Trump

In der (in weiten Teilen humanistisch-esoterisch angehauchten) Agile-Community ist die Vorstellung weit verbreitet, dass agile Vorgehensweisen immer einen Bezug zur Menschenfreundlichkeit haben, da sie sowohl Nutzern als auch Mitarbeitern das Leben angenehmer machen. Steve Denning weist zurecht darauf hin, dass es sich bei ihnen lediglich um ein Werkzeug handelt, mit dem ungeachtet seiner Geisteshaltung jeder arbeiten kann. Die von ihm angeführte "agile Kampagne" von Donald Trump ist ein sehr greifbares Beispiel, aber bei weitem nicht das Einzige. Vermutlich ist diese Entwicklung der Preis dafür, dass Agilität in den Mainstream wandert.

• The Washington Post: Open office plans are as bad as you thought

  "The shift in office space could have profound effects on productivity and the quality of work." Das ist das vorweggenommene Fazit einer aktuellen Studie der britischen Royal Society, aus der die Washington Post zitiert. Zusammengefasst: Grossraumbüros sorgen für eine Fragmentierung, Verlangsamung und Verringerung von Kommunikation in und zwischen Teams, mit den erwartbaren Auswirkungen auf Produktivität und Qualität. Bemerkenswert ist die Studie vor allem wegen ihrer Methodik: in ihr wurden nicht nur die Schwankungen der schriftlichen Kommunikation (Mail, Chat, etc.) überprüft sondern mit Hilfe von Sensoren auch die Gesprächsfrequenz. Sie dürfte dadurch valider sein als viele andere.
  

• Informatik Aktuell: Was Microservices wirklich kosten

  Ein eher technisches Thema. Microservices gelten seit einigen Jahren als ein guter Softwarearchitektur-Ansatz für agile Teams oder Unternehmen. Trotz unbestreitbarer Vorteile sind sie aber auch mit Nachteilen verbunden, die Jürgen Lampe hier aufzählt, vom Ressourcenverbrauch über den Testaufwand bis hin zu einer Rückkehr (oder Entstehung) von organisatorischen Silos und Wissensinseln. Wie in vielen anderen Fällen sollte man sich auch bei Microservices fragen, ob die erwarteten Vorteile in einer vertretbaren Relation zu den damit verbundenen Kosten stehen.

• Ron Jeffries: How to Impose Agile

  Ein Versuch die agilen Transitionen wieder vom Kopf auf die Füsse zu stellen. Statt Rollen, Events und Lieferzeiträume einzuführen "weil das so im Lehrbuch steht" geht Ron Jeffries von der anderen Seite an die Thematik heran. Welche Strukturen sind nötig um in kurzen Abständen neue Funktionen auf Produktion zu bringen, wo sie von den Anwendern genutzt (oder durch Nichtbeachtung abgelehnt) werden können? Im Ergebnis ist es natürlich wieder agil, allerdings mit einem Focus darauf warum das Sinn macht und wo die Schwerpunkte liegen sollten.

Deine Muda: Inventory

Bild: Flickr/GOVBA - CC-BY-2.0

Dritter Teil der Deine Muda-Serie. Die zweite Art der Mudas (無駄), also der nicht gewinnbringenden (und aus diesem Grund zu vermeidenden) Tätigkeiten des Toyota Production System ist die Lagerhaltung, auf Englisch Inventory. Auf den ersten Blick ein Problem das vor allem in Hardware-produzierenden Branchen auftritt, auf den zweiten Blick aber auch eines der Software-Industrie.

Zunächst zum Grundsätzlichen: warum ist Lagerhaltung ein Problem? Weil Güter die gerade gelagert werden gebundenes und nicht nutzbares Geld darstellen. In ihren Einkauf oder ihre Herstellung musste bereits investiert werden, so lange sie irgendwo gestapelt liegen kann mit ihnen aber kein Gewinn erwirtschaftet werden. Man spricht in diesem Zusammenhang auch von totem Kapital. Lagerhaltung zu vermeiden erhöht demnach die Liquidität und spart nebenbei noch die Kosten für die Anlagen in denen die Lagerung stattfindet.

Auch in der Softwareentwicklung gibt es das Phänomen, dass "auf Halde" produziert und dadurch totes Kapital angehäuft wird. Es tritt da auf wo Deployment- und Rollout-Prozesse so schwerfällig, bürokratisch und arbeitsaufwändig sind, dass ein Go Live neuer Features nur alle paar Monate möglich ist, im schlimmsten Fall nur ein- oder zweimal pro Jahr. Auch hier liegt zwischen dem Ausgeben von Geld für Lizenzen und Gehälter und dem Erwirtschaften der ersten Gewinne des neuen Produkts ein langer Zeitraum. Wirtschaftlich vernünftig ist das nicht.

Was spezifisch in der Software-Industrie dazukommt ist das Risiko, dass mit veraltenden Anwendungsteilen einhergeht - und veraltet ist Software mitunter schon nach mehreren Monaten "Lagerzeit". Wenn über längere Zeit hinweg Features zwar produziert aber nicht integriert werden (oder nicht mit echten Produktionsdaten laufen, oder keine echte Schnittstellenanbindung haben, etc.), dann steigt die Wahrscheinlichkeit, dass der Go Live Ausfälle, Hotfixes und übereilte Anpassungen nach sich zieht. Das kostet dann wieder Zeit und Geld.

Um eine derartige Folgen von Lagerhaltung fertiger Features zu vermeiden ist es nötig, dass die für einen Go Live nötigen Prozesse und Arbeitsschritte verschlankt, beschleunigt, digitalisiert und automatisiert werden. Erst wenn es möglich ist mindestens monatlich auf Produktion zu deployen können totes Kapital und ausufernde Integrations- und Bugfixing-Phasen vermieden werden. Das ist zwar nicht einfach, es ist aber machbar. Und es ist ein Business-Case.

Dev/Non-Dev Ratio

Bild: Pixabay / Louise Hoffmann - CC0 1.0

Grundsätzlich ist es zwar so, dass die Situation jeder Organisation irgendwie einzigartig ist, trotzdem gibt es bestimmte Rahmenbedingungen, die durchgehend Einfluss auf das jeweilige "Agilitätspotential" haben. Eine davon (zumindest in Software entwickelnden Firmen) ist das Verhältnis von Software-Entwicklern zu Nicht-Entwicklern. Je höher der Anteil an Nicht-Entwicklern an der Belegschaft ist, desto schwerer wird sich die Firma mit Agilität tun.

Um Missverständnissen vorzubeugen: in kaum einem Unternehmen nennenswerter Grösse werden die Software-Entwickler hundert Prozent des Personals ausmachen. Es wird so gut wie immer den Bedarf nach Buchhaltung, Einkauf, etc. geben. Zu einem Problem kann das aber werden, sobald die Anzahl dieser Leute an die der Software-Entwickler heranreicht oder sie übersteigt. Dann sind nämlich meistens einige (oder alle) der folgenden Konstellationen gegeben:

Es existieren organisatorische Silos

Wenn Teams und Abteilungen nicht crossfunktional aufgestellt sind enstehen permanent Koordinations- und Eskalationsaufwände. Im besten Fall müssen die verschiedenen Silos (Fachabteilung, Anwendungsentwicklung, Betrieb, etc.) ihr Vorgehen ständig miteinander abstimmen, gegebenenfalls gibt es sogar abweichende und gegenläufige Planungen, die regelmässig in Konflikten münden. Im schlimmsten Fall stellen sich die Silos ihre Leistungen gegenseitig in Rechnung, mit allem was das an Verhandlungen und Spar-Lösungen zur Folge hat.

Es existieren Wasserfall-artige Prozessketten

Ein ähnliches Phänomen, allerdings innerhalb der Anwendungsentwicklung. Wenn verschiedene Teams für Anforderung, Konzeption, Entwicklung, Test und Rollout tätig sind, dann führt das zu den gleichen Problemen wie im Fall der organisatorischen Silos. Zusätzlich dazu kommt das Phänomen, dass frühere Prozesschritte (Anforderung und Konzeption) in der Regel einen höheren Output haben als spätere (Entwicklung, Test und Rollout), wodurch es zu Stau, Multitasking und Priorisierungskonflikten kommt.

Es existieren vielstufige Hierarchien

Zum Teil eine Folge des letzten Punktes. Bei Konflikten greift noch zu häufig der Reflex, diese durch eine übergeordnete Eintscheidungsinstanz (das Management) lösen zu lassen statt durch die Beteiligten selbst. Das Weiterleiten vieler Entscheidungen nach oben kann aber nur zu zwei Ergebnissen führen: entweder entsteht dort ein weiterer Flaschenhals durch den alles verlangsamt wird, oder es werden immer mehr Entscheider/Manager eingestellt, die zwangsläufig einen immer grösseren Anteil ihrer Zeit dafür verwenden müssen, sich untereinander zu koordinieren.

Es existieren viele nicht automatisierte oder digitalisierte Arbeitsschritte

Ein etwas anderer Fall als bei den letzten Punkten - hier geht es um die eigentliche Produktion. Je geringer der Automatisierungs- und Digitalisierungsgrad beim Testen, Dokumentieren, Berechtigungsmanagement, etc. ist, desto mehr Zeit geht an diesen Stellen verloren. Die Anzahl an Nicht-Entwicklern wie z.B. manuellen Testern und Business Analysten ist an diesen Stellen ein Indikator für langsame und schwerfällige Prozesse.


Dass derartige Konstellationen existieren hat seine Ursache fast immer in einem falsch verstandenen Effizienzdenken. Die zuvor genannten Phänomene gehen oft auf die Annahme zurück, dass Software-Entwickler produktiver sind wenn sie nur Code schreiben und nichts anderes tun. Die Auslagerung von allem anderen in eigene Silos, Prozesschritte, Hierarchie-Ebenen und (Hilfs-)Teams ist die Folge davon. Dass stattdessen die Effizienz sinkt ist dann eine unangenehme Überraschung.