Entscheidungen – schneller

Gestern ist via Twitter bei mir der offene Brief von Jeff Bezos an die Aktionäre von Amazon hereingeflattert. Er passt sehr gut in ein paar Beobachtungen die ich ebenfalls gemacht habe. Eine Dieser ist, dass es grösseren Unternehmen sehr schwer fällt schneller die richtigen Entscheidungen zu fällen. In einer Welt die sich immer schneller bewegt, wird dies aber immer mehr zu einem Erfolgsfaktor. Jeff nennt dies “High-Velocity Decision Making” und erläutert dazu vier Gedanken:

• “…never use a one-size-fits-all decision-making process…”
• “…most decisions should probably be made with somewhere around 70% of the information you wish you had…”
• “…use the phrase ‘disagree and commit’…” ( das werden wir wohl in nächster Zeit sehr oft höhen  )
• “…recognize true misalignment issues early and escalate them immediately…”

In der agilen Welt reden wir oft von Feedback-Cycle, hier geht es also um die Verkürzung des Decision-Making-Cycle als Teil des Feedback-Cycle, denn auch Jeff ist der Meinung, dass “customer focus” eine Firma vital hält.

Eine Beobachtung die ich machen konnte ist, dass In Organisationen die inzwischen Agile – meist in Form von Scrum – eingeführt haben, sich das Antipattern Water-Scrum-Fall etabliert. In den einzelnen (IT-/Feature-) Teams werden Agile-Engineering Practices wie XP oder Lean eingeführt. Als Agile-Management Practice wird auf Team-Ebene meinst Scrum etabliert. Die einzelnen Teams arbeiten nach agilen Prinzipien und trotzdem verbessert sich die Situation aus Unternehmenssicht – oder besser aus Sicht des Kunden – nicht oder nur sehr wenig.

Wenn man im Netz nach “Water-Scrum-Fall” sucht findet man sehr viele Informationen dazu. Meine bevorzugte Grafik kommt vom Jez Humble (einer der Autoren von Continuous Delivery, btw. man rate, welche die im verlinkten Artikel erwähnte Versicherung in der Schweiz ist, die schon in den 90’igern Continuous Delivery – bzw. sogar Continuous Deployment – etabliert hatte):

Es geht also um den “Water”-Teil.

Die Entscheidungsprozesse werden schlicht nicht geändert. Entweder ein Komitee – meist im Monatszyklus – entscheidet über die Schritte welche getätigt werden sollen oder der HiPPO (highest paid person’s opinion) Ansatz ist noch etabliert. Es gibt noch mehr Möglichkeiten wie das Water im Diagramm entsteht. Allen Ansätzen ist eigen, dass es zu lange dauert oder auf Basis von ungenügend Informationen bzw Wissen Entscheidungen gefällt werden. Die Begründung für solcherart Vorgehen, welche ich am meisten gehört habe, ist: Risikomanagement. In Zeiten schneller Veränderungen ist aber das grösste Risiko keine Entscheidung zu fällen – oder aber zu spät.

Es scheint auch, dass die Entscheidungen so schwierig zu ändern sind, weil es meist so lange dauert zu einer Entscheidung zu kommen. Und hier gefällt mir die Idee “disagree and commit” von Jeff Bezos, welcher der Zeit ein sehr, sehr starkes Gewicht gibt (“Consider how much slower this decision cycle would have been if the team had actually had to convince me rather than simply get my commitment.”).

Organisationen sollten also so aufgebaut werden, das die Entscheidungen schnell gefällt und auch schnell wieder geändert werden können. Entscheidungen sollten dort gefällt werden, wo das grösste Wissen vorhanden ist und am schnellsten reagiert werden kann. Auf diese Weise minimiert man das Risiko auf verschiedensten Ebenen.

Ein gutes Beispiel, dass auch grosse, etablierte Organisationen eine ganzheitliche, unternehmensweite agile Transformation erfolgreich angehen, ist die holländische Banken-Gruppe ING. Für mich sehr interessant zu lesen war, das ING wichtig ist, dass die Organisation nicht konstant ist, sondern sich selber den Anforderungen anpassen kann. Am Anfang stand bei ihnen die Frage “Why agile?” und gleich danach, was sie bereit waren aufzugeben: ‘…We gave up traditional hierarchy, formal meetings, overengineering, detailed planning, and excessive “input steering” in exchange for empowered teams, informal networks, and “output steering.” …’

Um schnell auf Fehlentscheidungen reagieren zu können, sollte ein Mechanismus etabliert werden, der solche Fehlentscheidungen aufdeckt. Dabei kann Hypothesis driven development (Siehe dazu auch mein letzter Post.) zur Anwendung kommen. Das Verwerfen einer Hypothese via Signalen ist dort eingebaut. 

Leider konnte ich noch keine praktischen Erfahrungen mit Holacracy machen. Ich verspreche mir aber sehr viel von diesem Ansatz, weil es u.a. den Entscheidungsprozess explizit dezentralisiert. Falls jemand Interesse hat mit mir an Holacracy zu arbeiten – bitte melden.