12. Dezember 2018

Extended SCRUM Teams

SMART DEVELOPMENT NEWS 12/2018

Avatar: Herbert Schönebeck
von Herbert Schönebeck

Idealerweise ist das Scrum Team cross-funktional aufgesetzt und besteht aus T-Shaped Professionals. Dabei bedeutet Cross-Funktionalität, dass ein Team alle Fähigkeiten besitzt, die es zur Produktentwicklung benötigt – soweit die Theorie.

In der Praxis stellt diese Ideal-Anforderung an Scrum Teams für Unternehmen, die physische bzw. mechatronische Produkte entwickeln, meist eine Herausforderung dar, die mit der bestehenden Organisation nur schwer lösbar ist. Grund dafür ist die fast immer bestehende kleinteilige Verteilung von Spezialistentümern, deren Experten nur phasenweise und mit geringer Kapazität für die Entwicklung des Produkts benötigt werden.

Für Scrum Teams bestehen drei Forderungen:

1. Das Development Team soll das erwartete Ergebnis alleine liefern können,

2. möglichst zu 100 Prozent nur an dem einen Projekt arbeiten, und

3. gleichzeitig aber nicht mehr als 9 Teammitglieder haben.

Diese Anforderungen scheinen zunächst unlösbar. Natürlich kann idealisiert die Annahme getroffen werden, dass man irgendwann Entwickler mit breiterem Wissen im Unternehmen haben wird, die zum Beispiel neben der Konstruktion auch numerische Simulation beherrschen. Es gibt sicherlich auch Grund zur Annahme, dass jedes Unternehmen Potenzial hat, eine „Skill-Verbreiterung“ dieser Art zu realisieren. Aber hier und heute muss einfach die vorliegende Realität für den Start Agiler Teams akzeptiert werden.

Bedeutet das, dass dann nicht wirklich agil gearbeitet werden kann? Mit welchen Einschränkungen muss man rechnen? Welche Fehler kann man machen? Welche Lösungen gibt es?

Aus unserer Erfahrung kann man mit ein paar smarten Regelungen agile Teams aufsetzen, die einerseits so organisiert sind, dass sie effizient im Scrum Framework arbeiten können, andererseits aber auch Spezialisten in die Teamarbeit einbinden, die eben nur zeitweise oder mit geringer Kapazität benötigt werden.

Diese Art von Einbindung nennen wir „Extended Teams“. Die beiden wesentlichen Prämissen für die Einbindung sind einerseits eine saubere Aufgabensteuerung und andererseits eine adäquate Teilnahme an den Team Events.

Für die Mitglieder des Development Teams werden Patenschaften für die Mitglieder im Extended Team festgelegt. Meist entspricht diese Patenschaft auch den real vorliegenden Prozessabläufen. Zum Beispiel „steuert“ der Konstrukteur den Spezialisten für die numerische Simulation an. Vor jedem Sprint stimmt der Pate sich mit dem Spezialisten des Extended Teams darüber ab, welche Aufgaben voraussichtlich im Sprint erledigt werden müssen und ob die erforderliche Kapazität auch bereitsteht. So kann anschließend auch ohne direkte Teilnahme der Extended Teammitglieder eine verbindliche Sprint Planung entstehen. Die Teilnahme an den Dailys wird individuell gesteuert. Entweder nimmt der Spezialist an einigen Dailys selbst teil oder der Informationsfluss erfolgt bilateral über den Paten. Bei gewichtigen Ergebnissen kann der Spezialist selbst im Sprint Review präsentieren, ansonsten vertritt ihn der Pate.

Was auf den ersten Blick sehr nach indirekter Kommunikation aussieht – der Pate ist immer das Bindeglied zum Spezialisten – entpuppt sich in der Realität meist als bereits vorhandener Kommunikationsprozess.

Der Vorteil dieser Einbindung liegt klar auf der Hand. Zum einen muss ein Mitglied des Extended Teams nicht an allen Team Events teilnehmen. Nochmals zur Erinnerung: In einem zweiwöchigen Sprint bringen die Teammitglieder insgesamt 10 Stunden für die Events Sprint Planung, Daily, Sprint Review, Sprint Retrospective auf. Das sind Für Führungskräfte mit Geschäfts- bzw. Produktentwicklungsverantwortung ca. 12 Prozent der Arbeitszeit. Wenn aber ein Spezialist nur 20 – 30 Prozent für ein Projekt an Kapazität zur Verfügung hat, macht es keinen Sinn, einen so hohen Anteil an Zeit für die Team Events aufzubringen.

Zum anderen kann über die Trennung zwischen Development Team und Extended Team die Teamgröße des Scrum Teams verkleinert werden. Auch hier liegt viel Potenzial für Effizienzsteigerung.

Ein kleiner Trick noch für das Burndown-Chart: Das kann dann zweigeteilt geführt werden. Eines für das Kernteam mit konstanter Kapazität, auf dem man gut beobachten kann, ob die Anzahl der geschafften Story Points gesteigert werden kann. Und ein anderes für das Extended Team, auf dem man weniger auf Effizienzsteigerung achtet, sondern mehr darauf, dass zugesagte Leistungsumfänge auch erbracht werden.

Extended Teams entsprechen zweifelsohne nicht dem Idealbild eines Development Teams im Scrum Framework. Aber sie sind eine smarte und pragmatische Lösung, um mit der bestehenden Organisation erfolgreich erste agile Erfahrungen zu sammeln.