Kommentierte Links (CXX)

Grafik: Pixabay / Geralt - Lizenz

Das Internet ist voll von Menschen, die interessante, tiefgründige oder aus anderen Gründen lesenswerte Artikel schreiben. Viele dieser Texte landen bei mir, wo sie als „Food for Thought“ dazu beitragen, dass auch mir die Themen nicht ausgehen. Wie am Ende jedes Monats gibt es auch diesesmal wieder eine kommentierte Übersicht über die erwähnenswertesten.

Joe Foley: Delete to Accelerate: Boulders, rocks, pebbles - An Agile model that scales

Kurz bevor ich diesen Artikel von Joe Foley gelesen habe, habe ich selber den sehr ähnlichen Ansatz Rock, Pebbles, Sand bei einem Team meines aktuellen Kunden eingeführt. Was beiden gemeinsam ist, ist, dass sie dem häufigen Problem begegnen, dass vorgegebene Planungszyklen (Quartale, Sprints, etc.) nicht vollständig verplanbar sind. Statt in der verbleibenden Zeit mit der nächstwichtigsten Arbeit zu beginnen (die im Zweifel nicht abschliessbar ist), wird diejenige unter den nächstwichtige Aufgaben gewählt. die im verbleibenden Zyklus abschliessbar ist. Ein elementarer Unterschied.

Cliff Berg: Empowerment, Not Self-Organization

Es ist eine Debatte die so alt ist wie die agile Bewegung: bedeutet Selbstorganisation nur, dass sich ein bereits zusammengestelltes Team selber entscheidet, auf welchem Weg es ein vorgegebenes Ziel erreicht, oder sollte es sich auch selbst zusammenstellen und sich selbst einen Auftrag suchen dürfen? Cliff Berg plädiert hier für die erste Variante, und zwar nicht aus ideologischen Gründen, sondern aus Pragmatismus. Bei allen Vorteilen ist das Risiko von Konflikten und Dyfunktionen in vielen Fällen zu hoch für das nötige Investment. Ich kann da nicht widersprechen.

Sean Gödeke: How I ship projects at big tech companies

Was Sean Gödeke hier aufbringt ist auf den ersten Blick ein technisches Thema - wann ist eine neu entwickelte Funktion "verschifft" (im IT-Englisch: für die Endkunden-Nutzung verfügbar gemacht)? Seine auf den ersten Blick überraschende Definition: nicht dann, wenn das prozessual abgeschlossen ist, sondern erst dann wenn das Management und andere Stakeholder mit dem Ergebnis zufrieden sind. Ist das nicht der Fall, werden auch einwandfrei funktionierende Auslieferungen wieder und wieder überarbeitet werden müssen. Ein guter Impuls um die Definition of Done zu überdenken.

Paweł Huryn: 10 Sources of Waste in Product Management

Zum Thema der Mudas (無駄), also der nicht gewinnbringenden (und aus diesem Grund zu vermeidenden) Tätigkeiten aus dem Toyota Production System habe ich schon eine ganze Artikelserie geschrieben, aber auch ich kann aus Paweł Huryns Übertragung auf das Produktmanagement noch neue Erkenntnisse ziehen. Ich glaube sogar, dass es egal ist wo und in welcher Form man sie einsetzt - sobald man sich ernsthaft mit dem Thema Ressourcenverschwendung beschäftigt, wird man überall Verbesserungspotentiale finden können.

Pim de Moree: Bayer's Bold Bet: How a 160-Year-Old Giant is Liberating 100,000 People

Bei der aktuellen Konzern-Transformation der Bayer AG bin ich mir unsicher: in der Theorie klingt alles richtig und sinnvoll, was man von Beteiligten aus dem Unternehmen hört, klingt dagegen mitunter eher planlos und willkürlich. Andererseits entspräche das auch wieder den typischen Abwehrreaktionen von Menschen, denen ihre Komfortzone genommen wird. In diesem Text von Pim de Moree steht wieder die positive Seite im Vordergrund. Wie es wirklich ist, wird man vermutlich erst in einigen Jahren wissen, bis dahin ist es eine spannend zu beobachtende Live-Fallstudie.

