Gefangen im Zielsystem

Zielsysteme sind ein wichtiger Bestandteil in der Steuerung fast aller größerer Unternehmen. Manchmal ganz „klassisch“ mit vorgegebene Zahlen-Zielen, an denen noch irgendein Bonus hängt, manchmal etwas „moderner“ in der Form von OKRs.

Viele dieser Systeme sind meiner Meinung nach allerdings kaputt; sie sind in der Realität nicht so brauchbar, wie es die Theorie erstmal vermuten lässt. Darauf möchte ich in ein paar Artikeln hier eingehen, vorher möchte ich jedoch etwas Theorie stellen, da diese das meiner Meinung nach gängigste Problem von Zielsystemen erklären kann: das Gefangenendilemma.

Das Gefangenendilemma kennt vielleicht der ein oder andere aus der Spieltheorie. Die Geschichte in dem Modell funktioniert in etwa so:

Zwei Personen, die gemeinsam ein schweres Verbrechen verübt haben, werden verhaftet und einzeln verhört. Das schwere Verbrechen kann leider nicht zweifelsfrei bewiesen werden, wohl aber ein kleineres Verbrechen. Daher bietet der Staatsanwalt folgenden Deal an: Wenn Du gestehst, Dein Kollege aber nicht, so wirst Du als Kronzeuge frei kommen und der andere kommt für 20 Jahre ins Gefängnis. Gesteht ihr beide, kommt ihr beide für jeweils 15 Jahre in den Knast. Gesteht keiner von euch, so kommt ihr zumindest wegen des kleineren Vergehens für jeweils 5 Jahre ins Gefängnis.

Der rationale Verbrecher denkt nun so: Wenn mein Kumpel nicht gesteht und ich auch nicht, so muss ich für 5 Jahre ins Gefängnis. Wenn ich gestehe, dann gar nicht. Also wäre es in diesem Fall besser für mich, wenn ich gestehe. Wenn mein Kumpel uns aber verpfeift und ich nicht, so muss ich für 20 Jahre ins Gefängnis, es sei denn, ich gestehe auch, dann sind es nur 15. Also wäre es auch in diesem Fall besser, zu gestehen. In beiden Fällen wäre es also die rationale Entscheidung jedes Einzelnen, das Verbrechen zuzugeben. Am Ende werden also beide gegen den anderen Aussagen, womit insgesamt 30 Gefängnisjahre (15 für jeden) fällig werden.

Die optimale Lösung aus der Gesamtsicht (zumindest aus der Gesamtsicht eines Verbrecherkonsortiums) wäre es natürlich, wenn beide schweigen, da dann insgesamt nur 10 Jahre Gefängnis drohen. (Gesteht einer, so sind 20 Gefängnisjahre abzugelten, was auch schlechter ist.) Allerdings ist rein aus der Spieltheoretischen Sicht das Ergebnis „beide halten dicht“ nicht erreichbar, da es für den Einzelnen IMMER besser wäre, den anderen zu verraten.

Verallgemeinert man diese Geschichte, so sprechen wir davon, dass die beiden Verbrecher die „Spieler“ in diesem Spiel sind, wenn der Eine gegen den Anderes aussagt, so defektiert er. (Das ist das Gegenteil von Kooperation. Natürlich kooperiert der Verbrecher mit der Staatsanwaltschaft, aber hier geht es um die Kooperation der Spieler untereinander.)

Zusammengefasst: In einer Situation wie in einem Gefangenendilemma ist es für die Spieler immer rational zu defektieren. Das ist das sogenannte „Nash-Gleichgewicht“, das heißt, kein Spieler kann durch einseitige Abweichung seines Verhaltens (also Kooperation) sein Ergebnis verbessern. Im Gefangenendilemma ist das Nash-Gleichgewicht allerdings keine Pareto-optimale Lösung. Pareto-optimal wäre die Lösung dann, wenn aus Gesamtsicht das Ergebnis nicht verbessert werden könnte. Im Gefangenendilemma ist das grundlegende Problem, dass die Pareto-optimale Lösung eben kein Nash-Gleichgewicht ist und somit nicht erreicht werden kann.

Tiefer möchte ich auf das Gefangenendilemma an dieser Stelle gar nicht eingehen, es gibt außerdem Seiten, die das Thema umfänglicher und besser darstellen. (Zum Beispiel hier oder hier.) Insbesondere wird es interessant, wenn man das Modell auf mehr als 2 Spieler (n-Personen) ausdehnt oder sogar wiederholt (das iterierte Gefangenendilemma).

