h1

Det är dyrt att vara riktigt agil. Eller?

onsdag, 2 november, 2011

Att vara agil när man jobbar i Scrum betyder (bland annat) att man efter varje iteration har lyckats bygga en ny fungerande och värdefull version av produkten (eller systemet) som går att leverera till kund eller butik om man så önskar. Men att vara riktigt agil kostar. Eller?

För att varje sprint ska resultera i en nytt levererbart inkrement ställs det stora krav. Först måste vi ha lyckats bryta ner våra features så att de är tillräckligt små så att flera får plats i sprinten. Och med ”få plats” menar jag att man hinner med allt för att gå från idé till leverans, dvs. varje enskild feature ska designas, kodas, testas, dokumenteras och sammanfogas med helheten (allt enligt vår Definition of DONE for User Stories). Vi behöver dessutom känna oss trygga i att resten av systemet fortfarande fungerar och att vi inte har introducerat nya buggar.

Om vi förutsätter att vi har kontroll över våra IT-system och inte har några externa beroenden vad gäller testmiljöer och servar (vi är inte beroende av externa köer för att få något jobb gjort) så är det ändå inte helt trivialt att få till en leverans varje sprint.

Låt oss titta på ett exempel på hur en treveckorssprint skulle kunna se ut.

.

Först och främst har vi våra Scrum möten. Syftet med dessa är att planera (läs analysera) vad vi ska göra härnäst (Sprint Planning), hur vi på bästa sätt koordinerar oss inom teamet (Daily Scrum), fånga upp feedback så att vi kan förbättra processen (Sprint Retrospective) samt lära oss vad som kan göra produkten ännu bättre (Sprint Demo). Sista fredagen är dessutom en sprint-fri dag där teamet kan hämta andan och samla ny energi till nästa sprint.

.

För att vi med trygghet ska vilja lämna ifrån oss den nya versionen (som innehåller våra nya features) vill vi dessutom känna oss trygga i kvalitén. Detta gör vi med att arbeta med att fixa buggar och verifiera buggfixar (Hardening). Vi vill också testa igenom systemet i sin helhet för att försäkra oss om att vår nya kod inte saboterat någon annan funktionalitet eller försämrat någon egenskap (såsom t.ex. prestanda). Denna testning inleds typiskt med en uppgradering av acceptancetestmiljön. Hela teamet hjälps åt att testa. Vad man fokuserar på klurar man ut som team genom att göra en riskanalys. Det kan t.ex. innebära en balans mellan körning av delar av regressionstestsviten plus identifierade Exploratory Testing sessioner. Var man lägger sin testfokus beror på var man ser att riskerna finns, vilka moduler som utsatts för förändring etc. När så slutgiltig paketering är gjord och en sista hand har lagts på dokumentationen är teamet redo att leverera den nya versionen till kund eller förvaltning. Tada!

.

Det som återstår är vårt utrymme för utveckling. Det är alltså denna tid som finns tillgänglig för design, kodning, testning och dokumentation av nya features. Det vi påbörjar ska hinna slutföras innan ”Code-freeez-mode” slår till.

.

Sådärja. Då har vi lyckats visualisera de olika typerna av arbete som pågår under en sprint. Låt oss visualisera hur de olika formerna av arbeta står i proportion till varandra…

.

Nu ska man ställa sig två frågor:

Vilket arbete tillför värde?
Vilket arbete är waste?

.

Eftersom exemplet inte förtäljer hela historien så kan vi bara spekulera. ”Development” och ”Scrum Meetings” tillför såklart värde, det är här vi skapar, analyserar, planerar, designar och koordinerar oss. Sedan bör vi ställa oss frågan – kan Scrum mötena (såsom sprint planeringen) göras effektivare och kortare?

”Hardening” borde inte behövas om vi byggde kvalitet från början. Detta är tydlig waste. Packaging, miljöuppgraderingar etc. döljer också troligtvis en hel del waste – detta borde gå att automatisera.

Den gemensamma testinsatsen som sker i slutet av sprinten… är den waste? Jag skulle argumentera för att den inte är det – här bygger vi kunskap om hur systemet som helhet mår efter att vi infört våra förändringar och bygger beslutsunderlag till frågan – ska denna release gå till kund?

.

.

Det som blir uppenbart av att titta på bilden är dock att själva utvecklingen av nya features som mest utgör hälften av arbetet. Mycket tid går åt till ”annat”. Man skulle kunna påstå att Velocityn blir ”lidande” (antal features eller Story Points per sprint) eftersom vi anstränger oss för att vara helt agila. Från ett leveransperspektiv är det så att varje sprint levererar ett färdigt och komplett increment, dvs. Definition of DONE för User Stories är komplett och lämnar inget till senare. Vi VET att vi hela tiden är redo för leverans till kund. I exemplet ovan ”vet” vi att vi har levererat 24 features när deadline närmar sig.

.

Att vara helt agil i Scrum kostar så det är enkelt att lockas till att flytta ut vissa kriterier från Definition of DONE for User Stories till Definition of DONE for Release. Dvs. vi skjuter viss testning, viss dokumentation, etc. till en ”release sprint”. Detta ökar vår Velocity (antalet features per sprint), men vi är å andra sidan inte leveransredo varje sprint eftersom vi har skjutit arbete och risk framför oss. Faktum är att release sprinten troligtvis inte alls blir en strikt timeboxad sprint eftersom vi inte vet hur mycket arbete och risk vi skjutit framför oss förrän vi sitter ner och planerar (och exekverar) den sprinten. Med detta upplägg kanske vi levererat 30 features när deadline kommer, men det troliga är att vi kämpar med testning, buggfixningar och refactoring av tekniska svagheter långt förbi deadline. Vad ännu värre är att vi har skapat en rejäl fördröjning i feedbacken mellan test och kodning då vissa tester inte körs förrän så mycket som fem sprintar senare.

