Zugegeben, es klingt zunächst einmal absurd. Beim Gedanken an das Unites States Marines Corps drängen sich den meisten Leuten vermutlich Bilder aus Hollywoodfilmen auf. Filme wie Full Metal Jacket oder Platoon, deren Schauplätze und Inhalte so rein gar nichts mit dem Alltag eines Entwicklers zu tun haben. Wir Entwickler sitzen meistens in unseren Büros am Schreibtisch. Uns fliegen keine Kugeln um die Ohren. Wir fahren keine Panzer und wenn wir Apache sagen, dann meinen wir den Webserver und nicht den Kampfhubschrauber. Vor allem aber besteht für uns keine Gefahr für Leib und Leben. Halten wir also fest: die Realität eines Soldaten ist meilenweit entfernt von der Realität des Entwicklers.

Eine Sache jedoch haben Soldaten und Entwickler gemeinsam: beide arbeiten in einem Umfeld, in denen Unwägbarkeit und Veränderung an der Tagesordnung stehen. Dieser Umstand ist so sicher gegeben, dass die Informatiker Hadar Ziv und Debra Richardson dies sogar zur Maxime bei der Planung und Entwicklung von Softwaresystemen erhoben haben:

Uncertainty is inherent and inevitable in software development processes and products. - The Uncertainty Principle in Software Engineering

Nun ist die Softwareentwicklung mit ihren rund  60 Jahren noch eine recht junge Disziplin, die – glaubt man den Chaos Reports der Standish Group – eher mittelmäßig mit diesem Problem umzugehen weiß. Das Militär aber operiert in diesem Umfeld seit vielen hundert Jahren.

Schlachtfelder sind voll von Unwägbarkeit. Dieser Unwägbarkeit begegnet man nicht etwa, indem man Offiziere Befehle brüllen lässt, die die Soldaten dann blind befolgen. Die konstante Bedrohung für den Auftragserfolg, das eigene Leben und das der Anderen erfordert ein hohes Maß an Agilität, Vertrauen und Kooperation von jedem einzelnen Soldaten im Team. Und es erfordert eine Organisationsstruktur, die sich schnell auf neue Begebenheiten einstellen lässt.

Für uns als Entwickler steht zweifelsohne weniger auf dem Spiel. Auf abstrakter Ebene aber ähneln sich die Anforderungen. Wollen wir unsere Software also erfolgreich entwickeln und am Markt positionieren, hilft es daher uns ähnliche Fähigkeiten und Eigenschaften aneignen, wie die Soldaten auf dem Schlachtfeld. Grund genug also, einen Blick über den Tellerrand zu wagen.

Über den Krieg

Der griechische Philosoph Heraklit konstatierte einst "der Krieg sei der Vater aller Dinge". Damit meinte er, dass die Ganze Welt mit sich im Widerstreit stehen würde. Jede Aktion verändert den Status Quo. Die Veränderung ist somit die einzige Konstante in der Welt. Sie ist also nicht statisch, sondern dynamisch und in ständiger Interaktion. Alles fließt. Alles wird. Was wie fernöstliches Zen klingt, ist auch eine der Grundannahmen der Systemtheorie und ein Eckpfeiler der Kriegstheorie aller modernen Militärs.

Ein weiterer Eckpfeiler ist das Prinzip das Auftragstaktik. Diese wurde im 19. Jahrhundert vom preußischen General Carl von Clausewitz erfunden. Clausewitz brach damals mit den etablierten Theorien über den Krieg, indem er vorschlug, dass

Krieg nichts weiter ist, als ein erweiterter Zweikampf. Wollen wir uns die Unzahl der einzelnen Zweikämpfe, aus denen er besteht, als Einheit denken, so tun wir besser, uns zwei Ringende vorzustellen. Jeder sucht den anderen durch physische Gewalt zur Erfüllung seines Willens zu zwingen.