Die agile Bewegung

Bild: Unsplash / Miguel A. Amutio - Lizenz

Wenn von der Gruppe aller Menschen die Rede ist, die in irgendeiner Form agil arbeiten (oder denen das zumindest zugeschrieben wird) fallen häufig Begriffe wie "die agile Bewegung" oder "die agile Community". Was damit genau gemeint ist bleibt in der Regel offen, was aber keineswegs bedeutet, dass diese Gruppe nicht beschreibbar wäre. Tatsächlich gibt es in der Wissenschaft sogar eine ganze Kategorie sozialer Zusammenschlüsse, die hier passend ist: die der sozialen Bewegungen.

Ein wichtiges Merkmal an dem soziale Bewegungen erkennbar sind, sind übergeordnete, gesellschafts-verändernde oder gesellschafts-stabilisierende Ziele. Das ist offensichtlich bei Bürgerrechts- oder Umweltbewegungen, kann aber auch in Berufskontexten stattfinden. Hier ist die agile Bewegung neben New Work sogar eine der Wichtigsten. Ihr aus dem agilen Manifest abgeleitetes grosses Ziel: die Schaffung einer besseren, humaneren, nachhaltigeren und effektiveren Arbeitswelt.

Was soziale Bewegungen ausserdem von anderen Gruppen unterscheidet, ist die nur schwer überprüfbare Zugehörigkeit. Weder wird man in sie hineingeboren (wie in Familien oder Stämme) noch gibt es klar formalisierte Zugehörigkeits-Kriterien und Aufnahmebedingungen (wie in Unternehmen oder Vereinen). Was es stattdessen gibt sind Selbst- oder Fremdzuordnungen, die sich auch widersprechen können. Man denke z.B. an die Debatten, oder SAFe und OKRs agile Frameworks sind oder nicht.

Eine Folge dieser nicht-formalen Zugehörigkeit ist das weitgehende Fehlen von Macht-Mitteln und Ressourcen-Kontrolle. Bis zu einem gewissen Grad ergeben die sich zwar indirekt aus charismatischer Führung, bzw. der sich daraus ergebenden Gefolgschaft, es gibt aber keine Budgets, keine Karrierepfade und keine bei Fehlverhalten drohenden Konsequenzen. Das ist auch ein Hauptgrund für den in sozialen Bewegungen verbreiteten Idealismus, der als Motivator an die Stelle materieller Anreize tritt.

Dieser unklare und von materiellen Zielen getrennte Status wird allerdings weiter verkompliziert durch das Phänomen, dass es mit der Zeit zu Formalisierungen von Teilen sozialer Bewegungen kommen kann, die dann parallel zu den unformalisierten Teilen bestehen. Eines der bekanntesten Beispiele dürfte die Entstehung der grünen Parteien aus der Umweltbewegung sein, formalisierte Teile der agilen Bewegung sind u.a. die Agile Alliance oder die Scrum Alliance.

Diese letzten Beispiele zeigen auch ein Problem auf, dass soziale Bewegungen bekommen können, wenn sich Teile von ihnen formalisieren. Ob nur zur Finanzierung der eigenen Strukturen oder aufgrund einer Gewinnerzielungsabsicht - mit Formalisierung geht praktisch immer der ein Geldbedarf einher, der alleine aus Selbsterhaltungstrieb doch als materielles Ziel neben die ursprünglichen, idealistischen Ziele tritt - was von den nicht-formalisierten Teilen der Bewegung z.T. vehement abgelehnt wird.

Verstärkt werden derartige Konflikte durch ein weiteres Phänomen, den so genannten Sog der Addition. Er tritt auf, wenn ähnliche soziale Bewegungen gemeinsame Teilziele verfolgen und sich dadurch teilweise überlagern. Sobald diese Überlagerung eine kritische Masse überschreitet, werden auch ursprünglich nicht geteilte Ziele übernommen, im Fall weiter Teile der agilen Bewegung z.B. das Streben nach Basisdemokratie oder die Ablehnung von Shareholder Value-Orientierung.