Allerdings möchte ich an dieser Stelle schon eine Feststellung in den Raum werfen, meiner Meinung nach das Grundproblem aller Zielsysteme:

Jedes hinreichend komplexe Zielsystem eines Unternehmens stellt ein n-Personen-Gefangenendilemma dar, wodurch die Kooperation der Bereiche effektiv verhindert wird.

Planeinhaltung

In einem anderen Artikel hatte ich ja bereits darauf hingewiesen, dasses wichtig ist, einen Plan von einer Prognose zu unterscheiden. Wichtig ist dies insbesondere auch, weil er offensichtlich macht, wie unsinnig es in solchen Situationen ist, eine Planeinhaltung sicherstellen zu wollen.

Bleiben wir beim einfachen Beispiel aus dem genannten Artikel: Ich prognostiziere, dass es Im Dezember in Deutschland schneit. Ich plane daher, einen Mantel anzuziehen. Nun passiert irgendwas und ich ziehe den Mantel nicht an. Beispielsweise ist es doch viel zu warm oder ich befinde mich entgegen meiner ursprünglichen Prognose gar nicht im kalten Deutschland, sondern in Australien. Es wäre ziemlich widersinnig, die Planeinhaltung zu überprüfen, sinnvoll wäre es aber eventuell zu untersuchen, warum die Prognose nicht stimmte – zumindest bevor uns der Klimawandel in erster Linie deswegen zu Schaffen macht, weil wir uns in dicke Mäntel einwickeln.

Eine Planabweichung zu betrachten ist oft Unsinn. Statt dessen sollte eine Abweichung der zu Grunde liegenden Prognose betrachtet werden.

Die leidige Teamgröße – Ein kleiner Rant

„Die optimale Teamgröße beträgt sieben Mitglieder, plus oder minus zwei“, so steht es im Scrum Guide. Diese Zahl, so erlebe ich es, wird mehr und mehr als „in Stein gemeißelt“ angenommen und in einigen Firmen, die sich Richtung eines agilen Unternehmens transformieren möchten, als gesetzt angenommen und für alle Teams verbindlich vorgeschrieben. „Ihr seid zu zehnt? Dann teilt euch auf. In zwei 5er-Teams Weil: Steht da so!“

Das ist so ein Schwachsinn! Und zwar aus so vielen Gründen Schwachsinn, dass ich mich mit wachsender Begeisterung darüber aufregen könnte.

Zunächst mal wäre es vielleicht hilfreich, den oben zitierten Absatz weiterzulesen, da wird nämlich schon von den Autoren des Scrum Guides darauf hingewiesen, dass das ein Erfahrungswert ist, dass es aber auch funktionierende Gegenbeispiele gibt.

Außerdem beruht diese „Teamgröße“ – außer auf der Erfahrung der Scrum Guide Autoren – auf einer von einem Psychologen gemachten Erkenntnis. (Millersche Zahl) Ohne diese nun allzu sehr auf Stichhaltigkeit oder Übertragbarkeit prüfen zu wollen, es gibt ein Kommunikationsproblem dabei: Wein ein Psychologe oder Soziologe schreibt „7 +- 2“, so versteht ein Mathematiker (oder Informatiker oder Manager) oft „den Zahlenraum von 5 bis 9“. Der Psychologe meine allerdings „Durchschnitt 7, Standardabweichung 2“. Ja, unterschiedliche Menschen mit unterschiedlichen Hintergründen kommunizieren unterschiedlich! Leider sind es immer wieder Manager, für deren Weiterbildung in Kommunikationsschulungen mit den tollsten Kommunikationsmodellen und fragwürdigen Persönlichkeitstypen-Kategorisierungen tausende Euro gesteckt wurden, die nicht das nicht verstehen!

Das nächste, was mich an der one-size-fits-all Einstellung ärgert, ist, dass ständig vergessen wird, dass man vielleicht auch sagen muss, wofür die „ideale Teamgröße“ definiert werden soll.

Die Aussage aus dem Scrum Guide bezieht sich nämlich auf – Trommelwirbel – Scrum Teams! Soll das Team Fußball spielen, so wäre 9 eine ziemlich unangenehme Obergrenze, wenn der Gegner mit 11 Spielern aufläuft. Soll das Team effizient Entscheidungen treffen, so könnte eine gerade Anzahl Teammitglieder wenig hilfreich sein. Unterschiedliche Aufgaben können außerdem unterschiedliche Kommunikationsstrukturen erfordern, was auch wieder Einfluss auf die Teamgröße haben kann. Muss im Team wirklich jeder die Aufgaben der anderen vollständig verstehen oder übernehmen können? Dann sind 7 eventuell schon viel zu viel (weil ich dann auch die Skills aller Kollegen haben müsste). Müssen viele Skills aus unterschiedlichen Bereichen abgedeckt werden? Dann wird die Anzahl der Mitglieder vielleicht auch mal höher ausfallen dürfen.

