Micromanagement in agilen Prozessen

Micromanagement ist so eine Sache für sich… es hat bei den meisten Menschen keinen besonders guten Ruf, dennoch behaupten viele, dass es im Arbeitsalltag nicht ohne geht.

Agile Methoden werfen Micromanagement im eigentlichen Sinne über Bord. Es gibt keinen Manager, der kontinuierlich das Team überwacht und jede kleine Aktion steuert. Und falls doch, hat das Team, aber vor allem auch das Unternehmen ein Problem. Zum einen mangelt es offensichtlich an Vertrauen, das dem Team entgegengebracht werden muss. Das Team ist also nicht wirklich bevollmächtigt. Zum anderen schafft man damit eine effektive Barriere, die es daran hindert, wirklich agil zu werden. Denn selbst, wenn der Umstand dem Team nicht unbedingt bewusst ist, spürt ein Team mangelndes Vertrauen und traut sich nicht, es selbst zu sein, um die geforderten Aufgaben vollkommen eigenständig zu lösen.

Micromanagement von Innen

Trotzdem, und das ist das Paradoxe an der Geschichte, gibt es in einem funktionierenden, agilen Team Micromanagement. Es wird in kurzen Zeitabständen berichtet, es wird überwacht, schnell reagiert und an Stellschrauben gedreht. Durch Sicherheitsmechanismen wird dafür gesorgt, dass niemand seinen Fokus verliert, dass kaputte Builds sofort wieder gefixt werden und so weiter. Wer ist aber dann die Person, die hier das Micromanagement betreibt? Ganz einfach: Es sind alle! Das gesamte Team betreibt Micromanagement.

Da hätten wir zum einen das Daily Scrum bzw. die Daily Standup Meetings: Man tauscht Informationen aus, koordiniert sich, gibt anderen Teammitgliedern Tipps und Empfehlungen (“probier doch mal das hier”). Micromanagement also. Oder nehmen wir den Build, der durch den letzten Commit fehlgeschlagen ist und dank des Continuous Integration Systems jeden unmittelbar darüber informiert. Ebenfalls Micromanagement.

Man sieht also, dass nicht Micromanagement als solches schlecht und hinderlich ist. Der Schlüssel liegt darin, wer wen managed. Und ein agiles Team sollte selbstorganisierend sein und nicht von außen gesteuert werden.

Micromanagement passiert schneller, als man denkt

Agile Prozesse bieten aber dennoch viel Potential für Micromanagement von außen, ob bewusst oder unbewusst. Bei der Einführung eines agilen Prozesses sind es vor allem Stakeholder und Manager, die oft noch Schwierigkeiten damit haben, das Team “ziehen zu lassen”. Aber auch wenn ein Prozess schon etabliert ist und eben genannte Personen keinen Einfluss auf das Team ausüben, steckt der Teufel – wie so oft – im Detail.

Ein Beispiel: Auf unserem Taskboard haben wir unsere Anforderungskärtchen mit weiteren Informationen versehen: auf welchem Branch wurde diese Anforderung umgesetzt und wer war daran beteiligt. Diese Informationen sollten dem Product Owner und auch dem Team helfen, zu wissen, wo man eine Änderung findet und an wen man sich wenden kann, wenn man Fragen dazu hat. Vom Team wurde jedoch oft vergessen, die entsprechenden Infos beim Bearbeiten einer Anforderung einzutragen. Der Product Owner erinnerte das Team immer wieder daran und so kam jeden zweiten Tag der erhobene Zeigefinger.

Dass das keinen Erfolg brachte ist im Nachhinein betrachtet logisch, aber nicht sofort offensichtlich: Diese Form des Micromanagements durch den Product Owner erwirkte im Team das Gefühl, dass diese Informationen nur für ihn auf die Kärtchen gepinselt würden. Zudem entstand das Gefühl, dass einem in die Arbeit hereingeredet wird. Man fügte sich zwar, aber selbstständiger wurde die Informationvergabe auf den Kärtchen dadurch nicht.

Ich bat also unseren Product Owner, auch wenn es ihm schwer fällt, einfach mal auf diese Informationen zu verzichten. Zwar waren die Infos auf den Karten auch für das Team von Mehrwert, aber dadurch, dass seitens des Product Owners darauf gepocht wurde, war für das Team nur sein Mehrwert ersichtlich. Und ganz im agilen Sinne: Warum sollte man auf etwas beharren, das für das Team nicht funktioniert? Also wollten wir probieren, wie das Team reagiert.

Es dauerte nicht lange – wenige Tage – bis sich die ersten Teammitglieder eine Karte zum weiterarbeiten griffen und Sätze fielen, wie: “Das kann ich nicht reviewen. Ich weiß nicht in welchem Branch das liegt und wer das entwickelt hat”. Die Teammitglieder haben also für sich selbst erkannt, welchen Mehrwert diese Informationen liefern und begannen sich selbst zu “micromanagen”. Und der Product Owner bekam letztlich weiterhin die für ihn interessanten Informationen, ohne dem Team den erhobenen Zeigefinger zur Pflichterfüllung schwenken zu müssen.

Sehen und erleben!

So gibt es viele Beispiele, in denen der Product Owner und auch der Scrum Master schnell – zum Teil unbewusst – steuernd im Sinne von Micromanagement aktiv werden. Der Nutzen bleibt aber fast immer aus. Mehrwerte könne für das Team nur sichtbar sein, wenn sie einen freien Blick darauf haben und für sich selbst beurteilen können, was die Mehrwerte für sie selbst sind. Ansonsten bleibt höchstens das Gefühl der Pflichterfüllung bestehen. Diese Mehrwerte kann man selten durch Erklärungen sichtbar machen. Man kann sie durch Visualisierung passender Metriken sichtbar machen, etwa wenn eine Änderung die Anzahl Bugs pro Woche verringert hat. Noch besser ist es, wenn das Team sie einfach selbst erlebt und fühlt.