Nochmal von einer anderen Seite betrachtet können Soziale Bewegungen derartige interne Konflikte aber besser bewältigen und kompensieren als stärker formalisierte Gruppen, zum Einen weil sie eben aufgrund der fehlenden Formalität und Ressoucenverteilung in einem weitgehend konsequenzfreien Raum operieren, zum Anderen weil ihre übergreifenden idealistischen gesellschaftlichen Ziele eine Bindekraft haben können, die grösser ist als die Zentrifugalkräfte der verschiedenen internen Interessen.

All diese  Faktoren sorgen dafür, dass soziale Bewegungen im Allgemeinen und die agile Bewegung im Speziellen relativ schwer zu beschreiben und in Zusammenhänge einzuordnen sind, was nochmal dadurch verstärkt wird, dass die übergreifenden Ziele sich aufgrund einer fehlenden verbindlichen Regulierung mit der Zeit verändern können. Im Fall der agilen Community führt das zu einem fast schon versöhnlichen Schluss: ihr anzugehören bedeutet, sich regelmässig anzupassen.

Agile Coach, choose your words carefully

Eine kleine Anekdote: in einem meiner längeren Einsätze war ich mit der Begleitung einer agilen Konzern-Transformation beauftragt, in deren Rahmen ich über mehrere Monate Product Owner und Scrum Master ausbildete, Schulungen durchführte und bei der Erstellung einer neuen Aufbau und Ablauforganisation beriet. Im Großen und Ganzen ein Auftrag, auf den ich gerne zurückblicke - mit einer Ausnahme, bei der ich mich etwas fahrlässig verhalten habe.

In einem Workshop mit mehreren angehenden Scrum Mastern stellte irgendjemand einen der Klassiker unter den Einsteiger-Fragen: für was Scrum eigentlich die Abkürzung wäre.¹ Ich war gleichermassen amüsiert und leicht genervt, da ich den Ursprung dieses Namens bereits mehrfach erklärt hatte. Und aus einem Affekt heraus antwortete ich mit einem Witz: "Scrum steht für Scaled Corporate Rational Unified Model". Alle lachten kurz, ich dachte mir nichts dabei und der Workshop ging weiter.

Man kann sich vermutlich denken, was als nächstes passiert ist: Zu den Aufgaben der anwesenden neuen Scrum Master gehörte auch die Erstellung von Schulungsunterlagen, und als ich die zwei Wochen später zu Gesicht bekam, musste ich kurz nach Luft schnappen. SCRUM wäre eine Abkürzung, hiess es da, und sie würde stehen für Scaled Corporate Rational Unified Model. Mir war sofort klar, wo diese Fehldeutung ihren Ursprung hatte - bei mir.

Sensibilisiert durch dieses Erlebnis achte ich seitdem darauf, dass humorige oder sarkastische Bemerkungen von mir klar als solche zu erkennen sind, um nicht wieder zur Quelle für eine fehlerhafte Information zu werden. Und ich achte darauf, wo andere Agile Coaches versehentlich mit flapsigen Bemerkungen Falsch-Informationen verbritet haben. Und was soll ich sagen - selbst wenn es zum Glück nicht häufig ist, es kommt immer wieder vor.

Bei einem Kunden stand in der Dokumentation, dass die Kanban-Methode nach ihrem Erfinder Kenji Kanban benannt worden wäre. Bei einem anderen, dass SAD MF ein vielversprechendes Skalierungs-Framework wäre, dass man näher evaluieren sollte. Mehrfach habe ich erlebt, dass Jira erkennbar ironisch als agiles Framework bezeichnet wurde, einmal mit der Anmerkung, dass Entwickler die es benutzen nicht mehr selbst denken müssten. Offensichtlicher Sarkasmus, der aber nicht erkannt wurde.

