Enveckasiterationer del II

I ett tidigare inlägg berättade jag om hur vi har arbetat i mitt senaste team. Vi arbetar med enveckasiterationer, men det har vi inte alltid gjort. Tidigare har vi använt tre veckors iterationslängd. I detta inlägg tänkte jag kontrastera lite hur det är att gå från tre veckor till en vecka.

Fördelar

  • Planeringsmötet tar inte en tredjedel av tiden, vilket man kan tro, snarare en femtedel. Detta kan delvis förklaras av att vi kan förenkla och hoppa över vissa moment. Typiskt tar det en dryg timme men igår gjorde vi den på 45 minuter. Tidigare tog det 6 – 8 tim, för tre veckors arbete. Detta är givetvis bra då teamet istället kan lägga denna tid på att producera nytta.
  • Ett skäl till att planeringsmötet blir kortare är att vi slipper estimera uppgifter, dvs våra nedbrutna user stories. Vi har nått en bra nivå och våra uppgifter är oftast relativt små. Så vi förenklade och provade istället att bara räkna kort. Vi får 15 – 20 st på tre veckor. Det verkar fungera precis lika bra.
  • Antal och storlek på felestimeringar har minskat betydligt. Ju större arbetsmängd man ska estimera, desto större är naturligtvis risken att man har hamnat en bit fel. Med en veckas arbete är det mindre risk, även om vi i början var ganska dåliga på att få det rätt. En sprint estimerades till 6 poäng och när den började närma sig sitt slut fick vi lyfta ut 5 poäng. Nu har vi inte missat på många veckor.
  • Antalet uppgifter/kort räcker för att se status. Vi behöver därför inte att hålla koll med en sprintförbränningsgraf (eng. “sprint burndown chart”). I början fortsatte vi att rita den men, herrejösses, det är 4 dagar vi talar om! Det behövs inte. Sprintplanen är redan hanterbar och överblickbar.
  • Produktägaren gillar det. Hon kan välja att driftsätta varje vecka. Är något värdefullt för organisationen klart så får de ut detta till användarna på snabbast möjliga sätt. Leantankar omsatt i praktiken.
  • Möjligheten till omprioritering och nya tag nästa vecka skapar ett lugn och en flexibilitet hos produktägaren. Om något inte får plats så är det bara en vecka till nästa chans. Vi slipper många debatter om vad som är viktigt just nu.

Nackdelar

  • Givetvis kan kortare iterationer ge upphov till oproportionerligt stor andel transaktionskostnad, dvs tid att sätta upp och och avsluta varje iteration. Men som jag berättade ovan är vår erfarenhet snarare den omvända, om man kan utnyttja de förenklingar som man kan göra med en mindre omfattning.
  • En annan risk är att leveranserna tar för mycket tid, relativt sätt. Detta hände oss. Vår infrastruktur för leveranser höll inte måttet när vi gick till leverans varje vecka. Man kan välja att se detta som att vi blev avslöjade. Vi sänkte vattnet i floden tills dess att båten gick på grund, för att använda en leanmetafor. Lösningen är förstås inte att gå tillbaka till treveckorsiterationer utan att bli bättre på att leverera. Vi förbättrade våra byggskript, vi blev bättre på att följa IT-enhetens rekommenderade driftsförfarande, vi skärskådade beroenden på vårt system och minimerade vår exponering för att möjliggöra leverans utan att alla beroende system också måste leverera om. Att tvingas att bli bättre kanske egentligen ska ses som en fördel?

Så, borde alla team köra med en vecka?
Nej, det kan man inte säga. Jag kan bara säga att våra erfarenheter har varit mycket goda, så om man har möjligheterna tycker jag definitivt att man ska prova. Det har i alla fall gjort oss ett par snäpp mer agila.

Hur vet jag om vi kan prova enveckasiterationer?
Svårt att säga, men här är i alla fall en lista på vad jag tror är nödvändiga förutsättningar:

  • Mogen produktägare och kundteam som är duktiga på att förbereda planeringsmöten, prioritera och formulera user stories.
  • Engagerad, samlokaliserad produktägare
  • Moget team som är duktiga på agil metodik. De ska vara vana att hålla effektiva, tidsbegränsade möten.
  • Automatiserade systembyggen och leveranser
  • Troligen krävs ett relativt litet projekt, ett eller några team stort.

Något att fundera på
Så… om tremånadersiterationer är bättre än ett år långa, om enmånadsiterationer är bättre än tre månader och en veckas iterationslängd är bättre ändå, varför sluta där? Det är en relevant fråga. Om vi kan leverera på en vecka, varför inte varje dag? Eller, i förlängningen, kontinuerligt. Leveranser som bara en ständig ström av kontinuerligt värdeskapande. Ja, varför inte?

3 thoughts on “Enveckasiterationer del II

  1. “en lista på vad jag tror är nödvändiga förutsättningar:”

    Vi hade 4 av 5 punkterna som förutsättning och lyckades bra med enveckas. Produktägaren var helt ny och kundteamet också av ny sammansättning inte särskilt erfarna av att skriva user stories. Så om det här teamet fixade det med 4 av 5 punkter uppfyllda, tror jag att andra team också kan göra det. Kanske är det någon av de övriga 4 punkterna då som inte är uppfylld istället.

    Fö gillar jag din slutfundering, verkligen värt att fundera på!

  2. Du vet ju detta bättre än de flesta, men leveranser är inte bara en ström av värdeskapande, de möjliggör också kunskap om utvecklingshastighet etc. Så även om leveranser sker kontinuerligt är det värdefullt med timeboxar.

  3. Tack för kommentaren, Marcus! Jag är inte säker på var jag står i denna fråga ännu, det var därför jag ställde den. Men tillåt mig argumentera för att köra “iterationslöst” eftersom du tog ställning för iterationer.

    Ja, iterationsslut är praktiska tidpunkter för att mäta och kolla saker, helt korrekt. Men tror du inte att det finns sätt att göra detta utan att ha iterationer? Varför inte bara poängsätta stories och då och då kolla hur många som har gått igenom under en viss period? Inte behöver vi väl inrätta allt arbete efter det?

Comments are closed.