Die VUCA-Verkennung

Wenn es einen Begriff gibt, der von fast jedem Agile Coach oder Scrum Master regelmässig benutzt wird, dann ist es VUCA (volatility, uncertainty, complexity, ambiguity), bzw. dessen deutsche Übersetzung VUKA (Volatilität, Unsicherheit, Komplexität, Ambiguität). Meistens verwendet um zu zeigen, aufgrund welcher Faktoren Agilität nötig ist, verbirgt sich hinter ihm oft eine interessante Wahrnehmungs-Schere: die Selbsteinschätzungen der Betroffenheit durch VUCA gehen z.T. weit auseinander.

Aus einer abstrakten Beobachterposition heraus ist die Sache klar: sich ändernde Rahmenbedingungen, Marktdynamiken und unerwartete Ergebnisse von Hypothesen-Validierungen setzen praktisch jedem Entwicklungsteam permanent zu, so dass regelmässiges Innehalten, Abgleichen des Ist-Standes mit dem Ziel und ein Abgleichen des Ziels mit der möglicherweise veränderten Realität zwingend notwendig ist, wenn man nicht am Bedarf vorbeiarbeiten und so die eigene Firma gefährden will.

Umgekehrt gibt es aber interessanterweise aus vielen Teams und Management-Runden die genau entgegengesetzte Wahrnehmung. Die Existenz von Volatilität, Unsicherheit, Komplexität und Ambiguität im eigenen Umfeld wird hinterfragt oder sogar negiert, oft mit dem Hinweis, dass die Umgebungsfaktoren seit Jahren oder sogar Jahrzehnten unverändert und stabil wären. Oft treffen diese unterschiedlichen Einschätzungen (Vuca und Nicht-Vuca) sogar im selben Kontext auf - wie kann das sein?

Um den weniger wahrscheinlichen Fall zuerst zu betrachten: es kann tatsächlich vorkommen, dass es im Umfeld von Entwicklungsteams über längere Zeiträume zu keinen unerwarteten Entwicklungen kommt. Ein Fall der mir einmal untergekommen ist war z.B. ein Intranet, das nur mit einem selbstentwickelten Browser aufrufbar war. Es wurde zwar weiterentwickelt, war aber von den Überraschungen und Neuerungen der "Aussenwelt" komplett abgekoppelt. Wie gesagt, möglich aber selten.¹

Wesentlich wahrscheinlicher ist eine andere Erklärung: die Existenz der VUCA-Dynamiken wird nicht erkannt oder (ggf. unbewusst) ignoriert. Wer schon einmal in grösseren Organisationen unterwegs war, wird mit etwas Nachdenken sicher auf einige derartige Fälle kommen, die er selbst miterlebt hat. Wichtig für Ihr Verständnis ist dabei, dass diese "Betriebsblindheit" in den meisten Fällen nicht aus individuellen Schwächen entsteht, sondern systemische Gründe hat.

Einer davon kann ein Organisationsdesign sein, das die Entwicklungsteams durch ein zwischengelagertes Anforderungs- oder Produktmanagement weitgehend von Kunden, Anwendern und externen Faktoren abschirmt. Die äusseren Dynamiken finden in solchen Fällen zwar statt, die Teams sind sich ihrer aber nicht bewusst. Die Konsequenz ist ein irgendwann stattfindendes unschönes Erwachen, z.B. dadurch, dass man im Jahr 2020 herausfindet, dass COBOL nicht mehr zeitgemäss ist.²

Ein zweiter Fall wäre der, den man despektierlich als "kollektive Betriebsblindheit" bezeichnen könnte. Er liegt vor, wenn auf allen Hierarchie-Ebenen und in allen Organisationseinheiten die bestehenden Veränderungsdynamiken nicht erkannt oder als zu unwichtig eingeschätzt werden. Beispiele dafür wären die Mobiltelefon-Sparten von Siemens und Nokia, die das Potential der Smartphones nicht erkannt haben. Ihr Schicksal zeigt auch auf, welche Folgen solche Verkennungen haben können.

Ebenfalls anzutreffen ist der unschöne Fall, dass Monopolstellungen ausgenutzt werden, um Anwenderwünsche und technische Neuerungen bewusst zu ignorieren. Das wird z.B. einem grossen ERP-Entwickler immer wieder unterstellt, die meisten derartigen Fälle finden aber im Rahmen interner Anwendungsentwicklungen statt, vor allem dort, wo Konzerne ihre eigene Individualsoftware herstellen. Die Konsequenz daraus ist meistens eine zurückgehende Mitarbeiter-Loyalität, ggf. Kündigungen.³

Welche Variante es auch ist, mit den zu Beginn genannten wenigen Ausnahmen handelt es sich bei fast allen Fällen, in denen Produktentwicklungs-Einheiten glauben, nicht von den VUCA-Faktoren betroffen zu sein, um Verkennungen der Realität, die sich früher oder später rächen werden.  Zumindest in einem techniknahen Umfeld sollte man sich daher besser mit ihnen beschäftigen, und zwar auch und gerade dann wenn man das Gefühl hat, ihnen gar nicht ausgesetzt zu sein.