Commitments in agile teams
Enkele van de laatste artikelen gingen over Continuous Discovery en Dual-Track Agile. In dit artikel wil ik het hebben over een andere dimensie van effectieve werkwijzen in een agile omgeving – namelijk hoe je omgaat met commitments.
Commitments zijn vaak een probleem
Als je in agile teams het onderwerp commitments aansnijdt (bijvoorbeeld wanneer je wilt weten wat je gaat krijgen en wanneer), proberen de meesten zich eruit te draaien, of ze weigeren simpelweg.
Het is een permanente strijd tussen de managers en de stakeholders, die het bedrijf draaiende willen houden (met behulp van wervingsplannen, marketingprogramma's, samenwerkingen en contracten die afhankelijk zijn van concrete deadlines en resultaten) en de leden van het productontwikkelingsteam, die begrijpelijkerwijs niet graag commitments afgeven voor deadlines en productopleveringen – tenminste zolang ze nog niet precies weten wat ze moeten opleveren en of ze überhaupt in staat zullen zijn om de vereiste bedrijfsresultaten te leveren. Bovendien kunnen ze nu eenmaal niet inschatten wat het uiteindelijk gaat kosten als ze nog helemaal geen oplossing hebben.
De reden hiervoor is een les die veel productteams op pijnlijke wijze hebben moeten leren, namelijk dat veel ideeën simpelweg niet werken zoals we hadden gehoopt, en dat je voor de ideeën die wél zouden kunnen werken, normaal gesproken een aantal iteraties nodig hebt voordat je op een punt bent aangekomen waarop je het product een succes voor het bedrijf kunt noemen.
Bij klantspecifieke software kun je misschien gewoon zoveel iteraties doorvoeren totdat „het bedrijf" tevreden is met de software (of het idee weer laat vallen). Bij een productbedrijf werkt dat zo niet.
Begrijp me niet verkeerd. Veel mensen hebben me horen klagen over de gevaren van stakeholder-roadmaps. Het artikel over de Opportunity Backlog is slechts het meest recente dat op dit probleem ingaat. Goede productbedrijven minimaliseren deze commitments. Toch zijn er altijd enkele commitments die aangegaan moeten worden om een bedrijf effectief te kunnen runnen.
Wat moet je dan doen?
Het gaat erom te begrijpen dat het moment waarop de commitments worden aangegaan, de oorzaak is van alle problemen met commitments. Ze worden namelijk te vroeg aangegaan; nog voordat we überhaupt weten of we deze verplichting kunnen nakomen – en wat nog veel belangrijker is – of we daarmee überhaupt het probleem van de klant kunnen oplossen.
Ik heb al eerder over een vergelijkbare situatie geschreven (zie hier). Bij Dual-Track Agile gaat het bij de Discovery Track erom deze vragen te beantwoorden voordat we geld en tijd investeren om kwalitatief hoogwaardige producten te bouwen.
Bij commitments draait het dus allemaal om een voortdurend geven en nemen. We vragen de leidinggevenden en de andere stakeholders om ons in de Product Discovery wat tijd te geven, zodat we kunnen nadenken over de benodigde oplossing en de oplossing kunnen laten valideren; de klanten moeten de waarde en bruikbaarheid bevestigen, de ontwikkelaars moeten de haalbaarheid waarborgen en de stakeholders moeten bevestigen dat het voor het bedrijf ook levensvatbaar is.
Zodra we een passende oplossing hebben gevonden, kunnen we een weloverwogen en zelfverzekerde uitspraak doen over wanneer we het kunnen opleveren en welke bedrijfsresultaten we kunnen verwachten. We kunnen ook overwegen of het de moeite überhaupt waard is.
Let op dat onze projectmanagers enorm belangrijk zijn als het gaat om het bepalen van concrete data voor de commitments. Denk maar eens aan wat er gebeurt als de ontwikkelaars er weliswaar van uitgaan dat iets misschien maar twee sprints duurt, maar het team al bezig is met ander werk en ze pas over een maand met nieuw werk kunnen beginnen. Deze commitments en afhankelijkheden worden door de projectmanagers bijgehouden.
Het compromis is dus heel eenvoudig. Het productteam vraagt om wat tijd voor de Product Discovery voordat er commitments worden aangegaan. Na de Discovery-fase kunnen we dan commitments afgeven voor deadlines en resultaten, zodat ook onze collega's effectief hun werk kunnen doen.
Deze tekst is afkomstig uit de blog van Marty Cagan en is door ons naar het Nederlands vertaald.
Word gecertificeerd Scrum Master met de Agile Academy
Als je je team als Scrum Master beter wilt ondersteunen bij hun commitments en je op zoek bent naar meer informatie, hebben we verschillende mogelijkheden voor je.
Onze gecertificeerde trainers bieden opleidingen aan over de hele wereld en zorgen voor een training die perfect aansluit bij jouw vraagstuk.
Voor Scrum Masters bieden we de volgende trainingen en gratis opleidingsmogelijkheden:
