100% Auslastung – alles Einstellungssache

Boris Gloger schrieb vor einiger Zeit, dass Denken in Auslastung blödsinnig ist. Angeregt durch den Beitrag und das Thema, fielen mir Situationen ein, bei denen Manager auf mich als Scrum Master oder meinen Product Owner zukamen und behaupteten, dass die Teams, mit denen ich arbeitete, nicht ausgelastet seien. Nach einem kurzen Gespräch mit den Managern und betroffenen Teammitgliedern, konnte ich mir dann schnell ein Bild von der eigentlichen Situation machen und die Kommunikation in die richtige Richtung lenken. Wie kam es zu der Annahme und was tue ich in diesen Situationen?

Das Missverständnis

Treffen sich ein Manager und Entwickler auf dem Flur. Sagt der Manager „Na, wie läufts bei euch im Team, kommt ihr voran?“ Darauf sagt der Entwickler „Diesen Sprint habe ich nicht wirklich etwas zu tun, da das Sprint Backlog nur Backlog Items für die Frontend-Entwickler enthält.“ Denkt sich der Manager „Hmmm…, da sitzt jemand rum und hat nichts zu tun!“.

Sie merken, dieser angedeutete Witz hat keine Pointe, weil diese Situation in vielen Unternehmen zum Alltag gehört. Was so nebenbei beim Small-Talk ausgetauscht wird, wirkt sich häufig in falschen Annahmen aus. Leider ist es bei vielen Managern immer noch so, dass sie annehmen, eine 100% Auslastung sei erstrebenswert. Wenn also jemand sagt, dass er „nichts zu tun hat“, dann bedeutet dies für den Manager, dass nicht effizient gearbeitet wird oder der Drang zum regulierenden Eingreifen steigt. Als Scrum Master ist es in diesen Situationen wichtig, in Richtung Management und Scrum Team zu kommunizieren.

1. Missverständnisse beseitigen

Als Scrum Master weiß man, was in seinem Scrum Team los ist und hat dementsprechend auch die notwendigen Argumente parat, um auf solch eine Situation zu reagieren. Situationen wie diese machen deutlich, dass ein Gespräch mit dem Manager (oder eine Schulung der Führungsebene) sinnvoll ist.  In Richtung des Managements sollte man sich dann dem Thema Auslastung annehmen und argumentativ vorbringen, dass der Wunsch nach Auslastung an die Obergrenze, zum Verlust von Kreativität und Motivation führt. Die „Ressourcen“ die an einem kreativen Prozess wie der Softwareentwicklung beteiligt sind, benötigen Freiraum, um bspw. Risiken aufzudecken, Verbesserungen hinzuzufügen, sich selber oder Innovationen zu entwickeln. Ein ständiger Lauf im Hamsterrad würde diesen Blick versperren und zudem die Motivation senken.

Darüber hinaus ist es hilfreich, über die Selbstorganisation in Scrum zu sprechen und deutlich zu machen, warum diese so wichtig für das Zusammenspiel eines Scrum Teams ist. Gehen sie auf die Werte und Prinzipien der agilen Arbeit ein. Gehen sie auch darauf ein, dass es einen Unterschied macht, ob jemand „idle“ ist oder seine Arbeitszeit verschwendet, bspw. durch Wartezeiten, dauernde Unterbrechungen oder Abhängigkeiten (vgl. die Serie zu Lean Software Development von Kelly Waters).

Grundsätzlich sollte die Konsequenz nicht sein, dass jemand das Gefühl hat „es gäbe nichts zu tun“. Nicht auf der Seite eines Managers und auch nicht auf der Seite eines Team Mitglieds. Dies war nämlich in keiner der Situationen der Fall, in die ich involviert war. In Richtung des Managements und in Richtung des Scrum Teams kommuniziere ich folgende Optionen, um Situationen wie „Diesen Sprint habe ich nicht wirklich etwas zu tun…“ entgegenzuwirken.

2. Alternativen deutlich machen

„Ich habe nichts zu tun“ bedeutet oftmals, dass der- oder diejenige nichts in der Domäne zu tun hat, in der er seine Spezialisierung sieht. In einem Scrum Team gilt dies jedoch nicht, denn jeden geht jede Aufgabe etwas an und neben dem Spezialwissen, ist eben auch die Ausweitung des Wissens in die Breite gefragt. Im Sinne der Selbstorganisation des Scrum Teams liegt die Gestaltung des Arbeitstages oder des Sprints selbstbestimmt beim Scrum Team. Gerade bei jungen oder nicht eingespielten Teams, sind folgende Alternativen – gefühlten „Leerlauf“ zu vermeiden – mein Rat, um den Impuls entgegenzuwirken, nichts zur Bearbeitung des Sprint Backlogs beitragen zu können. Zum Beispiel können die Teammitglieder:

• die anderen Teammitglieder bei der Abarbeitung des Sprint Backlogs unterstützen (auch wenn es eben nicht Backlog Items aus der Domäne des jeweiligen Spezialisten sind) oder
• kommende Sprint Backlog Items (oder die Arbeit an ihnen) vorbereiten.

Neben diesen beiden essentiellen Punkten, die häufig im Mittelpunkt meiner Arbeit stehen, gibt es aber noch viele weitere Aspekte, die wichtig für die Entwicklung des Teams bzw. der Software sind und einen wertvollen Beitrag liefern, wie bspw.:

• das Aneignen von Fachwissen, welches für die Arbeit im Projekt notwendig ist (durch das Lesen von Fachbüchern, Blogs oder das Ansehen von Online-Vorträgen bzw. -Tutorials),
• das Verfassen von Backlog Items mit eigenen Produktideen oder technischen Verbesserungen,
• die Bearbeitung von Aufgaben aus einer Retrospektive (die das Team / ein Teammitglied angenommen hat),
• der Austausch mit Kollegen / anderen Teams, um Fragen oder Probleme zu klären oder
• die Realisierung von Produkt- oder Prozess-Innovation (siehe die hervorragende Serie „Slack to the rescue“ von Bernd Schiffer).

Es steht jedem offen innerhalb des Teams, die eigene Auslastung in vielerlei Hinsicht selbstbestimmt zu gestalten. Wenn man nicht selbstständig etwas findet, um seine „Idle Time“ zu überwinden, dann findet man sicherlich zusammen mit den Teammitgliedern etwas, um Wert zu generieren und um damit zu unterstützen, zu optimieren, zu prüfen oder vorzubereiten. In „erwachsenen“ Scrum Teams funktioniert diese Selbstregelung innerhalb des Teams von alleine. Bis dahin ist man als Scrum Master gefordert, das Team auf diesen Weg zu begleiten bzw. zu führen.

Graphic Credits: Business vector designed by Freepik