Der Krieg als großes Ganzes funktioniert also prinzipiell genauso wie ein Zweikampf. Der Erfolg im Zweikampf wiederum bedingt den Erfolg im großen Ganzen. Er fußt also auf den gleichen Mechanismen; Initiative, Tempo, Überraschung, Angriff und Verteidigung, usw. Da der Gegner sich in der Regel nicht kampflos ergeben wird, sind wir gezwungen uns immer wieder auf seine Gegenwehr neu einzustellen. Diese Erkenntnis klingt zunächst einmal banal, ist aber fundamental wichtig, um die wesentlichen Eigenschaften des Krieges zu begreifen.

Helmuth von Moltke, preußischer Generalfeldmarschall und Schüler von von Clausewitz folgerte aus dieser Dynamik des Krieges dass

kein Operationsplan mit einiger Sicherheit über das erste Zusammentreffen mit der feindlichen Hauptmacht hinaus reicht.

So gut wie alle Militärs basieren heute auf den Theorien von von Clausewitz und von Moltke. Ihre Bedeutung ist vergleichbar mit den Theorien von Deming und Drucker in der Managementwelt. Auch die lesenswerte Doktrin "MCDP-1 Warfighting" des United States Marine Corps beruft sich auf von Clausewitz und von Moltke. Ihre Lektüre gehört zur Grundausbildung jedes Marines und ist frei im Internet verfügbar.

Strategien vor Plänen

Die Unzulänglichkeit von Plänen beobachten wir auch in der Softwareentwicklung. Analog zu von Moltke könnte man sagen: keine Software überlebt den ersten Kontakt mit dem Endanwender. Unser Feind ist zwar (hoffentlich) nicht der Kunde oder Endanwender, sondern die Probleme, die wir für ihn lösen sollen. Aber oft genug lernen wir eben erst hinterher, dass das was wir entwickelt haben, nicht dem entspricht, was er haben wollte. Und tatsächlich formulierte der Informatiker, CMMI Erfinder und SEI Fellow Watts S. Humphrey das auch in etwa so:

For a new software system, the requirements will not be completely known until after the users have used it - Humphrey's Requirements Uncertainty Principle

In der Kommunikationswissenschaft formulierte Gerold Ungeheuer das Axiom, dass "alle Kommunikation grundsätzlich fallibel" sei. Wir haben schlichtweg keine Möglichkeit zu 100% sicher zu sein, dass wir uns verstehen. Entsprechend ist auch nie garantiert, dass die Anforderungen an unsere Software zu 100% richtig verstanden wurden. Dieser Faktor trägt wesentlich zur Unwägbarkeit von Softwareprojekten bei.

Oft verzögert sich auch die Fertigstellung von Software aus Gründen, die vorher so nicht vorhersagbar waren. Starre Pläne und rigide Prozesse funktionieren nur gut in vorhersagbaren Umgebungen, weil sie eben eine Antwort auf ein bestimmtes Problem haben. Ändern sich die Umgebungsvariablen, passt der Prozess oder Plan nicht mehr und muss angepasst werden. Nicht zuletzt deswegen bewertet das Agile Manifest auch das Reagieren auf Veränderungen höher als das Befolgen von Plänen.

In der Regel begegnen wir heutzutage diesem Problem der Unwägbarkeit mit einem iterativen Vorgehen. Aber auch das iterative Vorgehen erfordert, dass man zumindest eine Strategie für das Problem hat. Sonst iteriert man ziellos umher. Strategien erlauben uns auf dem Weg zum Ziel Kursänderungen vorzunehmen, ohne das Ziel aus den Augen zu verlieren.

Wie man zum Ziel kommt, ist nach von Moltke zweitrangig. Wichtig ist in erster Linie, dass die ausführenden Personen den Auftrag und dessen Rahmenbedingungen verstanden haben. Also was erreicht werden soll und warum. Den Rest entscheiden die Personen selbst. Auftragstaktik ist somit dezentral und weitgehend autonom organisiert. Die Entscheidungen werden dort getroffen, wo die Informationen sind.