Und nicht zuletzt: Teams sind aus Menschen zusammengesetzt. Menschen sind unterschiedlich. Dass eine „mathematische Regel“ hier einfach nicht der Weißheit letzter Schluss sein kann, sollte offensichtlich sein.

Klar, Teamgrößen sollten hinterfragt werden. Wenn mir ein Scrumteam sagt, es habe 14 Mitglieder, frage ich als Coach sicher sehr kritisch, ob das funktioniert und würde eventuell Versuche vorschlagen, mit Aufteilungen zu arbeiten. Aber ein „die Regel sagt, das darf nicht sein“ ist Quatsch.

Der überstrapazierte Plan

Planungsklausuren, Planungsworkshops, strategische Planungen, operative Planungen, Planungsteams, Planzahlen… Man sollte meinen, ein Großteil der Wirtschaft wäre reine Planwirtschaft.

Leider ist das Gegenteil der Fall: Das meiste ist recht planlos.

Das liegt nicht in erster Linie daran, dass die Planenden schlechte Planer sind, sondern daran, dass das, was in einem Unternehmen unter einem Plan verstanden wird, meist gar kein Plan ist. Doch worum handelt es sich dann?

Oft ist das, was in Unternehmen „Plan“ genannt wird entweder eine Wunschvorstellung, oder bestenfalls eine Prognose.

Die Wunschvorstellungen kennt wohl fast jeder: In fast allen Umsatz-Planungen eines Unternehmens handelt es sich um eine aufsteigende Kurve. Das ist typischerweise kein Plan, sondern eine Hoffnung, ein Wunsch, bestenfalls ein Ziel. Aber viel mehr störe ich mich an den anderen „falschen Plänen“, nämlich an denen, bei denen es sich eigentlich um Prognosen handelt.

Ein typisches Beispiel für dieses Phänomen ist eine „Absatzplanung“ (zumindest, wenn wir mal davon ausgehen, dass es sich nicht um einen Wunsch-Plan handelt). Es wird ein verändertes Konsumverhalten eines Kunden nicht geplant, sondern prognostiziert – darauf aufbauend kann dann ein Plan erstellt werden, beispielsweise Ausweitung oder Reduktion der Produktion.

Ein ganz anderes Beispiel als Analogie: Der Wetterbericht ist ganz offensichtlich keine „Planung“, sondern eine Prognose. Auf Grund dieser Prognose kann ich Planungen machen, beispielsweise für den Sommer leichtere Kleidung kaufen. Aber es ist wichtig, Prognose und Plan zu unterscheiden. Ändert sich das Wetter, so wäre der Versuch der „Planeinhaltung“ (kurze Hosen bei Regen, zum Beispiel) ziemlich absurd. Trotzdem ist es genau das, was in Unternehmen oft passiert.

Mein Wunsch: Unterscheidet Prognose und den daraus abgeleiteten Plan! Wenn man eine Prognose auch „Prognose“ nennt, so ist keine falsche Erwartungshaltung daran geknüpft, statt dessen kann man sinnvolle Pläne machen.

Feedback und Feedback-Mythen

Feedback sollte kein „Vorwurf“ sein, so liest man oft. Meist wird in diesem Kontext folgendes www-Vorgehen beim Feedback vorgeschlagen:

  1. Wahrnehmung – Was habe ich an Verhalten beobachtet?
  2. Wirkung – Welche Wirkung hat dies auf mich?
  3. Wunsch – Was wünsche ich mir vom Gegenüber.

Damit, so die Idee, sei man mit dem Feedback „bei sich“ und würde nicht sein Gegenüber angreifen.

Ich halte von diesem Vorgehen nichts. Selbst, wenn man es „richtig“ macht, was auch oft genug nicht vorkommt. Ein Beispiel:

„Ich beobachte, dass Du zu unseren Dailies immer 5 Minuten zu spät bist. Das wirkt auf mich, als würdest Du meine Zeit nicht schätzen. Ich wünsche mir, dass Du in Zukunft pünktlich bis.“

