Donnerstag, 23. April 2020
A Safety Net for the Champions of Change
Noch immer viel zu selten: Reflektionen über agile Transitionen aus der Sicht eines Managers. Dawie Oliver von der australischen Westpac Bank sagt es zu Beginn seines Vortrages selbst - am Anfang der meisten Transitionsvorhaben steht die Ansicht, dass das Management Teil oder sogar Ursache der zu überwindenden Probleme ist. Dass eine derartige Frontenbildung nicht hilfreich ist sollte offensichtlich sein, Oliver zeigt aber darüber hinaus auf wie wichtig die Rolle der Führungsebene in derartigen Phasen ist.Zu den wichtigsten unter den von ihm genannten Aufgaben des Managements in Transitionsphasen gehören:
- Den agilen Enthusiasten dabei zu helfen sich nicht an den zu erwartetenden Widerständen bis zum Burnout aufzureiben
- Der umgebenden Organisation zu vermitteln, dass der auf sie ausgeübte massive Veränderungsdruck nichts Bedrohliches ist und sie ggf. daran zu hindern mit Gegendruck zu reagieren
- Anderen Managern auf von ihnen akzeptierter Augenhöhe vermitteln, dass, warum und wie sie ihre Berufsausübung verändern müssen
- Mitarbeitern die sich in der neuen Arbeitswelt unwohl fühlen einen für sie gesichtswahrenden Ausstieg zu bieten
- Toxischen Mitarbeitern ihre Grenzen aufzuzeigen und sie ggf. aus den Teams zu entfernen um andere vor ihnen zu schützen
Montag, 20. April 2020
Die Probleme des Home Office
 |
| Bild: Kaboompics / Karolina Grabowska - CC0 1.0 |
Der offensichtlichste Grund der dagegen spricht, dass sich das Homeoffice dauerhaft durchsetzen wird ist die Infrastruktur. Anders als z.B. in den Niederlanden oder Südkorea ist die in Deutschland geprägt von Kupferkabeln und Funklöchern. Sowohl die Übertragung grösserer Datenmengen als auch die Durchführung von Remote-Meetings sind dadurch oft schwer bis unmöglich. Vor allem auf dem Land aber auch in erstaunlich vielen Städten ist man zu Hause praktisch von der Zusammenarbeit mit Arbeitskollegen, Kunden und Geschäftspartnern abgeschnitten.
Der zweitwichtigste, dafür aber am meisten unterschätzte, ist der, dass die Homeoffice-Fähigkeit stark vom sozialen Status abhängt. Berufe in den verschiedenen Niedriglohnsektoren (Telefonisten, Journalisten, Werbetexter, Sicherheitskräfte, Klicktester) haben häufig Wohnungen in denen ein gewisser Geräuschpegel herrscht (v.A. Verkehrslärm) oder die so klein oder so ungünstig geschnitten sind, dass ergonomische Arbeitsplätze sich hier nur schlecht einrichten lassen. Ist der Job ein freiberuflicher gibt es das zusätzliche Problem, dass die technische Ausrüstung oft nicht finanzierbar ist.
Selbst bei besser bezahlten Berufen kommt dazu, dass Heimarbeit vor allem dann funktioniert wenn man alleine und ungestört zu Hause ist. Arbeitet auch der Ehepartner aus der gemeinsamen Wohnung drohen die Telefonate und Meetings des jeweils anderen die eigenen zu überlagern oder die konzentrierten Ruhephasen zu stören. Und wenn sich ausserdem noch Kinder oder Haustiere in der Wohnung befinden kann von regelmässigen Unterbrechungen fest ausgegangen werden.
Sobald es um Berufe geht in denen mit sensiblen Daten gearbeitet wird tauchen noch Themen wie Datenschutz und Datensicherheit auf. Das beschränkt sich nicht nur auf technische Aspekte wie VPN oder Intranet-Zugriffe sondern hat erneut eine soziale Dimension: durch geöffnete Fenster und dünne Türen kann bereits mehr nach draussen dringen als man denkt, von den Kindern die Freunden und Mitschülern unbedacht von zu Hause erzählen ganz zu schweigen.
All diese Aspekte des Home Office sind bereits für sich genommen problematisch genug, dennoch muss man sich bewusst machen, dass sie nur an der Oberfläche kratzen. Bei genauerer Betrachtung zeigen sich noch weitere schwerwiegende Schwierigkeiten wie der Verlust von Reaktionsgeschwindigkeit, Produktivität, Kommunikations-Qualität und sozialem Zusammenhalt (mehr dazu hier und hier). Zusammengenommen tragen alle diese Punkte dazu bei, dass viele Menschen und Firmen die Heimarbeit so schnell wie möglich wieder gegen das Büro eintauschen werden. Nicht weil New Work schlecht ist, sondern weil Home Office Voraussetzungen erfordert die oft nicht gegeben sind.
Freitag, 17. April 2020
Altsysteme (II)
 |
