Scrum Forum

Empirisme stelt dat kennis voortkomt uit ervaring en het nemen van beslissingen op basis van wat bekend is.

Het hebben van meer dan negen leden vereist te veel coördinatie. Grote Ontwikkelteams genereren te veel complexiteit voor een empirisch proces om te beheren.

De Scrum gids noemt deze problemen met het aanwezig zijn in teams van meer dan 9 leden. Dit zijn zorgen, geen faalpunten, en een Scrum team van meer dan 15 leden kan werken. Het zal echter niet zo effectief zijn als een team van de juiste grootte. Idealiter zou je ze opsplitsen in twee teams, en de Nexus Gids volgen voor het opschalen van Scrum naar meerdere teams. Dat is de Scrum.org methode voor het schalen van Scrum. Je zou ook kunnen kijken naar SAFe, als een tweede methode voor agile schalen.

Het grootste probleem dat je zult vinden is waarschijnlijk niet de arbeid, maar de gebeurtenissen. Het houden van een Daily Scrum tijd boxed tot 15 minuten kan een uitdaging zijn met 7 mensen, en het verdubbelen van die teamgrootte maakt het veel moeilijker. De tijdbox uitbreiden is een no-go (na 15 minuten begin je de voordelen van een “stand up” meeting te verliezen), en je zult je beter moeten voorbereiden op de andere gebeurtenissen door dingen van tevoren te verduidelijken.

Zoals ik het begrijp, wordt je werk als Scrum Master in dit scenario moeilijker, maar niet onmogelijk. Je kunt een Scrum Team van 15 man hebben, maar omdat de events gebaseerd zijn op de lengte van de sprint en niet op de teamgrootte, zul je je minder in de dienende rol en meer in de leidende rol bevinden. Je moet je extra focussen om ervoor te zorgen dat dingen efficiënt gebeuren, omdat je minder ruimte (en minder tijd) in je schema hebt als foutmarge. Iemand die van het pad afdwaalt, zal een grotere impact hebben op een groot team dan op een klein team.