100% Auslastung – alles Einstellungssache

26.11.2012

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.

 

Autor: Robert Wiechmann

Robert Wiechmann arbeitet als Agiler Projektmanager vorrangig in der Rolle als Scrum Master und Kanban Coach. Zu seiner Leidenschaft zählen die Arbeit mit Menschen, insbesondere der Aufbau von produktiven Agilen Teams und die praktische Anwendung von Agilen Softwareentwicklungsmethoden. Zusammen mit Sven Röpstorff verfasste er das Buch Scrum in der Praxis.

6 Kommentare

  1. Dazu passt hervorragend der Artikel aus der HBR mit dem Hinweis “Introduce resource slack where utilization is highest.” (http://hbr.org/2012/05/six-myths-of-product-development/ar/1)

  2. Hallo Robert,

    einen wichtigen Aspekt hast Du in der Kommunikation zum Management nicht erwähnt: 100% Auslastung gehen im Umfeld Softwareentwicklung unweigerlich auf Kosten von Umsetzungsgeschwindigkeit (Lead Time) und Durchsatz (Troughput), und das sind die eigentlich wesentlichen Meßgrößen, nicht Auslastung (Auslastung kannst Du nicht verkaufen).

    Was sich im ersten Moment unlogisch anhört, kann man aber gut mit der Varianz der Aufgaben (Stories) erklären. Im Gegensatz zu den Aufgaben an einem statischen Fließband, sind Aufwände bei der Bewältigung der Aufgaben in der SW-Entwicklung von mal zu mal ungleich über die einzelnen Rollen verteilt. Egal wie viel Mühe man sich bei der Zusammenstellung des Teams odes des Backlogs gibt, es wird nie perfekt austariert sein. In einem solchen System ist man am schnellsten, wenn man sich am Engpass orientiert.

    Somit sollten alle MA, die nicht am Engpass arbeiten können, niemals etwas tun, was den Engpass beschäftigen oder stören könnte. Leider passiert genau das so oft. Es werden weitere Tätigkeiten angefangen, die dan unweigerlich auch den Engpass betreffen, was alles nur verschlimmert. Auch hier gibt es natürlich Möglichkeiten, die Du z.T. genannt hast oder auch einfach Themen wie Weiterbildung, Forschung etc.

    Grüße, Traian

  3. Traian hat es genau richtig und eigentlich vollständig gesagt. Beschäftige die Leute, die an einem Nicht-Engpass arbeiten, nie zu 100%! Ihr Beschäftigungsgrad muss sich am Engpass ausrichten. Andererseits werden sich die Bestände häufen, was teuer ist. In der SW-Entwicklung heisst dies. Es liegen Codefetzen herum, die irgendwer zusammensetzen muss, aber nicht dazu kommt. Die Codefetzen werden obsolete oder benötigen teure Nachbesserungen. Es geht also gar nicht so sehr um Verlust von Kreativität und Motivation, sondern ganz schnöd um Verlust von Geld. Und das verstehen alle Manager.

  4. @Traian @Peter

    Vielen Dank für eure Ergänzungen, denen ich nur zustimmen kann.

    Beste Grüße,
    Robert

  5. Hi,

    ich habe mich hinreißen lassen und auch noch mal etwas ausführlicher darüber geschrieben: http://www.xing.com/topics/de/maximale-werschopfung-in-der-softwareentwicklung-nicht-durch-auslastung-sondern-durch-orientierung-am-10523

    Grüße, Traian