Der grundlegende Fehler des SW-Engineering

Vor dem Aufkommen der Massenproduktion im zwanzigsten Jahrhundert waren die meisten Arbeitsplätze kleine Unternehmen, die nach ihren eigenen Faustregeln Maßarbeit leisteten. Dieser Ansatz bedeutete, dass die Arbeit teuer, unvorhersehbar und nur in kleinen Mengen erledigt werden konnte. Eine andere Methode war erforderlich, als sich die Art der Arbeit in große Produktionszentren verlagerte und die moderne Massenproduktion ernsthaft begann. Mit dieser Verschiebung ging eine andere Denkweise einher (die grundlegende Fehler erläutern wir hier), die den Fokus auf die Organisation für maximale Effizienz verlagerte, weil der Umfang der Arbeit so viel größer war.

Hier kommt Frederick Taylor und seine Prinzipien des wissenschaftlichen Managements ins Spiel. Taylor nutzte Zeit- und Bewegungsstudien, um die effizientesten Mittel zur Herstellung von Arbeitsergebnissen zu ermitteln, was er als wissenschaftliches Management bezeichnete. Vorbei waren die Faustregeln, und an ihre Stelle trat eine Managementklasse, die angeblich besser ausgebildet und aufgeklärter darüber war, wie die Arbeit erledigt werden sollte. Unter Verwendung von Taylors wissenschaftlichen Prinzipien erhielten die Arbeiter Anweisungskarten, auf denen genau beschrieben war, wie die Arbeit ausgeführt werden sollte und wie lange sie dauern sollte.

Obwohl es unklug war, den Input der Arbeiter darüber, wie sie ihre Arbeit am besten zu erledigen haben, abzulehnen, waren Taylors Methoden unbestreitbar transformativ. Die Produktivität stieg dramatisch, und die Gewinne folgten. Was hat diese Methoden so erfolgreich gemacht? Es war vor allem die Art der Fertigungsarbeit während der Epoche, die durch folgende Attribute gekennzeichnet war.

Aufgaben können in einfache, sich wiederholende und messbare Schritte unterteilt werden.
Der Wandel war langsam und vorhersehbar.
Die Informationen flossen langsam und meist lokal.
Es war selten notwendig, eine neue Art und Weise zu finden, etwas zu tun, wenn eine effiziente Methode gefunden war.
Der Wettbewerb fand hauptsächlich lokal in der Region oder Nation statt und wurde durch kapitalintensive Barrieren eingeschränkt.

Betrachten Sie im Gegensatz dazu die Attribute der Softwarearbeit.

Die Arbeit ist komplex und lässt sich nur schwer auf einfache Schritte reduzieren.
Der Wandel ist konstant, und sein Tempo beschleunigt sich.
Informationen fließen sofort rund um die Welt.
Der Wettbewerb ist hart und weltweit, und die Eintrittsbarriere ist niedrig.
Unsere Umgebung kann sich über Nacht mit einem einzigen Social-Media-Beitrag verändern.

Um das Offensichtliche zu sagen: Taylors Arbeitsattribute definieren eine vergangene Ära, die nicht mehr existiert. Dennoch verwenden wir immer noch seine Methoden, um unsere Softwarearbeit zu organisieren, und sind so tief in sie vertieft, dass wir ihre Allgegenwart nicht bemerken. Wie wir weiter unten sehen werden, wird diese Denkweise in der Softwareentwicklung zutiefst falsch angewendet. Es ist längst an der Zeit, sich von der Antike zu verabschieden und zu überdenken, wie wir unsere Bemühungen organisieren.

Aber warum stecken wir in der Vergangenheit fest? Um diese Frage zu beantworten, müssen wir uns zunächst mit dem Wesen des Software-Engineerings befassen.

Das Wesen der Software-Entwicklung

Die Vielschichtigkeit des Software-Engineerings ermöglicht es, es aus unterschiedlichen Perspektiven zu betrachten, die jeweils eine bestimmte Neigung haben. In diesem Abschnitt werden einige von ihnen untersucht und eine Sicht auf unsere Branche zusammengestellt, die wir bisher vielleicht nicht in Betracht gezogen haben.

Das Cynefin-Rahmenwerk

Eine Möglichkeit, die Natur des Software-Engineerings zu verstehen, ist die Verwendung des Cynefin Frameworks, eines Leitfadens für die Entscheidungsfindung. Das Framework ist in fünf Bereiche unterteilt, von denen jeder seinen eigenen Entscheidungsprozess hat. Die Domains gliedern sich wie folgt.

Klar

Im Clear-Bereich sind Ursache und Wirkung leicht zu erfassen, und das Ergreifen einer Handlung führt zu einem vorhersehbaren Ergebnis. Die Arbeit ist in der Regel standardisiert, so dass „Best Practices“ erstellt werden können, mit denen verlässliche Ergebnisse generiert werden können. In diesem Bereich spüren wir die Fakten unserer Situation, kategorisieren sie nach Regeln und reagieren dann mit den entsprechenden Best Practices.

Kompliziert

Im komplizierten Bereich können Ursache und Wirkung immer noch verstanden werden, aber es erfordert eine Analyse durch geschulte Experten, die ein gutes Urteilsvermögen ausüben. Best Practices werden durch „Good Practices“ ersetzt, die sich ändern können. Hier müssen wir zunächst die Situation spüren, um die Fakten zu ermitteln, die Ergebnisse zu analysieren und mit den entsprechenden bewährten Verfahren zu reagieren.

Komplex

Im komplexen Bereich sind Ursache und Wirkung unklar und können erst im Nachhinein bestimmt werden. Es gibt keine offensichtlichen „besten“ Antworten, aber viele mögliche Ideen könnten funktionieren. Hier müssen wir zunächst durch Experimente sondieren, die Ergebnisse spüren und mit Maßnahmen reagieren, von denen wir glauben, dass sie zu positiven Ergebnissen führen werden. Dieser Bereich liegt genau im Bereich der „unbekannten Unbekannten“. Das heißt, wir wissen nicht, was wir nicht wissen. Änderungen in einem Teil des Systems führen zu unvorhersehbaren, nichtlinearen Änderungen in anderen Bereichen. Es gibt keine Best Practices, aber mit der Zeit werden sich nützliche Praktiken herausbilden. Anstatt einen Aktionsplan zu erzwingen, müssen wir geduldig zulassen, dass der Weg nach vorn durch Emergenz und Iteration enthüllt wird.

Chaotisch

Im chaotischen Bereich können Ursache und Wirkung nicht bestimmt werden. Die Ereignisse sind unkontrolliert und chaotisch. Der einzige Weg nach vorn besteht darin, schnell zu handeln, wie auch immer. Wir müssen zuerst handeln, das Ergebnis spüren und dann mit weiteren Maßnahmen reagieren, die angemessen erscheinen, und versuchen, Ordnung in das Chaos um uns herum zu bringen. Ziel ist es, die Situation schließlich in die Domäne „Komplex“ zu migrieren.

Verwechslung

Die Confusion-Domain befindet sich in der Mitte aller anderen. Hier ist nicht klar, in welchem Bereich unsere Umwelt liegt. Unterschiedliche Fraktionen ringen um die Macht, und die Menschen streiten miteinander. Der einzige Ausweg besteht darin, die Probleme in Teile zu zerlegen und jedem einen anderen Bereich zuzuweisen, um dann entsprechend dem Diktat der jeweiligen Domänen zu reagieren.

Der Bereich Software-Engineering

Einige unserer Software-Engineering-Arbeiten liegen in den Bereichen Clear oder Complicated. Wir haben diese Aufgaben schon einmal erledigt und verfügen über Best Practices dafür. Ein Beispiel in der Clear-Domain ist das Ändern des Textes auf einer Schaltfläche oder das Aktualisieren von Daten für eine Website, auf der Umsatzsteuersätze angezeigt werden. Ein Beispiel für die komplizierte Domäne wäre das Hinzufügen einer Schnittstelle zu einem externen Dienst, in dem wir bereits viele andere verwenden. Diese Schnittstellenarbeit ist schwierig, aber wir haben sie schon einmal gemacht, und sie erfordert nur eine sorgfältige Ausführung von Experten. Gelegentlich fällt unsere Arbeit in den chaotischen Bereich. Ein gutes Beispiel ist, wenn unsere abonnementbasierte Software unerwartet offline geht und eine große Anzahl zahlender Benutzer daran gehindert wird, ihre Arbeit zu erledigen.

Wir arbeiten jedoch am häufigsten im komplexen Bereich, in dem unsere Arbeit empirisch, nicht-deterministisch und emergent ist. Um einen Weg nach vorne zu finden, müssen wir mit sicheren Experimenten experimentieren, die Ergebnisse erspüren und mit weiteren Experimenten reagieren, um einen Weg zu beleuchten. Wir müssen geduldig und iterativ vorgehen. Unsere Lösungen sollten durch Experimente entdeckt werden, anstatt von oben aufgezwungen zu werden.

Selbst wenn wir denken, dass wir uns in einem bestimmten Quadranten befinden, können wir es oft nicht wissen, bis wir die Arbeit beendet haben. Schlimmer noch, die Grenzen zwischen den Quadranten sind verschwommen und fließend. Zum Beispiel kann unsere Arbeit zwischen kompliziert und komplex wechseln, ohne dass wir es merken. Diese Unsicherheit macht vorausschauende, planungsbasierte Ansätze frustrierend fehleranfällig.

Komplexe adaptive Systeme