Wie es zu derartigen Transfer-Missverständnissen kommt ist dabei einfach erklärbar: Für den Agile Coach ist sene Arbeit entweder Routine, die er durch Scherze aufzulockern versucht, oder eine Frustrationserfahrung, die in zu Sarkasmus verleitet. Die ihn umgebenden Menschen befinden sich dagegen in einer Sondersituation, sind noch unsicher was von dem neuen Wissen relevavant ist und verinnerlichen vorsichtshalber alles. Was daraus folgt ist offensichtlich.

Gerade aufgrund dieser Wissens-Asymetrie befindet sich der jeweilige Agile Coach in einer Position, in der er sich verantwortungsvoll verhalten muss. Wie oben gesagt, Humor und Sarkasmus sind in Ordnung, sie müssen aber als solche erkennbar sein, im Zweifel durch die Anmerkung, dass die letzte Aussage bitte nicht ernst zu nehmen ist. Das hilft allen anderen, hilft aber auch dem Agile Coach selbst, der sich weniger Sorgen machen muss, dass von ihm versehentlich das Falsche gelernt wird.

¹Wie verbreitet der Irrtum ist, dass das Wort Scrum eine Abkürzung wäre, erkennt man daran, dass es häufig komplett in Grossbuchstaben geschrieben wird, also SCRUM.

Agile Success Stories: Die iterativ-incrementelle Reorganisation

Die Entwicklung einer negativen Weltsicht durch viele "agile Methodiker" (Agile Coaches, Scrum Master, etc.) ist ein bedauenswertes, aber auch menschlich verständliches Phänomen - wer sich ständig mit dem Beseitigen von Impediments und dem Kampf gegen Change Fatigue und Konzern-Trolle beschäftigen muss, kann leicht in Frustration abrutschen. Um nicht selbst in dieses Muster verfallen, veröffentliche ich ab und zu selbst erlebte "agile Erfolgsgeschichten", um zu zeigen, dass vieles auch gut läuft.

In dieser hier geht es um das Durchführen einer Konzern-Reorganisation. Besagter Konzern hatte in den Jahren zuvor bereits mehrere Reorganisationen durchgeführt, und alle Beteiligten waren sich einig, dass sie nur mittelgut verlaufen waren. Am Anfang hatte es zwar jedesmal gut durchdachten Pläne gegeben, sobald die auf die Realität trafen, hatten sie sich aber jedesmal als lückenhaft erwiesen. Die Anpassung an die Realität hatte dann jedesmal zu Bürokratie, Unordnung und Unzufriedenheit geführt.

Das neue Vorgehen, mit dem es diesesmal anders werden sollte, sah zunächst vor, die Veränderungen in Arbeitspakete aufzuteilen, die nach und nach, in Abständen von wenigen Wochen, ausgeliefert werden sollten. Das Besondere daran: spätere Schritte wurden bewusst noch nicht ausdetailliert, stattdessen wurde nach jeder Auslieferung ein Feedback-Prozess gestartet, auf dessen Basis die Detaillierung angepasst wurde. Sogar das Rückgängigmachen früherer Reorganisationsschritte war ggf. möglich.

Um es an Beispielen konkret zu machen: ein erstes Arbeitspaket war die grundsätzliche Aufteilung und Bündelung von Zuständigkeiten, ein zweites der darauf aufbauende Zuschnitt der Bereiche und Abteilungen, ein drittes die Besetzung der Leitungspositionen, ein viertes die Zuordnung derjenigen Mitarbeiter, deren Tätigkeitsprofil das eindeutig zuliess, ein fünftes die Zuordnung der nicht ganz so eindeutigen Fälle, ein sechstes die Verteilung der neuen Einheiten auf die Büros.¹

Der Feedback-Prozess, der nach der Fertigstellung von jedem dieser Arbeitspakete folgte, bestand aus mehreren Dimensionen. Zum einen gab es Versammlungen der (bisherigen) Standorte und Abteilungen, in denen Fragen, Bedenken und Hinweise geäussert werden konnten. Parallel dazu wurden Mitarbeiter aus allen Organisationseinheiten zu Teilzeit-Change Managern ernannt, die dort Ansprechpartner waren und Rückmeldungen sammelten. Zuletzt gab es physische und virtuelle Feedback-Briefkästen.²