In Unternehmen mit starken Hierarchien gibt es diese Autonomie oft nicht. Entscheidungen werden stattdessen von formal autorisierten Personen getroffen und deren Mitarbeiter führen nur aus. So entsteht ein Flaschenhals, weil alle Entscheidungen, insbesondere Planänderungen, erst genehmigt werden müssen.

Außerdem verhindert eine zentralisierte Organisation, dass Mitarbeiter ihr volles Potential entfalten. Neben dem Verstehen der Strategie war es für von Moltke absolut notwendig, dass alle Soldaten, insbesondere die Offiziere, mitdenken und handeln. Von Moltke wollte Führer auf allen Ebenen. Eine Idee, die das United States Marine Corps später auch übernommen hat.

Zwar gibt es auch im United States Marine Corps formale Befehlsketten und Hierarchien, aber die notwendigen Schritte zum Erreichen der Missionsziele werden entlang dieser Befehlskette verteilt. Die Hauptmission stellt dabei nur den Ausgangspunkt für viele Untermissionen dar, die immer konkreter werden, je weiter man von der strategischen Ebene, über die operative Ebene zur taktischen Ebene kommt. Das führt dazu, dass alle Aktionen am primären Ziel ausgerichtet sind.

Absichten verstehen

Da die reelle Gefahr besteht, dass die Befehlskette durch technische Probleme, Verwundung oder Ableben einer kommandierenden Offiziers durchbrochen wird, unterrichten die Offiziere ihre Untergebenen nicht nur über deren Aufträge, sondern auch über ihre eigenen Aufträge. Als Offizier kenne ich also nicht nur meinen eigenen Auftrag, sondern auch den des mir vorgesetzten Offiziers. Der sogenannte "Commander's Intent" soll sicherstellen, dass die Befehlskette resistenter gegen Störungen ist. 

Auch Entwickler können den "Commander's Intent" für sich nutzen. Der Vorgesetzte muss ja nicht gleich das Zeitige segnen. Er kann aber krank werden oder anderweitig verhindert sein. Wenn der Entwickler nun weiß, welche Absichten sein Vorgesetzter mir einer Aufgabe verfolgt, kann er im Sinne des Vorgesetzten seiner Arbeit weiter nachgehen und ist nicht blockiert.

Um besser einschätzen zu können, ob der Entwickler den "Commander's Intent" verstanden hat, kann er sich des "Backbriefings" bedienen. Das bedeutet, dass er seinem Vorgesetzten nochmal in eigenen Worten schildert, was die Aufgabe ist und warum sie erledigt werden muss.

Schneller als die Anderen

Der Militärstratege Colonel John Richard Boyd hat über Jahre hinweg untersucht, wie eine Organisation oder ein Individuum auf Veränderungen reagiert. Dabei entwickelte er die Theorie des sogenannten Observe, Orient, Decide, Act (OODA) Loops. Ein Kreisprozess, der – wenn man ihn schneller durchläuft als der Gegner – dazu führt, dass man im Kampf die Initiative (und somit die Oberhand) behalten wird.

Ursprünglich für Jetpiloten entworfen, erweiterte Boyd diese Theorie über die Jahre zu einer Theorie des Manöverkrieges, die aber explizit auch außerhalb des Militärs Anwendung finden kann.  

Die vier Phasen des OODA Loops unterteilen sich in die Phasen "Observierung", also das bloße Sammeln von Daten, "Orientierung" in der die Daten bewertet werden und einer darauf resultierenden "Entscheidung", die dann in die "Handlung" mündet. Nach der Handlung beginnt der Prozess von Neuem. Die neue Situation wird beobachtet und neu bewertet, neue Entscheidungen getroffen und neue Handlungen ausgeführt.

Die Phase, die primär über die Geschwindigkeit des OODA Durchlaufs entscheidet, ist die Orientierungsphase. In dieser Phase werden die aktuelle Situation gegen den eigenen Erfahrungshorizont ausgewertet; also gegen alle jemals gemachten Erfahrungen, gegen alles Wissen, aber auch gegen alle Überzeugungen und Werte des Einzelnen. Im sogenannten "Framing" entsteht so eine Hypothese über die Situation und wie damit umzugehen ist. Langsam werden wir immer dann, wenn wir diese Hypothese nicht bilden können; wenn wir also die Situation nicht deuten können.

