Tagcloud

Bepaal je sprintlengte gericht

Hoe de duur van de sprint bepalen.Om uiteenlopende redenen lukt het een startend team vaak niet om het geplande werk af te ronden binnen de duur van de Sprint. Toch kiest een team vaak voor een voor de hand liggende oplossing, het verruimen van de duur van de Sprint. Maar als je het werk niet af krijgt in bijvoorbeeld twee weken, waarom denk je het werk dan wel af te krijgen in drie of vier weken? “Ja, maar Scrum zegt één-vier weken, dus het mag toch?” Werk niet afkrijgen is een signaal waar we niet omheen moeten werken. Wat zijn de oorzaken dat het niet lukt? Waar doet het pijn? Lukraak een Sprint-lengte kiezen en de leercurve aangaan is niet de beste optie. Hoe kies je nu een Sprintlengte die het best past voor jouw team en project?

Projectduur
Het eerste waar we naar kunnen kijken is de projectduur. Stel dat je project drie maanden duurt en dat de Sprintlengte vier weken bedraagt. Dit heeft als gevolg dat de klant slechts twee demonstraties krijgt in de Sprint Review. Weinig feedback is een grotere kans op risico’s. Maken we wel het juiste? Heeft de klant wel een goed beeld van wat ze willen? Begrijpen we onze klant wel goed? Daarnaast heeft het Scrum Team slechts 2 mogelijkheden om te het proces waarmee ze samenwerken te evalueren en aan te passen. Weinig mogelijkheden tot verbetering. En inherent langer doorlopen met een knellende schoen. Mijn advies; kijk bij projecten die kleiner zijn dan drie maanden naar een Sprintlengte van één of twee weken. Duurt een project langer dan drie maanden (en minder dan een jaar!), kies dan een Sprintlengte tussen twee en vier weken. Een lengte van twee weken is in de meeste gevallen de juiste omvang voor ‘stimulus-respons’.

Klant/Stakeholders groep
Belangen van het ontwikkelteam en die van de klant kunnen verschillen. Een kortere Sprint kan voor ontwikkelaars een goede keuze zijn, echter dit kan nogal wat druk leggen op de relatie met de klant. Een kortere sprint vraagt namelijk om een hogere mate van betrokkenheid. Niet elke klant kan of wil dat. Dit is wederom niet iets waar we omheen moeten werken. Dat de mate van betrokkenheid sterk van invloed is op het succes van het project is helaas nog geen gemeengoed. En dat is niet zo gek. Klanten zijn vaak niet gewend aan een Agile proces als Scrum. Ze zijn gewend om voorafgaand aan een project eenmalig hun wensen te uiten. Dat de wereld tussentijd verandert, wordt toch maar even ‘vergeten’.  We willen ze juist graag gedurende het development proces aan boord houden. Het is niet zo zeer de vraag welke mate van samenwerking haalbaar is voor de klant, het is de vraag in welke mate ze mee willen werken aan succes. Er is werk aan de winkel om de klant ‘op te voeden’ waarom frequente feedback van essentieel eigenbelang is.

Het belang van frequente feedback mag dan wel duidelijk zijn, sommige bedrijfsomgevingen hebben de nodige beperkingen die een ideale Sprintlengte in de weg staan. Denk bijvoorbeeld eens aan de culturele beperkingen. Projectbetrokkenen kunnen allemaal nog zo overtuigd zijn van het nut van het frequent opleveren van werkende software, als hoger management vasthoudt aan de mindset van gedetailleerde planningen vooraf, heb je toch een ‘leuke uitdaging’. Daarnaast zijn er vaak ook beperkingen die te maken hebben met regelgeving. Dit soort beren blijken bij de introductie van Scrum niet gemakkelijk van de weg te tillen. In praktijk kan regelgeving een zware wissel trekken op wat en wanneer een team iets kan opleveren. Is er bijvoorbeeld sprake van de nodige audits, assessments en andere vormen van goedkeuring, dan ligt een Sprintlengte van minimaal twee weken meer voor de hand om in staat te zijn productierijpe software op te leveren. Blijf echter kritisch over nut en noodzaak die regelgeving met zich mee brengt. Vaak blijkt iets eerder een gewoonte dan noodzaak! Kunnen we het anders doen?