Die Erkenntnisse aus diesen Feedbacks waren zum Teil sehr wertvoll. An einer Stelle wurde z.B. darauf hingewiesen, dass beim Abteilungsschnitt eine Zuständigkeitslücke gelassen wurde, an einer anderen Stelle, dass die Aufteilung bestimmer Aufgaben auf zwei Abteilungen zwar theoretisch möglich, in der Realität aber schwierig umzusetzen sein würde, da sie bisher von den selbem Personen durchgeführt wurden. Mehrfach führte das zu Anpassungen, die ebenfalls wieder Gegenstand von Feedback wurden.

Dass diese Anpassungen mit verhältnismässig gerigem Aufwand durchgeführt werden konnten, war vor allem dem Verzicht auf zu frühe Detailplanung zu verdanken. So wären in den beiden erwähnten Beispielen die Korrekturen der suboptimalen Abteilungsschnitte deutlich schwieriger gewesen, wenn zu dem Zeitpunkt bereits alle Versetzungen in diese Einheiten stattgefunden hätten. Da die Versetzungen jetzt erst in einem nächsten Schritt stattfanden, entstanden die Probleme gar nicht erst.

Als Nebeneffekt wurde auch die Kommunikation der Veränderungsmassnahmen deutlich einfacher. Statt alle Veränderungen auf einmal konsistent erklären und als Ganzes verstehen zu müssen, wurde jeweils nur auf das aktuelle Arbeitspaket vertieft eingegangen, bei den späteren reichte eine kurze Ankündigung des Inhalts und des geplanten Zeitpunkts. Sowohl im Kommunikationsteam als auch in der Belegschaft wurde das im Vergleich zu früheren Reorganisationen als deutliche Verbesserung empfunden.

Eine Pointe dieser Geschichte hier ist, dass das in ihr beschriebene Vorgehen, nie offiziell als "agil" konzipiert oder bezeichnet wurde. Stattdessen ging es nach Ansicht aller Beteiligten lediglich auf Common Sense und Erfahrungswerte zurück, aus denen sich ganz selbstverständlich die hier beschriebenen Schritte ergaben. Erst ganz zum Schluss fiehl einem Vorstand auf, dass es offensichtliche Parallelen zur agilen Produktentwicklung gab. Grösser thematisiert wurde das aber nie.

¹Natürlich ist das eine vereinfachte Darstellung, in der Realität war es etwas komplizierter
¹Auch anonymes Feedbach war hier möglich

Welches SAFe darfs denn sein?

Dass es von jedem agilen Framework in der Realität sehr unterschiedliche Ausprägungen gibt, dürfte jeder wissen, der verschiedene agil arbeitende Unternehmen gesehen hat. Zu den Gründen dafür gehört zum einen ein bewusst offen gelassener Gestaltungsspielraum, zum anderen aber auch versehentliche oder absichtliche Verfremdungen der ursprünglichen Idee. Das trifft auf Scrum zu, auf Kanban, auf OKRs, aber auch auf das Scaled Agile Framework (SAFe).

SAFe ist dabei aber in einem Aspekt deutlich anders als die anderen Frameworks: während sich deren Variantenvielfalt u.a. daraus ergibt, dass sie sich in einem Spannungsfeld zwischen einem praxisnahen Graswurzel-Ursprung und einer später entstandenen starken Kommerzielisierung bewegen, ist SAFe bereits in seinen Ursprüngen kommerziell angelegt. Sämtliche seiner Varianten sind dadurch Teil des Beratungs- und Zertifizierungs-getriebenen agil-industriellen Komplexes.¹ Hier sind sie:

The Little Agile Release Train