Geschieht dies ständig, geraten wir ins Hintertreffen. Praktisch kann man sich den OODA Loop wieder mit den von Clausewitz'schen Ringern vorstellen. Beide zirkeln um sich herum, täuschen Angriffe vor, weichen aus, bis der unerfahrenere von beiden die Situation falsch einschätzt, einen Fehler macht und zu Boden geht. Die Aufgabe des Soldaten ist es daher, den Kreisprozess des Gegners zu stören und den eigenen erfolgreichen Durchlauf des OODA Loops zu schützen.

Störungen vermeiden, Erfahrung aufbauen

Auch als Entwickler "ringen" wir ständig mit irgendwelchen Problemen in unserem Code oder unserer Infrastruktur. So könnte zum Beispiel ein Anwender melden, dass sein Login für eine Website nicht mehr funktioniert. Nehmen wir an, dies liegt daran, dass die Festplatte auf dem Host voll ist und daher keine Sessiondaten mehr geschrieben werden können. Der unerfahrene Entwickler wird nun wahrscheinlich erst einmal den Applikationscode debuggen, während der erfahrene Entwickler zunächst das Monitoring prüft und dem Unternehmen so viel Zeit bis zur Fehlerbehebung spart.

Ähnlich verhält es sich auch beim Schreiben von Code. Der Junior-Entwickler, der sich gerade zum ersten Mal mit Entwurfsmustern befasst hat, wird vielleicht großflächig Singletons verwenden wollen. Der "Clean Code" Entwickler hingegen kennt die damit verbundenen Probleme, z.B. in Hinblick auf die Testbarkeit des Codes, und wird das Muster gezielter einsetzen oder ganz vermeiden.

Das United States Marine Corps hat Colonel John Boyds Theorie über den OODA Loop vollständig übernommen und trainiert seine Soldaten konsequent in verschiedensten Simulationen für den Ernstfall. Ausdrücklich gewünscht ist, dass Soldaten in diesen Trainings Fehler machen, um aus den Konsequenzen zu lernen. Durch die in den Trainings gesammelte Erfahrung sind die Soldaten später schneller in der Lage situativ angemessener zu handeln und eben solche Fehler zu vermeiden.

Gerade beim Erreichen kritischer Unternehmensziele zahlt sich eine Investition in die eigenen Mitarbeiter oft aus. Zwar lernt jeder von uns auch "on-the-job", aber dabei geschehen häufig Fehler, die hinterher meist teurer zu stehen kommen, als ein Training oder eine "Spike Solution" vorab gekostet hätten (Stichwort Technische Schuld und Legacy Code). Nicht zuletzt ist das Kapital eines Technologieunternehmens das gesammelte Wissen seiner Mitarbeiter. Stagniert das Wissen, stagniert auch das Unternehmen.

Unser OODA Loop kann aber nicht nur durch fehlende Erfahrung gestört werden. Auch die alltäglichen Begleiter, wie Smartphone, Social Media und auch die lieben Kollegen können sich störend auswirken. Wer effizient arbeiten will, versucht solche Störfaktoren zu vermeiden.

Kohäsive Teams leisten mehr

Wir haben gesagt, dass die Mechanismen des Krieges im Kleinen wie im Großen identisch sind. Entsprechend gilt auch für den OODA Loop, dass er sowohl für das Individuum als auch für Gruppen und Organisationen funktioniert. Arbeitet ein Entwicklerteam gemeinsam an einem Problem, so agiert es als Einheit. Intern existieren zwar für jedes Mitglied einzelne OODA Loops, aus systemischer Sicht haben wir es aber nur mit einem einzelnen OODA Loop zu tun. Ähnlich wie in der "Theory of Constraints" ist die Durchlaufgeschwindigkeit dieses OODA Loops gleich der Durchlaufgeschwindigkeit des langsamsten Mitglieds. Störungen von außen, wie von innen können die individuellen OODA Loops treffen, z. B. kann ein Teammitglied plötzlich krank werden (äußerer Einfluss) oder zwei Entwickler sind sich uneins über die Implementierung eines Stück Codes (innerer Einfluss). Beides sind Störfaktoren, die sich negativ auf die Entscheidungsfindung und Handlungen des Teams auswirken können.