Obiges Beispiel entspricht sogar halbwegs dem www-Schema, allerdings gibt es einen großen Fehler: Der Wunsch bezieht sich auf das beobachtete Verhalten, nicht auf die Wirkung. Wenn ich mein Feedback so verpacke, dann hat die „Wirkung“ einzig den Zweck, ein weiterer Vorwurf und eine „Waffe“ zu sein. Davon abgesehen hat das Gegenüber keine „Handlungsoptionen“. Zu guter letzt ist da das kleine Wörtchen „immer“ in der Beobachtung, das immer veralgemeinert und nie richtig ist. 😉 Nächster Versuch:

„Ich beobachte, dass Du zu unseren Dailies bisher 5 Minuten zu spät gekommen bist. Das wirkt auf mich, als würdest Du meine Zeit nicht schätzen. Ich wünsche mir, dass ich das Gefühl habe, dass Du meine Zeit in den Meetings wertschätzt.“

Das ist schon etwas besser. Zumindest hat der Angesprochene nun Optionen. Er könnte vorschlagen, das Meeting später anzusetzen, da er zur bisherigen Zeit gar nicht kann. In der ersten Variante hatte er diese Möglichkeit nicht, da der Wunsch schon fast zu spezifisch war.

Noch besser gefällt es mir aber, wenn man im Gespräch den Wunsch gar nicht formuliert, sondern eine Frage anschließen kann. (Was sicher nicht immer möglich ist, aber ich gehe gerade von einem ansonsten eigentlich funktionierenden Teamgefüge aus.)

„Ich beobachte, dass Du zu unseren Dailies bisher 5 Minuten zu spät gekommen bist. Das wirkt auf mich, als würdest Du meine Zeit nicht schätzen.Wie siehst Du das?“

Manch einer mag nun einwenden, dass man „Feedback doch auch annehmen solle“ und dass so wie in diesem Beispiel eine „Rechtfertigung“ ausgelöst würde. Um ehrlich zu sein, das entspricht gar nicht meinem Menschenbild. Zunächst: Eine Erklärung ist keine Rechtfertigung. Außerdem: Man muss nicht jedes Feedback annehmen.

Die letzte Variante würde es beispielsweise erlauben, dass der Angesprochene eine Erklärung abgeben kann – eventuell kann er zeitlich das Daily gar nicht schaffen. Er kann auch darauf eingehen, dass er die Wirkung gar nicht intendiert habe und so den Feedbackgeber eventuell „entlasten“, da dessen Bedürfnisse ernst genommen werden. Kurz, man gibt so die Möglichkeit, dass gemeinsam an der Wirkung gearbeitet werden kann, anstatt dass ein Symptom, eventuell zu aller Unzufriedenheit, behoben wird.

OKR – Mini How-To

Wie funktionieren OKR? Aus den Google-Handreichungen und anderen Quellen destilliert:

  • „Objectives“ beschreiben das „Was“:
    • Drücken Ziele und Absichten aus
    • Sind aggressiv aber realistisch
    • Sind greifbar objektiv und eindeutig – es sollte durch einen rationalen Beobachter erkennbar sein, ob das „Objective“ erreicht wurde.
    • Es muss einen erkennbaren Wert für die Systel haben.
  • „Key Results“ beschreiben das „Wie“:
    • Drücken messbare Meilensteine aus, ihre Erreichung tragen zum Fortschritt der Bestandteile eines Objectives sinnvoll bei.
    • Beschreiben Ergebnisse, keine Aktivitäten.
    • Enthalten Belege für deren Erreichung
    • Sind die KR alle erreicht, so ist das Objective erreicht
  • Es gibt 2 Arten von OKRs: Verpflichtete (Commited) und Ehrgeizige (Aspirational). Verpflichtete OKRs müssen zu 100% erreicht werden, bei ehrgeizigen ist eine Erfüllung von etwa 70% zu erwarten.
  • Klassische Fallen und Fehler im Schreiben von OKRs:
    • Verpflichtende und ehrgeizige OKRs werden nicht unterschieden
    • Business-as-Usual OKRs
    • Schüchterne ehrgeizige OKRs
    • Sandbagging
    • Who-cares-Objectives / Objectives mit niedrigem Wert
    • Unzureichende Key-Results

Product Owner = On-Site Customer?

Bei einem IT-Dienstleister, der Softwareprojekte für Kunden durchführt, höre ich immerwieder den Satz im Rahmen von Scrum-Projekten: „Der ProductOwner muss vom Kunden kommen.“ Auch wenn dies teilweise richtg sein mag, so verwehre ich mich gegen die starke Pauschalität dieser Aussage.