| Bild: Deutsche Fotothek / Eugen Nosko - CC BY-SA 3.0 |
Wie verschiedene amerikanische Medien berichteten sind die Behörden mehrerer US-Staaten zur Zeit nicht in der Lage die Beiträge der Arbeitslosen-Unterstützung zu erstatten, darunter auch die von New York State, New Jersey und Connecticut, in deren Gebiet der zur Zeit besonders stark von Arbeitslosigkeit betroffene Grossraum New York mit über 20 Millionen Einwohnern liegt. Der Grund: die Erstattungssysteme sind mit Cobol programmiert, einer mehr als 60 Jahre alten (!) Programmiersprache, die heute kaum noch jemand beherrscht.
Dieser Zustand führt seit dem Ansteigen der Beschäftigungslosigkeit auf Rekordniveau zu den erwartbaren Problemen. Die Systeme brechen unter der ungewohnten Last zusammen, es zeigt sich, dass die Frontends nicht mit modernen Endgeräten kompatibel sind und der gestiegene Bedarf an Wartungs- und Reparatur-Tätigkeiten kann vom bisherigen Personal nicht mehr bewältigt werden. Der Notstand ist mittlerweile so gross geworden, dass COBOL-Entwickler in öffentlichen Aufrufen gebeten werden sich zu melden und zu helfen.
Was sich hier bemerkbar macht ist, dass es sich bei der Ablösung von Altsystemen ähnlich verhält wie beim Abschluss von Versicherungen. Solange es keine Probleme gibt scheint es (für unreflektierte Menschen) so als wäre es eine gute Idee Geld einzusparen indem auf sie verzichtet wird. Sobald der Krisen- oder Schadensfall eintritt fällt ihr Fehlen dann aber um so stärker auf. Es zeigt sich dann, dass die scheinbare Stabilität in der Regel nur darauf beruht, dass lange Zeit einfach keine Änderungen vorgenommen wurden durch die die in Wirklichkeit gegebene Instabilität offensichtlich geworden wäre.
Das Problem: da eine Systemablösung schwierig ist und lange dauert kann sie im Krisenfall nicht schnell nachgeholt werden. Sie braucht Zeit. Und währenddessen sind nicht nur die IT sondern auch die von ihr abhängige Organisation gelähmt. Welche schwerwiegenden und zum Teil existenzbedrohenden Folgen das haben kann lässt sich zur Zeit in Amerika beobachten.
Dienstag, 14. April 2020
Maslow's Hammer
 |
