Godispåsedagar

Vi behövde hitta ett format för att kunna jobba med mindre förbättringar för våra användare trots väldigt många stora nyutvecklingsprojekt som egentligen tog all vår kapacitet. 

Ibland kan ett utvecklingsteam hamna i ett läge att inflödet av stories som behöver utvecklas är betydligt större än vad teamet klarar av.  Det kräver en tuff prioritering så att vi verkligen vet att vi gör rätt saker, alltså det som levererar mest nytta. Vårt team hamnade i den situationen, det var mycket ny funktionalitet som skulle utvecklas för att kunna erbjuda helt nya produkter till våra kunder. Vi jobbade tillsammans med flera stora projekt med många team inblandade. Det innebar för oss att vi inte hade någon tid att ge användarna de små förbättringar som de önskade kring funktioner som vi redan hade levererat. Allt det fick läggas åt sidan för tillfället. Det betydde också att vi fick lägre motivation och arbetsglädje i teamet, att bara jobba med stora features som inte ska börja användas förrän långt senare när alla delar i kedjan är på plats kan vara utmanande. Dessutom växte backloggen okontrollerbart, vilket också ger en tung känsla.

Vi var tvungna att göra något! Så lösningen blev att vi planerade in en kort 3-dagars sprint som vi kallade för ”godispåsedagar”. Tanken var att plocka upp många små ärenden, som skulle ge stor nytta. Utvecklarna fick avgöra om det verkligen var en story som gick ner i godispåsen. Det fick inte vara för stort (max 2-3 timmars utvecklingstid) och inte ha beroenden till andra delar av systemet eller andra team.

Vi byggde en tillfällig tavla på väggen och började första dagen med att plocka in stories som kvalificerade som "godis". Utvecklarna fick sedan välja fritt från godispåsen. Produktägarna var på plats för att svara på frågor. Runt lunch byggde vi det som var klart till testmiljön och så kunde produktägarna testa medan vi fortsatte med fler stories under ytterligare en dag. Dag 3 avslutade vi med en demo och sedan produktionssättning av våra trettiotal stories som vi hade lyckats få klart. 

En bonus förutom att vi faktiskt levererade väldigt mycket värde på kort tid var att vi höjde temperaturen och motivationen i teamet. En utvecklare sa "alla fick lite återhämtning samt känsla att förbättra något som ger uppskattning av användarna”. Vi visade också för oss själva och för de stora projekten runt oss att vi behöver ta ansvar för hela vår lösning och alla våra användare. Att alltid prioritera utifrån strikt affärsvärde är inte modellen utan prioritering har så många andra olika aspekter. Att ge utrymme för att leverera sånt som inte har ett lika start business case kan stärka teamet och öka nöjdheten hos användarna.

Sen dess försöker vi nu alltid hålla ögonen på "godis", sånt som vi kan få in i våra releaser med lite arbete och som ger stor nytta. Länge hade vi kvar en speciell ruta på vår tavla där produktägarna kunde kasta in sånt som de hoppades skulle kunna vara godis och som utvecklarna kunde plocka ifrån.