Umgekehrt verhält es sich jedoch nicht so, dass die maximale Geschwindigkeit des OODA Loops gleich der schnellsten Durchlaufzeit der einzelnen OODA Loops ist. Stattdessen kann sie höher liegen. Das liegt daran, dass gut aufeinander eingestellte Teams oft von emergenten Effekten profitieren können, also solchen Effekten, die sich kausal nicht einfach auf ein oder zwei Faktoren zurück führen lassen. Es sind diese fast magischen Momente, wenn jeder weiß, was zu tun ist und jeder Handgriff sitzt und das Team als wahre Einheit agiert.

Um so eine Einheit herzustellen ist vor allem wichtig, dass die Teams in der Orientierungsphase des OODA Loops zu ähnlichen Bewertungen gelangen. Aus diesem Grund legt das United States Marine Corps großen Wert darauf, allen Marines den eigenen "esprit d'corps" zu vermitteln. Die Idee ist, dass Individuen, die die gleichen Überzeugungen, Werte und Erfahrungen teilen (also einen ähnlichen Erfahrungshorizont haben) auch zu ähnlichen Entscheidungen kommen werden. Diskussion wie im Falle der oben beispielhaft erwähnten Entwickler, die sich nicht auf eine Implementierung einigen können, entfallen so. Zwar garantiert das noch keine emergenten Effekte, aber es erhöht zumindest die durchschnittliche Durchlaufzeit.

Solche kohäsiven Teams zeichnen sich außerdem durch ein starkes Wir-Gefühl und gegenseitiges Vertrauen aus, dass sich aus dem gemeinsamen "esprit d'corps" aber noch viel mehr aus gemeinsam gemachten Erfahrungen ergibt.

Da sich der OODA Loop beliebig nach oben skalieren lässt (Individuen, Teams, Abteilungen, Unternehmen) fallen unter diesen Begriff alle koordinierten Handlungen, die das Erreichen einer Strategie zum Ziel haben. Das United States Marine Corps spricht hier von der "Unity of Action".

Damit auch Unternehmen eine "Unity of Action" erreichen, ist es wichtig, dass die Mitarbeiter, Teams und Abteilungen verstehen, was eigentlich die Ziele und Absichten des Unternehmens sind und die Rahmenbedingungen zur Erreichung dieser Ziele kennen.

Einen unternehmensweiten "esprit d'corps" zu etablieren gestaltet sich hingegen schwieriger. Die propagierten Unternehmenswerte und die tatsächlich vorhandenen Werte unterscheiden sich oft voneinander und Kultur auf Knopfdruck funktioniert nun mal nicht. Das United States Marine Corps hat hier den großen Vorteil, dass die Soldaten die Grundausbildung durchlaufen, in denen ihnen der gewünschte Korpsgeist vermittelt wird.

Entwicklerteams können aber durchaus für sich selbst herausfinden, was ihre gemeinsamen Werte sind und ihre Handlungen daran ausrichten. Hierbei kann schon der Akt des gemeinsamen Herausfinden viel für das gegenseitige Vertrauen und den Zusammenhalt beitragen. Die (vermeintlich) einfache Frage dazu lautet: "wie wollen wir sein?".

Führung als Selbstverständnis

Die Frage "wie wollen wir sein" gilt auch für den Einzelnen. Ein Marine zu sein beginnt mit dem Marine selbst. Es ist Teil der eigenen Identität; es ist nicht lediglich ein Beruf, sondern vielmehr Berufung und Lebenseinstellung. Das United States Marine Corps definiert dieses Selbstverständnis in der Doktrin MCDP-6 "Leadership".

