Kategorie: Management

Die leidige Teamgröße – Ein kleiner Rant

Daemonic Coder

„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

Daemonic Coder

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.

Entwickler sind keine Köche

Daemonic Coder

Außerhalb der Entwickler-Welt gibt es ja immer mal wieder den Einen oder Anderen, der mit „Entwicklersprech“ nichts anfangen kann. Der von Commits und Libraries noch nie gehört hat, der npm-Pakete nicht kennt und dem die Arbeit eines Entwicklers wie eine Mischung aus Magie und Pizzaessen erscheint.

Ich finde es vollkommen in Ordnung, in solchen Fällen den „Unwissenden“ die Arbeit mit Vergleichen näher zu bringen. „Ein Softwarearchitekt macht etwas Ähnliches wie jeder Architekt, er plant etwas, bevor es aufwändig umgesetzt wird. Nur eben eine Software, kein Haus.“

Aber wenn man mit Entwicklern redet, finde ich solche Vergleiche nicht passend. Ich kannte mal einen Manager, der seinem Entwicklungsbereich die Vorteile der Standardisierung näherbringen wollte und dies seinen Mitarbeiterinnen und Mitarbeitern an einem Beispiel aus der Industrie verdeutlichen wollte. Alle, so meinte er, sollten sich auf die Gewindegrößen einigen und so würden Schrauben, Muttern, Bohrer und Dübel immer zusammenpassen.

Bei den Mitarbeitern sorgte dies in erster Linie für Widerspruch: „Die Kundenwünsche lassen sich nicht in ein Dutzend Standardgrößen abbilden“, „Wir wollen nicht 1000x das Gleiche Loch bohren“ und „Muttern sind keine Schnittstellen“ waren die Reaktionen. Und in erster Linie war der Eindruck: Unser Manager hat offensichtlich keine Ahnung, was wir hier arbeiten, sonst müsste er sich nicht eines solchen Beispiels bedienen.

Warum nutze der Manager in diesem Fall kein Beispiel aus der Softwareentwicklung? Er hatte sogar Wissen aus der Softwareentwicklung (C und C++), hätte er erklärt, welchen Nutzen die Standardisierung der Programmiersprache hatte und beispielsweise den Compilerhersteller zu wechseln, dann wäre er von seinen Mitarbeitern meiner Meinung nach viel mehr ernst genommen worden.

Aber irgendwie scheint es sich etabliert zu haben, dass die Arbeit von Entwicklern immer mit der aus anderen Industrien oder Berufen verglichen werden muss. Schon in „Vom Mythos des Mann-Monats“ vergleicht Frederick Brooks die Arbeit eines Entwicklerteams mit einem Ärzteteam. Zugegeben, bei Erscheinen des Buches war die Erfahrung in der Softwareentwicklung auch noch nicht einige Jahrzehnte alt.

Ich persönlich fühle mich als Entwickler von Managern nicht ernst genommen, die ihre Ideen oder Vorstellungen einleiten mit „Nehmen wir mal an, Entwicklung wäre wie…​ Häuser bauen.“

Sicher, man kann daraus lernen, wie andere (Berufe) ihren Job machen, aber — nehmen wir doch mal an, wir würden Software entwickeln. Und darin wollen wir besser werden.

Business-Barnum

Daemonic Coder

„Genau, der kennt unserer Probleme! So läuft das bei uns auch“ manchmal wenn ein Berater oder Referent in eine Firma kommt, dann kommt dieser Eindruck auf und man fühlt sich gleich viel „sicherer“ in seinen (oder ihren, bitte entschudligt an dieser Stelle die rein männliche Form) Händen.

Manchmal muss ich bei so etwas allerdings an klassische Horoskope denken. (Oder an dubiose Persönlichkeitstests wie den MBTI.) Dort gibt es die sogenannten Barnum-Aussagen, die so allgemein oder schwammig gehalten sind, dass sich darin fast jeder wiederfindet. So sind auch manche Berater-Aussagen  so gehalten, dass sie auf praktisch jedes Unternehmen in einer gewissen Größe zutreffen könnten.

Hier mal ein paar Beispiele, die mir über den Weg gelaufen sind, von etwas, was ich gerne „Business-Barnum“ nennen möchte:

  • „Wir kämpfen oft damit, die richtigen Leute in die richtigen Projekte zu bringen, wir müssen die ‚right person for the job‘ finden.“
  • „Digitalisierung ist eine der großen Herausforderungen, der wir uns stellen müssen.“
  • „Wir müssen flexibler werden, dürfen dem aber eine sinnvolle Standardisierung nicht zum Opfer fallen lassen.“
  • „Unsere Prozesse sind zu schwerfällig für den sich schnell verändernden Markt.“
  • „Führung muss anders gedacht werden.“
  • „Die Veränderungen muss in den Köpfen, in den Werten und der Kultur stattfinden, nicht nur in den Prozessen.“

Ergänzungen sind mir sehr willkommen. 😉

Schwarze Magie bei HR

Daemonic Coder

In zahlreichen Seminaren, sei es zum Verkauf, Beratung, Management – immer wieder werden sie ausgepackt, die Menschenbild-Modelle. Insbesondere in einem „Führungs-Seminar“ bin ich da kürzlich wieder drauf gestoßen.

Sei es DISG, MBTI, was-auch-immer, alle Modelle haben gemeinsam, dass sie versuchen, Menschen in „Farben“, „Typen“, oder, wenn man beim Urvater dieser Modelle bleiben möchte, „Archetypen“ einzuteilen.

Ich erinnere mich an meinen ersten Kontakt mit solchen Modellen: Ich war etwa 16 und machte an der VHS eines kleinen Städtchens einen Rhetorik-Kurs. Der Trainer packte dort den MBTI aus und ließ uns einen Kurztest machen, danach bekamen wir alle, entsprechend unseres Typs, ein Blatt, auf dem Stand,was für ein „Typ“ wir sind. Ich war damals sehr erstaunt, fand ich mich doch in der Beschreibung recht gut wieder. Pronpt kaufte ich mir damals ein Buch zu dem Thema und jeder in meinem Umfeld, der nicht schnell genug davon lief, bekam auch so eine Typisierung und ich las aus dem Buch die entsprechende Seite mit der Persönlichkeitsbeschreibung vor. Immer schien es gut zu passen. Einmal wollte ich einen guten Freund etwas ärgern und las ihm genau „das Gegetnteil“ dessen vor, was sein Typ laut Test hätte sein sollen. Er fand sich darin recht gut wieder. Die nächsten Versuche waren dann, dass ich bei ein paar weiteren Bekannten eine zufällige Auswertung vorlas, die sich auch ganz zufrieden in der Beschreibung wieder fanden.
Sicherlich war das keine wissenschaftlich fundierte Kontrollgruppe, aber das Ergebnis ernüchterte mich damals ziemlich. Leider gab es noch kein Internet, so dass ich damals noch nicht herausfand, was Barnum-Aussagen sind, sonst wäre mir das Phänomen erklärbarer gewesen.

Kurz gesagt, dieser Test ist ziemlicher Humbug. Die anderen, wie bspw. DISG, sind auch nicht viel besser. Alle haben das Problem, dass damit Menschen zu sehr in Schubladen einsotriert werden. Vielleicht mag das Model dem ein oder anderen dabei helfen, zu verstehen, dass nicht alle Menschen gleich ticken – aber um ehrlich zu sein, wer das bei einem Führungsseminar vermittelt bekommen muss, der war vielleicht ohnehin schon der Falsche für eine Führungsrolle!