Feedback kann nicht kontraproduktiv sein

Neulich bei einem meiner Kunden …

Wir befinden uns gerade inmitten einer Transformation eines kompletten IT Bereiches mit etwa 120 Mitarbeitern zu einer agilen Organisationsform, die sich maßgeblich am Scrum Framework orientiert. Die Mitarbeiter arbeiten in mehreren Teams an der Implementierung einer recht umfangreichen Applikationsplattform. Aus umliegenden Fachbereichen prasseln mehr oder weniger unkoordiniert Anforderungen herein. Viele der Anforderungen müssen durch technische Lösungen (oder Lösungsanteile) in mehreren Teams umgesetzt werden.

Um den Austausch zwischen den Entwicklungsteams zu verbessern, wurde vom Management entschieden, tägliche, Team-übergreifende Stand-Ups durchzuführen, zu denen je ein Teamvertreter kommen sollte. Gäste waren bei Interesse willkommen. Das kennt man auch unter dem Namen Scrum of Scrums. Die Maßnahme wurde vom Scrum Master Team, sozusagen als verlängertem Arm der Management-Ebene, „eingesteuert“.  Die Stand-Ups wurden also nicht von den Teams initiiert und es gab gewisse Vorgaben, dass man sich vorrangig auf fachlicher Ebene austauschen sollte um die vielschichtigen Abhängigkeiten der Anforderungen in den Griff zu bekommen.

Schon zu Beginn gab es einige Stimmen, wie “Oh Gott, noch ein Meeting …” und nach wenigen Wochen nahm die Teilnehmerzahl rapide ab. Es bestand kaum mehr Interesse an dem Termin. Aus dem Management wurde entschieden, dass man etwas tun müsse und das man Feedback einholen würde. Ein Plakat wurde gut sichtbar im Großraumbüro aufgehängt und per EMail wurden alle dazu aufgefordert, darauf Feedback zu hinterlassen.

Zunächst standen einige wenige, mehr oder minder nützliche Kommentare auf dem Plakat, wie “Pünktlichkeit nicht gut”. Bis einer der Scrum Master – offensichtlich mit etwas Erfahrung zu agiler Skalierung – per Post-it auf dem Plakat anregte, man möge ggf. darüber nachdenken, dass zu viele “Zwangstermine” zum Gegenteil dessen führen können, was man erreichen will. In der Anregung war weiterhin zu lesen, dass man darüber nachdenken solle, die informelle Kommunikation durch gemeinsame Refinements und Plannings zu fördern, und dass die Ursachen für das Nicht-funktionieren des Scrum of Scrums vielleicht ganz wo anders liegen könnten.

Bevor ich den Vorschlag des Scrum Masters an sich bewerten möchte, will ich auf die Reaktion des Managements eingehen. Die sah nämlich ungefähr so aus:

Das Post-it wurde entfernt. In der nächsten Runde der Scrum Master wurde der betreffende Kollege freundlich aber bestimmt darauf hingewiesen, solches Feedback bitte nicht mehr offen sichtbar zu hinterlassen. Ferner wurde festgestellt, dass das “kontraproduktiv” sei, da man ja schließlich versuche, den Austausch zwischen den Teams zu verbessern. Ein solcher Kommentar sei nicht hilfreich. Bam!

Wie finden Sie das?

Ich finde das ziemlich unanständig und unehrlich. Wenn Sie in einer agilen Umgebung mit offener Kommunikation arbeiten wollen, in der die Grundsätze “Inspect and Adapt” und kontinuierliche Verbesserung gelten, dann sehen Sie davon ab, Feedback von Mitarbeitern zu zensieren oder aus sonstigen formellen Gründen abzulehnen.  Jedes Feedback kann hilfreich sein, wenn Sie es nur wollen.

In diesem Fall erscheint besonders traurig, dass der Kreis der Scrum Master letztlich mit seiner Vorgehensweise demonstriert, wie wenig man Agilität verinnerlicht hat. Anstatt sich inhaltlich mit dem Feedback auseinanderzusetzen und offensiv mit einem sachlichen Verbesserungsvorschlag umzugehen, verteidigt man “Heilige Kühe” durch Ausübung formeller Macht.

Wo kämen wir nur hin wenn andere solches Feedback lesen würden und gar auf den Gedanken kämen, dass die teamübergreifenden Stand-Ups abgeschafft werden sollen?

Dazu kann ich nur sagen, dass offensichtlich viele diesen Gedanken ohnehin schon haben und dies durch ihr Nichterscheinen offen demonstrieren. Der Kollege Scrum Master hat diese Erkenntnis lediglich auf einem Zettel festgehalten. Agilität hat ganz häufig auch etwas disruptives um Freiraum für neue Innovationen zu schaffen. Das gilt insbesondere für die Organisationsstruktur selbst.

Generell kann ich nur empfehlen, jedem Feedback nachzugehen und im Gespräch von Angesicht zu Angesicht zu versuchen, es zu verstehen. Auch wenn es zunächst nicht hilfreich oder gar kontraproduktiv erscheint. So demonstrieren Sie einerseits, dass jeder gehört wird und es sich immer lohnt mitzumachen. Andererseits können Sie nur so auch destruktive Kritik wirksam adressieren. Wenn Sie Kritik einfach nur ohne Begründung killen, wird sie sich nur im Verborgenen fortsetzen und nachhaltig für schlechte Stimmung sorgen. Feedback an sich kann meiner Meinung nach nicht kontraproduktiv sein, sondern nur das, was man daraus macht.

