Zusammensetzung des Scrum-Teams

Im Umfeld der agilen Methode „Scrum“ würde ich gerne einen wichtigen Aspekt des Projektmanagements näher betrachten. Die Zusammensetzung des Projektteams. Im klassischen Projektmanagement ist dies eine der grundlegendsten Aufgaben des Projektleiters. Im Idealfall kann er sein Projektteam selbst zusammenstellen und im laufenden Projekt verändern. Im realen Arbeitsalltag unterliegt er natürlich vielen äußeren Zwängen wie z.B. einer begrenzten Auswahl an potentiellen Teammitglieder, der Konkurrenz durch anderen Projekte und Budgetgrenzen, was aber nichts daran ändert, dass der Projektleiter diese Befugnis haben sollte.

Bei Scrum gibt es die Rolle des Projektleiters nicht mehr. Die meisten Befugnisse und Verantwortlichkeiten haben sich auf die drei Rollen Product Owner, Scrum Master und Team verteilt. Wie geschieht das im Bereich der Teamzusammenstellung? Dabei sind folgende Teilaufgaben zu betrachten:

  • Initiale Teamzusammensetzung
  • Fehlende Fähigkeiten im Team
  • Vergrößern des Teams (um Velocity zu steigern)
  • Verkleinern des Teams (bei „Leerlauf“)
  • „Low Performer“ und „Störenfriede“ identifizieren und ausschließen

Initiale Teamzusammensetzung
Die Zusammenstellung des Teams bei Projektstart kann nicht durch das Team selber ge­sche­hen, das gibt es zu diesem Zeitpunkt noch gar nicht. Durch seine Budget­ver­ant­wort­lich­keit hat der Product Owner natürlich einen sehr starken Einfluss, aber die genaue Entscheidung liegt sinnvollerweise beim Scrum Master. Er sollte darauf achten, dass das Team gerade in der ersten Zeit funktionieren kann, sowohl von den fachlichen als auch den sozialen Fähigkeiten der einzelnen Teammitglieder.

Die hier auftauchende Frage wie eine gute Zusammensetzung des Projektteams über den gesamten Projektverlauf aussieht, halte ich für sehr spannend würde aber den Rahmen sprengen. Diese werde ich in einem zukünftigen Artikel beleuchten.

Fehlende Fähigkeiten
Sollten im Team für das Projekt benötigte Kompetenzen fehlen, wird das durch das Team sehr schnell als Hindernis artikuliert. Meist erfolgt dies schon in den Daily Scrums, spätestens aber in den Retrospektiven. Es ist dann die Aufgabe des Scrum Masters dafür zu sorgen das Team mit den fehlenden Fähigkeiten auszustatten. Da bieten sich dem Scrum Master unterschiedliche Handlungsoptionen:

  • Veränderung der Teamzusammensetzung
  • Schulung/Coaching von Teammitgliedern
  • Hinzuziehen eines Spezialisten

Vergrößerung des Teams
Hier geht es um die Entscheidung das Team zu vergrößern um die Velocity langfristig zu steigern. Der Grund kann eine sinkende (oder stagnierende) Velocity, der ansteigenden Termindruck des Projekts von außen oder einfach freie Mitarbeiterkapazitäten die in laufende Projekte eingebunden werden sollen sein.

Dieser Fall beschäftigt vor allem den Product Owner und das Team. Der Product Owner muss immer zwischen einer steigenden Velocity und den höheren Kosten (durch ein größeres Team) abwägen. Das Team wiederum kann beurteilen ob und in welcher Form weitere Teammitglieder überhaupt sinnvoll helfen.

Verkleinerung des Teams
Im Projektgeschäft kommt es immer wieder zu „Leerlauf“. Die Gründe hierfür sind sehr unterschiedlich, z.B. sind alle weiteren Aufgaben abhängig von einer Spezialistenaufgabe und sind so blockiert, zum Sprintende ist das Sprint-Backlog leer oder das Projekt­ende zeichnet sich gar durch eine leeres Product-Backlog ab. Auch lassen Projekte meist nur eine begrenzte Parallelisierung zu. Diese kann im Laufe des Projekts variieren und so „Leerlauf“ erzeugen. Dabei kann es sich beim „Leerlauf“ um ein spontanes Phänomen handeln oder er ist von systematischer Natur.

Erste Aufgabe ist es, zu erkennen, dass ein systematischer „Leerlauf“ vorliegt. Hier sind Team und Scrum Master gefordert. Dann ist eine passende Lösung zu finden, bevorzugt (und auch in den meisten Fällen möglich) im bestehenden Team, z.B. durch Neuschneiden der Aufgaben um die Spezialisten-Engpässe zu umgehen.

Aber gerade wenn es Richtung Projektende geht oder eine bisher genutzte hohe Parallelisierbarkeit entfällt, kann es Sinn machen, ein großes Team zu verkleinern.

Die Frage, welche neue Teamgröße sinnvoll ist, kann evtl. noch das Team entscheiden. Ich halte es aber für unklar, wie und durch wen die Teammitglieder ermittelt werden, die das Team verlassen müssen.

