Das große M

Tom DeMarco nennt es die große "M"ethodik. Das große M stellt eine Dysfunktion in Organisationen dar. Man spricht davon, wenn blind auf eine Methodik vertraut wird und man die Methodik höher stellt als die Menschen, die sie ausführen müssen. Wem das vertraut vorkommt, dem ist der Teilsatz "Scrum-Einführung mit Management-Support" sicherlich bekannt.

Die Einführung einer Methodik vollzieht man auf zwei Arten:

  1. Methodik als Mittel angepasst an Situation, Plan und Organisation
  2. Methodik als Standard, auszuführen nach Rezept

Nutzt man eine Methodik, um sie wie bei 1. selbst an die eigenen Bedürfnisse anzupassen, wird man wenig an der Sinnhaftigkeit der Methodik zweifeln. Wichtig ist hier, sich seines Systems in dem man sich befindet klar zu sein. Obwohl die meisten Menschen sofort bejahen, dass sie diesen Überblick haben, wird auf den 2. oder 3. Blick meist klar, dass das nicht der Fall ist.

Wenig Raum in dieser Gasse - vielleicht eine Abkürzung aber sicher kein Raum für beste Ergebnisse.

Schreibt man eine Methodik wie bei 2. vor, die zwanghaft umgesetzt werden muss, verringert man den Status der Menschen, die man zur Methodik zwingt. So sagt man ihnen doch deutlich, dass die Kompetenz bei der Methodik liegt und nicht in den Köpfen der Menschen. Man degradiert sie und sie antworten mit angepasster Methodenhörigkeit als Protest, angedeuteter Inkompetenz als Widerstand oder offenen Anfeindungen als Ablehnung. Tritt ein Fehler auf, kann man ihn der Methodik zuschieben, man ist die Verantwortung los - prima!

Durch die Entmündigung verliert man das Commitment, da die bestmögliche Leistung und der Stolz der Menschen durch die Methodik blockiert wird.  Das ist nur die menschliche Seite. Die Imitation führt oft auch zu mangelhaften Ergebnissen, da Situationen nicht 1:1 übertragbar sind und methodenabhängige Folgeeffekte in jeder Umgebung wünschenswert sind.

Was ich nicht sage

Methoden "by the book" auszuführen ist schlecht. Das sehe ich nicht so.

Meiner Erfahrung nach waren beispielsweise die erfolgreichsten Scrums die, die "by the book" umgesetzt wurden. Jedoch lag dort auch immer der Fokus auf den Menschen und der Interaktion, und die Methodik war nicht Aggressor. Insbesondere dort wo ein Standard fehlt, kann eine Methode eine Baseline setzen. Wenn man seine Arbeitsweise ändert, lohnt es sich an einen Standard zu halten und sich davon aus fortzubewegen.

Was ich sage

Menschen benötigen die Herrschaft über ihre eigenen Prozesse. Keine aufgezwungen Prozesse, die fern ihrer Realität aufgezwungen werden.

Ein Beispiel:

Eine Abteilung wurde bestimmt der Prototyp für eine Scrum-Skalierung zu werden: 3 Teams, neu geschnitten und alle direkt nach Scrum arbeiten. Was für zwei Teams eingeschränkt in Ordnung war, war bei einem Team extrem kontraproduktiv, da sie bereits ihren besten Prozess gefunden hatten: ein Flow-System von der Anforderung direkt in die Produktion, optimiert von den Menschen, die bereits jahrelang Erfahrung mit ihrem eigenen System hatten. Einige neue Praktiken hätten sicherlich geholfen. Das fremde Paket zerstörte Motivation, Commitment und Durchsatz.

Was man noch bedenken sollte

Alle, die seit Jahren auf den Scrum-Hype aufspringen und alles Scrumatisieren verpassen eines: die Vielfalt es besser machen zu können. 

SVNWNK 

Ohne Commitment kein Team

Ohne Commitment ist ein Team nur eine Gruppe von Menschen: Ohne Einsatz, Verbindlichkeit, Verlässlichkeit oder gar Hingabe entsteht selten etwas Gemeinsames. Die Bereitschaft ein gemeinsames Ziel zu verfolgen eint eine Gruppe zu einem echten Team.

Weswegen mangelt es immer wieder an Verlässlichkeit, Verbindlichkeit, Einsatz oder Hingabe?

Ein oftmals unterschätzter Punkt ist das Fehlen des Stolzes auf die eigene Arbeit. Gerade auf diesen Punkt kann man aus vielen Perspektiven blicken.

Eine Perspektive ist es wenn die übertragene Verantwortung sich nicht mit den eigenen Mitteln deckt. Das kann sein, wenn die Fähigkeit fehlt eine Aufgabe dem Anspruch gerecht auszuführen. Wenn aus Herausforderung eine Überforderung wird. Eine gerade so oder schlecht ausgeführte Arbeit macht niemanden stolz. Unrealistische Fristen stellen auch eine Art der Überforderung und des "damit ungenügend Seins" dar. Wer so etwas aufstellt, nimmt den Team oft das Commitment am Start - obwohl ironischer Weise bei unrealistischen Fristen das höchste Commitment überhaupt notwendig wäre.

Ein sehr dynamischer Zug. Ohne Commitment nicht zu machen, nicht zu halten.

Foto "Dyno" von Marian Schütz (Flickr/ Creative Commons)

Ein weiterer Punkt, der hoffentlich bald ad acta gelegt wird, ist es dem Team vorzuschreiben schlechte Arbeit zu machen. Gibt's nicht? Leider doch. Es gibt immer noch Organisationen, die ihren Teams die Grundlage nehmen tadellose Produkte zu liefern. Darunter fallen in der Software-Entwicklung TDD-Verbot oder miese Coding-Guidelines. Insbesondere die Unternehmen, die keinen Verbesserungsprozess aus dem Team heraus gestatten oder fördern, untergraben die tägliche Arbeit und damit das tägliche Commitment. 

Brutal ist das nicht nur am eigenen Leib zu erfahren, sondern auch im Gespräch mit anderen. Ich kann mich noch zu gut an eine Interview-Reihe erinnern, die ich durchgeführt hatte: "Ich möchte gute Arbeit leisten, aber mir wird gesagt, ich soll schlechte Arbeit machen! Das ist ausreichend, nur nicht mehr rein stecken. Ich verzweifle hier."

Ob sich in diesem Unternehmen etwas geändert hat, ich hoffe schon, denn schon ein schlauer Mann hat mal gesagt:

Eliminate barriers that rob people of their right to pride in workmanship.
— W. E. Deming

Erste Schritte

Wie kann man einem Team seinen Stolz geben? Hier ein paar Punkte zum ausprobieren:

  • Applaudiert ihnen im Review
  • Lasst sie nur das in den Sprint ziehen, was sie schaffen
  • Belastet Teams nicht mit künstlichen, unrealistischen Fristen
  • Lasst sie ihre Arbeit verbessern und ihre Qualität erhöhen
  • Bringt sie mit Endnutzern in Kontakt
  • Released häufiger
  • Gebt euren Team-Mitgliedern den Auftrag zuhause oder bei ihren Freunden ihr Produkt vorzustellen

SVNWNK