Die Grösse von Scrum Teams und ihre Herausforderungen

Das agile Projektmanagement Framework Scrum ist in aller Munde und in vielen Entwicklungsteams wird damit gearbeitet. Doch welche Teamgrösse ist am sinnvollsten? Ob bei einem Start-Up, einem Unternehmen mit mehreren kleinen Produkten oder grossen Entwicklungsteams, es gibt einige Aspekte zu berücksichtigen, damit das Team seine Zeit effizient nutzen kann.

Der Scrum Guide definiert weniger als zehn Personen als ideale Teamgrösse. Wichtig ist, es sollen so viele sein, dass innerhalb eines Sprints massgebliche Arbeit für ein Produkt erledigt werden kann. Experten empfehlen dabei keine Doppelrollen zu vergeben, da es schwierig sein kann Entscheidungen zu treffen, wenn man beispielsweise gleichzeitig Scrum Master und Developer ist. Gemäss einer Studie liegt die ideale Teamgrösse bezüglich ihrer Effizienz bei 4.6 Vollzeitstellen, wodurch wir zur Annahme gelangen können, tendenziell auf kleinere Teams zu setzen.

Herausforderungen

Selten kann die Teamgrösse frei definiert werden. Meistens gibt es Rahmenbedingungen in Bezug auf Ressourcen wie Arbeitsleistung oder Geld, die dazu führen, dass kleine Teams zusammengestellt werden müssen, wie etwa in einem Start-Up. So kommt es oft dazu, dass Doppelrollen verteilt oder vielleicht auf wichtige Aufgaben des Scrum Masters verzichtet werden.

Eine andere Ursache, welche aber zur selben Problematik führt, ist ein Produktportfolio, welches keine regelmässigen und umfangreichen Weiterentwicklungen benötigt. Hier hat man die Wahl zwischen Klumpenrisiko beim Know-how oder fehlendem Produktfokus. Was dabei auch oft unterschätzt wird, sind alle Einflüsse ausserhalb des Scrum Teams. Wenn es für kein grösseres Scrum Team reicht, sind oft auch die anderen Geschäftsbereiche wie Support, Betrieb und Projektleitung nur schwach besetzt. Dies führt vermehrt zu Unterbrechungen im Entwicklungsteam, was die Umsetzungsperformance einbrechen lassen kann.

Doch auch Teams, welche nahezu zehn Personen umfassen, haben ihre Herausforderungen. Man hat hier die Möglichkeit mit Spezialisten zu arbeiten, wo hingegen in kleinen Teams Generalisten gefordert sind. Jedoch führt jedes neue Teammitglied zu exponentiell mehr Kommunikationsaufwand, was sich massgeblich auf die Performance niederschlägt. Ähnliche Symptome können auftauchen, wenn das Team mittelgross ist, darin aber mehrere Personen in einem Teilzeitpensum arbeiten.

Lösungsansätze

Wir haben diverse Faktoren beleuchtet, welche die Arbeit in Scrum Teams erschweren kann. Folgende Empfehlungen sollen als Denkanstösse für individuelle Lösungsansätze dienen:

  • Einer der fünf Grundwerte des Scrum Guides ist Fokus. Sollten die organisatorischen Gegebenheiten keinen Fokus auf ein Produkt und eine Rolle zulassen, ist Scrum dann die passende Lösung? Vielleicht lohnt es sich einen Blick auf Kanban zu werfen und eine hybride Form zu wählen.
  • Bei mehreren Produkten mit kleinen Teams empfiehlt sich einen möglichst einheitlichen Technologie-Stack zu wählen, sodass bei Engpässen auch mal teamübergreifend geholfen werden kann.
  • Dazu könnte man auch einen regelmässigen Wechsel zwischen den Produkten in Betracht ziehen. Dies ergibt einen Produktfokus für den Sprint, zudem kann das Produkt Know-how auf mehreren Personen verteilt werden, was bei Ferien und kurzfristigen Ausfällen hilfreich ist.
  • Wenn aufgrund obiger Herausforderungen keine Prognose für die Entwicklungsgeschwindigkeit gemacht werden kann, macht es Sinn die individuellen Verfügbarkeiten der Developer beim Sprint Planning zu berücksichtigen. Dabei sollten geplante Tätigkeiten in Projekten und Support bereits abgezogen werden.
  • Bei tiefer Performance könnte man verschiedene Sprintlängen austesten. Wenn während eines Sprints nur wenig umgesetzt werden kann, kann eine längere Sprintdauer den Anteil an Meetings verringert und gleichzeitig deren Inhalt ergiebiger werden.
  • Falls ein Team die Grösse von fünf Personen überschreitet, sollte man sich Gedanken über eine Aufsplittung machen. Vielleicht ist das Produkt modular aufgebaut und ein Teilbereich kann separat weiterentwickelt werden.

Ganz nach dem agilen Ansatz empfiehlt es sich Dinge auszuprobieren und regelmässig zu überprüfen, ob die aktuelle Arbeitsweise noch passend ist. Gerade in herausfordernden Konstellationen sollte die Sprint Retrospektive nicht aus Zeitgründen weglassen werden.

Beitrag teilen

Marina Wenk

Marina Wenk ist Software Engineer in einem Unternehmen, welches Lösungen für Energieversorgungsunternehmen entwickelt und bloggt aus dem Unterricht des CAS Modern Software Engineering & Development.

Alle Beiträge ansehen von Marina Wenk →

Schreibe einen Kommentar