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.

Lesestoff: Organisationskulturen beeinflussen: Eine sehr kurze Einführung

Dem Titelzusatz „Eine sehr kurze Einführung“ wird das Buch durchaus gerecht – ich glaube, nach einer Zugfahrt hatte ich das kleine Büchlein gelesen. Aber es war eine kurze Zeit, in der ich viele Informationen und Ideen aufnehmen konnte.

Einen wichtigen Beitrag, den das Buch zum Verständnis von Organisationskulturen liefert, ist eine klare Begriffsdefinition und Abgrenzungen gegen andere Phänomene, die oft mit in den Topf „Organisationskultur“ geworfen werden. Alleine diese Definitionen sind die Lektüre des Buches wert. Auf Grundlage dieser Definition unterscheidet der Autor gibt der Autor viele beispiele für untaugliche Versuche, Kulturen zu beeinflussen. Etwas ernüchternd ist dann allerdings der Abschnitt, der aufzeigen soll, wie Organisationkulturen beeinflusst werden können. Durch die konstatierte enge Verbindung zwischen formaler Struktur und der Kultur einer Organisation sei die Änderung der formalen Strukturen der richtige Ansatzpunkt, so die Autoren. Leider bleibt es – vielleicht auch der Kürze des Buches geschuldet – bei dieser recht allgemeinen Aussage.

Trotzdem meiner Meinung nach eine klare Empfehlung an jeden, der sich mit Kulturarbeit im Unternehmen beschäftigen möchte, das Buch zu lesen.

 

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!