• 2012/08/01
  • ALbert Mietus
  • Nederlands
  • Narrative, Geïntegreerd Agile
  • Team

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 (beoogd) effect.

  • Behoudt 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 al testers bevatten. Ook functionele en domein-kennis is belangrijk. Evenals kennis over test-automatisering. Dit zijn minimum eisen; zonder hier aan 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 teams. En er een geheel van bouwt.

Disqus

Aardige feedback is altijd welkom, evenals alternative meningen; zolang ze relevant zijn voor alle lezers. Hiervoor gebruik ik momenteel ‘Disqus’.

comments powered by Disqus