Der ProductOwner ist dafür verantwortlich, was gebaut wird. Er bestimmt die Fachlichkeit der Anwendung und priorisiert, welche Anforderungen wichtig sein. Er hilft bei Klärung fachlicher Fragen. Vieles davon ist sicherlich bei einem PO, der vom Kunden der Software kommt, gut aufgehoben. Insbesondere die fachlichen Fragen sind oft so speziell, dass ein PO von Kundenseite hier eindeutig Vorteile bietet.

Aber es gibt auch Gegenbeispiele; Microsoft Word beispielsweise, hier wäre ein PO, der von einem bestimmten Verlag kommt, eine PO, die Autorin eines Buches wäre, ein PO aus einem Sekretariat oder eine PO aus einem Übersetzungsbüro keine gute Idee. Denn dann würde die Software vielleicht genau für diese Person oder eventuell sogar für diesen Anwendungsfall geeignet sein, das Produkt würde aber sicherlich nicht in allen diesen Bereichen eingesetzt werden. Hier sind die Nutzer „nur“ Stakeholder der Software, ein ProductOwner muss die Interessen der Nutzer gegeneinander abwägen und teilweise auch hinten anstellen.

Meiner Meinung nach sollte es nicht unbedingt der Default sein, dass „der PO von Kundenseite kommen muss“. Scrum nennt auch explizit diese Rolle ProductOwner, nicht „On-Site Customer“, wie er in eXtreme Programming existiert!

Um erfolgreich zu sein, so der Scrum Guide, müssen die Entscheidungen des PO in der Organisation respektiert werden. Hier kann auch ein Knackpunkt liegen, wenn der PO von Kundenseite kommt. Denn eine kundenseitige PO ist beispielsweise Governance-Vorgaben nicht unterworfen, die für einen Betrieb der Software nötig sein können.

Keine Lösung ist es zumindest, einen „internen PO“ und einen „externen PO“ nebeineinander zu stellen!

Scrum statt Monatsabschluss?

Wenn ein größeres Unternehmen sich in Richtung Agilität transformieren möchte, so kommt früher oder später der Zeitpunkt, an dem – und sei es, um „dabei zu sein“ – auch Querschnittsbereiche wie HR oder Controlling auf einmal agile Methoden anwenden wollen. So kam es, dass ich kürzlich ein Gespräch mit Kollegen aus dem Controlling hatte, die unbedingt Scrum einführen wollten.

Ich muss zugeben, dass mir die Arbeit des Finanz-Bereiches zunächst noch etwas schleierhaft war, daher fragte ich mich zunächst durch, wie denn die tägliche Arbeit aussähe. Und siehe da, im Controlling besteht die tägliche Arbeit gar nicht aus Projekten oder der Produktumsetzung. Statt dessen werden monatlich die Auslastungs- und Umsatzzahlen erhoben und geprüft, dann gibt es einen monatlichen Bericht. Super, damit lässt sich doch auch leicht ein Sprintziel definieren, oder? Einfach jeden Monatsabschluss als Sprintziel benennen…

Das ist natürlich absolut sinnlos. Durch Sprints ist hier gar nichts gewonnen; die Frage ist nämlich vollkommen falsch gestellt. Wenn das Unternehmen agil werden soll, so muss nicht jeder Querschnittsbereich agile Methoden befolgen, die erste Frage sollte sein, wie sich die Arbeit inhaltlich ändert.

Ist es beispielsweise bislang im Controlling und in der Buchhaltung die Aufgabe des Finanzbereiches, in Richtung Geschäftsführung die Zahlen zu kommunizieren, damit diese strategische Entscheidungen treffen kann, so ändert sich in einem agilen Unternehmen die Zielrichtung der Kommunikation: Alle Mitarbeiter müssen die Zahlen verstehen, um selbstorganisiert arbeiten zu können und um strategische Entscheidungen zu erarbeiten.

Auch eine klassische Budgetierung steht einem agilen Unternehmen im Weg. Eventuell kann das Bild eines „internen Kredites“ für Innovationen erfolgversprechender und für die Mitarbeiter fassbarer sein.

All dies darf dann auch meiner Meinung nach gerne in den „klassischen Strukturen“ methodisch abgebildet werden. Eine Methode zu wählen, die dies eventuell besser unterstützt ist dann zumindest erst der zweite (oder dritte) Schritt.