Abhängig von Projektumfang, Umsetzungsfrist und weiteren Rahmenbedingungen wird der Umfang eines Scrum-Entwicklungsteams dimensioniert. Dabei muss insbesondere darauf geachtet werden, dass das Team so zusammengesetzt wird, dass es gemeinsam in der Lage ist, alle Anforderungen zu realisieren. Zugleich ist darauf zu achten, dass das Team einfach zusammenarbeiten kann und nicht zu gross ist, um sich einfach abzustimmen. Untersuchungen haben gezeigt, dass grössere Teams tendenziell mehr Zeit durch einen höheren internen Abstimmungsbedarf verlieren und dadurch eine geringere Produktivität pro Teammitglied aufweisen. Entsprechend ist die Teamgrösse in Scrum auf 3-9 Teammitglieder limitiert. Werden für die Umsetzung eines Projektes mehr als neun Entwicklungsressourcen benötigt, so werden diese auf mehrere Teams aufgeteilt, welche alle Aufgaben aus demselben Produkt Backlog umsetzen. (Pro Produkt existiert immer nur ein Produkt- Backlog, unabhängig davon, wie viele Personen daran arbeiten.)
Da Scrum keinen Projektleiter (oder eine vergleichbare Rolle) kennt, sondern auf selbstverantwortlichen, selbstorganisierten Teams basiert, ist die Abstimmung zwischen Entwicklern in einem Entwickler-Team nicht einfach. Um sie sicherzustellen, treffen sich die Entwickler eines Teams täglich zum «Daily Scrum» (auch Daily Standup genannt), bei dem jedes Teammitglied die drei Fragen beantwortet. Werden Anforderungen von mehreren Entwicklungsteams umgesetzt, muss sichergestellt werden, dass auch zwischen den Teams eine Absprache möglich ist.
In Scrum wird dazu eine Art «virtuelles Team» gebildet, welches aus Vertretern der verschiedenen Teams gebildet wird und sich regelmässig zu einem dem Daily Scrum vergleichbaren Meeting trifft. Abhängig vom Abstimmungsbedarf kann dies ebenfalls täglich oder auch seltener erfolgen. Wichtig ist dabei, dass jedes Team eine Person entsendet. Dabei erweist es sich als sinnvoll, dass die Entsendung des Teammitglieds – wo angebracht – themenbasiert erfolgt oder – wenn es nicht darum geht, ein bestimmtes Thema abzustimmen – die Teammitglieder abwechselnd entsandt werden. Wir haben in Scrum keinen Teamleader und wir möchten nicht einen informellen Teamleader etablieren, der das Team nach aussen repräsentiert.
Scrum of Scrums
Im Meeting des virtuellen Teams, welches keine Timebox hat, treffen sich die Vertreter der Teams. Dieses Meeting wird «Scrum of Scrums» genannt. Es dient dazu, Probleme, gegenseitige Abhängigkeiten, Schnittstellen und weitere Fragen, zu welchen es Abstimmungsbedarf gibt, zu klären und die entsprechenden Resultate anschliessend wieder zurück in die Teams zu nehmen.
Während manche Teams das Scrum of Scrums ähnlich knapp wie ein Daily Scrum halten und nur die folgenden Fragen beantworten, nehmen sich andere virtuelle Teams hier ausreichend Zeit, um gemeinsam alle offenen Fragen möglichst abschliessend zu erörtern.
Die vier Fragen:
- Was hat mein Team seit dem letzten Scrum of Scrums gemacht?
- Was plant mein Team bis zum nächsten Scrum of Scrums umzusetzen?
- Welche Hindernisse beschäftigen das Team?
- Welche Abhängigkeiten zu anderen Teams sind zu besprechen?
Anschliessend werden Themen, welche sich aus der Beantwortung der Fragen ergeben haben, entweder von allen Anwesenden oder – wenn diese nur einige Teams betreffen – von deren Vertretern abgestimmt.
Wichtig beim Einsatz mehrerer Teams
Product Owner
Wird mit mehreren Teams am selben Produkt gearbeitet, so hat es sich bewährt, dass die Sprints der entsprechenden Teams parallel verlaufen. So können die Arbeitsresultate der einzelnen Teams jeweils in ein gemeinsames Inkrement integriert werden. Allerdings hat diese Synchronisierung der Sprints auch Nachteile. Wenn die Sprints mehrerer Teams zeitgleich beginnen, dann finden auch ihre Sprint-Planungsmeetings parallel statt, was bedeutet – da ein Product Owner nicht zeitgleich an mehreren Meetings teilnehmen kann – dass man mehrere Product Owner braucht.
Obwohl in der genannten Konstellation nur ein einziger Product Backlog eingesetzt wird, werden die Entwicklungsteams jeweils von eigenen Product Ownern unterstützt. Trotzdem gilt, dass eine Person die Verantwortung für die Erzielung maximaler Wertschöpfung wahrnehmen muss. Es ist nicht möglich, dass mehrere Personen die Priorisierung abwechslungsweise nach ihren Vorstellungen vornehmen. Ein Chief Product Owner übernimmt die Priorisierung sowie den Kontakt zum Kunden (soweit dies möglich ist). Er kann parallel auch Product Owner eines der Teams sein, wenn dies seine Kapazität zulässt. Er entscheidet final über den Product Backlog.
Scrum Master
Wenn mehrere Teams am selben Produkt arbeiten, so gibt es in den meisten Fällen auch mehrere Scrum Master, welche eines oder in manchen Fällen auch mehrere Teams unterstützen. Wichtig ist in jedem Fall, dass jedes Team sowohl einen festen Scrum Master wie auch einen festen Product Owner besitzt, unabhängig davon, ob diese weitere Teams unterstützen. Sollte eine Rolle dabei mehrere Aufgaben übernehmen (z.B. ein Scrum Master mehrere Teams betreuen), so muss damit gerechnet werden, dass dies mit einer Produktivitätseinbusse der betreffenden Teams erkauft wird.
Crossfunktionale Teams
Oft werden beim Einsatz mehrerer Teams in Scrum funktionale Teams gebildet. Ein Team kümmert sich beispielsweise um die Erstellung von Grundfunktionalität, ein weiteres um Datenbankzugriffe und ein weiteres um das User Interface. Dies ist nicht Scrum-konform und hat viele Nachteile. Resultat solchen Arbeitens ist oft ein hohes Mass an gegenseitigen Abhängigkeiten oder die Situation, dass Anforderungen in Funktionen aufgegliedert werden, welche den verschiedenen Teams zugeordnet werden und erst im Verlaufe mehrerer Sprints Resultate bringen, zu denen der Kunde ein sinnvolles Feedback geben kann. Die vermeintliche Vereinfachung wird also damit erkauft, dass Feedback erst verspätet eintrifft und damit das Risiko für Fehlentwicklungen steigt, die Reaktionsmöglichkeit auf Feedbacks erst nach mehreren Sprints besteht und damit die Wertschöpfung für den Kunden reduziert wird.
Definition of Done
Arbeiten mehrere Teams am selben Produkt, so ist es wichtig, dass alle Teams dieselbe Definition of Done haben, damit alle Entwicklungsresultate miteinander harmonieren und möglichst einfach integriert werden können. Es hat sich bewährt, dass die Teams die Definition of Done in diesem Fall gemeinsam entwickeln, damit sichergestellt wird, dass alle ihre Anforderungen und Arbeitsweisen darin widergespiegelt finden.