Low Performer und Störenfriede
Als eine der schwierigeren Aufgaben im Projektmanagement empfinde ich den Umgang mit Teammitgliedern, die nicht das benötigte Leistungsniveau zeigen oder massiv und anhaltend Unruhe in die Gruppe bringen. Eine Stärke von Scrum kann bei der Selbstregulierung innerhalb der Gruppe liegen. Diese setzt aber entsprechende soziale Kompetenzen und ein gutes Standing bei den anderen Teammitgliedern voraus. Es ist möglich, dass das alleine die Situation nicht rettet. Dann ist der Scrum Master gefordert, solche Dinge zu erkennen, anzusprechen und auf eine Lösung zu drängen. Ultima Ratio bleibt in solchen Situationen, das entsprechende Teammitglied aus dem Team zu entfernen, wobei unklar ist, wer diese (harte und recht endgültige) Entscheidung fällen darf.

Fazit
Auch in diesem Bereich teilen sich die Aufgaben auf die neuen Rollen auf. Gerade für harte Entscheidungen, aber auch in der Startphase von Projekten kann der “klassische Projektleiter” trotz allem vermisst werden.

  • Facebook
  • Delicious
  • Digg
  • StumbleUpon
  • Reddit
  • Blogger
  • LinkedIn
Marc Clemens

3 Antworten auf Zusammensetzung des Scrum-Teams

  1. Hallo Marc,

    ein sehr wichtiges Thema!

    Die Zusammenstellung des Teams bei Projektstart kann nicht durch das Team selber ge­sche­hen, das gibt es zu diesem Zeitpunkt noch gar nicht.

    Es kommt drauf an, wie und wo die freien Leute verfügbar sind. Ich hab Berichte gehört, wo in einem sehr großen Projekt, mit mehreren Scrum-Teams sich die Teams selbst zusammengefunden haben (ich meine es wäre Henrik Kniberg gewesen — oder Bas Vodde). Die erste Frage, die geklärt werden muss ist: warum muss ein neues Team zusammengestellt werden? Wird für jedes Projekt ein neues Team gegründet, oder ist es besser, mit dem gleichen Team unterschiedliche Projekte durchzuziehen?

    sind alle weiteren Aufgaben abhängig von einer Spezialistenaufgabe und sind so blockiert, zum Sprintende ist das Sprint-Backlog leer oder das Projekt­ende zeichnet sich gar durch eine leeres Product-Backlog ab

    Ich denke hier gibt es andere Möglichkeiten, als das Team zu verkleinert :)

    Bzgl. des Spezialisten-Flaschenhalses ist es Aufgabe des Scrum Masters das Problem nachhaltig zu lösen, was nicht darin besteht die Aufgabe neu zu schneiden, sondern die Kompetenzen im Team aufzubauen. Ein leeres Sprintbacklog lässt sich in der Regel in Absprache mit dem Product Owner recht zügig wieder auffüllen.

    Leerlauf bei Projektende ist meiner Ansicht nach auch ein Schnitzer des Product Owners. Entweder des aktuellen Product Owners, der das nächste Release noch nicht vorbereitet hat, oder des zukünftigen Product Owners des nächsten Projektes.

    Ultima Ratio bleibt in solchen Situationen, das entsprechende Teammitglied aus dem Team zu entfernen, wobei unklar ist, wer diese (harte und recht endgültige) Entscheidung fällen darf.

    Ich vermute, bevor es zu drastischen Maßnahmen wie einem Ausschluß kommt, wird die Problematik auch in den Reflections diskutiert. Die Situation kann auch so verfahren sein, dass das Team durch “emotionale Zerrüttung” komplett arbeitsunfähig ist. Dann liegt es in der Verantwortung des Scrum Masters über kommunikative Mittel die Konflikte und Emotionen wieder zu glätten.

    Wer letzten Endes die Entscheidung fällt ist meiner Meinung nach klar: Aus dem Team muss ein klares Signal kommen, dass unter Beibehaltung der entsprechenden Person das Projekt gefährdet ist / bzw. es wesentlich bessere personelle Alternativen gibt. Organisatorische Durchführung liegt dann beim Führungsverantwortlichen der Person.

    • Marc Clemens sagt:

      Hallo Andreas,

      Die erste Frage, die geklärt werden muss ist: warum muss ein neues Team zusammengestellt werden? Wird für jedes Projekt ein neues Team gegründet, oder ist es besser, mit dem gleichen Team unterschiedliche Projekte durchzuziehen?

      Ich glaube das diese Fragen sehr eng damit zusammenhängen wie ein Scrum-Team strukturiert sein sollte. Dazu aber in einen späteren Artikel mehr.

      Leerlauf bei Projektende ist meiner Ansicht nach auch ein Schnitzer des Product Owners. Entweder des aktuellen Product Owners, der das nächste Release noch nicht vorbereitet hat, oder des zukünftigen Product Owners des nächsten Projektes.

      Aus meiner Erfahrung haben viele Projekte kein hartes Ende sondern klingen langsam aus. Die Anzahl der neuen Anforderungen bzw. Änderungen sinkt. Damit ist ein “nicht” so volles Product Backlog kein Schnitzer der Product Owner. Ein Product Backlog eines anderen Projekts würde nur helfen wenn das Team in einem Sprint an zwei Projekten gleichzeit arbeitet.

  2. Good post.

    Scrum is a flat organization. The three roles are responsible (and thus have authority) for different aspects of development. The Product Owner decides what features to build and in what order, the team decides how to implement those features, and the Scrum Master is responsible for the development process. But no one is “above” the other.

    This is both a strength and a disadvantage of Scrum. When things get rough and members have to be excluded, there’s no formal authority to handle it.

    Thus, Scrum is heavily dependent upon strong informal leadership. Often, this leadership can be found with the Scrum Master — coaches are generally good leaders — but leadership could be provided by any of the three roles.

Hinterlasse eine Antwort

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

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>