Ein komplexes adaptives System besteht aus mehreren Teilen, die dynamisch und auf unvorhersehbare und nichtlineare Weise miteinander interagieren. Es gibt keinen einzelnen Teil, der das gesamte System steuert, was die Wechselwirkungen zwischen den Teilen schwer vorherzusagen und zu kontrollieren macht. Jeder Teil wird von den Handlungen der anderen beeinflusst und passt sich unvorhersehbar an diese an. Die Identifizierung von Ursache und Wirkung in solchen Systemen ist eine Übung in Sinnlosigkeit, da eine gegebene Ursache eine Auswirkung haben kann, die zufällig nicht vorhanden, gering oder tiefgreifend ist, und es fast unmöglich ist, vorherzusagen, welche es sein wird. Beispiele für komplexe adaptive Systeme sind Wirtschaftsmärkte, Wetter, Natur und Softwareentwicklung.

Warum sollten wir Softwareentwicklung als komplexes adaptives System betrachten? Weil es aus komplexen, mehreren Agenten besteht, die dynamisch und auf autonome, unvorhersehbare Weise miteinander interagieren. Bei diesen Agenten kann es sich um Kunden, Regulierungsbehörden, Programmierer, Code, Märkte, Anforderungen oder jede andere Entität handeln, die das System beeinflusst. Jeder Agent passt sich den Handlungen anderer Agenten an, und jede Anpassung führt zu weiteren Runden von Anpassungen in einer fortwährenden Reiz-Reaktions-Schleife. Darüber hinaus sind Systemänderungen nichtlinear, und das Ausmaß ihrer Auswirkungen kann nicht geschätzt werden. Schließlich hängen die Ergebnisse stark von den Anfangsbedingungen ab, die selten ausreichend detailliert bekannt sind, um zukünftige Reaktionen vorherzusagen.

Im Gegensatz zu leicht modellierbaren, einfachen Systemen, wie z. B. Fließbändern in der Fertigung, entzieht sich die Vernetzung komplexer adaptiver Systeme einer Vorhersage. Es ist fast unmöglich, sich vorzustellen, wie sie darauf reagieren und sich weiterentwickeln werden. Einfach ausgedrückt: Softwareentwicklung wird niemals ein einfaches, vorhersehbares Unterfangen sein, egal wie sehr wir es sonst bevorzugen mögen. Es ist fest im komplexen, adaptiven Bereich verankert.

In Klammern gesagt, ist einer der ärgerlichsten Aspekte eines komplexen adaptiven Systems, dass die Fähigkeit, einen Teil des Systems vorherzusagen, nicht bedeutet, dass wir das gesamte System vorhersagen können. Wir sehen diese Dynamik häufig, wenn wir Softwareprojekte in Aufgaben und Teilaufgaben zerlegen, jede einzelne schätzen und die einzelnen Schätzungen kombinieren, um zu einer Gesamtschätzung zu gelangen. Selbst wenn wir das Glück haben, einige der einzelnen Aufgaben genau zu schätzen, schlägt die kombinierte Schätzung leider in der Regel fehl, oft spektakulär. Es ist verlockend, den Schätzern einen Mangel an Geschicklichkeit vorzuwerfen, wenn dies geschieht, aber es ist eine unausweichliche Eigenschaft komplexer adaptiver Systeme. Egal, wie oft wir versuchen, unsere Schätzungen zu verbessern, wir können der Unvorhersehbarkeit dieser Art von Systemen nie entkommen. Sie trotzen den Vorhersagen. Die Frage, die wir uns vielleicht stellen, ist, warum wir weiterhin etwas anderes glauben.

Fertigung vs. Softwareentwicklung

Der Glaube an den Fertigungsansatz führt dazu, dass Softwareunternehmen ihre Mitarbeiter für Effizienz und Ausführung organisieren und die Arbeit in Fachgebiete aufteilen, wobei jedes Fachgebiet eine separate Abteilung hat. So gibt es beispielsweise Abteilungen für Produktmanagement, Entwicklung, Datenbank, QA und DevOps. Abteilungsleiter überwachen die Arbeit und stellen sicher, dass sie planmäßig erledigt wird und jeder voll ausgelastet ist, um die Effizienz zu maximieren. Wenn jeder Spezialist seine Arbeit erledigt hat, bewegt sich das Produkt wie am Fließband zum nächsten Spezialisten in der Linie, der seine Arbeit erledigt, sie an den nächsten weitergibt und so weiter. Jeder Spezialist verleiht dem Artikel Form und Gestalt, bis er am Ende der Linie als vollwertiges Arbeitsprodukt für den Kunden hervorgeht. Es ist ein intuitiver, unkomplizierter Prozess, der leicht zu organisieren ist. Leider ist es nicht sehr effektiv.

Es ist natürlich, sich zu fragen, warum Taylors Methoden in der Fertigung effektiv waren, aber immer wieder enttäuschende Ergebnisse liefern, wenn wir sie auf die Softwareentwicklung anwenden. Es scheint so sinnvoll, dass der gleiche grundlegende Ansatz für jede Art von Fertigungsvorhaben funktionieren sollte, egal ob es sich um ein physisches Produkt oder die Nullen und Einsen von Software handelt. Warum sehen wir also nicht den Erfolg, den Taylor hatte?

Denn Software ist nicht dasselbe wie Fertigung. Anders als in der Fertigung ist dieses Wissen, anders als in der Fertigung, für die nächste Aufgabe von geringem Nutzen, wenn wir erst einmal herausgefunden haben, wie man etwas macht, weil es sich von der vorherigen unterscheidet. Taylor musste sich nie unserem hartnäckigen und hartnäckigen Problem stellen:

In der Softwareentwicklung machen wir nie immer wieder dasselbe.

Stattdessen ist jede Aufgabe, die wir übernehmen, anders als die letzte. Wenn die Aufgaben die gleichen wären, würden wir einfach unsere Softwarekenntnisse nutzen, um den Prozess zu automatisieren. Ganz gleich, wie sehr sich die neue Aufgabe auf die der Vergangenheit reimen mag, sie sind nie dieselben, was bedeutet, dass wir ständig innovativ sein müssen.

Wenn es nur so einfach wäre, herauszufinden, wie man eine Aufgabe erledigt und sie dann immer wieder macht, wie in der Fertigung. Wenn die Arbeit nur deterministisch wäre und das Tempo des Wandels langsam wäre, wie es bei Taylor der Fall war. Leider funktioniert es bei uns einfach nicht so. Betrachten Sie, wie Harvard-Professorin Amy Edmondson die Ära Taylor beschreibt, und vergleichen Sie sie dann mit unserer schnelllebigen, unsicheren, modernen Softwarewelt:

„Mit Perioden der Stabilität konnte man rechnen. Produkte, Prozesse und sogar Kunden waren gnädigerweise einheitlich, so dass keine Improvisation in Echtzeit erforderlich war, um auf unerwartete Probleme, technologische Veränderungen oder Kundenbedürfnisse zu reagieren.“
Amy Edmondson

So unangenehm es auch sein mag, dies zu akzeptieren, Softwareentwicklung ist Wissensarbeit, und Wissensarbeit spiegelt komplexe, unvorhersehbare Prozesse wider, nicht die vorhersehbaren, denen Taylor begegnet ist. Für uns ist es jedes Mal etwas Neues. Massenproduktionsmethoden gelten für uns einfach nicht.

Unser fehlerhafter mentaler Rahmen

Was ist der Grund für unsere lange Geschichte der Organisation unserer Software-Abteilungen, als würden wir repetitive Fertigungsarbeiten ausführen? Gewohnheit und unkritisches Denken vielleicht, was zu einem fehlerhaften mentalen Rahmen führt.

Wir gehen davon aus, dass wir in einer geordneten und vorhersehbaren Welt agieren und dass jede Unsicherheit durch angemessene Planung und Aufsicht kontrolliert werden kann. Diese Überzeugung ist die Grundlage unserer Pläne und Managementstrukturen. Wenn unser Geschäftsbereich vorhersehbar ist, so die Überlegung, können wir Befehls- und Kontrollsysteme entwickeln, die planbare, konsistente und vorhersehbare Ergebnisse liefern.

Im Kern werden unsere Misserfolge durch unsere Unfähigkeit verursacht, die mathematischen Grundlagen von Wissensarbeit und Innovation zu begreifen. Wir sind uns nicht bewusst, dass wir fälschlicherweise davon ausgehen, dass nichtdeterministische, stochastische Prozesse so geplant und vorhergesagt werden können, als wären sie deterministisch und linear.

Ob wir uns dessen bewusst sind oder nicht, wir verschreiben uns im Wesentlichen der Idee eines Uhrwerk-Universums, das allgemein als Laplace’s Demon bekannt ist. Laplace glaubte, dass, wenn ein allwissendes, intelligentes Wesen (ein „Dämon“) die Anfangsbedingungen eines Systems perfekt kenne, es dann den Ausgang aller Ereignisse weit in die Zukunft vorhersagen könne. Es war eine vollkommen deterministische Sicht des Universums.

Wir treffen unwissentlich ähnliche Annahmen, wenn wir das Ergebnis unserer Softwarebemühungen vorhersagen – in der Regel Kosten und Fertigstellungstermine. Wir glauben, dass unsere Unternehmen komplizierte Maschinen wie Laplace’s Demon sind, die mit der richtigen Aufsicht gesteuert werden können und dass dies zu vorhersehbaren Ergebnissen führt.