| Bild: Pixabay / Mr. Ninko - Lizenz |
Ein prominentes Beispiel für Maslow's Hammer ereignete sich in den letzten Tagen: Jeff Sutherland, einer der Begründer von Scrum, veröffentlichte bei Twitter diese (mittlerweile wieder gelöschte) Aussage:
Passend zum Twice the Value-Versprechen von Scrum unterstellte er also einem (angeblich) nach Scrum arbeitenden Forschungsinstitut die doppelte Leistungsfähigkeit im Vergleich zu anderen Einrichtungen. Bemerkenswert ist aber der mittlere Teil der Aussage. In ihm wird die vermeintlich geringere Leistungsfähigkeit der anderen Einrichtungen begründet mit "because they are not doing Scrum and unable to function". Mit anderen Worten: wenn es nicht Scrum ist funktioniert es nicht. Starker Tobak. Und grober Unfug!1
Um hier keine Missverständnisse aufkommen zu lassen: Sutherland ist ein hochintelligenter Mensch, der ein weltweit geschätzter Experte für Organsationsformen und Prozesse ist. Dass er sich trotzdem derartig versteigt macht diesen Vorfall zu einem guten Beispiel für den Hintergründ von Maslow's Hammer. Der besteht nämlich keineswegs darin, dass es dem der ihn anwendet an grundsätzlichem Verständnis fehlt (selbst wenn das in Einzelfällen so sein kann), es ist komplizierter als das.
Bei Maslow's Hammer handelt es sich um ein Phänomen das in der Psychologie als Kognitive Verzerrung, bzw. Cognitive Bias bezeichnet wird. Dieses spielt sich unterbewusst ab und täuscht dem Betroffenen eine derartige Schlüssigkeit und Offensichtlichkeit vor, dass ein Hinterfragen dieser scheinbaren Tatsachen nicht mehr stattfindet. Als Folge dessen lässt das Bewusstsein diese Falschannahmen ungehindert passieren und gibt sie an die Umgebung weiter. Genau das dürfte hier passiert sein.
Als Ursache kommt eine ganze Reihe möglicher Faktoren zum Tragen. Häufig sind Bestätigungsfehler (die Neigung, Informationen so zu interpretieren, dass diese die eigenen Erwartungen erfüllen), Professionelle Deformation (die Neigung eine berufsbedingte Perspektive über ihren Geltungsbereich hinaus anzuwenden), Korrelations-Fehlschluss (die Annahme, dass gemeinsam auftretende Phänomene voneinander abhängen) und Blind Spot Bias (die Negierung der Möglichkeit nicht objektiv zu sein), es gibt aber unzählige weitere.
Ihnen allen ist gemeinsam, dass sie klar erkennbar sind, sobald man die eigenen Standpunkte ernsthaft auf sie überprüft (was sowohl aufgrund von Selbstreflektion als auch aufgrund einer externen Intervention geschehen kann). Mit ein bisschen Selbstüberwindung kann Maslow's Hammer dann zurückgenommen werden, oder (wie in diesem Fall) der Tweet gelöscht.
1Scrum ist ein weit verbreiteter, zigtausendfach erfolgreicher und seit Jahrzenten optimierter Ansatz. Aber weder ist es der einzig richtige noch der grundsätzlich überlegene Weg
Donnerstag, 9. April 2020
Limit the Blast Radius
Eine eigentlich naheliegende Erkenntnis: um hohe Stabilität zu erreichen ist nicht etwa eine (ohnehin nicht machbare) Reduzierung von Fehlern auf Null der beste Weg sondern das Begrenzen möglicher negativer Auswirkungen auf das kleinstmögliche Ausmass. Und um das zu erreichen sollten nicht etwa möglichst umfassende Kontrollen geschaffen werden (die alles langsam und bürokratisch machen würden) sondern Strukturen in denen Änderungen in abgekapselten Bereichen möglich sind und die über eine einfache (De-)Aktivierbarkeit verfügen. Wer das einleuchtend findet wird diesen Vortrag von Dave Karow mögen.Was dieses Video zu einem guten macht: es führt die Diskussion über Agilität weg von Rollen und Prozessen und hin zu Liefer- und Reaktionsfähigkeit. Letztenendes also wieder zurück dahin wo sie eigentlich immer geführt werden sollte.
Montag, 6. April 2020
Wer hat in Scrum die Prozessverantwortung?
 |