Die vielleicht häufigste Variante, wenn auch oft mit anders benannten Namen und Rollen.² Drei bis zehn Teams arbeiten in synchronisierten Sprint-Rhythmen, es gibt eine übergreifende Quartalsplanung und oberhalb der Product Owner und Scrum Master einen Produktmanager / Chief Product Owner und Release Train Engineer / Chief Scrum Master, der ihnen jeweils übergeordnet ist. Für sich genommen eine noch relativ schlanke, agile und halbwegs unbürokratische SAFe-Umsetzung.

The Feature Factory

Die Grössenordnung, die die Aussenwahrnehmung von SAFe am stärksten prägt. Ab einer Größe von mehr als zehn Teams ist ein Release Train nicht mehr ausreichend, es werden mehrere parallel zueinander eingerichtet, über denen dann eine zusätzliche Hierarchieebene mit einem Solution Manager und einem Solution Train Engineer entsteht. Feedback-Schleifen und Nähe zwischen Entwicklern und Anwendern sind nur noch schwer möglich, es werden vor allem Feature Requests abgearbeitet.

Disruptive SAFe

Während der einzelne Release Train und die Feature Factory die alten Strukturen einer Firma noch weitgehend unangetastet lassen, hat SAFe einige optionale Elemente, deren Anwendung einiges durcheinanderwerfen würde, z.B. die Koppelung der Budgetierung an Teams statt an Features oder die Ausrichtung der Planungen an Value Streams statt an Roadmaps. Aus einer "agilen Perspektive" sehr wünschenswert, kommt aber in der Realität nur sehr selten vor.

Absorbed SAFe

Dort, wo (warum auch immer) alles in einem einzigen, grossen agilen Framework organisiert werden soll, die Auswirkungen von disruptivem Safe den Verantwortlichen aber zu weit gehen, ist es eine häufige Reaktion, so lange Anpassungen vorzunehmen, bis zentrale Elemente des bisherigen Vorgehens nicht mehr angetastet werden. Das Ergebnis können Hybrid-Frameworks wie SpotiSAFe sein, ggf. aber auch einfach eine Erweiterung oder Beschneidung des SAFe-Umfangs an entscheidenden Stellen.

Post-SAFe

Mittlerweile erstaunlich häufig anzutreffen sind Unternehmen, die sich irgendwann entschlossen haben, nicht mehr nach SAFe zu arbeiten, da die damit verbundenen Erwartungen nicht erfüllt werden konnten. Mitunter werden aber einzelne funktionierende Elemente beibehalten, z.B. das PI Planning oder die Rolle des Release Train Engineers. Man erkennt durch sie noch, dass SAFe hier einmal im Einsatz gewesen ist, der aktuelle Zustand hat aber nur noch eingeschränkt damit zu tun.

Und viele mehr ...

Wie immer bei solchen Aufzählungen ist auch diese hier nicht vollständig, in den Unternehmen dieser Welt kann man mit Sicherheit noch weitere SAFe-Varianten finden. Wichtig ist an dieser Stelle vor allem die zentrale Botschaft: es gibt verschiedene Ausprägungen dieses Frameworks, die sich z.T. sehr deutlich voneinander unterscheiden, wodurch es viel weniger eindeutig und einheitlich ist, als es auf den ersten Blick erscheinen mag.

Völlig losgelöst von diese Betrachtung bleibt übrigens die Frage, ob man SAFe mag und ob man es überhaupt für ein agiles Framework im Sinn des Manifests für agile Softwareentwicklung hält. Das kann jeder für sich entscheiden.

¹Ob dieser Text hier Meinungsäusserungen enthält? Bestimmt. Und es kommen noch weitere.
²Bei abweichenden Benennungen ist nicht immer klar erkennbar, ob hier SAFe die ursprüngliche, später begrifflich angepasste Idee war, oder ob es durch Einbringung von SAFe-Elementen in LeSS, Nexus oder Scrum@Scale-Umsetzungen zu diesen Ergebnissen gekommen ist.

Wie der Staat wieder handlungsfähig wird (II)

Bild: Strassen NRW

