Ein Diskussionsstrang in im Deutschen Scrum Meeting am 11.07.2008 erscheint mir ziemlich wichtig, man könnte ihn auch so zusammenfassen: Erklären vor Eskalation.

Die Diskussion fing damit an, was man - in einem selbstorganisierten Team - tut, wenn sich ein Mitglied z.B. schlicht weigert, am Daily Scrum teilzunehmen. Wenn man nicht einfach aufgeben will, bleibt augenscheinlich nur eine Eskalation.

Das führt aber sofort in das Dilemma: kann man ein Team zwingen, sich selbst zu organisieren?

Ich habe dann zunächst eine andere Frage: warum muss man das erzwingen? Erfahrungsgemäß wollen fast alle Entwickler etwas vernünftiges erreichen und effektiv arbeiten. Sind wir auf eine der seltenen Ausnahmen gestossen? Oder ist der Entwickler zu oft betrogen worden? Oder hat er andere Gründe, fühlt er sich überfordert und hat Angst vor der Transparenz, die ein Daily Scrum herstellt?

Als Coach muss ich zuerst verstehen, wodurch diese Blockade zustande kommt. Sie kann am Entwickler liegen, an der Vorgeschichte, am Team, am Linienmanager oder an mir. Das Herausfinden ist aber ebenfalls keine Einbahnstrasse. Was ich in diesem Prozess beitrage, ist eine Argumentationskette:

Regeln -> Prinzipen -> Werte

Am Beispiel des Daily Scrum könnte das so verlaufen: Die Regel ist der Daily Scrum, dahinter liegt das Prinzip, dass in einem Scrum-Team Informationen über die eigene Arbeit ausgetauscht werden und dahinter der Wert, dass in einem selbstorganisierten Team die Arbeitszufriedenheit höher sein kann und auch das Unternehmen profitiert, weil einfach kreativer und effektiver gearbeitet wird.

Dann können wir entweder gemeinsam zu einer Diagnose kommen, wo das Problem liegt und hoffentlich zu einer Lösung kommen - oder ich habe als Coach verloren und muss eskalieren. Nochmal ausdrücklich: die Eskalation ist immer ein Stück Niederlage.

Interessant ist auch der andere Teil: es könnte an mir liegen. Ich nahm vor 2 Jahren an einer Open-Space-Session in einem Scrum-Gathering teil (Minneapolis 2006, die Session hatte Jiri Lundak initiiert) mit einer fast identischen Fragestellung. Dort erarbeiteten wir einen Katalog von Lösungsmöglichkeiten für eine fast identische Fragestellung. Und wir waren seht verblüfft, als wir uns das Flipchart vornahmen und die zeitliche Reihenfolge der Vorschläge analysierten: Am Anfang kamen die Vorschläge wie "Get him fired. Now." und gegen Ende der Session regnete es konstruktive Vorschläge, die immer auch eine Fragekomponente umfassten. Deshalb: achte immer auch auf Dich, Du könntest das Problem sein.