| Bild: Pexels / Christina Morillo - Lizenz |
Beginnen wir mit dem Scrum Master. Wegen des Scrum Guide, der als offizielles Regelwerk scheinbar eine klare Richtung vorgibt, gibt es häufig die Auffassung, dass ganz klar er es ist der die Prozessverantwortung haben muss. Sowohl bei den Aufgaben der Rolle als auch an anderen Stellen könnte man es herauszulesen, dass er bei diesem Thema den Hut auf hat. Also, ist es so? Nun ja, Jein. In die umgebende Organisation wirkt der Scrum Master nur um zu verhindern, dass das Umsetzungsteam gehemmt wird. Und das was das Scrum-Regelwerk für seine Arbeit im Team vorgibt ist lediglich die Verantwortung für einen Prozess-Teilbereich, den des Scrum-Prozesses nämlich. Der ist zwar von zentraler Bedeutung, er gibt aber nur den groben Rahmen für den eigentlichen Arbeitsprozess vor.
Dieser eigentliche Arbeitsprozess ist losgelöst vom Scrum-Prozess (und der Scrum Master-Rolle) zu sehen. Wer macht was wann mit welchem Ziel und mit welchen Werkzeugen? Solange dabei am Sprintende ein funktionierendes Produktinkrement entsteht sollte der Scrum Master da für alles offen sein, genau gesagt muss er es sogar. Der Scrum Guide ist hier sehr eindeutig: Development Teams [...] are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality. Da bleibt kein Platz für Missverständnisse, verantwortlich ist das Umsetzungsteam und sonst niemand.
Über die Scrum- und Arbeitsprozesse hinaus gibt es aber noch einen weiteren Prozessbereich, der üblicherweise mit Namen wie Compliance, Governance oder Betriebsorganisation überschrieben wird. Auf ihn bezogen ist die Natur der Prozessverantwortung wieder eine andere als in den beiden zuvor genannten Fällen. Wenn hier davon gesprochen wird, dass jemand für den Prozess verantwortlich ist, verbirgt sich dahinter in der Regel der feine aber wichtige Unterschied, dass es die Einhaltung der Prozesse ist, für die jemand die Verantwortung trägt. Gestaltet werden sie in der Regel von irgendeiner zentralen Abteilung.
An dieser Stelle dürfen wir uns nichts vormachen - in den meisten Unternehmen ist nur dieser Bereich gemeint wenn von Prozessverantwortung gesprochen wird. Das ist nicht per se schlecht, die meisten Vorschriften beruhen im Grundsatz auf irgendeinem Sinn oder gehen sogar auf Gesetze zurück, dass sie durch Willkür oder Unsinn entstehen ist ein klischeehafter aber seltener Fall. Auch für die Existenz der zentralen Abteilung kann es gute Gründe geben, etwa eine nötige juristische Qualifikation. Es gibt aber sehr oft eine unnötig bürokratische Umsetzung, und auf die gehen meistens die wahrnehmbaren Probleme zurück. Und hier kommen wir zurück zu Scrum, zuerst wieder zum Scrum Master.
Wenn die Prozessverantwortung im Sinne des Sicherstellens der Prozesseinhaltung dem Scrum Master übergeben wird, dann mag das auf den ersten Blick naheliegend erscheinen, es stürzt ihn aber in einen tiefen Intra-Rollen-Konflikt. Auf der einen Seite erwartet Scrum von ihm, dass er dem Umsetzungsteam dabei hilft stetig effektiver zu werden, auf der anderen Seite soll er auf die Einhaltung ineffektiver Arbeitsvorgaben dringen? Und wenn der von aussen vorgegebene, unnötig komplizierte Prozess ein Hindernis für die Arbeitsfähigkeit des Teams ist, soll er zeitgleich versuchen ihn abzuschaffen und für seine Einhaltung sorgen? Das kann nicht funktionieren.
Genau umgekehrt ist es mit dem Umsetzungsteam, bei dem es auf den ersten Blick sinnvoll erscheinen mag es vom Prozessmanagement zu entlasten, damit es "richtige Arbeit" machen kann. Weit gefehlt. Damit würde es nicht nur aufhören crossfunktional zu sein, es wäre auch nicht mehr in der Lage Prognosen oder Commitments für die Sprints abzugeben, da es diese aufgrund der Abhängigkeit zu den externen Prozessverantwortlichen nicht mehr selbst vervollständigen und beenden könnte. Eine der Grundvoraussetzungen von Scrum, die Lieferfähigkeit des Umsetzungsteams, wäre ausgehebelt.
Aus alldem ergibt sich in Scrum folgende Verteilung in der Prozessverantwortlichkeit: der Scrum Master ist verantwortlich für den Scrum-Prozess, das Umsetzungsteam für den Arbeitsprozess. Alle sonstigen Prozessvorgaben (sofern deren Einhaltung eine Voraussetzung für die Lieferfähigkeit des Umsetzungsteams ist) fallen ebenfalls in dessen Verantwortung, wobei es die Aufgabe des Scrum Masters ist so auf das Team und die umgebende Organisation einzuwirken, dass an dieser Stelle Bürokratie und Ineffizienz nicht entstehen können.
Glücklich schätzen kann sich dagegen der Product Owner, an dem die Prozesse weitgehend vorbeigehen. Die einzige grosse Ausnahme davon liegt vor wenn es einen vorgelagerten Anforderungsprozess gibt, was aber nochmal ein Thema für sich ist.
Freitag, 3. April 2020
Dezentrale Krisenbekämpfung
 |