.

Att inte vara DONE utan att först uppnå DONE i release sprinten öppnar upp för följande:

Vi riskerar missa deadline
Vi introducerar waste genom långa feedbackcyckler (både vad gäller test och kvalitet men även kundens feedback om funktions värde)
Vi skjuter på tekniska risk och missar chansen att hantera problem tidigt
Vi tappar den sanna insynen i hur vi faktiskt ligger till (vi vet inte vad som är klart och vad som är ”work in progress” eftersom vi inte testat klart)
Vi förlorar styrförmåga. Innan vi helt kan styra om fokus måste vi genomföra release ”sprinten”.

.

Så är det dyrt att vara agil, eller är det kostsamt att inte vara det?

.

4 kommentarer

  1. Mycket intressant läsning Jimmy!

    På Sveriges radio så jobbar vi med tre veckors sprintar, och jag känner igen mycket av dina resonemang. Vi driftsätter regelmässigt efter varje sprint. Finns arbete som kräver flera sprintar försöker vi ”dölja” det på hemliga url:er tills det är dags för att släppa det publikt. Vi har ingen codefreeze utan utvecklar ändå in i kaklet.

    Något vi själva pratar mycket om är att vi skulle kunna höja kvaliteten med just en codefreeze.

    Jag har skickat länken till hela vår avdelning och hoppas kunna prata om den på måndag eftermiddag när vi har vårt gruppmöte.

    mvh Jacob Hamacher
    Utvecklingschef Sverigesradio.se


  2. Hej Jacob,

    Väldigt roligt att höra att du fann artikeln intressant och givande!

    Låt mig kommentera lite kring ”Code freeze mode”. I detta sprint-upplägg jag ger som exempel (och som är baserat på ett riktigt projekt) förekommer en tidpunkt då teamet går in i ett ”Code Freeze Mode”. Efter denna tidpunkt är det fortfarande ok att fixa buggar (eller lägga till ny kod i syfte att höga kodens stabilitet), MEN för att minska risken att introducera nya galenskaper måste alla kod ske under Pair Programming.

    (Jag skulle kunna argumentera för att man alltid parprogrammerar. Då skulle ”Code Freeze Mode” råda hela tiden.)

    Efter ”Code Freeze Mode” slagit till (när detta ska ske planeras under ”Release Planning” i mitten av sprinten) får ingen utveckling av nya features ske.

    ”Code Freeze Mode” var kanske ett illa valt namn men jag hoppas du förstår andemeningen i tillståndet.

    Är det något jag vill belysa extra i exemplet ovan så är det att teamet gör en gemensam testinsats och att omfattningen av denna styrs av hur mycket risk man introducerat under utvecklingen av nya features.

    Detta upplägg gör att hela teamet tar ett större helhetsansvar samt att mognare diskussioner sker kring exempelvis:
    * Hur mycket kan vi committa till under Sprint Planning (och fortfarande hinna med Hardening, Joint Testing, Packaging och Release)
    * Kan vi påbörja OCH slutföra denna User Story under sprinten utan att introducera mera teknisk skuld.
    * Hur påverkar den tekniska lösningen på User Story X denna sprints releaseplanering?

    Sanningen ”Skräp in – skräp ut” blir väldigt konkret. Slarvas det med implementeringen av en User Story drabbar det en själv samma sprint eftersom alla hjälper till med Hardening och Testing.

    Lycka till med ert gruppmöte!

    Mvh
    /Jimmy


  3. Idag har jag återigen hänvisat till ditt blogginlägg efter att veckans release av funktioner till sverigesradio.se återinförde en del gamla buggar.

    Vi jobbar inte testdrivet och har väldigt lite regressionstester. Det gör att vissa typer av fel gärna återkommer. Särskilt fel i funktioner som inte direkt syns när vi surfar igenom på vår testserver. Denna gång uppstod ett fel i hur ljudklipp presenteras på Facebook, samt hur nyheter delas ut på twitter. Allvarliga fel för ett medieföretag som satsar på sociala medier.

    Det är väldigt svårt att testa logiken bakom en webbplats då logiken ofta är så visuell. Och det visuella uttrycket förnyas ständigt så är svårt för utvecklarna att veta exakt hur det skall se ut och fungera.

    Och det är svårt att vara trogen mot en gammal User story. Facebook och twitter gjorde vi i våras. Det går inte att titta på den ursprungliga specen längre då den utvecklats och förändrats. Så för att vara trogen sajtens alla användarfall så måste man kunna i princip hela sajten och dess historia. Och det är inte så lätt.

    /jacob


  4. […] Läs hela artikeln på Jimmy Janlens blogg […]



Kommentera

Fyll i dina uppgifter nedan eller klicka på en ikon för att logga in:

WordPress.com Logo

Du kommenterar med ditt WordPress.com-konto. Logga ut / Ändra )

Twitter-bild

Du kommenterar med ditt Twitter-konto. Logga ut / Ändra )

Facebook-foto

Du kommenterar med ditt Facebook-konto. Logga ut / Ändra )

Google+ photo

Du kommenterar med ditt Google+-konto. Logga ut / Ändra )

Ansluter till %s

%d bloggare gillar detta: