DevelopmentSamenwerking in Scrum teams

Herken je de volgende situatie? De organisatie heeft (ooit) besloten om Scrum te werken en daarmee is de organisatiestructuur veranderd: we hebben geen fases meer om werk over te dragen naar andere teams zoals in de waterval projecten en waar we eerst teams van alleen ontwikkelaars of testers hadden, hebben we nu Scrum teams. Volgens de theorie en kenners is dat goed maar we zien gelijk de eerste problemen opkomen. Waar we eerst een heel team van testers hadden, hebben we nu maar één tester* in het team, en wat gaat diegene doen aan het begin van de sprint als we nog aan het ontwikkelen zijn? (* of welke functie, die niet in het begin van de sprint zijn taken kan oppakken). We zijn immers gewend om altijd bezig te zijn in de waterval projecten, omdat deze vaak dakpansgewijs georganiseerd werden met meerdere projecten achter elkaar.

Scrum zelf zegt er niets over. Alleen het feit, dat het team in staat moet zijn een werkend increment op te leveren, maar niet hoe de samenstelling is en ook niet welke acties het team zou moeten doen. Dit laat veel ruimte over voor interpretatie van de invulling van de teams en ligt het dus aan de mensen die bezig zijn met de teamsamenstelling hoe die invulling gedaan wordt.

Om te weten waar we staan in een organisatie hebben we grofweg 4 fases bepaald:

Fase 1 – mini waterval

De eerste fase is die net nadat de organisatie is begonnen met Scrum. Van elke afdeling is een aantal mensen in het Scrum team gezet en de teamleden gaan aan de slag. Vaak zie je dat de mensen bij elkaar gezet zijn en er nog niet echt aan zelfmanagement is gedaan. Met andere woorden: de teamleden zijn ‘gedwongen’ met mensen samen te werken waar ze een paar dagen geleden nog over zaten te klagen ( en laten we eerlijk zijn: dat hebben we allemaal wel een keer gedaan) of waar ze het werk aan overdroegen.

Kenmerken van deze fase zijn:

  • mini watervallen: het team deelt het werk nog op in fases;
  • iedereen blijft in zijn eigen functie werken (testers testen alleen en ontwikkelaars ontwikkelen alleen);
  • de afwachtende houding van het team, wat ze moeten doen.

Eigenlijk zit men nog in de mindset van de waterval projecten en de functie die men nog heeft of had. Je bent immers aangenomen omdat je een tester of analist bent.

Daarnaast zijn sommige functies niet zo vaak ingevuld als dat er teams zijn. Denk dan aan specialisten, zoals documentalisten en architecten.

Fase 2 – De functie is dubbel uitgevoerd

In deze fase merk je dat de teams meer zelfmanaging worden; men ziet de problemen en komt met oplossingen. Eén van de problemen die men ziet, is dat als een functie maar één keer uitgevoerd is (er is maar één tester in het team) dan hebben we een probleem als deze ziek of vrij is.

Kenmerken van deze fase zijn dat er nog steeds wel een mini waterval van werken is en teams gaan meeracties ondernemen om hun werk beter te doen. Deze acties komen uit hun eigen ervaring en zijn dus vaak vanuit waterval gedacht De oplossing is dan ook voor deze teams om een tweede tester in het team te halen (wordt ook wel aangehaald als de verhouding tussen het aantal ontwikkelaars en aantal testers). Het probleem is in ieder geval opgelost, want elke functiegroep kan met elkaar afspreken dat er altijd iemand is.

Fase 3 – Iemand heeft even niets te doen

In deze fase merk je dat de teams beter worden in het Scrum proces zelf. Aan het einde van de sprint is (bijna) alles opgepakt en afgemaakt, de volgende sprint kunnen we beginnen met een schone lei (of sprint backlog).

Kenmerken zijn: taken worden nog steeds in volgorde opgepakt : eerst bouw, dan test. Daardoor worden taken voor testers in het begin van de sprint bedacht om ze bezig te houden tot de software ontwikkelt is. Dit wordt zeker meer zichtbaar als er meerdere testers of andere functies in het team zitten, die aan het einde van het proces zitten.

Een oplossing voor deze fase is niet om taken in de sprint te zetten voor mensen die even niets te doen hebben, maar het zogenoemde T-shape pi-shape model (π) te introduceren. Het idee van dit model is dat een teamlid heel goed is in één ding en de rest van de activiteiten in ieder geval een beetje kan. Dit lijkt voor teams in het begin vaak overweldigend: moet ik overal verstand van hebben? En het antwoord is eigenlijk: op een gegeven moment wel, ja. Maar begin met één activiteit, die je nog niet kan. Pi-shaped is hetzelfde als het T-shaped model, maar dan kan je één activiteit heel goed en minimaal nog één activiteit behoorlijk goed.

Om dit goed te laten werken bestaan er verschillende manieren, denk aan de Guilds in het Spotify model of vormen van pair programming. Het is in ieder geval belangrijk dat er kennisoverdracht is om mensen met minder kennis van een activiteit of onderwerp meer kennis te laten vergaren.

Fase 4- Volledige samenwerking

De teamleden weten wat ze aan elkaar hebben en weten ook hoeveel kennis de ander heeft van een onderwerp of activiteit. Er wordt al gekeken naar verbeteringen in het proces om nog minder afhankelijk te zijn van specifieke personen.

Kenmerken zijn: taken worden geautomatiseerd, user stories worden sneller opgepakt en afgemaakt en vaak zie je een duidelijke verhoging van opleveren van waarde. Let hier specifiek op de Daily Scrum en de retrospectieve hoe iedereen met elkaar omgaat.

De grenzen tussen de originele functies zijn vervaagd en er is een duidelijk team met gevoel voor verantwoordelijkheid richting een doel.

Conclusie

Elke fase heeft zijn eigen problemen en oplossingen en soms lijkt een team in twee fases te zitten. In dat geval is het beter om de problemen uit de eerdere fase op te lossen voor je verder gaat, omdat dat de basis is voor de verdere samenwerking.

Dit is natuurlijk een korte beschrijving van deze fasering en er zijn veel nuances en tips niet genoemd om teams nog beter de waarde te kunnen leveren, die ze willen.

Weten in welke fase uw team zit en hoe het team naar de volgende fase kan worden geholpen? Neem dan contact met ons op.

Alex Roos, DevOps consultant

  • Applicatie-modernisering-banner