- 2012/08/01
- Nederlands
- Narrative Geïntegreerd Agile
Het bouwen van een effectief Geïntegreerd Agile team¶
Ik krijg vaak vragen over het samenstellen of wijzigen van een agile- of scrum-team. Wie doet
dat? Waarom en wanneer verandert het team? En vooral: hoe helpt dit om het team (steeds)
efficiënter te maken?
Dit zijn goede vragen, al zijn ze lastig te beantwoorden. Er is namelijk geen vast stramien
voor. Bovendien zijn de antwoorden sterk afhankelijk van het project en de omgeving. Een nieuw
project van 8 FTE opzetten is anders dan het ombouwen van een bestaand project met 17 of 50
mensen naar een Geïntegreerd Agile team. Ook zal, telkens als het project groeit of krimpt,
moeten worden nagedacht over het bouwen van het team.
Afwegingen¶
Ik wil mijn ervaring (en visie) hierin graag delen. Onderstaande afwegingen gelden zowel voor Geïntegreerd Agile software-engineering projecten als voor gewone- en scrum-teams. De focus ligt echter op complexe projecten met meerdere (sub)teams.
Vakmanschap van de ScrumMaster¶
Het bouwen van een goed team is de verantwoordelijkheid van de ScrumMaster. Die moet dat
in goede banen leiden, al heeft de rest van het team veel invloed. En zoals in elk team of project
is het vooral vakmanschap dat bepaalt of het goed gebeurt.
Hoewel vakmanschap en ervaring belangrijk zijn, zijn er een aantal algemene aandachtspunten.
Daarbij is één regel impliciet en het meest belangrijk: Zorg dat de opbrengst in lijn ligt met de
investering!
Een projectteam verdubbelen qua omvang zonder de overtuiging dat de velocity ook (ongeveer)
twee keer zo groot wordt, is niet vaak verstandig. Natuurlijk zijn er omstandigheden waarbij het
niet anders kan. Maar zorg dan dat de redenen vooraf besproken zijn.
Prioriteiten¶
Veel zaken zijn belangrijk; de vraag is, welke zijn nog belangrijker dan anderen? In de stijl van het Agile-manifest kunnen een aantal prioriteiten benoemd worden:
Motivatie is veel belangrijker dan kennis (van Agile).
Verbeteren is veel belangrijker dan perfectie.
Een verbeterde toekomst is veel belangrijker dan elke fout in het verleden.
Vuistregels¶
Samen met een paar vuistregels moet er gezocht worden naar de juiste balans. Zoals vaak gaat het niet om het toepassen van het proces, of de regels, maar om het (beoogde) effect.
Behoud mensen en kennis!
Roei met de riemen die je wel hebt!
Verbeter per sprint!
Kijk naar het geheel¶
Een van de belangrijkste uitgangspunten is: een team is zelfstandig. Er moet dus voldoende kennis aanwezig zijn. Bij een software-engineering-project moet elk team zowel programmeurs als testers bevatten. Ook functionele en domeinkennis is belangrijk. evenals kennis over testautomatisering. Dit zijn minimumeisen; zonder hieraan te voldoen is het sterk de vraag of de doelstellingen gehaald worden. Zie ook de bekende valkuilen in Zwart-Wit, zonder Grijs!.
Naast deze ‘cognitieve’ kennis is ook ervaring en ‘senioriteit’ nodig, evenals een goede mix van soft-skills. Een team met louter grijze muizen is vaak niet effectief, maar een team waarin iedereen vecht om de meeste aandacht ook niet. Terwijl een mix van saaie, ‘mieren-neukende’, detaillisten en de bekende spring-in-het-veld, ongeleide ‘genieën’ prima kan werken. Zeker als er ook een paar ‘gewone’ collega’s tussen die extremen zitten.
Het gaat om de mix. Niet elke groep mensen is een team. Zoek dus niet naar perfectie in mensen,
maar naar mensen die goed samenwerken en zo perfectie nastreven.
Zo is een goede ScrumMaster ook een leider, die luistert naar zijn teamleden en er een team
van bouwt.
Disqus
Aardige feedback is altijd welkom, evenals alternative meningen; zolang ze relevant zijn voor alle lezers. Hiervoor gebruik ik momenteel ‘Disqus’.