Marine zu sein bedeutet sich selbst zu führen, besser zu sein als alle anderen und nach den Idealen des US Marine Corps zu streben. Dazu gehören Werte wie Ehre ("Honor"), also ethisch und moralisch gut zu sein, Mut ("Courage") die eigenen Werte zu verteidigen und die Verpflichtung ("Commitment") zur Exzellenz in allen Handlungen.

Der ideale Marine ist integer, loyal und aufrecht. Er behandelt seine Kollegen mit Respekt und Fairness. Er ist ausdauernd, enthusiastisch, initiativ und selbstlos und richtet seine Handlungen nach den folgenden Leitprinzipien aus:

• Kenne dich selbst und strebe nach Selbstverbesserung ("know yourself and seek self-improvement")
• Kenne dein Team und sorge für sein Wohlergehen ("know your team and look our for their welfare")
• Sei technisch und taktisch fähig ("be technically and tactially proficient")
• Halte dein Team informiert ("keep your team informed")
• Sei Vorbild ("set the example")
• Stelle sicher, dass die Aufgabe verstanden, überwacht und erreicht wurde ("make sure the task is understood, supervised and accomplished") - wobei das Ziel aber ausdrücklich ist, die Aufgabe ohne Überwachung zu erreichen.
• Trainiere deine Marines als Team ("train your Marines as a Team")
• Setze dein Team gemäß seinen Fähigkeiten ein ("employ your team in accordance with it's capabilities")
• Treffe angemessene und zeitnahe Entscheidungen ("make sound and timely decisions")
• Suche Verantwortung und übernehme Verantwortung für deine Handlungen ("seek responsibility and take responsibility for your actions")

Wer jetzt an Ritter in glänzenden Rüstungen denkt, der halte sich noch einmal vor Augen, in welchem Umfeld Marines operieren. Zwar kann man eine gewisse Portion Heldentum und Pathos nicht verleugnen, aber die Führungsdoktrin des United States Marine Corps dient in allererster Linie nicht der Selbstverherrlichung, sondern der erfolgreichen Absolvierung von Kriegseinsätzen und dem Schutz des eigenen Lebens und dem der Kameraden. Es ist schlicht eine Notwendigkeit.

Diese elitäre Einstellung mag für den ein oder anderen Lesern trotzdem befremdlich oder auch zu anstrengend wirken. Aber wieso eigentlich? Was ist schlecht daran, nach Exzellenz zu streben? Was ist schlecht daran, gemeinsam etwas erreichen zu wollen und erfolgreich zu sein? Ist es nicht viel angenehmer in einem motivierten Team zu arbeiten, in dem die Kollegen respektvoll miteinander umgehen, sich gegenseitig helfen und gemeinsam Probleme lösen? Oder zu wissen, dass ich mich auf meine Kollegen verlassen kann? Und was ist die Alternative dazu? Jeff Sutherland, einer der Scrum Erfinder, formulierte diese Frage etwas pointierter:

My standard speech to teams large and small is: 'Do you really want to suck forever? Is that what your motivation is in life? Because it’s a choice, you know—you don’t have to be that way.' A team has to demand greatness from itself. - Jeff Sutherland

Letzten Endes steht hinter dieser Frage auch die Frage danach, was eigentlich Professionalität in unserer Branche ausmacht. Wie muss ein professioneller Entwickler sein? Was sind unsere Leitwerte? Unser Berufsethos? Was ist das technische, aber auch soziale Rüstzeug, dass ein Entwickler braucht, um Software zu entwickeln?

Diese Frage kann jeder für sich selbst beantworten. Am Ende muss man sich halt nur darüber bewusst sein, dass es tatsächlich die eigene Entscheidung ist. Und dass diese Entscheidung Konsequenzen hat, die im Zweifelsfall auch Auswirkungen auf mein Unternehmen, mein Team und mich selbst haben.