Unsere Arbeit wäre so viel einfacher, wenn dieser Ansatz funktionieren würde, aber leider tut er es nicht. Zufälligkeit und winzige Unvollkommenheiten in unserem Wissen über die Anfangsbedingungen dringen in unser perfektes Modell ein und führen im Laufe der Zeit zu völlig unterschiedlichen Ergebnissen. In Wirklichkeit sind wir kaum in der Lage zu verstehen, was heute passiert, und wir verstehen schon gar nicht, was in der Zukunft passieren wird. Wenn wir etwas anderes glauben, deutet dies auf einen Mangel an Bewusstsein für die grundlegende Natur unserer Arbeit hin.

Unser mentaler Rahmen aus vorhersehbaren Systemen gilt einfach nicht für unsere Arbeit, egal wie sehr wir es uns wünschen und wie sehr wir versuchen, es passend zu machen. Das ist die grundlegende Diskrepanz in der Softwareentwicklung. Wir handhaben es, als wäre es deterministisch, aber die Realität ist, dass es nicht-deterministisch und empirisch ist, fest verankert im Bereich des Komplexen.

„Unsere tröstliche Überzeugung, dass die Welt einen Sinn ergibt, ruht auf einem sicheren Fundament: unserer fast unbegrenzten Fähigkeit, unsere Unwissenheit zu ignorieren.“
Daniel Kahneman

Fallstricke der Organisation für die Antike

Es gibt so viele Fallstricke bei der Organisation für die Antike, wie es Organisationen gibt, und jede wird ihre einzigartige Vielfalt offenbaren. Dennoch gibt es breite Klassen, die in der gesamten Landschaft verbreitet sind. In diesem Abschnitt werden einige dieser häufigen Probleme beschrieben.

Silos

Wie oben beschrieben, ist es üblich, dass Softwaremitarbeiter in separaten Abteilungssilos für Produktmanagement, Entwicklung, Datenbank, QA und DevOps organisiert sind. Diese Beispiele sind nur eine unvollständige Liste, und ein kurzer Blick darüber liefert viele weitere. Diese Trennung ist sinnvoll, wenn wir uns rein auf Effizienz konzentrieren, aber sie gerät ins Stocken, wenn wir wollen, dass die Arbeit kontinuierlich in Richtung Kunde fließt.

Das Problem ist, dass die Trennung der Mitarbeiter in Silos dazu führt, dass Informationen, Zusammenarbeit, Lernen und Arbeitselemente in den Grenzbereichen zwischen den Silos verbleiben. Wissenstransfer und Lernen werden gedrosselt, was bedeutet, dass Lösungen, die in einer Abteilung abgeleitet wurden, in anderen mit erheblichen Kosten neu erfunden werden müssen. Anstatt sich schnell durch das System zu bewegen, bewegen sich Arbeitsprodukte in Schüben und warten auf die Genehmigung von Managern und die Bandbreite anderer Teams. Wir steigern die Effizienz in jedem Silo, indem wir alle beschäftigen, aber wir sehen nicht die enorme Kostenbelastung, die dadurch entsteht, dass Teams voneinander isoliert sind.

Eine Anekdote: Ich habe einmal in einem Unternehmen gearbeitet, dessen Manager sich häufig über „zu viele Silos hier“ beschwerten und diejenigen, die in den Silos lebten, dafür kritisierten, dass sie nicht in andere Silos griffen, um Informationen auszutauschen. Die Manager schienen nie zu begreifen, dass es nicht die Schuld der Arbeiter war. Stattdessen war es die Schuld des Systems, das explizit auf isolierten Silos ausgelegt war und dadurch die Menschen trennte, die hätten zusammenarbeiten sollen.

Warteschlangen

Die Trennung der Mitarbeiter in isolierte Abteilungen bedeutet unweigerlich, dass sich Warteschlangen zwischen ihnen bilden, während Arbeitselemente darauf warten, von einem Silo zum nächsten verschoben zu werden. Warteschlangen sind schockierend allgegenwärtig, unsichtbar und werden an den meisten Arbeitsplätzen nicht verwaltet. Sie sind auch wirtschaftlich schädlich. Wie viel? In seinem Buch „The Principles of Product Development Flow“ stellt Donald Reinertsen fest:

„Unsichtbare und nicht verwaltete Warteschlangen sind die Hauptursache für eine schlechte wirtschaftliche Leistung in der Produktentwicklung.“
Donald Reinertsen

Warteschlangen führen zu längeren Lieferzeiten, erhöhtem Risiko, geringerer Qualität und schlechter Moral. Sie verzögern auch wichtiges Feedback zu unserer Arbeit bis lange, nachdem wir ihren intellektuellen Kontext verloren haben, und verlangen von uns, Zeit und Geld in die Wiederherstellung zu investieren, wenn wir aufgefordert werden, die Arbeit erneut zu überdenken. Darüber hinaus bedeutet dieses späte Feedback, dass wir Zeit und Geld damit verschwenden, fruchtlose Wege zu verfolgen, bevor wir einen besseren Weg finden.

Es mag überraschend sein, dass die schlechte wirtschaftliche Leistung nicht durch das verursacht wird, was die meisten Unternehmen vermuten, wie z. B. untätige Mitarbeiter, überhöhte Gehälter, die Einhaltung gesetzlicher Vorschriften oder eine Vielzahl anderer Kosten. Stattdessen ist es ein direktes Ergebnis der Art und Weise, wie sie sich organisiert haben, und etwas, über das sie die vollständige Kontrolle haben.

Der beliebte Kinderbuchautor Dr. Suess beschrieb in seinem Buch Oh, the Places You’ll Go! unwissentlich organisatorische Warteschlangen. Ersetzen Sie einfach „Menschen“ und „Jeder“ durch das Wort „alles“:

ich fürchte, auf einen höchst nutzlosen Ort zusteuerte.
Der Warteplatz…
… für Leute, die nur warten.
Warten darauf, dass ein Zug fährt
oder ein Bus kommt, oder ein Flugzeug, das geht
, oder die Post, die kommt, oder der Regen, der geht
, oder das Telefon, das klingelt, oder der Schnee, der schneit
, oder das Warten auf ein Ja oder Nein
oder das Warten, bis ihre Haare wachsen.
Alle warten nur.

Inventar

In der Softwareentwicklung kann Inventar als jeder Gegenstand definiert werden, bei dem nachgedacht wurde und der Gegenstand gelagert wird, während er auf weitere Arbeit wartet. Beispiele hierfür sind User Storys, die sich in einem Backlog befinden, und nicht bereitgestellter Code, der sich in einem Repository befindet. Eng mit Warteschlangen gekoppelt, ist das Inventar das unvermeidliche Nebenprodukt der Trennung von Arbeitern in Silos.

In Software-Engineering-Kreisen berücksichtigen wir den Bestand selten, weil er auf einem Computer versteckt ist und sich nicht wie in der Fertigung in der Fertigung stapelt. Sein Mangel an physischer Präsenz bedeutet, dass er zu oft „aus den Augen, aus dem Sinn“ ist.

Was ist also falsch an der Lagerbestände? Schließlich wird der Lagerbestand in produzierenden Unternehmen als Vermögenswert in der Bilanz betrachtet. Es kann jedoch argumentiert werden, dass in Softwareorganisationen das Inventar eine Belastung ist, die Verwaltungskosten verursacht, bis es zu einer bereitgestellten Software wird, die Einnahmen generiert, und dann in einen Vermögenswert umgewandelt wird. In den Prinzipien des Lean Manufacturing wird der Bestand als Abfall eingestuft. Darüber hinaus nimmt der Nutzen des Inventars mit der Zeit ab, da sich die Märkte verschieben und unsere Arbeit nicht mehr belohnen können, wenn es schließlich bereitgestellt wird. Mit dieser Sichtweise ist es leicht zu erkennen, dass der Lagerbestand etwas Teures ist, das wir minimieren sollten.

Bürokratie

Sobald die Mitarbeiter in Abteilungen organisiert sind, werden Manager für jede Abteilung als notwendig erachtet. Jeder Manager muss dann seinem Vorgesetzten berichten, dass seine jeweiligen Abteilungen voll ausgelastet sind und seine Mitarbeiter immer bei der Arbeit sind. Bald folgen Statusberichte und andere Hemmnisse einer festgefahrenen Bürokratie. Darüber hinaus erstellen separate Abteilungen unweigerlich Übergabeartefakte, um zu beweisen, dass jede Abteilung ihre Arbeit angemessen erledigt hat und dass die Abteilung nicht beschuldigt werden kann, wenn etwas schief geht.

All dieser „Beweis der Geschäftigkeit“ trägt wenig dazu bei, die Interessen der Kunden zu fördern, und dient vor allem dazu, die Anwesenheit der Bürokratie zu rechtfertigen. Die Dokumentation und die Checklisten validieren die Arbeit, aber sie bestimmen nicht, ob wir nützliche Software entwickeln, sondern nur, dass wir hart arbeiten und uns gleichzeitig Zeit nehmen, um genau die Software zu entwickeln, die unsere Kunden wollen. Es ist eine sichere Wette, dass Kunden wenig oder gar keinen Wert aus Statusberichten und anderen bürokratischen Ausgaben ziehen.

Ein noch schädlicheres Problem besteht darin, dass eine Bürokratie, wie klein und unbedeutend sie anfangs noch sein mag, bald zu einem lebendigen Organismus wird, der versucht, ihre Reichweite und Dauer zu vergrößern. Welche positiven Werte sie auch bieten mag, diese sind oft der Aufrechterhaltung ihrer Existenz untergeordnet.

Ein weiterer Nachteil bürokratisierter Systeme ist ihre negative Wirkung auf Moral und Initiative. Die Arbeiter, die durch restriktive Verfahren und Genehmigungsverfahren gelähmt sind, werden nach und nach durch bürokratische Hürden zermürbt. Ihre Moral und Eigeninitiative leiden darunter, was die Zukunft des Unternehmens gefährdet. Viele Arbeiter erliegen schließlich der erlernten Gleichgültigkeit und bemühen sich einfach, „den Kopf gesenkt und den Mund zu halten“. Dieses Ergebnis ist kaum ein Rezept für langfristigen organisatorischen Erfolg angesichts hungriger Wettbewerber.

Wenn die Bürokratie nicht kontrolliert wird, verdrängt sie schließlich Innovation, unabhängiges Denken und die Freude an der Problemlösung. Alles ist standardisiert, um den Regelmachern zu dienen, deren Macht allzu oft absolut ist. Es ist leicht, sich selbst davon zu überzeugen, dass dieser Ansatz die Arbeit vorhersehbarer und einfacher zu messen macht. Das ist unwahrscheinlich, aber eines ist es nicht: Unsere Arbeit ist letztlich weniger befriedigend und weniger offen für Innovationen, die den Marktfortschritt und die Kundenzufriedenheit vorantreiben.

Planen und Vorhersagen

Ein Teil der Organisation für die Antike besteht darin, zu glauben, dass unsere Arbeit vorhersehbar und planbar ist. Wie oben erwähnt, ist das bei der komplexen Arbeit, die wir in der Softwareentwicklung finden, einfach nicht möglich.

Wir können nie im Voraus wissen, ob die nächste Aufgabe schwer oder leicht wird. Viel zu oft denken wir, dass wir den schwierigen Teil geschafft haben, und der nächste Teil wird einfach sein, nur um festzustellen, dass er es nicht ist. Es ist sehr wahrscheinlich, dass der schwierigste Teil das sein wird, was als nächstes kommt, und wenn das abgeschlossen ist, wird auch der nächste Teil schwierig, wenn nicht sogar noch schwieriger sein.

Überlegen Sie, wie viele Projekte, die zu 90 % abgeschlossen sind, weitere 90 % ihrer Zeit benötigen, um die letzten 10 % abzuschließen. Das liegt in der Natur komplexer Systeme. Wie schwierig und zeitaufwändig etwas sein wird, können wir erst feststellen, wenn wir es abgeschlossen haben. Kurz gesagt, Gewissheit findet man erst im Nachhinein. Vorausschau ist nur zufälliges Raten.

Der Nachteil der Planung und Vorhersage ist, dass wir unsere begrenzte Zeit mit verschwenderischen Praktiken verbringen. Es wäre viel produktiver, diese Zeit damit zu verbringen, wertvolle Software zu entwickeln und unsere Fähigkeiten dafür zu verbessern.

Verzögertes Feedback

Wenn wir nach Abteilungen und Fachgebieten organisiert sind, schaffen wir versehentlich Barrieren in unserem Arbeitsablauf, die uns daran hindern, den Durchsatz unserer Arbeit zu maximieren. In der Tat dauert es viel länger, als es sollte, um Marktfeedback zu erhalten, um zu sehen, ob wir auf dem richtigen Weg sind oder ob wir in die Irre gehen.

Schnelles Feedback bietet einen starken wirtschaftlichen Hebel. Nur wenige Unternehmen nutzen dies, möglicherweise weil sie einfach nicht dafür organisiert sind. Stattdessen bewegen sich ihre Arbeitsergebnisse träge durch ein System, das auf Effizienz statt auf Effektivität ausgelegt ist, was ihre Fähigkeit behindert, zu erkennen, ob sie auf dem richtigen Weg sind, und sofort umzuschwenken, wenn dies nicht der Fall ist. Unternehmen, die dies nicht erkennen, werden einen Wettbewerbsnachteil haben.

Innovation im Keim ersticken

Einer der unvermeidlichen Nachteile der Anwendung einer Fließband-Denkweise auf die Software-Engineering-Arbeit besteht darin, dass wir in der Regel keine Zeit für Innovationen lassen. Nehmen wir an, wir glauben, dass wir wie ein Fließband mit jedem Widget, das wir herstellen, Geld verdienen. In diesem Fall ist die natürliche Schlussfolgerung, so viele Widgets wie möglich zu produzieren, um den Gewinn zu maximieren. In der Tat werden wir zu einer Feature-Factory, die sich wenig um die Innovation kümmert, die das langfristige Überleben vorantreibt.

Wenn wir außerdem Taylors Mantra übernehmen, die Arbeiter zu überwachen, um das Beste aus ihnen herauszuholen, berauben wir sie ihrer Initiative, ihrer Freiheit zum Experimentieren und zur Anpassung sowie ihrer Bereitschaft, sich mit anderen zusammenzuschließen, um Probleme zu lösen, die nicht durch unabhängiges Arbeiten gelöst werden können. Stattdessen sollten wir ein Gleichgewicht zwischen der Beibehaltung bestehender Produkte und der Innovation neuer Produkte finden.

“… Die Management-Denkweise, die eine effiziente Umsetzung ermöglicht, hemmt tatsächlich die Lern- und Innovationsfähigkeit eines Unternehmens. Der enge Fokus darauf, Dinge zu erledigen, behindert das Experimentieren und Reflektieren, die für einen nachhaltigen Erfolg unerlässlich sind.“
Amy Edmondson

Dieser „enge Fokus darauf, Dinge zu erledigen“ durch das Festhalten an Fließbandprozessen führt dazu, dass wir die langfristigen Folgen unseres kurzfristigen Denkens oft nicht berücksichtigen. Ein solches Versehen führt zu einer stetigen Anhäufung von technischen Schulden, aufgeblähter Software, fragilen Codebasen und anderen Problemen, die Innovationen unnötig erschweren.

Eine Anekdote: Ich habe einmal in einem Team gearbeitet, in dem ein leitender Angestellter einen seiner Manager mir gegenüber lobte und bewundernd sagte: „Er erledigt die Dinge.“ Angesichts der Tatsache, dass der Manager dazu neigte, kurzfristige Entscheidungen zu treffen, die mit erheblichen langfristigen Kosten verbunden waren, ließ ich meine offensichtliche Erwiderung unausgesprochen: „Vielleicht wäre es besser, wenn es die richtigen Dinge wären, anstatt die richtigen Dinge.“ Erst Jahre später wurde mir klar, dass es ein Beispiel dafür war, wie man sich so sehr auf die Gegenwart konzentrierte, dass es langfristige Innovationen erstickte.

Die Fähigkeitsfalle

Es gibt eine grausame, sich selbst verstärkende Schleife bei der Organisation für die Antike. Per Definition ist diese Schleife fast unmöglich zu sehen, wenn wir darin gefangen sind, so dass es unwahrscheinlich ist, dass wir uns selbst herausziehen. Es funktioniert so: Wenn wir uns darauf konzentrieren, das Fließband in Bewegung zu halten, haben wir keine Zeit, einen Schritt zurückzutreten, die Ursache häufiger Probleme zu finden und Verbesserungen vorzunehmen, um sie zu lindern. In der Tat sind wir so mit der Brandbekämpfung beschäftigt, dass wir keine Zeit haben, das Unterholz zu beseitigen, das die ganze Brandbekämpfung verursacht. Dieser Ansatz bedeutet in der Regel, dass wir zu beschäftigt sind für zeitsparende Aktivitäten wie das Refactoring von unübersichtlichem Code, das Schreiben von Komponententests, die das Ändern von Code sicherer machen, oder die Automatisierung unseres Build- und Bereitstellungsprozesses.

Dieses Phänomen ist in allen menschlichen Systemen so verbreitet, dass es einen Namen dafür gibt: Die Fähigkeitsfalle. Wenn wir für die Antike organisiert sind, bleibt selten Zeit, unsere Fähigkeiten zu verbessern. Das Ergebnis ist, dass es immer schwieriger wird, unsere Arbeit zu erledigen, und wir gezwungen sind, Überstunden zu machen, um mit der Nachfrage Schritt zu halten. Diese Überstunden verschlimmern das Problem nur, weil erschöpfte Arbeiter anfällig für Fehler sind, und die Behebung der Fehler bedeutet, dass noch weniger Zeit bleibt, um die Dinge zu verbessern. Es ist ein frustrierend selbstverstärkendes Muster.

Leider ist die erste Regel der Fähigkeitsfalle, dass wir, wenn wir in ihr gefangen sind, selten wissen, dass wir darin gefangen sind. Diese teuflische Blindheit gegenüber unserer misslichen Lage bedeutet, dass wir unsere Zeit damit verbringen, immer härter zu arbeiten, ohne erkennbaren Gewinn oder Erkenntnis, dass wir uns befreien müssen.

Wenn ein Unternehmen immer tiefer in die Fähigkeitsfalle versinkt, könnten Manager versucht sein, ihre Schwierigkeiten auf die Faulheit der Mitarbeiter zurückzuführen, anstatt auf die wahre Ursache: ein ineffektives System.

Wenn das Management glaubt, dass die Arbeiter faul und schichtlos sind, dann ist es verlockend, eine „Get tough“-Politik einzuführen, die sie dazu verleitet, hart zu arbeiten. Nicht nur die Einschätzung des Managements ist falsch, sondern auch ihre Lösung. Untersuchungen zeigen, dass das Schüren von Angst das Gegenteil von dem bewirkt, was wir wollen, indem es den Arbeitnehmern erschwert wird, sich zu konzentrieren, innovativ zu sein und komplexe Probleme zu lösen. Diese Aktivitäten sind für die Entwicklung von Software von entscheidender Bedeutung. Leider bestärkt dieses Ergebnis in der Regel die Überzeugung des Managements, dass sich die Arbeiter drücken, was zu weiteren „harten Maßnahmen“ und einem entsprechenden Rückgang der Produktivität führt, was zu einer sich selbst verstärkenden Abwärtsspirale führt. Das Ergebnis? Wir brauchen uns keine Sorgen um Konkurrenten zu machen, wenn wir „hart“ sind, wenn wir selbst zu unseren schlimmsten Feinden werden.

