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 met alleen ontwikkelaars of alleen 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? 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, behalve dat het team in staat moet zijn een werkend increment op te leveren. Er wordt niets gezegd over de samenstelling van het team en ook niet welke acties het team zou moeten doen. Dit laat veel ruimte over voor interpretatie en is het dus aan de mensen die de teams samenstellen.
Om te weten waar we staan in een organisatie hebben we grofweg 4 fases bepaald om te zorgen voor een probleemloze samenwerking binnen een Scrum team:
Fase 1 – mini waterval
De eerste fase is die net nadat de organisatie is gestart 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 meer acties 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 ontwikkeld 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 retrospective 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 jouw team zit en hoe het team naar de volgende fase kan worden geholpen? Neem dan contact met ons op.
Alex Roos, DevOps consultant
