Systemhus

Steg 2: Agil utveckling

Development process - Step 2 w frame

 

Veckocykler

Att jobba agilt innebär, som vi kort har beskrivit tidigare, att man jobbar flexibelt och i veckocykler. I den agila terminologin kallas en veckocykel för en sprint. I varje sprint utvecklas produkten ännu ett steg och lanseras till användare för att testas. Resultatet blir input som startar nästa veckas sprint.

Få ut värde tidigt

Anledningen till att man numera arbetar agilt är att man har förbättrat sina processer baserat på erfarenheterna från en mer klassisk linjär utveckling, vilken vi beskrev i ”Steg 1: Från idé till definition”. Man vill även få ut ett värde till kunden så tidigt som möjligt i utvecklingsprocessen och inte först när slutprodukten är färdig.

MVP

Den initiala produkten som kommer efter första sprinten kallas MVP, Minimum Viable Product, ungefär Minsta ”livskraftiga” produkt. Ofta innehåller MVP bara en liten del av all funktionalitet som i slutändan ska levereras, men tillräckligt mycket för att en användare ska kunna börja använda produkten och att den ska ge ett första värde till kunden.

Handbromsen

Kunden har alltid möjlighet att dra i handbromsen vid varje sprintavslut när produkten presenteras för dem och andra stakeholders. Återkopplingen kan då bli ”fortsätt med detta”, ”justera detta” eller ”detta behöver vi ändra totalt eftersom prioriteringarna har förändrats”. Ibland behöver man också pausa vissa delar i projektet därför att andra saker har dykt upp som måste inkluderas.

2 veckor

Vi rekommenderar sprintar på 2 veckor. Det innebär att vi jobbar i 2-veckorspass med att utveckla det som vi tillsammans med kunden har definierat för den sprinten. Passet avslutas med att demonstrera för kund och planera vad som ska göras i nästa 2-veckorssprint. Vi reflekterar över hur det har fungerat att arbeta under sprinten och om det är något vi ska ta med oss till nästa arbetspass.

Flexibla tider

Tack vare det agila arbetssättet har vi möjlighet att jobba på flera olika sätt beroende på kundens behov och preferenser. För sprintarna är vår rekommendation 2 veckor, men vi är flexibla om vår kund vill ha ett annat tidsintervall. Den vanliga tiden för en sprint är mellan 1 till 4 veckor för att behålla en bra fart i processen.

Scrum, Kanban och ScrumBan

Vi använder Scrum i den framåtriktade utvecklingen, dvs. där man planerar framåt i utvecklingen av produkten. För bakåtriktad utveckling, dvs. underhåll, använder vi istället Kanban. En tredje metod som vi gärna arbetar efter är ScrumBan. ScrumBan är en kombinerad metod för både framåtriktad och bakåtriktad utveckling där teamet avsätter X procent av tiden för underhåll och lägger resten på sprintarna, vilket ger en ännu närmare integration mellan underhåll och utveckling.

Lärdomar

Våra erfarenheter från att ha arbetat agilt under en längre tid är att både våra kunder och vi själva lär oss under processen, vilket gör efterföljande sprintar enklare att definiera. Processen tar också hänsyn till en snabbrörlig marknad som inte ser exakt likadan ut när idén till produkten uppstod som när produkten är klar att lanseras.

 

Se de andra stegen i utvecklingsprocessen:

 


 

Mer information

 

 jag vill veta mer