Ab und zu wird man von der staatlichen Verwaltung positiv überrascht, in diesem Fall vom Landesbetrieb Straßenbau Nordrhein-Westfalen. Der ist u.a. verantwortlich für den Neubau einer Brücke, die ich in den letzten Jahren ab und zu benutzt habe, der Wupperbrücke Blombacher Bach in Wuppertal. Dieser Neubau wurde dieses Jahr in einer rekordverdächtigen Geschwindigkeit von nur wenigen Wochen abgeschlossen, und das mit Massnahmen, die jetzt zum Standard in NRW werden sollen.

Die erste dieser Massnahmen ist ein frühes Beteiligungsverfahren, an denen sich alle betroffenen Gruppen (in diesem Fall Anwohner, Pendler, Unternehmen, etc.) beteiligen und ggf. ihre Bedenken einbringen können. Das mag auf den ersten Blick wie eine Verzögerung wirken, sorgt aber später im Prozess für Geschwindigkeit, da durch die Einbeziehung derartiger Stakeholder die Wahrscheinlichkeit von Fehlplanungen und Gerichtsprozessen geringer wird.

Über die zweite Massnahme habe ich bereits an anderer Stelle etwas geschrieben: es ist die Modulbauweise. Die einzelnen Bauelemente können an einer anderen Stelle im Voraus gefertigt werden und werden vor Ort nur noch zusammengesetzt und durch eine so genannte Ortbetonergänzung verbunden (was für ein schönes deutsches Wort). Neben der Geschwindigkeit ergibt sich dadurch ein zweiter Vorteil - beschädigte Brückenteile können später einfacher ersetzt werden.

Die dritte Massnahme ist vermutlich für die deutsche Bürokratie am revolutionärsten, es handelt sich um die so genannte funktionale Ausschreibung der Bauvorhaben. Bei derartigen Ausschreibungen wird kein detaillierter Leistungskatalog mehr vorgegeben, sondern es wird nur das zu erreichende Ziel definiert (z.B. Abriss und Neubau einer Brücke) ggf. verbunden mit in diesem Rahmen zu erreichenden Kennzahlen (z.B. der Traglast dieser Brücke).

Dieses Vorgehen hat gleich mehrere positive Effekte: der Umfang der zu erstellenden und zu bearbeitenden Ausschreibungs-Unterlagen wird geringer, den Bauträgern wird es möglich gemacht, neue und innovative Bautechniken einzusetzen, ohne die Bauämter davon überzeugen zu müssen, diese in die Pläne aufzunehmen, und durch die geringeren Aufwände in diesen Ämtern ist der dort spürbare Fachkräftemangel ein weniger starker Verlangsamungsfaktor für Planungs- und Genehmigungsprozesse.

Wie immer in solchen Fällen fragt man sich zwar, warum das nicht schon viel früher so gemacht worden ist, nach vorne blickend kann man sich aber darüber freuen, dass die Baustellen in Nordrhein-Westfalen zukünftig viel schneller wieder beendet sein werden als bisher. Vielleicht sollte auch die Bahn sich mal mit dem Landesbetrieb Straßenbau austauschen? Schaden würde es sicher nicht.

A Field Guide to Reliability Engineering

Mir fällt gerade auf, dass ich noch nie etwas zum Thema Site Reliability Engineering (der Schaffung einfach skalierbarer und trotzdem hochzuverlässiger Softwaresysteme) geschrieben habe. Hole ich irgendwann nach, für den Moment nimmt mir Heinrich Hartmann diese Arbeit aber ab, in dem er gut darstellt, wie das bei seiner Firma (Zalando) gemacht wird.

Was mir besonders gut daran gefällt: er streicht deutlich heraus, dass es sich bei Site Reliability Engineering nicht nur um ein rein technisches Thema handelt, sondern um ein technisch-soziales, das ohne Berücksichtigung der Anwender, bzw. ihrer Wünsche und Reaktionen, nicht zu denken ist.

Unternehmens-Multikultur