| Grafik: Pixabay / Geralt - Lizenz |
Dezentrale Systeme ermöglichen die parallele Erprobung verschiedener Lösungsstrategien
Das eigentlich Naheliegendste: bei Krisen die ohne historische Vergleichsfälle sind müssen verschiedene Vorgehen erprobt werden um herauszufinden welche besser geeignet sind und welche nicht. So geht das aktuell am stärksten befürwortete "Flatten the Curve"-Vorgehen wesentlich auf den Vergleich der unterschiedlichen Massnahmen zurück mit denen amerikanische Städte 1918/1919 die Spanische Grippe bekämpft haben. Ähnliches dürfte für die verschiedenen Massnahmen zur Bekämpfung des Coronavirus in Deutschland gelten, erst rückwirkend wird sich zeigen ob es Ausgangssperren, Betretungsverbote oder Kontaktverbote gewesen sind die am wirksamsten waren.In dezentralen Systemen können die Massnahmen besser an lokale Probleme angepasst werden
Eine verbreitete Argumentation ist, dass davon ausgegangen werden könne, dass sich Regierungen verantwortungsvoll verhalten und die "einzig richtigen" Massnahmen auswählen würden. Die Realität widerlegt das leider. Egal ob in Italien, in Frankreich oder in Grossbritannien - die jeweiligen Regierungen haben hier schwere Falschentscheidungen getroffen, die unter anderem deshalb so verheerend waren weil durch sie Massnahmen flächendeckend ausgerollt werden sollten die nur unter bestimmten Voraussetzungen hilfreich gewesen wären, unter anderen aber Schaden anrichteten. Als Gegenbeispiel kann Deutschland dienen, wo die Reaktionen auf die Verbreitung des Virus von Beginn an den lokalen Gegebenheiten angepasst waren, was vor Ort zu Erfolgen führte.Dezentrale Systeme können schneller reagieren
Ein Gegenargument zu der häufigen Annahme, dass zentralisierte Systeme eine höhere Reaktionsfähigkeit hätten. Tatsächlich ist es so, dass die Konzentration von Entscheidungsbefugnissen in der Regel zu Flaschenhals-Effekten führt. In der Theorie kann zwar schnell reagiert werden, da sich vor der Entscheidungsstelle aber schnell ein Stau bildet dauert im Endeffekt alles länger. Auch hier können Beispiele genannt werden: auf der einen Seite Grossbritannien mit seinem langsam reagierenden nationalen Gesundheitssystem und Japan, dessen zentralisiertes Vorgehen als "Zugentgleisung in Zeitlupe" bezeichnet wurde, auf der anderen Seite nochmal Deutschland, wo lokale Behörden nicht auf Genehmigungen warten mussten sondern schon früh mit Tests und Eindämmungen beginnen konnten.In dezentralen Systemen können Fehlentscheidungen besser ausgeglichen werden
Letzten Endes die berühmten Checks and Balances. In Ländern wie China und dem Iran wurden die Krankheitsfälle von den Regierungen vertuscht und kleingeredet, mit desaströsen Auswirkungen und tausenden Toten. Auch in der westlichen Welt gibt es leider ähnliche politische Entscheidungen, hier können sie aber ausgeglichen werden. In den USA, Mexiko und Brasilien sind die Relativierungen und die Tatenlosigkeit der jeweiligen Bundesregierungen durch Massnahmen der einzelnen Bundesstaaten ausgeglichen worden, wordurch die Ausbrüche abgeschwächt werden konnten.Mit etwas mehr Recherche würden sich noch weitere Aspekte finden lassen, die zentrale Erkenntnis sollte aber klar sein - dezentrale Systeme haben in der Krisenbekämfung klare Vorteile.
Dienstag, 31. März 2020
Kommentierte Links (LX)
 |