Abseits des oben genannten Beispiels ist generell zu bedenken, dass es meist ein Thema hinter dem Thema gibt. Wenn Kollegen sehr negativ-destruktive Kommentare abgeben, steckt etwas dahinter. Da können Sie sich sicher sein. Lassen Sie nicht zu, dass das Thema hinter dem Thema im Verborgenen bleibt. Die berühmten “Elefanten im Raum” müssen adressiert werden, sonst können Sie sie nicht loswerden und Sie werden Ihnen immer im Weg stehen.

Nun möchte ich noch auf den spezifischen Vorschlag des Scrum Masters in diesem Beispiel eingehen, der in meinen Augen keineswegs destruktiv oder kontraproduktiv war. Denn in agilen Umgebungen herrscht hoher Kommunikationsbedarf, insbesondere wenn bei der Arbeit an großen Produkten über mehrere Teams skaliert wird. Die haben so ohnehin schon viele Regeltermine wie Plannings, Reviews, Retrospektiven und Daily-Scrums. Wenn in eine solche Umgebung weitere Termine (bzw. formelle Informationskanäle) “hineingedrückt” werden, ist oft Ablehnung die Reaktion. Die Teams wollen arbeiten und möglichst wenig Zeit mit Diskussionen, Meetings und Abstimmungen verbringen.

In diesem Fall ist das teamübergreifende Stand-Up eine Art Extrapolation der Daily-Scrums aus den Umsetzungsteams. Die Daily Scrums der Teams funktionieren in der Regel recht gut weil sie innerhalb “echter” Teams stattfinden. Mit echten Teams meine ich diejenigen, in denen die einzelnen Mitglieder einander brauchen um ihre Arbeit zu machen. Daher brauchen sie auch den täglichen Austausch miteinander und niemand würde das Daily in Frage stellen. Bei den teamübergreifenden Stand-Ups ist das etwas anders, denn die Teilnehmer sind kein echtes Team. Sie brauchen einander nicht zwingend um ihre Arbeit zu machen. Die Abhängigkeiten sind hier nur punktuell. Für die meisten Teilnehmer im teamübergreifenden Stand-Up ist der Nutzen daher auch nur gering. Die eine Person, mit der sie vielleicht reden müssten, könnten sie auch einfach einmal so ansprechen. Damit sie das auch tun ist es allerdings wichtig, dass sie Kenntnis darüber erlangen, dass die Abhängigkeit besteht. Das gelingt zum Beispiel, in dem man die oben erwähnten Refinements und Plannings teilweise übergreifend durchführt.  Die Teams können dann selbstständig die Verantwortung für die Behandlung der Abhängigkeiten übernehmen. Ferner ist es auch eine Überlegung wert, ob man nicht durch Umstrukturierung der Teams und ggf. der Anforderungen, die Abhängigkeiten zwischen den Teams nachhaltig reduzieren kann. Die Aussage „die Teams müssen sich abstimmen“ ist zwar richtig, aber das eigentliche Problem sind ja die Abhängigkeiten zwischen den Teams. Das Scrum of Scrums behandelt also zunächst einmal nur ein Symptom.

Genau betrachtet sind Meetings und Abstimmungen auch nicht wertschöpfend (genannt “Waste” im Lean-Jargon). Zwar ist Abstimmung notwendig aber gleichzeitig ist es wichtig, den “Waste” zu minimieren. Idealerweise entscheiden die Team-Mitglieder selbst, wann und wie sie sich mit Kollegen austauschen und abstimmen – je nach Notwendigkeit. Und das geht am besten informell. Sie müssen dafür sorgen, dass sie wissen, mit wem sie sich zu welcher Problemstellung austauschen können, und ihnen die Freiheit geben, das auch wann immer sie wollen zu tun. Unterstützen können Sie das durch vielfältige Maßnahmen. Sorgen Sie für möglichst kurze Wege zwischen Kollegen und Teams. Machen Sie den Teams auch Ihre Erwartungshaltung klar, und dass Sie den teamübergreifenden Austausch als Arbeitsgrundlage voraussetzen. Und geben Sie Ihnen die Autorität, selbst zu entscheiden, wann und mit wem sie sich treffen und beraten. Das ist effektiver und zeitsparender, als alle zu einem Stand-Up zu verdonnern, in dem sich ein Großteil der Teilnehmer überflüssig fühlt.

Im vorliegenden Fall hat man sich leider darauf beschränkt, Feedback aus formellen Gründen wegzuwischen und sich so die Möglichkeit genommen, sich mit wirksamen Lösungen für das eigentliche Problem zu beschäftigen. Mit diesem kleinen Exkurs zur Skalierungs von Scrum möchte ich zeigen, dass Lösungen für komplexe Probleme nicht in Modellen zu finden sind, sondern darin, dass man mit Hilfe von Feedback einen Lernzyklus etabliert, in dem Lösungsvorschläge getestet werden können.  In diesem Sinne – wenn Sie mit mir über dieses Thema sprechen möchten, freue ich mich, wenn Sie mich kontaktieren.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.