Beliebte Suchanfragen

Cloud Native

DevOps

IT-Security

Agile Methoden

Java

|
//

Zusammensetzung des Scrum-Teams

22.7.2010 | 4 Minuten Lesezeit

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.

|

Beitrag teilen

Gefällt mir

0

//

Weitere Artikel in diesem Themenbereich

Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.

//

Gemeinsam bessere Projekte umsetzen.

Wir helfen deinem Unternehmen.

Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.

Hilf uns, noch besser zu werden.

Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.