Scrum Team
Een belangrijke factor die de Sprintlengte beïnvloed is het Scrum Team. Denk bijvoorbeeld eens aan de ervaring van het ontwikkelteam, maar ook de engineering practices die ze gebruiken (test driven development, continuous integration etc). En wat te denken van hun vaardigheid om werk op te kunnen delen. En los van die vaardigheid vaak hun weerstand om dat te doen.

Startende teams hebben evident nog een hoop te leren als het gaat om Scrum. Er leeft aanvankelijk nog te veel de gedachte: “Dit is mijn aandeel in het werk”. Daarnaast is er de vastgeroeste gedachte dat individuele optimalisatie dé oplossing is voor de efficiëntie van de keten. Niets is minder waar. Het samen werken versus individueel werken aan resultaat is een leercurve. Starten met een Sprintlengte van een week is dan niet het eerste streven.
Maar een andere mindset is niet het enige dat telt. Goede engineering-vaardigheden zijn onmisbaar. We kunnen immers met volle overtuiging – zij aan zij – emmers doorgeven om een brand te blussen, het wordt wel wat lastig als er gaten in deze emmers zitten of als er geen hengsel aan zit. Met samenwerking en motivatie alleen redden we het niet. Voor korte Sprints hebben  teams daarom baat bij zaken als een continuous integration omgeving, test driven development, geautomatiseerd testen of pair programming. Scrum schrijft hierin niks voor, maar de gemeenschap laat zien dat er een aantal ingrediënten een substantiële bijdrage kunnen leveren aan geoliede teams.
Los van de Sprintlengte is de vaardigheid van een team om werk op te kunnen delen cruciaal. Niet alleen op ‘user story’-niveau, maar ook op taak-niveau. Werk opdelen vraagt om kritisch denken, een heldere geest en de vaardigheid over het probleem heen te kunnen kijken. Deze vaardigheid hebben we sowieso bij elke Sprintlengte nodig, maar het ontbreken van deze vaardigheid wordt knellender bij kortere Sprints. Is een team goed in deze decompositie dan zijn kortere Sprints van één a twee weken aan te raden. Hebben teams relatief meer moeite dan zijn korte sprints inherent knellender. Mocht je kiezen voor een ruimere sprint in dit opzicht dan is het wel raadzaam om vast te stellen dat het team echt moeite heeft. Onwil ligt vaak op de loer.

Tot slot
Alhoewel Scrum pleit voor het leren en aanpassen, is er tegelijkertijd ook een advies om de Sprintlengte constant te houden en deze gericht te kiezen. De redenen waarom Scrum afhankelijk is van een constant werkritme valt  buiten de scope van deze blog. Samenvattend is het verstandig om bij de start van een project de volgende zaken in kaart te brengen:

  • Wat is de duur van het project?
  • Hoe beschikbaar is de klant voor zowel feedback als gedurende de Sprint?
  • Is de klant al bekend met Scrum?
  • Zijn er culturele beperkingen?
  • Zijn er beperkingen ten aanzien van regelgeving?
  • Ervaring team met Scrum?
  • Technische capaciteiten team?
  • Is het team vaardig in decompositie van werk?

Belangrijkste advies; werk niet om problemen of uitdagingen heen. Onderzoek waar het pijn doet en kijk naar oplossingen.  Scrum is geen status quo. Het blijft een proces van leren en aanpassen. Er zullen dan ook een aantal heilige huisjes onbewoonbaar verklaard gaan worden.

 Wil je op de hoogte gehouden worden van nieuwe blogs, volg ons op Twitter!
Heb je een vraag of opmerking naar aanleiding van deze blog? Neem dan gerust contact op!

  
Problem to solution