Många IT-projekt blir inte klara i tid eller överhuvudtaget. De överskrider budget, både vad det gäller tid och pengar. Det är ett stort problem för både privata och offentliga organisationer. Det måste gå att driva IT-projekt effektivare! Men hur ska utvecklingsteam arbeta för att bli klara med sina åtaganden?
Det finns naturligtvis många anledningar till att projekt inte blir klara, exempelvis kan kraven vara otydliga. Det här inlägget kommer att lyfta vad vi ser som en av de största anledningarna, nämligen att projektteamet inte arbetar fokuserat med att hela tiden leverera färdiga funktioner. Endast det som är levererat till slutanvändare tillför värde.
För att kunna bli klar och leverera färdiga funktioner gäller det att dela upp funktionaliteten i minsta möjliga beståndsdelar som tillför värde för slutanvändaren.
Nedan följer vi två team som tar sig an ett, mycket förenklat, projektuppdrag; att bygga ett digitalt stöd åt en förskola för att kunna skicka informationsbrev till föräldrarna.
Exempel – Informationsbrev från förskolan
På förskolan vill man kunna skicka ut information, och vill ha ett digitalt stöd för det, där föräldrar kan prenumerera på ett informationsbrev. I en första analys har följande krav dykt upp: som förälder anger man sitt för- och efternamn, samt sin e-postadress, sen får man informationsbrev från förskolan.
Sprint 1
Det ena teamet kommer överens med förskolan om att det räcker med epost för att förskolan ska kunna skicka ut informationsbrevet. Det kommer att ge värde åt användarna, så i sprint ett bestämmer de sig för att enbart bygga funktionalitet för epost. För- och efternamn kan läggas till senare, när och om de blir prioriterade. Epost är en så liten funktion, att när sprinten är klar, kan teamet leverera en färdig funktion till användarna!
Det andra teamet gör ingen djupare analys av kraven, utan börjar koda med en gång. En person börjar med epost i användargränssnittet, en annan med förnamn i backend och den databasansvariga tänker att det är effektivast att skapa alla fält i databasen med gång. Det andra teamet påbörjar flera olika funktioner, men hinner inte helt klart med någon av dem. De har därför inget färdigt att leverera när sprinten är klar.
Sprint 2
Nu kommer förskolan på att det är viktigare att kunna skicka sms-påminnelser till alla föräldrar, än att ha koll på deras namn i systemet. Det kan t.ex. vara en påminnelse om att förskolan stänger tidigare idag.
Det första teamet jobbar tillsammans för att fokuserat bygga klart funktionen för sms-påminnelser, och när sprinten är klar levereras den funktionen till användarna.
Det andra teamet fortsätter med sina påbörjade aktiviteter för epost, för- och efternamn, och epost-funktionen blir klar! Dock kan teamet fortfarande inte leverera när sprinten är klar, eftersom databasen kräver förnamn och kraschar när användargränssnittet via backend skickar null som förnamn.
Sprint 3
Nu kommer förskolan på att det är viktigt att kunna knyta insamlade kontaktuppgifter till barnet, för att till exempel kunna meddela föräldrar att deras barn har fått feber och behöver hämtas.
Det första teamet lägger enkelt till den funktionen och levererar den i slutet av sprinten.
Det andra teamet börjar på den funktionen, men hinner inte klart. Dels för att kodbasen är stökig att jobba i, de har börjat på en arkitektur som inte på ett lätt sätt kan stödja det här nya kravet. Och dels för att de inte samarbetar med den funktionen, en del fortsätter jobba med föräldrars för- och efternamn.
Sammanfattning
I exemplet kan det första teamet snabbt byta fokus när beställaren kommer på nya behov. Det andra teamet har flera påbörjade men inte avslutade funktioner, vilket gör att det inte kan byta fokus lika snabbt.
När ett team fokuserar på en sak i taget, kommer det att kunna leverera tidigt, och svara på ändrade prioriteringar. En funktion som är halvfärdig tillför inget värde, tvärtom belastar den vidareutveckling. Värdet av en funktion realiseras först när den kan användas av slutanvändarna.
Hur lyckas det första teamet att bli klart i varje sprint? Jo, genom att:
- Tillsammans med beställaren hitta den minsta beståndsdelen som ger ett värde.
- Göra en sak i taget. Med en sak menar vi verkligen en sak, och inget annat. Att inte påbörja förnamn i något lager, när det är epost teamet bygger!
- Göra en funktion helt klar i hela systemet. Designad, kodad, refaktoriserad, testad och installerad.
- Inte utveckla saker teamet tror kommer att behövas senare (läs mer om YAGNI här!)
Om fler utvecklingsteam arbetade enligt denna enkla tes är vi övertygade om att fler projekt skulle lyckas leverera! Vilket skulle vara det första steget som ditt team behöver ta, för att komma närmare det här arbetssättet?
