Hur ska vi utveckla stora och komplexa IT-lösningar när det finns så många okända variabler? Vattenfallsmodellen fungerar inte, utan vi behöver använda en implementeringsmodell som har förändringshantering som sin kärna. En av de mest använda ramverken är Scrum. Lägg fem minuter på att läsa vidare så förstår du vad Scrum går ut på.
Överraskande ofta används vattenfallsmodellen i IT-projekt ‒ eller varianter av den. Detta innebär att projektet är indelat i separata faser där man först planerar allt, sedan bygger allt, sedan kvalitetssäkrar allt och slutligen går live med produkten när allt är klart. Jobbet forsar på som ett vattenfall, uppifrån och ned.
Detta är ett bra sätt att genomföra ett projekt på om du till exempel bygger en bro. Då behöver du samla in all information i början för att sedan kunna genomföra projektet på ett bestämt sätt, i en given ordning. Beställarens önskemål och de blivande användarnas beteende kommer inte att präglas av radikala förändringar eller påverkas av nya trender ‒ den som ska använda bron ska helt enkelt ta sig från A till B. Byggmaterialets livslängd är relativt konstant och kan planeras för, vindhastighet kan beaktas och så vidare. Brobyggarprojektet har mer eller mindre konstanta parametrar som du vet om i förväg och kan planera för.
IT-projekt har inte den här lyxen. Det finns relativt få riktiga konstanter och det kan under projektets gång hända mycket som är svårt att förutsäga. Både beställarens och användarnas behov, beteendemönster eller intressen kan förändras. De ramverk och tekniker som används för att bygga en IT-lösning förändras ständigt. En annan aktör kan lansera en konkurrerande lösning. Lagändringar kan kräva nya funktioner ‒ tänk på hur GDPR förändrade kraven på lagring och radering av data. Om vi redan har planerat hela vårt IT-projekt när en sådan förändring sker, står vi inför ett enormt problem.
Så hur ska vi utveckla stora och komplexa IT-lösningar när det finns så många okända variabler? Det vi behöver är en implementeringsmodell som inte bara tar hänsyn till att det finns en viss risk för förändring, utan som har förändringshantering som sin kärna. Ett av de mest använda ramverken är Scrum.
Vad går Scrum ut på?
Scrum är ett smidigt processramverk utvecklat för att stödja komplex produktutveckling. Det är baserat på empirism, det vill säga att kunskap kommer från erfarenhet och beslut baseras på vad som är känt. Scrum är det ledande ramverket för mjukvaruutveckling, men det kan också vara användbart i andra sammanhang.
Scrum består av tre grundläggande roller som tillsammans utgör ett Scrumteam:
- Produktägare, som oftast är kunden och bestämmer vad produkten ska omfatta. Produktägaren prioriterar löpande vilka funktioner som ska utvecklas och arbetar tillsammans med Scrumteamet för att i detalj beskriva önskad funktionalitet och skapa acceptanskriterier. Detta arbete dokumenteras i en ”product backlog” ‒ en prioriterad och estimerad lista över funktionalitet. Produktägaren är vanligtvis en person som har djup kunskap om verksamhetsområdet, känner väl till användarnas behov och har beslutsförmåga och behörighet att prioritera både efter funktionalitet och budget.
- Utvecklingsteamet bygger produkten enligt produktägarens prioritering. Utvecklingsteamet ska vara självorganiserande ‒ deltagarna bestämmer själva hur de vill organisera arbetet och alla är ömsesidigt ansvariga för att leverera den beställda funktionaliteten. Storleken på utvecklingsteamet är normalt mellan 5 och 9 personer ‒ tillräckligt många för att leverera en betydande mängd arbete, men få nog för att vara flexibla. Utvecklingsteamet är optimalt kompetensmässigt sammansatt så att det kan leverera en färdig, produktionssatt lösning, och har företrädesvis kompetens inom design, arkitektur, mjukvaruutveckling och kvalitetssäkring.
- Scrum Master ser till att hela Scrumteamet följer Scrum-teorin. Detta görs bland annat genom att vara coach och sparringpartner, underlätta god kommunikation och planering, ta bort hinder som uppstår under vägen, skydda utvecklingsteamet för distraktioner och yttre tryck samt underlätta transparenta processer mellan utvecklingsteam och produktägare. En Scrum Master har ingen formell auktoritet, men fungerar som en ”servant leader” som säkerställer att alla har det de behöver för att utföra sitt jobb effektivt.
Genomförandet sker i cykler
Projektet i sig genomförs på ett inkrementellt sätt. Det innebär att man börjar med den viktigaste och grundläggande funktionaliteten (dvs den funktionalitet som produktägaren prioriterar mest) och bygger sedan på med mer och mer funktionalitet. På det här sättet maximeras alltid värdet på produkten och det blir korta återkopplingsslingor ‒ utvecklingsteamet får kontinuerlig feedback om vad som fungerar eller inte fungerar och kan göra justeringar allt eftersom.
Detta görs i så kallade ”sprintar” ‒ fasta leveranscykler på en till fyra veckor. Under sprinten planerar och utvecklar man nästa steg (eller version) av produkten. Man visar funktionaliteten för projektets intressenter och gör därefter utvärdering och genomför förbättringsåtgärder.
Sprintcykeln får hjulen att snurra
- Planeringsmöte: En sprint börjar med ett planeringsmöte där Scrumteamet fastställer vad som ska levereras under sprinten och hur. Varje enskild funktionalitet granskas tillsammans med produktägaren, så att hela utvecklingsteamet har en god förståelse för både behov och mål som detaljplaneras sedan ned till specifika arbetsuppgifter. Resultatet av mötet är ett övergripande mål för sprinten. Sprint-backloggen, dvs alla uppgifter som ska utföras i sprinten, består oftast av digitala komihåg-lappar på en tavla med kolumner för ”to do”, ”doing” och ”done”.
- Sprint: Under sprinten utförs själva arbetet. Varje medlem i utvecklingsgruppen väljer en uppgift ur “to do”-kolumnen, slutför den och flyttar den till ”done”. Vanligtvis är flera personer inblandade i samma uppgift för att kvalitetssäkra arbetet. Varje dag hålls ett kort statusmöte för att se vad som har gjorts, vad som måste göras och vilka eventuella hinder som upptäckts. På detta sätt upprätthålls en transparent kommunikation, alla är uppdaterade och hinder identifieras tidigt samt beslut kan fattas snabbt.
- Sprint Review: I slutet av sprinten hålls en Sprint Review med hela Scrumteamet och andra intressenter. Här tittar man på vad som har levererats under sprinten och får feedback och input. Detta leder ofta till att nya uppgifter upptäcks och man diskuterar tillsammans vad nästa sprint ska innehålla för att maximera produktvärdet.
- Sprint Retrospective: Det sista som händer i sprinten är en Sprint Retrospective. Här gör Scrumteamet en tillbakablick på sprinten som varit och identifierar vad som har gått bra och vad som kunde ha gått bättre. Man kommer sedan fram till en handlingsplan för att förbättra sättet man arbetar på.
Varför Scrum?
Scrum gör det möjligt att fokusera på små, konkreta uppgifter samtidigt som man alltid har ”den stora bilden” klar för sig. På detta sätt hjälper Scrum till att skapa tillräckligt med struktur för att utvecklingsteamet ska kunna fokusera sin innovationskraft på att lösa något som annars kan verka vara en oöverstiglig uppgift. Med ett kompetent och självorganiserande utvecklingsteam har teamet själv möjlighet att göra allt arbete som krävs för att leverera en färdig produkt och kommer när som helst kunna organisera sig så att arbetet utförs på det mest effektiva sättet. När man dessutom upprepar/itererar arbetet med produkten och processerna garanterar man en kontinuerlig förbättring av såväl utvecklingsteamets effektivitet och värdeskapande som produktkvaliteten.
Det som har gjorts, vad som görs och vad som ska göras i framtiden är information som är synlig för alla hela tiden. Detta ger produktens intressenter den information de behöver samtidigt som det har en motiverande effekt på utvecklarna. Under ett projekt är det dock normalt att kunden ändrar sig eller att det dyker upp oväntade utmaningar. Den empiriska, inkrementella och iterativa inställningen i Scrum gör att man kan hantera detta och snarare fokuserar på att maximera förmågan att reagera och leverera snabbt.
Scrum är också skalbart. Man kan ha flera parallella utvecklingsteam som arbetar med samma produkt. Det bör dock bara finnas en dedikerad produktägare som fattar de slutliga besluten om prioritering och funktionalitet.
Scrum är lätt att förstå men svårt att bemästra. Det kräver arbetsinsats och förändringsvilja samt att man måste vara öppen för att experimentera och utforska. När man väl fått grepp om helheten och börjar behärska Scrum, har man en kraftfull uppsättning principer och praxis som gör även stora och komplexa projekt genomförbara.
Vill du veta mer om Visma Consulting som digitaliseringspartner?
Vill du veta mer om Visma Consulting som digitaliseringspartner?
Texten bygger på ett inlägg på Vismas norska blogg, skrivet av Solveig Maria Nes, seniorkonsult, Scrum Master och Full Stack-utvecklare i Visma Consulting AS.