Mission Command ist ein Konzept für den militärischen Konflikt. Zu militärischen Konflikten mag man so oder so stehen. Aus dem Konzept lassen sich aber nützliche generelle Ideen für das Zusammenwirken mehrerer Teams gewinnen, z.B. für Produktentwicklung und Softwareentwicklung.
Disclaimer
Ich war nie beim Militär. Dieser Blogpost basiert auf meinen Recherchen (Quellen habe ich unten angegeben). Immerhin hat ein Offizier der Bundeswehr nach einem Vortrag bestätigt, dass meine Darstellung passend wäre.
Command&Control und Mission Command
Bei Stephen Bungay habe ich in einem Vortrag das erste mal diese Darstellung gesehen, mit der er visualisiert hat, dass Alignment und Autonomie nicht in einem Spannungsfeld stehen müssen, sondern orthogonale Achsen sein können. Wenn man das hinkriegt, kann man hohe Autonomie bei großem Alignment schaffen.
Als guter Berater macht man da natürlich ein 4-Quadrantenmodell draus 🙂
Command & Control (links oben): Alignment wird durch Anweisungen erzeugt. Es gibt wenig Autonomie bei der Umsetzung. Das ist weniger gut geeignet, um in dynamischen Situationen zu agieren, weil die immer wieder notwendige Anpassung des Handelns zentral entschieden werden muss. Für statische Kontexte funktioniert der Ansatz aber gut.
Mission Command (rechts oben): Das Was und Warum wird klar gemacht und es wird dafür gesorgt, dass die Menschen die notwendigen Fähigkeiten besitzen. Die konkrete Umsetzung und die Reaktion auf die Situation vor Ort obliegt aber den Menschen. Wir bekommen Alignment und Autonomie.
Chaos (rechts unten): Es gibt einen hohen Grad an Autonomie, aber das Alignment fehlt.
Die meisten Unternehmen kommen aus der Command & Control-Welt. Dass sie einen anderen Umgang mit der zunehmenden Dynamik der Umwelt finden müssen, ist vielen Unternehmen klar. Agile Entwicklung schien dafür passend. Mit der Einführung agiler, selbstorganisierter Teams stellte sich aber oft das Gefühl ein, dass man nicht bei Mission Command, sondern bei Chaos gelandet ist.
Das zeigt bereits, dass Mission Command nichts ist, was man dadurch kriegen kann, dass man ein bestimmtes Vorgehen implementiert. Es braucht harte und langwierige Arbeit. Viele Unternehmen haben dann lieber versucht, das Chaos durch mehr Vorgaben und Struktur einzudämmen und sind damit im Grunde wieder Richtung Command & Control zurückgerudert. Teams blieben aber meist bestehen, so dass die Unternehmen jetzt eine effektivere Form von Command&Control haben als früher. Von Mission Command ist das aber noch Welten entfernt.
Mission Command
Wir bekommen Mission Command nicht dadurch, dass wir ein bestimmtes Vorgehen, eine Struktur oder ein Framework implementieren!
Leider!
Je nach Quelle werden 3 bis 4 Aspekte angeführt, die für Mission Command notwendig sind. Ich mag diese:
- Absicht: Was soll warum erreicht werden?
- Schwerpunkt: Was ist der Handlungsschwerpunkt?
- Gemeinsames Bewusstsein: Wir haben ein gemeinsames Verständnis davon, welche Akteure welche Rolle spielen und wie sie sich verhalten werden.
Jeder der drei Aspekte ist anspruchsvoll herzustellen und keiner lässt sich durch eine Methodik herbeizaubern. Es braucht Übung und Erfahrung.
Absicht
Allen Beteiligten muss klar sein, was warum erreicht werden soll. Wenn mir selber klar ist, was ich warum erreichen will, bedeutet das noch lange nicht, dass ich das so kommunizieren kann, dass andere es auch verstehen. Man kann durch Übung immer besser darin werden. Auf jeden Fall braucht es einen Mechanismus, um sicherzustellen, dass wir ein gemeinsames Verständnis der Absicht haben.
„Habt ihr das verstanden?“ ist vermutlich die schlechteste Frage, die man dazu stellen kann. Viel besser geeignet ist Backbriefing: Diejenigen, die die Mission erledigen sollen, überlegen sich, wie sie vorgehen wollen und präsentieren dem Missions-Geber ihren Plan. Das tun sie nicht, um sich auf den Plan zu committen (dann könnten sie ja nicht mehr flexibel auf die Situation reagieren), sondern damit der Missions-Geber prüfen kann, ob seine Absicht richtig verstanden wurde. Wenn sie missverstanden wurde, wird das aus dem Plan ersichtlich werden.
Schwerpunkt
In militärischen Kontexten wird zur Erklärung des Scherpunkt-Konzeptes häufig der Ablenkungsangriff verwendet. Die Idee besteht darin, den Feind zur Ablenkung von vorne anzugreifen, um ihm dann in den Rücken zu fallen. Dieser Angriff ist der Schwerpunkt. Allen anderen Einheiten (z.B. Versorgung, Ablenkungsangriff) ist klar, was der Schwerpunkt ist und dass sie ihr Verhalten so anpassen müssen, dass sie den Schwerpunkt unterstützen.
Bungay zitiert ein einen Kampf der preußischen und der französischen Armee. Eine preußische Einheit hatte die Aufgabe, sich den Franzosen in den Weg zu stellen, aber nicht anzureifen. Die Verlangsamung der Franzosen sollte einer anderen Einheit erlauben, den Franzosen in den Rücken zu fallen. Leider sind die Franzosen auf die Idee gekommen, zur Seite auszuweichen („kein Plan überlebt den ersten Feindkontakt“). Daraufhin hat die blockierende Einheit entschieden, die Franzosen doch anzugreifen, damit der Schwerpunkt-Angriff möglich bleibt. Das war dann auch der Fall und die Franzosen wurden geschlagen. Hinterher gab es in der preußischen Armee Diskussionen darüber, ob die verantwortlichen Offiziere vor’s Kriegsgericht gestellt werden sollten, weil sie einen Befehlt missachtet hatten (nicht anzugreifen). Aus Mission Command-Sicht haben sie aber genau das Richtige getan. Sie haben den Schwerpunkt unterstützt.
Angriffe dieser Art haben wir in der Produktentwicklung zum Glück selten. Dennoch kann es sehr hilfreich sein, auch hier auf strategischer Ebene den Schwerpunkt zu definieren, an dem sich alles ausrichten soll. Operationalisieren lässt es sich z.B. mit dem Goal#1-Konzept (das ist hier genauer beschrieben).
Einen guten Schwerpunkt zu definieren, ist nicht leicht und fühlt sich oft riskant an. Auch hier gibt es keinen Mechanismus, der verlässlich zu einem guten Schwerpunkt führt. Übung und Erfahrung kombiniert mit offenen Dialogen und unterschiedlichen Perspektiven führt zum Ziel.
Gemeinsames Bewusstsein
Wir wollen uns schnell an geänderte Randbedingungen anpassen können. Wenn wir dazu jedesmal ein Meeting mit allen Teams brauchen, werden wir träge in unserer Anpassung. Viel schneller sind wir, wenn wir keine Meetings brauchen. Dazu ist es notwendig, dass jedes Team einschätzen kann, was die anderen Teams als nächstes tun werden. Dann können sie ein Verhalten wählen, dass harmonisch zu dem Verhalten der anderen Teams ist (Boyd spricht interessanterweise nicht von Alignment, sondern von Harmony). Natürlich informieren die Teams die anderen Teams darüber, was sie gerade tun, so dass ggfs. ein Nachsteuern möglich wird. Die Koordination findet nicht synchron (Meeting) statt, sondern asynchron (Info).
Damit das funktioniert, braucht es gemeinsames Bewusstsein der beteiligten Teams. Das gemeinsame Bewusstsein braucht:
- Klarheit, welche Akteure es gibt.
- Klarheit, welche Rolle/Aufgabe welcher Akteur hat (inkl. Schwerpunkt, Nebenpunkt).
- Vertrautheit der Teams untereinander, so dass die wahrscheinlichen Aktionen abgeschätzt werden können.
- Vertrauen der Teams untereinander, so dass die Teams gegenseitig davon ausgehen, dass die Teamentscheidungen passend in dem jeweiligen Kontext sind und man sich daher an den Entscheidungen der anderen Teams ausrichtet.
Das Militär hat relativ viel Zeit zum Üben im Verhältnis zur Zeit im Kampfeinsatz. In der Geschäftswelt haben wir den Luxus nicht (dafür ist es auch weniger gefährlich) und müssen den kontinuierlichen Aufbau des gemeinsamen Bewusstseins in unsere tägliche Arbeit integrieren.
Quellen
Der Militärhistoriker Stephen Bungay hat in seinem Buch „The Art of Action“ wichtige Mission Command-Elemente historisch aufgearbeitet, beginnend bei der Auftragstaktik der preußischen Armee.
Col. John Boyd (US Air Force) hat den OODA-Cycle definiert und daran gearbeitet, das Verständnis von Mission Command zu verbessern. Von ihm gibt es wenig Aufgeschriebenes. Es gibt eine (leider tontechnisch sehr schlechte) Aufnahme seines „Patterns of Conflict“-Briefings für Generäle auf Youtube (mehrteilig).
Robert Coram liefert in seiner Biographie „Boyd: The Fighter Pilot Who Changed the Art of War“ über Boyd ein paar weitere Eindrücke.
Chet Richards hat mit John Boyd zusammengearbeitet und Boyds Konzepte in seinem Buch „Certain to Win: The Strategy of John Boyd, Applied to Business“ auf Unternehmensstrategie übertragen.
Ben Ford (Ex Militär) hat verschiedenen nützlichen Content (Podcast) beigetragen. Ich habe eine Online-Schulung bei ihm belegt, die ich sehr gut fand, aber im Internet nicht mehr finden kann.
Über den Autoren
„Wir müssen immer wieder das Unmögliche versuchen, um das Mögliche zu erreichen.“ H. Hesse
E-Mail: stefan.roock@it-agile.de
LinkedIn: https://www.linkedin.com/in/StefanRoock/
Mein Name ist Stefan Roock und ich will eine bessere Arbeitswelt schaffen; eine in der Kunden von den Produkten und Services begeistert sind, Mitarbeitende ihre Arbeitsbedingungen lieben, Unternehmen erfolgreich sind und sich verantwortlich in der Gesellschaft verhalten. Ich helfe Menschen und Unternehmen dabei, ihre Potenziale für dieses Ideal zu entfesseln.
Ich verbreite und entwickle seit 1999 neue Arbeits- und Organisationsansätze in Deutschland. Das habe ich zunächst als Entwickler in agilen Teams, später als Scrum Master/Agile Coach und Product Owner getan. Ich habe seitdem mein Verständnis dessen, was für begeisternde Produkte und Arbeitsbedingungen notwendig ist, kontinuierlich weiterentwickelt. Besondere Produkte entstehen nicht dadurch, dass Teams „agil“ Anforderungen umsetzen. Stattdessen müssen Teams gemeinsam im direkten Kundenkontakt Produkte und Services gestalten.
Auf diesem Weg habe ich unter anderem die it-agile GmbH mitgegründet.