| Bild: Unsplash / Dayne Topkin - Lizenz |
Michael Küsters: Remote Agile Coaching
Um es gleich zu Beginn klar zu sagen: egal welche Tools und Techniken man einsetzt, egal weit Mindset und Maturity sind - als Scrum Master oder Agile Coach wird man remote nie so effektiv arbeiten können wie vor Ort. Das bedeutet aber nicht, dass es nicht gehen würde, im Gegenteil. Es ist möglich und es ist unter diesen Umständen sogar dringender nötig als im Rahmen der meisten vor Ort-Konstellationen. Für alle die jetzt zum ersten mal gezwungen sind auf diese Art zu arbeiten hat Michael Küsters einige gute Ideen formuliert. Wie immer in solchen Fällen gilt zwar, dass das keine Blaupause sein kann die man einfach auf sich übertragen kann, wertvolle Impulse sind aber auf jeden Fall dabei.
Mareike Andert: Firma im Ausnahmezustand
Ein sehr anschauliches Beispiel für eine Firma die über eine hohe Agilität verfügt (möglicherweise sogar ohne diesen Begriff zu kennen). Laut dieses TAZ-Artikels war TIB Molbiol die erste Firma der Welt die einen Test auf Covid-19 entwickeln konnte, und wer ihn liest ahnt warum. Die Prozesse sind schlank, die Hierarchien flach, die Erfahrung und Expertise gross, aber auch die Experimentierbereitschaft und der Pragmatismus. Auch eine zitierbare Anekdote aus der Praxis findet sich hier: die ersten Test-Sets in die Einsatzgebiete zu schicken und die Beipackzettel erst während des Transports zu produzieren und hinterherzumailen ist ein grossartiges Beispiel für die Beschleunigung langwieriger Prozesse. Man kann sich nur mehr Geschichten wie diese wünschen.
Mark Graban: Covid-19 - Don’t Blame Toyota or “Just in Time” for Your Risky Supply Chain Strategy
Zu den unschönen Begeiterscheinungen des Corona-Ausbruchs gehört, dass teilweise eher unreflektiert Schuldzuweisungen ausgesprochen werden. Dass diese mitunter auch in Richtung Lean Management, bzw. Toyota Production System gehen nimmt Mark Graban zum Anlass für eine Verteidigungsschrift. Selbst wenn es so gewesen sein sollte, dass die Verflechtung der globalen Liefer- und Produktionsketten zur Verbreitung der Krankheit beigetragen haben, so ist das nichts was man als Argument gegen die Lean-Bewegung in Position bringen sollte. Diese zielt nämlich eben nicht darauf ab möglichst grosse Teile der Produktion in Billiglohnländer zu verlagern, ganz im Gegenteil. Kundennähe kann hier auch im engeren Wortsinn verstanden werden, als Produktion in möglichst grosser Nähe zum Absatzmarkt. Auch wenn die Löhne da teurer sind ist das in der Gesamtsicht billiger, da es Transport-, Reise- und Wartezeiten reduziert.
Davide Sher: Italian hospital saves Covid-19 patients lives by 3D printing valves for reanimation devices
Dass 3D-Druck Agilität in die Hardwarefertigung bringt ist schon seit Jahren ein wachsender Trend, mittlerweile zeigt sich, dass dieses Vorgehen nicht nur effektiv sondern sogar lebensrettend sein kann. Mitten in einem der schlimmsten Ausbruchsgebiete des Corona-Virus können mit Hilfe eines 3D-Druckers jetzt medizinische Werkzeuge produziert werden die von den Krankenhäusern dringend gebraucht werden. Zuerst Reanimationsgeräte, seit kurzem auch Beatmungsmasken. Letztere sind auch aus einem weiteren Grund nennenswert: statt hier alles neu herzustellen werden nur Einzelteile angefertigt, mit deren Hilfe man handelsübliche Tauchmasken umfunktionieren kann. Ein erstaunlich effektiver Weg um schnell zu einem benutzbaren MVP zu kommen.
Christoph Prantner: Das Coronavirus testet die Widerstandsfähigkeit Europas
Ein bemerkenswerter Artikel über die Widerstandskräfte die einen Staat befähigen mit Pandemien wie Covid-19 umzugehen. Bemerkenswert deshalb weil hier Begriffe benutzt werden die sich normalerweise bei der Beschreibung von Unternehmen wiederfinden die gerade Transitions- oder Disruptionsprozesse durchlaufen: Resilienz, Robustheit, Agilität, Lernfähigkeit, Bounce Back/Bounce Forward. Und bemerkenswert auch weil hier dem gerade verbreiteten reflexhaften Ruf nach mehr Zentralstaat nicht nachgegeben wird sondern er stattdessen als das benannt wird was er in der Realität häufig ist - ein Hindernis für schnelle Reaktionsfähigkeit.