Noch einmal zum Thema Unternehmenskultur. Wie bereits an anderer Stelle geschrieben hat jedes auch nur halbwegs grosse Unternehmen nicht nur eine Kultur, sondern mehrere, die parallel zu einander existieren: eine in der Fertigung, eine im Vertrieb, eine in der Finanzabteilung, eine in der Software-Entwicklung, etc. Das gilt übrigens auch dort, wo offiziell etwas anderes behauptet wird, wo die "offiziell verkündete Kultur" total positiv erscheint oder wo sie von allen gewollt wird.

Das wirft aber weitere Fragen auf: sind diese verschiedenen Kulturen überhaupt miteinander kompatibel? Wiedersprechen sie nicht ggf. sogar in ihren Grundannahmen und Werten? Ist es auf dieser Basis überhaupt möglich, eine gemeinsame (Firmen-)Identität zu schaffen und sich auf gemeinsame Ziele zu einigen? Oder muss man nicht befürchten, dass die verschiedenen kulturellen Gruppen eher gegeneinander als miteinander arbeiten? Alles berechtigte Punkte.

Die gute Nachricht an dieser Stelle ist, dass es bereits seit langem eine umfangreiche wissenschaftliche Beschäftigung mit diesem Thema gibt, nämlich in der Soziologie, genauer gesagt in der Kultursoziologie. Zwar beschäftigt die sich eher mit Gesellschaften als Unternehmen, die Ergebnisse sind aber übertragbar. Bekannte Forscher sind hier Milton M. Gordon, John Rex oder Alf Mintzel (der in seinem Buch Multikulturelle Gesellschaften in Europa und Nordamerika eine gute Übersicht über das Thema gibt).

Das (vereinfachte) Ergebnis dieser Forschungen ist, dass Menschen in der Lage sind, in multikulturellen Umgebungen ihre Kultur temporär zu wechseln. In der Gesellschaft könnte dieser Wechsel z.B. zwischen Familie und Beruf stattfinden, in einem Unternehmen z.B. zwischen Projekt und Linie. In beiden Umfeldern werden dabei jeweils (bewusst oder unbewusst) die Verhaltensmuster an den Tag gelegt, von denen angenommen wird, dass sie in der jeweiligen Situation Kultur-konform sind.

Natürlich sind mit dieser Art von Multikultur Risiken verbunden. Zum einen kann es beim Aufeinandertreffen der jeweiligen kulturellen Gruppen für den, der zwischen ihnen wechselt, zu Rollenkonflikten kommen (zu wem verhält man sich jetzt kompatibel?), zum anderen sind während der temporären Zugehörigkeit zur einen Gruppe die Anliegen der anderen Gruppe nicht mehr so einfach zu erklären, ohne aus der Rolle zu fallen (die Folge ist der so genannte Kontext-Kollaps).

Um derartige Missverständnisse und daraus folgende potentielle Konflikte zu entschärfen, neigen multikulturelle Gesellschften (bzw. Unternehmen) dazu, selbstorganisiert jeweils zwei Varianten jeder einzelnen ihrer Teil-Kulturen herauszubilden: die primäre, die nur innerhalb der jeweils gleichartig ausgeprägten Gruppen ausgelebt wird, und die sekundäre, die dort ausgelebt wird, wo sich der Wirkungs- und Wahrnehmungsraum verschiedener kultureller Gruppen überschneiden.

Dabei kann es dazu kommen, dass die von den verschiedenen Einzelgruppen herausgebildeten Sekundär-Kulturen sich so ähnlich sind, dass sie sie kaum noch unterscheiden lassen. In einer Betrachtung von aussen kann dadurch der Eindruck entstehen, dass es doch eine gemeinsame, einheitliche Unternehmenskultur gäbe. Da diese Annahmen die parallel existierenden Primär-Kulturen nicht beachten, halten sie einer näheren Betrachtung aber kaum stand.

PS:

Die hier genannte Unternehmens-Multikultur ist übrigens nicht zu verwechseln mit dem in grossen Unternehmen häufigen Zusammenarbeiten verschiedener Nationalitäten oder Ethnien. Es gibt zwar Überschneidungen, aber trotzdem ist es nochmal ein eigenes Thema, zu dem es eine eigene wissenschaftliche Forschung gibt.