Att jobba iterativt och inkrementellt

För att vi ska kunna leverera värde så tidigt som möjligt behöver agil utveckling både vara iterativ och inkrementell. Men vad är egentligen skillnaden och hur ser det ut när vi jobbar både iterativt och inkrementellt?

Den iterativa processen

Definitionen av iterativt är att någonting upprepas. I en agil kontext innebär det att vi gradvis förfinar eller förbättrar vår produkt. I blogg-posten Agile Needs to Be Both Iterative and Incremental jämför Mike Cohn den iterativa processen med hur en skulptör jobbar. Skulptören mejslar till en början ut grova konturer och förfinar sedan skulpturen allt eftersom, genom att mejsla ut finare detaljer, under återkommande sessioner.

Om vår utvecklingsprocess är helt och hållet iterativ, men inte inkrementell, skulle det innebära att vi bygger alla kravställda funktioner parallellt. Vi skulle sedan kontinuerligt förfina dessa funktioner, till dess att allt jobb är klart. Bilden nedan illustrerar en sådan process:

Att jobba med gradvis förbättring på det här sättet är ett steg i rätt riktning, men det är fortfarande något som fattas för ett fullt ut agilt arbetssätt, nämligen: ett inkrement av vår produkt.

Den inkrementella processen

Inkrementellt innebär att någonting sker stegvis. I en inkrementell arbetsprocess fokuserar man på att bygga bitar, eller inkrement, av ett helt system. Till skillnad från den iterativa processen fokuserar man på att helt och hållet färdigställa en funktion innan man börjar jobbet med nästa.

Om vår process vore helt och hållet inkrementell, men inte iterativ, skulle det innebära att vi jobbar på varje funktion tills dess att den är helt klar och perfekt innan vi påbörjar nästa funktion. En illustration av en sådan process kan se ut så här:

Det är vanligt att nya team som anammar Scrum hamnar i ett arbetssätt som påminner om detta. När vi jobbar i en process som är inkrementell men inte iterativ, kan vi lura oss själva att tro, att vi har ett agilt arbetssätt, men eftersom vi ofta jobbar med ett inkrement i taget – där varje nästkommande moment dessutom, ofta är beroende av att ett föregående moment är klart – jobbar vi fortfarande på ett sätt som mer påminner om “vattenfall”, det traditionella sättet att jobba.

Tre tecken på att vi jobbar inkrementellt men inte iterativt är att:

• Trots att vi bygger vår produkt i små steg – det vill säga inkrement – har vi inte levererat en potentiellt publiceringsbar version i slutet av varje iteration.
• Vi jobbar på en enskild uppgift eller aktivitet till perfektion, istället för att gradvis förbättra helheten. Bara när föregående uppgift är helt klar, kan vi påbörja nästa. (Till exempel ägnas de första sprintarna åt design. Sedan ägnar vi kanske en hel sprint endast åt utveckling. Och sedan ett par sprintar åt utveckling kombinerat med testning.)
• Vi bryter ner våra krav horisontellt istället för vertikalt. Ett exempel på en horisontell nedbrytning skulle till exempel vara att vi har ett beroende mellan tre user stories där varje story representerar ett separat “skikt”: En story för UX-jobbet, en story för frontend-jobbet och slutligen en story för backend-jobbet. I en vertikal nedbrytning skulle en story, i detta fall, istället innehålla en del UX, en del frontend och en del backend-uppgifter. (Läs mer om att bryta ner stories vertikalt: 10 useful strategies for breaking down large User Stories).

Notera att det rent inkrementella arbetssättet även kan benämnas som “Iterativt Vattenfall”. Låt dig inte förvirras av att uttrycket innehåller ordet “iterativt”, det är fortfarande ett inkrementellt sätt att jobba. Här syftar man helt enkelt på att man jobbar i en traditionell process (även kallat “vattenfall”), och att man ovanpå det har anammat det agila tänket att fördela sin tid över cykler/sprintar – det vill säga iterationer, därav “iterativt vattenfall”.

Problemet med att jobba på det här sättet är att vi kan hamna i en situation där vi har investerat för mycket tid i en viss lösning och att det därför blir för dyrt att ändra eller göra om. Vi har helt enkelt målat in oss i ett hörn och får nu stå vårt kast. Detta arbetssätt leder även ofta till starka beroenden mellan aktiviteter, där förseningar i en aktivitet påverkar flera – eller ibland samtliga – efterföljande aktiviteter. Genom att investera mycket tid och jobb i en isolerad del av systemet vid ett tidigt stadium, blir vi också ovilliga att göra ändringar senare. I och med detta har vi även brutit mot agil princip nummer 2, som säger att vi ska “välkomna förändrade krav, även om de kommer sent under utvecklingen”. Med andra ord, finns det en risk att ett arbetssätt som är inkrementellt men inte iterativt, gör oss mindre lättrörliga (läs: mindre agila).

Iterativt och inkrementellt

När vi kombinerar det iterativa och inkrementella arbetssättet får vi en process där vi både jobbar med flera funktioner (eller aktiviteter) parallellt och där vi samtidigt levererar någonting som går att använda i slutet av varje iteration: ett inkrement. Detta är vad ett agilt arbetssätt eftersträvar: genom att fokuserar på att leverera någonting potentiellt användbart i slutet av varje cykel, levererar vi värde både tidigare och oftare än om vi hade jobbat bara iterativt eller bara inkrementellt. Vi skapar samtidigt möjligheten att få tidig feedback från kunden eller användaren, vilket är ett viktigt verktyg för att vi ska kunna lära oss mer om projektet under resans gång. Ett arbetssätt som är både iterativt och inkrementellt kan till exempel se ut såhär:

Som du ser är detta arbetssätt inkrementellt därför att man leverera en fullständig version i varje cykel, och det är iterativt därför att man kontinuerligt förbättrar sin nästkommande version under varje iteration.

Koncepten ovan kan vara enkla att förstå men samtidigt svåra att implementera. Kom ihåg att vägen till att bli agil är en ständigt pågående resa, det är inte en destination. Det viktiga är att kontinuerligt utvärdera både sig själv och sin organisation, och att fortsätta ta små steg i en riktning mot ett mer agilt arbetssätt.