„Angst mag diejenigen motivieren, die routinemäßige, gedankenlose, individuelle Arbeit verrichten, aber sie ist lähmend für diejenigen, die Arbeit leisten, die Teamarbeit und Lernen erfordert.“
Amy Edmondson

Diese sich selbst bestätigenden Zuordnungsfehler führen Unternehmen in eine grausame Falle. Unfähig zu erkennen, dass ihre Handlungen ihre missliche Lage verschlimmern, indem sie ein angstbasiertes Umfeld schaffen (dem ihre fähigsten Arbeiter entkommen werden), erschweren sie die Erledigung der Arbeit noch und verstärken ihre Zuschreibungsfehler weiter. Es ist ein Teufelskreis, der manchmal erst endet, wenn das Unternehmen aufhört zu existieren.

Da sich Komplexität und Entropie mit der Zeit ansammeln, müssen wir uns Zeit nehmen, um die Dinge besser zu machen. Andernfalls werden sie sich stetig verschlimmern, bis es eine Herkulesaufgabe ist, etwas zu erledigen. Das ist der Moment, in dem Manager frustriert sind, dass „es so lange dauert, die Dinge hier zu erledigen“ und glauben, dass es daran liegt, dass niemand hart genug arbeitet. Strafmaßnahmen sind dann nur noch einen Katzensprung entfernt, die das Problem nur noch verschlimmern.

Wenn man den Arbeitern Angst einflößt, damit sie „Dinge erledigen“, bedeutet das, dass sie keine Zeit oder intellektuelle Leichtigkeit zum Lernen haben. Im Grunde werfen wir die Chance weg, in unserem Job besser zu werden, neue Produktideen zu entdecken und unser Verdienstpotenzial zu erhöhen.

Eine Anekdote: Vor vielen Jahren war ich Mitarbeiter in einer Agentur, die ihre Leute in Unternehmen in der Umgebung vermittelte und Softwarearbeiten für die Unternehmen durchführte. Dies beinhaltete in der Regel eine Meet-and-Greet-Sitzung mit dem Kunden, bei der wir uns im Büro des Managers versammelten und uns vorstellten, um seine Bedürfnisse zu verstehen und Vertrauen aufzubauen. Es waren sehr effektive Treffen, die bei allen Beteiligten ein Gefühl des Optimismus auslösten, und ich habe mich immer darauf gefreut.

Bis eines Tages.

Wir hatten einen neuen Kunden an Land gezogen, und irgendetwas schien sofort nicht in Ordnung zu sein, als wir das Büro des Managers betraten. Statt eines Gefühls des Optimismus und des Willkommens gab es eine elektrische Spannung, bevor es überhaupt losging. Anstatt uns freundlich die Hand zu schütteln, begann der Manager sofort, uns einen nach dem anderen zu verhören und Fragen zu stellen wie:

„Wo bist du zur Schule gegangen? Was haben Sie studiert? Wie hoch war Ihr Notendurchschnitt?“

Einige dieser Fragen schweiften sogar unangenehm in den persönlichen Bereich ab. Unnötig zu erwähnen, dass wir uns nach ein paar Minuten alle verstohlene Blicke zuwarfen, die unseren Unglauben über die Taktik des Trainers zeigten. Endlich, als er seine Inquisition beendet hatte, wandte er sich an uns alle und sagte:

„Ich werde dich auf Trab halten. Ich weiß, dass du versuchen wirst, mich zu betrügen, also verstehe, dass ich klug zu dir bin.“

Wenn es Zweifel an der Wirksamkeit dieses Ansatzes gab, wurde dies einige Minuten später deutlich, als wir den Administrator seines Computersystems trafen. Ich war zutiefst bestürzt, jemanden zu sehen, der so viel Angst hatte, seinen Job zu verlieren, dass er sich nicht auf die anstehende Aufgabe konzentrieren konnte.

Ein paar Tage später wurde es erneut bewiesen, als derselbe Administrator unsere Anweisungen zur Einführung einer unserer Änderungen nicht befolgte, was zum Absturz des primären Computersystems des Unternehmens führte. In seiner Wut hinterließ er eine Voicemail voller Obszönitäten, Drohungen und Schuldzuweisungen, alles andere als das Problem zu untersuchen, um eine Wiederholung zu vermeiden. Auf eine verdrehte Art und Weise war seine Begründung verständlich. Er hatte offensichtlich Angst vor seinem Vorgesetzten und wollte wahrscheinlich die Schuld von sich ablenken, um sich selbst zu schützen – eine gängige Taktik in destruktiven Arbeitsumgebungen. Ich vermute, dass jeder, der wegen besserer Arbeitsbedingungen gehen konnte, dies schon vor langer Zeit getan hat.

Ich kann es nie mit Sicherheit wissen, aber ich denke, der Trainer in dieser Folge glaubte wirklich, dass er das Richtige tat. Ich vermute, dass er einfach nicht in der Lage war, den Schaden zu sehen, den er anrichtete, und dass es vielleicht einen besseren Weg gab, andere zu überwachen. Vielleicht ist die Moral, dass es sich lohnt, zu hinterfragen, was wir unter effektivem Management verstehen. Wir richten vielleicht mehr Schaden an, als uns bewusst ist.

Organizing für die Moderne

Jetzt ist es an der Zeit, sich nicht mehr über unseren antiquierten Ansatz zu informieren, sondern moderne Organisationsmethoden für das Software-Engineering zu entdecken. Im Folgenden finden Sie eine Liste dieser Ideen.

Verändern Sie unser mentales Gefüge

Die Realität der komplexen, anpassungsfähigen und aufstrebenden Geschäftswelt um uns herum passt nicht mehr zu unserem einfachen Command-and-Control-Ansatz. Und egal wie sehr wir uns bemühen, wir können nicht weiter einer Welt aufzwingen, wie sie an unser Modell angepasst wird. Ob es uns gefällt oder nicht, wir befinden uns in einer aufstrebenden, kollaborativen Welt.

Sobald wir dies verstanden haben, werden wir erkennen, dass wir anstelle von Befehls- und Kontrollsystemen Teams schaffen sollten, die von Ungewissheit leben und auf Veränderungen reagieren. Wir können dann Variabilität und Unsicherheit nutzen, um Just-in-Time-Antworten zu generieren, die uns helfen, in Richtung Wert zu steuern.

Taylor hatte ein tiefes Misstrauen gegenüber den Arbeitern und eine geringe Meinung von ihrem Intellekt, da er glaubte, dass sie jederzeit sorgfältig gemessen und überwacht werden mussten, damit sie sich nicht ihren Pflichten entzogen oder das Falsche taten. Seine Meinung über sie war so gering, dass er glaubte, sie müssten von einem „intelligenteren“ Vorgesetzten streng instruiert werden. Es ist schwer zu erkennen, wie diese Philosophie auf die Wissensarbeiter in der Softwareentwicklung zutrifft, aber wir sehen heute allzu oft Spuren davon. Es ist an der Zeit, Taylor in der Vergangenheit zu lassen, wo er hingehört, und Anreize für Zusammenarbeit, Lernen, Experimentieren zu schaffen und die Dinge für morgen einfacher zu machen. Anstatt die Arbeiter an der kurzen Leine zu halten, wie Taylor es tun würde, sollten wir lernen, darauf zu vertrauen, dass die Arbeiter sich selbst organisieren, um ihre Arbeit am besten zu erledigen.

„Selbstorganisation erfordert eine grundlegende Abkehr von der Befehls- und Kontrollphilosophie traditioneller hierarchischer bürokratischer Organisationen. Selbstorganisation erfordert den Glauben an die lokale Rationalität von Individuen und Einheiten (z.B. wer dem Kunden am nächsten steht, kennt den Kunden am besten).“
Vidgen und Wang

Wir verursachen unwissentlich einen Preis für Verzögerungen, indem wir hierarchische Befehls- und Kontrollsysteme zur Genehmigung von Entscheidungen verwenden. Genauer gesagt gehen wir davon aus, dass der Wert von Informationen statisch ist und dass es keinen Wertverlust gibt, wenn sie langsam in die oberen Bereiche der Hierarchie zur Genehmigung wandern. In Wirklichkeit haben Informationen an modernen Arbeitsplätzen eine erschreckend kurze Lebensdauer, ihr Wert verfällt mit der Zeit schnell, und Verzögerungen bringen erhebliche und oft unsichtbare Kosten mit sich.

„Die Praxis, Entscheidungen in der Befehlskette nach oben und unten zu leiten, basiert auf der Annahme, dass die Organisation die Zeit dafür hat, oder, genauer gesagt, dass die Kosten der Verzögerung geringer sind als die Kosten der Fehler, die durch die Entfernung eines Vorgesetzten verursacht werden. Oft ist es jedoch so, dass das Risiko, zu langsam zu handeln, höher ist als das Risiko, kompetente Personen Entscheidungen treffen zu lassen.“
Stanley McChrystal

Werden Sie eine lernende Organisation

Lernende Organisationen haben eine Kultur, die sich auf den kontinuierlichen Erwerb und die Verbreitung von Wissen konzentriert. Sie legen Wert auf persönliche und berufliche Weiterentwicklung, streben nach Wissen durch Experimentieren, psychologische Sicherheit, Offenheit für neue und manchmal gegensätzliche Ideen und lassen Zeit zum Nachdenken. Sie testen die Gültigkeit ihres Wissens durch produktive Debatten und unterhaltsame abweichende Standpunkte. Sie wollen von allen lernen, anstatt Wissen von oben auf Steintafeln weiterzugeben.

Der Mensch wird mit einer bemerkenswerten Superkraft geboren: intellektueller Neugierde, aber wir sind allzu oft bereit, sie für den Nervenkitzel aufzugeben, zu glauben, dass wir Recht haben. So wunderbar es auch ist, zu glauben, dass wir Recht haben, es ist viel besser, zu lernen.

Durch das Aufbrechen von Silos, das Überschreiten von Grenzen und das Üben der Zusammenarbeit sind lernende Organisationen in der Lage, Wissen in ihrem gesamten Unternehmen zu verbreiten. Das Prinzip der marginalen Gewinne scheint zwar aus kurzfristiger Sicht gering zu sein, bedeutet jedoch, dass sich kleine, tägliche Verbesserungen im Laufe der Zeit zu bemerkenswerten langfristigen Vorteilen addieren. Dieses Prinzip ist die Essenz einer lernenden Organisation.

Eine lernende Organisation versteht, dass sie zwar die profitablen Nischen, die sie gefunden hat, nutzen muss, aber nicht ausreicht, sich ausschließlich auf sie zu konzentrieren. Aufgrund von Wettbewerbern und Marktkräften sind die Nischen zwangsläufig vergänglich. Die Organisation muss auch nach neuen Möglichkeiten suchen, um ihr langfristiges Überleben zu sichern.

„Das langfristige Überleben einer Organisation hängt von ihrer Fähigkeit ab, genügend Ausbeutung zu betreiben, um die derzeitige Lebensfähigkeit der Organisation zu gewährleisten, und genügend Explorationen durchzuführen, um ihre Zukunftsfähigkeit zu gewährleisten.“
Vidgen und Wang

Akzeptieren Sie Misserfolge und lernen Sie aus ihnen

Es gibt verschiedene Klassen von Misserfolgen. Die stereotype Sichtweise ist, dass sie von unachtsamen Individuen stammen, die das Wohlergehen ihrer Arbeitgeber rücksichtslos missachten. Das ist zweifellos eine Klasse, wenn auch ein verschwindend kleiner Prozentsatz. Die weitaus häufigere Klasse des Scheiterns tritt auf, weil wir unseren Weg nach vorne noch nicht kennen und iterativ experimentieren müssen, um ihn zu finden, indem wir immer wieder scheitern und es erneut versuchen, bis wir Erfolg haben. Dabei handelt es sich um sogenannte intelligente Fehler, die ein notwendiger Bestandteil der Arbeit mit komplexen adaptiven Systemen sind.

Fehler sind in komplexen adaptiven Systemen unvermeidlich, da es fast unmöglich ist, alles beim ersten Mal richtig zu machen. Es braucht Trial-and-Error-Experimente, um Lösungen zu finden, und Misserfolge auf dem Weg zur Entdeckung sind notwendige Schritte, um ein Endziel zu erreichen, das zu Beginn nicht sichtbar ist. Leider sehen viele Unternehmen Scheitern als etwas, das bestraft werden muss, anstatt als etwas, von dem man lernen kann. Es ist allzu einfach, mit dem Finger auf eine einzelne Person zu zeigen, in dem falschen Glauben, dass komplexe Systeme nur einem einzigen Punkt der Schuld zugeschoben werden können. Der Gedanke scheint zu sein, dass alles, was wir tun müssen, ist, diese Person zu finden, ein Exempel an ihr zu statuieren, indem wir sie bestrafen, und wir werden zukünftige Misserfolge verhindern.

Wenn es nur so einfach wäre.

Leider trägt dieser Ansatz nicht dazu bei, zukünftige Fehler zu verhindern. Es macht den Arbeitern nur Angst (schränkt ihre Fähigkeit ein, Probleme zu lösen), treibt Misserfolge in den Untergrund und zerstört die Lernmöglichkeiten, die das Scheitern bietet.

Fehler sind Teil unseres Lernens, und wir sollten sie berücksichtigen. Manager, die die perfekte Ausführung zelebrieren, hindern ihre Teams unwissentlich daran, sich hart genug zu dehnen. Wenn wir überfordert sind, machen wir die Fehler, die uns neue Dinge lehren. Schlimmer noch: Wenn Manager klarstellen, dass sie Fehler nicht tolerieren, tut das nichts, um sie zu verhindern. Er begräbt lediglich die kleinen, unausweichlichen Fehler, bis sie in viel größerer Form wieder auftauchen und das Überleben des Unternehmens bedrohen. Eine lernende Organisation muss das kostenlose Melden von Problemen und Fehlern ermöglichen, damit ihre Lernmöglichkeit nicht verloren geht.

„Führungskräfte denken oft, wenn die Leute nicht für Misserfolge verantwortlich gemacht werden, was stellt dann sicher, dass sie ihr Bestes geben? Diese Sorge beruht auf einer falschen Dichotomie. In Wirklichkeit kann ein Klima des Eingeständnisses von Misserfolgen mit hohen Leistungsstandards koexistieren.“
Stanley McChrystal

Schließlich werden die Arbeiter oft für das Versagen des Systems zur Rechenschaft gezogen, über das sie wenig bis gar keine Kontrolle haben. Anstatt uns auf eine Befehls- und Kontrollreaktion auf Komplexität zu konzentrieren, sollten wir uns darauf konzentrieren, Systeme zu entwickeln, die ihr gegenüber widerstandsfähig sind.

Team von Teams

Die meisten Softwareunternehmen basieren auf vertikal angeordneten Silos von Spezialistenteams. Wie oben erwähnt, führt dies zu Problemen mit der Koordination, Kommunikation und dem Lernen. Anstelle von Silos mit starren, hierarchischen Befehlsketten könnten wir die Idee eines Teams von Teams in Betracht ziehen. Bei diesem Ansatz wechseln die Teammitglieder fließend zwischen den Teams, machen sich mit anderen Fähigkeiten vertraut, geben Teams, denen es fehlt, Fachwissen zur Verfügung und kehren nach Abschluss zu ihrem ursprünglichen Team zurück. Niemand ist für die Dauer seiner Beschäftigung fest an ein bestimmtes Team gebunden, sondern befindet sich in einem Netzwerk von Teams.

Ein Vorteil dieses Ansatzes besteht darin, dass Informationen nicht mehr im Raum zwischen den Teams verfallen, sondern zwischen ihnen ausgetauscht werden, wodurch die Informationen im gesamten Unternehmen verbreitet werden. Ein zusätzlicher Vorteil ist, dass wir die grundlegende menschliche Tendenz minimieren, uns in Stämme von Wir und Sie zu gruppieren. Theoretisch wollen wir glauben, dass wir alle im selben Team sind und in die gleiche Richtung rudern. In der Praxis ist das oft alles andere als das. Das Verschieben von Einzelpersonen zwischen Teams bedeutet, dass es weniger wahrscheinlich ist, dass sich das Unternehmen in Gruppen von „Die sind lausig und wir nicht“ aufteilt, was zu einem besseren Fluss und einer besseren Zusammenarbeit im gesamten System führt. Einfach ausgedrückt: Teams, die sich Mitglieder teilen, schneiden besser ab.

„Wir brauchen nicht jedes Mitglied eines Teams, um jeden anderen in jedem anderen Team zu kennen. Wir müssen nur jeden kennen, der in jedem anderen Team ist. Auf diese Weise stellen sich die Teams ein freundliches Gesicht für andere Teams vor und nicht für konkurrierende Rivalen.“
Stanley McChrystal

Software-Teamarbeit

Es gibt eine leicht verfügbare Alternative zur problematischen Silo-Strategie. Anstatt unsere Kräfte zu teilen, konzentrieren wir sie und bringen ihre kollektive Kraft in unsere Arbeit ein. Wir gruppieren die Leute in Teams, die physisch zusammenarbeiten und alle zur gleichen Zeit und am selben Computer die gleiche Aufgabe bearbeiten. Bei dieser Strategie handelt es sich um den Software Teaming (Mob Programming) Ansatz.

Wenn wir unsere Kräfte bündeln, wird nicht jeder in jedem Moment zu 100 % gebraucht, aber wenn es nötig ist, gibt es keinen Aufschub für jemanden, der sich mit dem Team beschäftigt. Der Fokus liegt auf dem Fluss der Arbeit, sie in Richtung Kunde und Gewinn zu bewegen, anstatt auf die maximale Auslastung des Einzelnen. Auch wenn es beunruhigend sein mag, zu erkennen, dass einige Teammitglieder Momente des Leerlaufs haben werden, können die Vorteile, die wir daraus ziehen, uns helfen, unser Unbehagen zu überwinden. Zu diesen Vorteilen gehören:

Die Anzahl und Länge der Warteschlangen wird reduziert.
Es wird weniger Inventar erstellt.
Mit weniger Wartezeiten wird der Code schneller an die Kunden geliefert, was den Durchsatz umsatzbringender Produkte erhöht.
Eine schnellere Lieferung sorgt für einen früheren Return on Investment. In der Finanzwelt gilt: Früher ist besser als später.
Eine schnellere Lieferung ermöglicht ein schnelles Marktfeedback, was eine starke wirtschaftliche Hebelwirkung bietet und den Weg zu mehr Gewinn ebnet.
Der Code wird ständig in Echtzeit überprüft und umgestaltet, wodurch doppelter Code reduziert, Designs verbessert und teure Fehler minimiert werden.
Technisches Wissen wird im gesamten Team verbreitet und nicht innerhalb des Einzelnen gespeichert. Das Risiko eines Single Point of Failure ist geringer, wenn jemand Entscheidendes aufgibt. Und in isolierten Unternehmen gibt es in der Regel jemanden, von dem die Manager befürchten, dass er kündigt.
Es sind weniger Besprechungen, E-Mails, Dokumentationen und ähnliches erforderlich, um die Arbeit aller zu koordinieren und so mehr Zeit für die Entwicklung profitabler Software zu haben.

Offene Allokation

Eines der zwölf agilen Prinzipien ist es, motivierte Mitarbeiter einzustellen, ihnen die Werkzeuge an die Hand zu geben, die sie benötigen, und ihnen zu vertrauen, dass sie ihre Arbeit erledigen. Dieses Prinzip minimiert Managementhindernisse, die darauf abzielen, unmotivierte Arbeiter zu erkennen, und spart Geld, indem fragwürdige Aufsichtsmechanismen vermieden werden. Der Mechanismus der offenen Zuteilung basiert auf genau diesem Vertrauen.

Bei der offenen Zuweisung schlagen die Arbeiter Ideen vor, und es ist ihre Aufgabe, andere Arbeiter zu rekrutieren, die sich ihnen anschließen. Vielversprechende Ideen ziehen auf natürliche Weise Arbeitskräfte an und gewinnen an Dynamik. Schwache Ideen verkümmern schnell. Dieser Ansatz basiert auf den Open-Space-Konzepten eines Marktplatzes der Ideen, der Freiheit, die für uns interessantesten auszuwählen, und der Fähigkeit, unsere Meinung jederzeit zu ändern und an einen anderen Ort zu gehen, an dem wir einen Mehrwert schaffen können. Kurz gesagt, wir nutzen Marktsignale, um zu bestimmen, welche Ideen am tragfähigsten sind und welche am besten ausgelöscht werden.

Anstatt dass das Management entscheidet, wer woran arbeitet, können die Mitarbeiter mit Open Allocation aus einem ständig wechselnden Angebot wählen. Im Grunde sagen wir ihnen: „Du bist gut in dem, was du tust. Deshalb haben wir Sie eingestellt. Wir vertrauen darauf, dass Sie entscheiden, wo Sie den größten Mehrwert schaffen können.“

Open Allocation hat den Vorteil, dass die Anreize, die zu Bürokratie führen, reduziert werden. Es gibt wenig Bedarf an teuren, hierarchischen Schichten, wenn wir frei sind, die Arbeit vorzuschlagen und zu wählen, die uns interessiert. Dieses Modell bedeutet, dass diejenigen, die ihre Fähigkeiten am besten kennen, die einzelnen Arbeitnehmer, frei wählen können, wo sie ihre Fähigkeiten am besten einsetzen können.

Agile Organisationen wissen, dass der Markt dynamisch ist und dass statische Projekte ihre Anpassungsfähigkeit behindern. Sie erkennen, dass angesichts des ständigen Wandels und der sich schnell verändernden Märkte und Technologien eine viel bessere Philosophie als statische Ziele darin besteht:

Jeden Tag musst du morgens ankommen und das Wichtigste und Hilfreichste bestimmen, was jetzt getan werden muss. Oft ist das so wie gestern oder letzte Woche, manchmal aber auch nicht. Wenn Sie an früheren Prioritäten festhalten, denken Sie nicht intensiv genug über das komplexe, anpassungsfähige System um Sie herum nach. Der Glaube von gestern war gestern in Ordnung, könnte aber heute überholt sein. Halten Sie sie locker und seien Sie bereit, sie jeden Moment zu wechseln.

Faktoren, die Veränderungen hemmen

Wenn wir uns entscheiden, unsere antiquierten Organisationsstrukturen in etwas Moderneres zu ändern, ist das dann eine einfache Sache? Wie es normalerweise passiert, nein. Es gibt oft beträchtliche Barrieren zu überwinden, aber wie bei den meisten schwierigen Änderungen sind die Belohnungen die Mühe wert. Außerdem, wenn es einfach wäre, würde es jeder tun und seinen Wettbewerbsvorteil zunichte machen.

Dogma

Obwohl Menschen hochintelligente Geschöpfe sind, sind sie nicht immer geschickt darin, über unser Denken nachzudenken, insbesondere wenn es darum geht, lang gehegte, populäre Überzeugungen neu zu bewerten. Diese Überzeugungen verkalken sich oft zu einem Dogma, in dem wir sie nicht mehr sorgfältig im Lichte der Beweise abwägen, sondern sie unhinterfragt akzeptieren. Schlimmer noch, anstatt den Verdienst derjenigen zu bedenken, die uns bitten, diese Überzeugungen zu überdenken, werden wir ihnen gegenüber manchmal defensiv und feindselig.

Wir neigen besonders zu Dogmen, wenn wir unter starkem Druck stehen, Dinge zu erledigen. Es ist nicht ungewöhnlich, wenn man eine lang gehegte Praxis in Frage stellt, dass man mit einer verärgerten Antwort und der Antwort konfrontiert wird: „Dafür haben wir keine Zeit! Mach es einfach.“ Wir können sicherlich argumentieren, dass wir „Dinge schneller erledigen“, wenn wir nicht aufhören, sie zu hinterfragen, aber ob das auf lange Sicht ratsam ist, steht auf einem anderen Blatt. Kurz gesagt, es ist einfacher, einem ausgetretenen Pfad zu folgen, als einen neuen Weg durch das Dickicht zu schlagen, daher ist es nur natürlich, dass wir das Gleiche tun.

Es ist vielleicht nicht überraschend, dass nach mehr als einem Jahrhundert des Taylorismus seine Philosophie als Dogma in unser Denken eingebettet ist. An dieser Stelle ist es einfach rot, das Gesangbuch, aus dem jeder singt.

Wie können wir diese dogmatische Organisationssicht über Bord werfen und Alternativen in Betracht ziehen? Die schlechte Nachricht ist, dass es keine einfache Antwort gibt. Das Dogma ist per definitionem eine grundlegende menschliche Tendenz und unempfindlich gegen Vernunft. Die gute Nachricht ist, dass wir nicht machtlos sind. Allein wenn wir uns der Allgegenwart des Dogmas bewusst sind, ist es wahrscheinlicher, dass wir seiner kognitiven Anziehungskraft widerstehen.

Wenn es ein Funktionsprinzip gibt, das hilft, Dogmen zu überwinden, dann ist es vielleicht dieses:

Lassen Sie anstelle von Dogmen Raum für Zweifel.

Ausnutzung

Auslastung ist ein weit verbreiteter und selten hinterfragter Glaube, dass wir unsere Software-Engineering-Mitarbeiter jederzeit voll beschäftigen müssen, sonst verschwenden wir Geld. Diese Philosophie ist ein direkter Auswuchs des Taylorismus und ist in Unternehmen, die sich an die Taylor-Prinzipien halten, weit verbreitet.

Das Problem, mit dem wir konfrontiert sind, wenn wir uns für die Modernität organisieren, besteht darin, dass wir akzeptieren müssen, dass nicht alle Mitarbeiter zu jeder Zeit zu 100 % ausgelastet sind, wenn wir uns darauf konzentrieren, die Arbeitsprodukte in Richtung des Kunden zu bewegen. Diese Erkenntnis ist oft ein Schritt zu weit für diejenigen, die vom Auslastungsmantra durchdrungen sind, und sie widersetzen sich in der Regel jedem Ansatz, der etwas anderes als die volle Auslastung der Arbeiter zulässt.

Wie können wir das umgehen? Ähnlich wie wir es mit dem Problem des Dogmas tun. Allein das Wissen, dass wir das Problem haben, ist ein großer Schritt, um es zu überdenken und schließlich zu überwinden. Es ist auch hilfreich zu erkennen, dass sich unser Fokus von der Auslastung auf die Aufrechterhaltung des Arbeitsflusses verlagern muss.

Anreize

Eines ist bei Anreizen klar: Sie funktionieren, oft zu gut und auf unbeabsichtigte Weise, die mit unseren gewünschten Zielen in Konflikt steht.

Angenommen, ein Unternehmen ist um Fachabteilungen, Befehls- und Kontrollhierarchien und Entscheidungsfindung in der Befehlskette herum organisiert. In diesem Fall ist es schwierig, die Arbeitnehmer davon zu überzeugen, ihre Praktiken zu ändern, ohne auch ihre Anreizstrukturen zu ändern. Andernfalls sagen wir ihnen im Wesentlichen: „Wir belohnen dich für diese eine Sache, wollen aber, dass du eine andere tust, ohne die Garantie einer Belohnung.“

Es ist unrealistisch zu erwarten, dass Menschen ihre Gehaltsschecks für ein ungewisses Ergebnis riskieren. Wir müssen ihre Anreize ändern, wenn wir wollen, dass sie ihr Handeln ändern. Wir könnten sogar in Erwägung ziehen, Anreize ganz zu entfernen, angesichts der Forschung, die zeigt, wie oft sie das falsche Verhalten maximieren und diejenigen demotivieren, die ansonsten selbst motiviert sind. Es gibt wenig Bedarf an Anreizen, wenn wir darauf vertrauen, dass die Arbeiter sich selbst organisieren und ihre beste Arbeit leisten.

