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?

Många team använder Scrum och tycker att iterationer på tre veckor är häftigt snabbt. Allt är relativt. Vi beslöt oss vid årsskiftet för att gå över till en iterationslängd på en vecka och se vad som hände. Vi kände oss mogna för detta och produktägaren efterfrågade fler leveranser. Här följer en kort beskrivning av hur vi arbetar.

Kort bakgrund

Teamet har bestått av 5-8 pers varav 2-3 personer har ägnat sig åt produktägaruppgifter. Systemet är ett webbaserat, administrativt system för att hantera utbildningsobjekt på en akademisk institution i Stockholm. Metodikmässigt har vi använt en kombination av Scrum och XP. Vi strävar efter 100% testdriven produktionskod, vi använder acceptanstester i Fitnesse för att driva utvecklingen och vi har obligatorisk parprogrammering av all produktionskod. Vi har historiskt sett nästan helt använt iterationslängd på tre veckor. Projektet har pågått i ett drygt år så teamet är väl sammanslutet, metodikdrivna och bra på att leverera.

Förberedelser

Vår produktägare är en pigg dam från Norrbotten. Hon får stöd och övergripande prioriteringar från en kundgrupp av viktiga intressenter som träffas med en månads mellanrum, ibland oftare. I teamet har produktägaren stöd av en assisterande produktägare, på deltid, en UX-designer (användbarhetsexpert) på halvtid och Scrummäster. Produktägaren och hennes team arbetar parallellt med att prioritera och förfina user stories (enkla kravrepresentationer) inför kommande iteration.

Sprintplanering

Hela teamet samlas normalt på onsdag morgon kl 9.00 för sprintplanering. Mötet sker i stort sett enligt Scrums riktlinjer, bara mycket kortare. Produktägaren presenterar user stories i prioriteringsordning. Teamet diskuterar dessa och tar med hjälp av planeringspoker fram ett grovt estimat av varje user story i poäng (relativt mått på svårighetsgrad och arbetsinsats). Poängen ligger nästan alltid mellan 0,5 och 5 med 0,5 och 1 som vanligaste estimat.

Teamet åtar sig en veckas arbete baserat på magkänsla. Kunden beskriver sprinten med ett sprintmål. Varje user story bryts därefter ned i uppgifter som inte estimeras. Hastighet mäts istället i antal uppgifter per vecka och ligger normalt på 15-25.

Både user stories och uppgifter representeras av kort. Sprintplanen består av kort i grupper per user story i sekvens. Korten sätts upp på en whiteboard med kolumner för Åtaget, Pågår, Klart. Detta avslutar sprintplaneringen och tar 1 – 1,5 tim.

Under sprinten

Morgonmöte sker varje morgon under veckan kl 9 framför sprintplanen och tar normalt ca 5 min. Utvecklare tar en uppgift genom att sätta sina initialer på kortet och flytta det till Pågår. När uppgiften uppfyller våra klarkriteria får den flyttas till Klart.

Vi arbetar användningscentrerat, med en UX-designer som genomför workshops och användartester parallellt med övrigt arbete. Hon delar sin tid mellan detta och att hjälpa teamet skapa en god interaktionsdesign. Teamet förevisar kontinerligt framsteg för produktägaren, som också bistår med testning av applikationerna.

Avslutning

Sprinten avslutas med en kort demonstration för produktägaren och de som vill av kundteamet varje tisdag kl 13.00 och tar ca 30 min. Var tredje vecka har vi istället längre demonstrationer för alla som vill se kl 09.00. Dessa tar 1-1,5 tim. Vi har fortsatt att ha stora demonstrationer med treveckorsintervall helt enkelt då många intressenter har inte tid att komma varje vecka, men de vill ändå se allt som hänt sen sist.

Varje iteration avslutas med ett kort sprintretrospektiv på ca 30 min. Var tredje vecka är det längre, ca 1,5 tim. En mindre del av sprinten avsätts till internt effektiviseringsarbete. Retrospektiv har vi normalt i samband med sprintplaneringen för nästa sprint.