Der er mange årsager til, at vi ikke har godt nok styr på tidshorisonter og afstemningsfrekvenser. En af de primære årsager er, at vi generelt er ret dårlige til at lure, hvor lang tid noget tager: Vi undervurderer konsekvent, hvor lang tid ting tager. Det kunne umiddelbart lyde som en dårlig ting, at vi generelt gør det – men det har nogle positive effekter, som er med til at gøre, at vi bevarer troen på, at det nok skal gå: “Vi skal nok nå at pakke bilen og nå færgen”, “Vi når nok at gøre rent inden gæsterne kommer” og “Naturligvis når vi at have hele systemet klar inden deadline”. Du kender sikkert flere…
Og mange gange når vi det faktisk, fordi vi netop tror på, at vi nok skal nå det. Det sker ofte, når vi har en vis erfaring med dét, der skal nås. Erfaring er nemlig med til at gøre vores “hvor lang tid tager det her mon?”-bud noget mere præcist.
Men når det er noget ukendt og uprøvet, har vi en grundlæggende tendens til at undervurdere kompleksitet og dermed tidsforbrug. Det er her, at vores tidshorisont kan risikere at være helt skæv…
Løsning: Gang altid med pi
Vi har to tommelfingerregler, som hjælper os med at undgå den værste tidsoptimisme. Den første tommelfingerregel er meget enkel: For at vi kan se, om noget virker, skal vi som minimum gøre det tre gange. Det gør nemlig, at man kan prøve at gøre det første gang, rette til anden gang og blive sikker tredje gang.
Men vær opmærksom på, at det er minimum tre gange! Som du nok ved, så gør øvelse mester. Så skal det ind på rygraden og være en god fast ny vane, skal man gerne gøre det mange gange. Vores anden tommelfingerregel er, at efter 10 iterationer, begynder det så småt at sidde på rygraden. Hvor lang tid, det så er, det afhænger af afstemningsfrekvensen.
Afstemningsfrekvenser i Scrum
Selvom de hjælper meget, de to tommelfingerregler, så kræver det stadig, at vurderingen af, hvor lang tid det tager at gøre det én gang, skal være rimeligt præcis. Her bruger vi de forskellige afstemningsfrekvenser, der er indbygget i Scrum.
I Scrum afholder man events med forskellige frekvenser: Daily Scrum holdes dagligt, retrospectives hver 2.-3. uge, Sprint Planning hver 2.-3. uge og eventuelt PI-planning hver 8.-10. uge. De tidsintervaller er dét, vi betragter som afstemningsfrekvens. De angiver nemlig, hvor tit vi mødes og har mulighed for at afstemme, hvor langt vi er kommet i vores fælles projekt med at ændre noget i vores vaner, arbejdsgange eller kultur.
Tricket er at vurdere, hvornår det bedst giver mening at snakke om hvad, der skal ændres.
Hvornår kan du se effekten?
Så langt, så godt. Tidshorisonten for et projekt, er altså afstemningsfrekvens ganget med 3. Men hvor lang tid tager det, før vi ved, om projektet har skabt en varig ændring?
Vores erfaring er, at det kan man begynde at konkludere på efter 3 gange tidshorisonten. Er tidshorisonten et sprint, kan du vurdere ændringens varighed og effekt efter 3 sprints. Det kan sagtens være, at du kan se en effekt af ændringen tidligere. Men den kan meget vel være ustabil og forsvinde igen.
Årsagen til det er ganske enkelt, at den største fare for nye gode vaner, er en travl hverdag. For det første, der ryger, når presset stiger, er nye vaner. Derfor kan man først korrekt vurdere, om en ændring af vaner, arbejdsgange eller kultur er slået effektivt igennem og har skabt en varig og stabil effekt, når hverdagen er sat ind. Og det tager sådan ca. tre gange så lang tid, som projektet varede.
Konkrete eksempler
Vi har lavet en lille liste over helt konkrete eksempler, som du kan lade dig inspirere af:
Fokus på kvalitetssikring af koden og vidensdeling
På sidste retrospective besluttede teamet, at man vil gøre en indsats for at kvalitetssikre koden og samtidig facilitere mere vidensdeling i teamet. Teamet opretter en statuskolonne kaldet kode-review i projektstyringsværktøjet, så man nemt på hver Daily Scrum kan tjekke, om der bliver lavet kode-review på alle opgaver og sikrer, at det ikke er de samme, der laver alle kode-reviews. Man aftaler, at man angiver initialer i opgavens titel, så resten af teamet nemt kan se, hvem der har lavet opgaven, og derfor ikke kan lave kode-review på den.
Til de første tre Daily Scrums skal der afsættes mere tid, da det er her usikkerheden og uenigheden kan være størst. Derefter handler det mest om at holde fast i det aftalte og lave mindre korrektioner.
Afstemningsfrekvensen er daglig, da det sker til Daily Scrum.
Tidshorisonten er 1 sprint. Det gør nemlig, at teamet dels har haft kode-review oppe på Daily Scrum 10 gange og dels, at de på et retrospective kan vurdere, om de er kommet i mål. Hvis ikke kan det være nødvendigt at fortsætte med at kigge på kode-review på Daily Scrum. Og er man i mål, bliver det taget op til tjek på de næste 2 retrospectives. Det sikrer nemlig, at når dagligdagen igen rammer, kan teamet hjælpe hinanden med at holde fast i at lave kode-reviews på den aftalte måde, selvom den måske er mere tidskrævende og besværlig.
Effekten af det nye tiltag slår først for alvor igennem efter 3 sprints. Det er først her, det giver mening at vurdere, om ændringen er varig og har den ønskede effekt.
Ny event: Kunde-reviews
Teamet vil gerne have en tættere kontakt og dialog med brugerne af det system, de udvikler. Men de er meget bekymret for, at vise brugerne funktioner, der ikke er helt færdige. De frygter, at kunderne ikke kan forstå, hvis noget bliver ændret, eller hvis noget fejler under et kunde-review.
Teamet rækker derfor ud til andre teams i organisationen, der har erfaring med kunde-reviews. De aftaler, at de kan holde en generalprøve på et kunde-review for et af de teams, der har gode erfaringer med kunde-review. De aftaler også med en konsulent, der er tilknyttet virksomheden, at konsulenten kan agere kunde til generalprøven.
Det betyder, at der skal afsættes mere tid til de første kunde-review. Det forventes, at tidsforbruget vil være markant lavere allerede efter 3-4 kunde-reviews.
Afstemningsfrekvensen er 1 sprint, altså 2-3 uger, da der kun afholdes et kunde-review i et sprint.
Tidshorisonten er 6-9 uger, alt efter om et sprint er 2 eller 3 uger.
Effekten kan først endeligt vurderes efter 18-27 uger, altså 5-6 måneder. Når afstemningsfrekvensen er lav, tager det lang tid, før alle involverede parter er blevet helt trygge ved at afholde kunde-reviews.
En af fordelene ved en meget lav afstemningsfrekvens er, at det hurtigt er svært at huske, hvordan det var før, man holdte kunde-reviews. Sammenholdt med vores erfaring om, at kunde-reviews er meget populære både af interne (eks. kundeservice) og eksterne interessenter (eks. brugere og samarbejdspartnere), så bliver kunde-reviews hurtigt en naturlig og fast rutine for teamet.
Vidensdeling mellem teams
Vidensdeling på tværs af teams i en stor organisation er en stor og vanskelig opgave. Men i kraft af flere større projekter, der dels går på tværs af teams og dels skaber et behov for at dele viden og erfaringer hurtigere og nemmere, vil man til PI-planning indføre to typer demoer: Feature demo og teknisk demo. Førstnævnte skal vise, hvordan nye features hjælper brugerne, så det er nemmere at forstå konteksten for den nye feature. Sidstnævnte har fokus på at give indsigt i, hvordan løsningen er lavet rent teknisk.
Til det første PI-planning udvælges 1-2 teams til at lave en pilot af en feature demo og teknisk demo. Disse teams kan bruge længere tid på at overveje formen for demoen, hvordan den udføres bedst muligt både praktisk og teknisk, hvordan den kan deles efterfølgende og så videre. På baggrund af erfaringerne fra disse pilot-demo, udformes en skabelon, som teams kan bruge, når de skal lave deres demo til det følgende PI-planning.
Afstemningsfrekvensen er meget lav i dette tilfælde, da der kun holdes PI-planning hver 3. sprint – altså hver 6-9 uge.
Tidshorisonten er 18-27 uger.
Effekten af vidensdeling til PI-planning kan derfor tage lang tid om at komme til udtryk på en måde, der kan ses tydeligt i dagligdagen. Der kan gå 1-1 1/2 år før det sker. Men det betyder ikke, at der ikke er nogen effekt i mellemtiden! Hav derfor tålmodighed – vores erfaring er, at effekten er så positiv og stor, at det nok skal være ventetiden værd.