„Die beste Politik könnte darin bestehen, Anreize ganz zu vermeiden und sich stattdessen auf die Schaffung von Systemen zu konzentrieren, in denen intrinsische Motivation, Kooperation, ethisches Verhalten, Vertrauen, Kreativität und Freude an der Arbeit gedeihen können.“
Gipsie Ranney

Eskalation des Engagements

Wie oben erwähnt, betrachten einige Arbeitsumgebungen Misserfolge als etwas, das versteckt werden muss, wenn es passiert, und bestraft wird, wenn es nicht passieren kann. Es ist wahrscheinlich keine Überraschung, dass die Menschen in diesen Umgebungen nur ungern zugeben, dass eine Strategie nicht funktioniert. Sie werden stattdessen damit fortfahren, und sei es nur aus dem Grund des Arbeitsplatzerhalts. Wenn auf dem Weg dorthin viel Geld und Ressourcen verbraucht wurden, wird die Angst vor dem Verlust des Arbeitsplatzes noch verstärkt. Dieser Ansatz garantiert fast, dass gescheiterte Strategien weiterhin verwendet werden, selbst wenn es mehr als klar ist, dass sie aufgegeben werden sollten.

Anstatt innezuhalten und unsere Methoden zu überdenken, glauben wir oft, dass das Scheitern darauf zurückzuführen ist, dass wir sie nicht rigoros genug anwenden, und vernachlässigen es, innezuhalten und zu bedenken, dass unsere Methodik fehlerhaft sein könnte. Wenn unser stark geplanter und gesteuerter Ansatz nicht funktioniert, so die Überlegung, liegt das nicht daran, dass der Ansatz grundlegend falsch ist. Vielmehr liegt es daran, dass wir sie nicht mit ausreichendem Engagement umsetzen, und deshalb müssen wir unsere Anstrengungen verdoppeln und unser Engagement für den Erfolg weiter ausbauen. Diese Verdoppelung des Scheiterns ist eine weit verbreitete Voreingenommenheit, die sogar so häufig ist, dass sie als „Eskalation des Engagements“ bezeichnet wird.

Wir wären viel besser bedient, wenn wir kognitiv neugierig wären, immer bereit wären, liebgewonnene Überzeugungen zu überdenken und mit neuen Ansätzen auf wirklich agile Weise zu experimentieren.

„Es ist bequem, bewährte Verfahren zu verdoppeln, unabhängig von ihrer Wirksamkeit. Nur wenige von uns werden kritisiert, wenn wir treu das tun, was schon viele Male zuvor funktioniert hat. Wir leben nicht mehr in einer Welt, in der Planung und Disziplin zum Erfolg führen. Stattdessen leben wir in einer Welt, die Agilität und Innovation erfordert.“
Stanley McChrystal

Das Verlangen nach Gewissheit

Der Wunsch nach Gewissheit ist ein Grundpfeiler vieler Software-Arbeitsplätze. Geschäftspläne und Quartalsergebnisse implizieren, dass unsere Softwarebemühungen mit ausreichender Kompetenz und Hingabe so vorhersehbar sein können wie ein Fließband in der Fertigung. Wie oben beschrieben, ist dies einfach nicht möglich.

Aber diese Erwartung ist so grundlegend, dass wir agile Frameworks einsetzen werden, die vorhersehbare Ergebnisse versprechen, indem sie ihren genauen Anweisungen und Checklisten folgen. Es ist erwähnenswert, dass das vorhersehbarste Ergebnis dieser Frameworks nicht immer Agilität ist, sondern Bürokratie und teure Berater, die uns bei der Nutzung des Frameworks anleiten.

Zu wissen, was die Zukunft bringt, ist ein grundlegendes menschliches Bedürfnis, das so alt ist wie unsere Spezies. Deshalb gibt es bei uns Horoskope und Wahrsager. Aber wie kann ein Prozess in unserer sich ständig verändernden, unvorhersehbaren Softwareumgebung Gewissheit über die Zukunft bieten? Das kann es nicht, und wir werden davon profitieren, wenn wir uns dagegen wehren.

„Wir müssen gegen den Wunsch nach Anweisungen ankämpfen, die Prozessschritte vorgeben und Ergebnisse garantieren. Wir müssen akzeptieren, dass jeder Prozess notwendigerweise unzureichend ist und immer verbessert werden kann. Leider sehnen wir uns nach der Gewissheit, einen Prozess zu haben, der garantierte Ergebnisse verspricht.“
Amy Edmondson

Allzu oft suchen wir den Nervenkitzel der Gewissheit in einem Bereich, in dem er selten zu finden ist. Wenn wir sofortige Antworten auf Probleme wollen, die Zeit brauchen, um sie zu verstehen und zu definieren, können wir falsch informierte Entscheidungen treffen und dann zum nächsten Problem eilen, während wir uns sicher sind, dass wir Dinge wissen, die wir in Wirklichkeit nicht wissen, und auf falschem Wissen handeln. Jede unüberlegte Entscheidung ist mit stetig anfallenden, langfristigen Kosten verbunden, die unsere zukünftige Arbeit unnötig erschweren. Es ist eine Form der absichtlichen Ignoranz auf der Suche nach kurzfristigem Gewinn.

Bürokratischer Widerstand

Bürokratien sind geschickt darin, sich dem Wandel zu widersetzen und ihre Dominanz zu bewahren. Selbst wenn wir denken, dass wir sie in eine flexiblere Form umorientiert haben, ist es manchmal so, dass wir sie nur in eine andere Bürokratie verwandelt haben. Es kann eine wahnsinnige Übung sein, einen Ballon zusammenzudrücken, in eine Richtung zu drücken, nur um zu sehen, wie er in einer anderen auftaucht, was die Anstrengung effektiv zunichte macht.

Die Lösung, wenn es eine gibt, besteht darin, alle Beteiligten darüber zu informieren, dass die langfristige Rentabilität der Organisation das Hauptanliegen ist und Vorrang vor den kurzfristigen Provinzinteressen bürokratischer Lehen haben muss.

Eine Anekdote: Ich habe einmal in einer Softwarefirma gearbeitet, in der Softwarebereitstellungen von mehreren Ausschüssen genehmigt werden mussten, die jeweils als Ergebnis fehlgeschlagener Bereitstellungen gebildet wurden. Die Ausschüsse waren Teilmengen voneinander, was bedeutete, dass dieselben Mitglieder einen Einsatz mehrmals genehmigten. Erschwerend kam hinzu, dass die meisten Mitglieder des Komitees keine technischen Leute waren und wenig Verständnis davon hatten, was tatsächlich eingesetzt wurde. Sie stellten meist Fragen, die versuchten, herauszufinden, ob ich meine Hausaufgaben gemacht hatte. Oberflächlich betrachtet war es eine verständliche Strategie, um eine Katastrophe zu verhindern, aber in Wirklichkeit trug sie wenig dazu bei, weitere Ausfälle zu verhindern. Stattdessen fügte es nur Schichten bürokratischen Widerstands hinzu. Es wäre wahrscheinlich besser gewesen, die Ausschüsse in einem einzigen Komitee zusammenzufassen. Besser noch, entfernen Sie sie vollständig, indem Sie robustere Tests, Codeüberprüfungen und Systemresilienz entwickeln, anstatt zu hoffen, dass Genehmigungsmaßnahmen Probleme verhindern könnten.

Fazit

In weiten Teilen unserer Branche basiert der grundlegende Glaube, wie wir uns organisieren sollen, auf falschen Annahmen über die Art unserer Arbeit, was uns letztendlich auf lange Sicht schadet. Unsere Arbeit liegt im Bereich des Komplexen, nicht im einfachen, klaren Bereich der Taylor-Ära. Dieses Phänomen ist der Grund, warum schwerfällige, bürokratische Systeme Schwierigkeiten haben, mit dem schnellen und ständigen Wandel in der Softwarebranche Schritt zu halten.

In der Vergangenheit funktionierte es für Produktionsunternehmen gut, für die Antike organisiert zu sein, weil das Tempo des Geschäfts langsam und die Arbeit einfach war. Heute bewegen wir uns in halsbrecherischer Geschwindigkeit, und die Geschwindigkeit nimmt weiter zu. Sich für die Antike zu organisieren bedeutet, dass wir uns für eine Welt strukturieren, die nicht mehr existiert und die nie auf die Softwareentwicklung angewendet wurde.

Es gibt vielleicht einen Silberstreif am Horizont der weit verbreiteten Praxis, unsere Arbeitsplätze nach den Prinzipien des Taylorismus zu organisieren. Wenn alle für die Antike organisiert sind, bietet sich für diejenigen, die sich für einen moderneren Ansatz entscheiden, eine bedeutende Marktchance. Besser noch, wenn die Mehrheit dogmatisch über ihre Methode ist, ist es weniger wahrscheinlich, dass sie erkennen, dass ein Konkurrent eine effektivere Strategie gefunden hat und sie selbst anwendet, was denjenigen, die sich für die Modernität organisieren, einen langfristigen Nutzen bringt.

Für die Antike organisiert zu sein, ist ein Problem, das sich vor aller Augen verbirgt. Wir haben uns unwissentlich Taylors jahrhundertealten Prinzipien angeschlossen, und nur ein Überdenken unseres Glaubenssystems wird offenbaren, dass wir auf die falsche Art und Weise organisiert sind. Es ist an der Zeit, einen anderen Ansatz zu wählen.

Weiterer Beitrag: Multithreading und Mutexes einfach