Opsplitsen van een Scrum team

1663686471De Scrum-guide geeft, mijns inziens terecht, aan dat een Scrum-team tussen de 3 en 9 man groot moet zijn.

Het team dat ik op dit moment begeleid groeide naar 11 man, dus het werd tijd om te splitsen. Dat deden we overigens niet omdat het moet van de Scrum-guide. Zo scrumdamentalistisch zit ons team niet in elkaar. Wel omdat we last kregen van de grootte:

  • allereerst heel praktisch, de ruimte waar we zaten als team werd gewoon te klein om er te kunnen zitten met 11 man;
  • we merkten ook dat meetings steeds langer werden doordat in een grote groep iedereen toch zijn zegje moet doen;
  • en als belangrijkste, het werd vaak onrustig. Te veel interactie tussen teamleden is niet goed. Iedereen luistert toch even met een half oor mee als twee mensen met elkaar in gesprek gaan, als er een gebruiker langs komt met vragen, een stakeholder met wensen, etc.

Na de splitsing merkte we een enorm verschil in de rust rondom het team. Zeker in het kleinere team (4 man) dat in een kleiner, separate kamer ging zitten.

We hebben goed nagedacht over hoe we het team zouden splitsen. We zagen 3 snijvlakken:

  1. development versus maintenance, met andere woorden, bouw van nieuwe features versus vernieuwbouw van bestaande features
  2. functioneel beheer versus development; het team had 5 ontwikkelaars, 2 testers, 2 functioneel beheerders, 1 scrum master/tester en een product owner. Een optie was om de functioneel beheerders en de PO in een ‘ready-team’ te zetten, naast het development team
  3. een splitsing langs technische of functionele onderdelen van ons systeem

Optie 1 was aantrekkelijk en aanvankelijk de voorkeur vanuit de stuurgroep. Het team wordt behoorlijk geremd in de gewenste velocity voor nieuwbouw doordat er continu bugs en kleine praktische verbeterwensen uit de organisatie komen. Nieuwbouw krijgt daardoor niet de rust die nodig is om snelheid te maken.

Het nadeel van optie 1 is echter dat het een perverse mentaliteit oproept. Het nieuwbouw-team mag rommel afleveren omdat het maintenance-team het later wel zal oplossen. Natuurlijk zal niemand dat bewust zo aanpakken. Maar onbewust kan dit gevoel wel ontstaan. Een aanpak waarbij ‘de vervuiler betaalt’, degene die de bugs maakt ze ook moet oplossen leek ons beter.

Optie 2 had ook een paar voordelen. Het is (nog steeds) hard nodig in dit team dat er meer structuur komt in de backlog. We zitten nog in een fase die door Henrik Kniberg ‘spoon-feeding the team’ genoemd wordt, de PO kijkt maar 1 sprint vooruit. Aan de andere kant: de functioneel beheerders hebben veel domein-kennis die bij de developers veel beperkter is. Veel interactie tussen functioneel beheer en development om slimme, werkbare oplossingen te bouwen is noodzakelijk.

We hebben daarom gekozen voor optie 3. Het ene team pakt alle financiële onderdelen op van het systeem en imports van data van nieuwe klanten. Het andere team richt zich meer op documenten en workflows binnen het systeem. Ieder team heeft 1 functioneel beheerder die de PO ondersteunt in het refinen van de user stories.

Deze indeling is in feite een vertical slice. Vergelijkbaar met de manier waarop user stories geplitst moeten worden.

Advertisements

About André Heijstek

Rijnlands / Agile verbeteren van software ontwikkeling
This entry was posted in Agile, Scrum. Bookmark the permalink.

2 Responses to Opsplitsen van een Scrum team

  1. John Wansink says:

    Interessant artikel weer Andre. Ga hem morgen in Bodegraven delen:-)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s