Agil produkt vs. Agilt arbetssätt

av | Feb 12, 2018

Gunnar Södergren är utvecklare och projektledare på Purple Scout. Med sig i bagaget har han sin utbildning inom utveckling av digitala spel, datavetenskap, interaktionsdesign och givetvis sin Scrum Master-certifiering. Här skriver han om agila verktyg som du kan ha stor nytta av i dina projekt och benar ut grunderna i agilitet.

Agilitet – Vad är det?

Att arbeta agilt har många namn: Scrum, Kanban, etc. Agilt arbete kan sammanfattas som att arbeta i korta, avgränsade tidsperioder (så kallade sprintar) med en eller flera delar av en produkt (så kallade “backlog items” och “tasks”). I slutet av varje tidsperiod reflekterar man över gånget arbete och planerar den nya tidsperiodens arbete.

Att arbeta agilt tillför mycket i ett projektet:

  • teamet får större flexibilitet och rörlighet
  • produkten blir ofta mer robust
  • produkten mer testad och mer användbar
  • användarinput är både lättare att ta in och enklare att ta hänsyn till

Bild: www.youtube.com/watch?v=Q-AaZVmeMz

Agilitet brukar ställas som motsatsen till den s k “vattenfallsmetoden”, där en produkt konceptualiseras, tas fram och formas i projektets absoluta startskede och sedan utvecklas linjärt tills den är färdig. I vattenfallsmetoden sker ingen iteration och ingen återblick.

I min erfarenhet är agilt arbetssätt nästan alltid att föredra framför vattenfallsmetoden och det verkar som att branschen (eller branscherna, snarare) håller med mig. Scrum, Kanban och liknande kanske inte är lika mycket i snacket som det tidigare varit, men det tycks bli allt vanligare att det används, på alltfler arbetsplatser.

Agil Produkt och Agilt Arbetssätt

Många säger att de arbetar agilt, men gör de verkligen det? Agil produkt är en produkt som vid slutet av varje sprint går att använda och är bättre än efter förra tidsperioden. Produkten är användbar vid varje sprints slut och inkrementeras till något bättre, större och mer användbart efter varje sprint. Alla produkter och tjänster lämpar sig inte som agila produkter, och bör inte vara agila produkter. Att bygga en bro, exempelvis, kommer aldrig fungera som en strikt agil produkt.

Agilt arbetssätt är helt sonika att använda metodiken från Scrum, Kanban eller annan agilt ramverk och applicera på en produkt eller tjänst som inte nödvändigtvis är agil. Man delar upp arbetet i ett antal delar (tasks), estimerar hur lång tid de kommer ta och, kanske viktigast, identifierar vilka delar som är beroende av andra. Arbetet planeras sedan efter ett antal sprintar och vid varje sprintstart bestäms vad som är viktigast, högst prioriterat och som ger mest värde just då och detta blir den sprintens arbete.

Att skilja på agil produkt och agilt arbetssätt är skillnaden mellan att påstå att en bro kan användas efter två veckor, men det kommer ta tio att göra den fulländad och att påstå att arbetet fördelas över fem tvåveckorssprintar som planeras vid slutet av varje sprint. Det är skillnaden mellan produkt och arbetssätt.

Att skilja dessa två, produkt och arbetssätt åt är viktigt för alla led i ett projekts beslutslinje. Att tydliggöra för beslutsfattare, stakeholders och, viktigast, team-medlemmar hur en arbetar och vad en faktiskt arbetar med gör kommunikation och samarbete mycket lättare. Att säga “vi använder Scrum här” blir inte längre tandlöst när en inser att det är en bro vi ska bygga.

Hur vet man vilket som är bäst, då?

Först och främst: om du utvecklar en agil produkt, så bör du även använda agilt arbetssätt, nästan helt utan undantag. Eller ja, för all del, prove me wrong.

Jag finner att agilt arbetssätt fungerar bra till många typer av produkter och tjänster, men allra bäst i team som är cross-functional och självständiga. När ett team kan arbeta helt själva, utan beroende på andra team, andra personer eller andra avdelningar i företaget så är agilt arbetssätt nästan alltid att rekommendera: det ger teamet ansvar och ägandeskap över produkten, det ger dem möjlighet att revidera, förändra och förbättra sin process under projektets gång och framförallt resulterar det ofta i en bättre slutprodukt.

Agil produkt är knepigare att bena ut. Agila produkter behöver vara tydlig inkrementerbara, det behöver finnas många versioner av den som är (mer eller mindre) användbara, testbara och funktionella. Spel och spelliknande produkter tycker jag lämpar sig extremt väl som agila produkter, eftersom det ger många tillfällen att testa prototyper, experimentera med gameplay och, som är så viktigt, “Find the Fun”. Mindre lämpliga som agila produkter är de produkter som har stenhuggna scopes och priser, där flexibilitet inte är möjligt eller rimligt och där slutprodukten är tydlig utmejslad redan från projektets start.

Att välja agilt arbetssätt och/eller agil produkt är inte en exakt vetenskap och det bästa en kan göra är att pröva sig fram, experimentera och testa. På samma sätt som Scrum är en verktygslåda, inte en To-do-lista, bör det agila arbetssättet och den agila produkten vara verktyg att ha med sig i projektet. Precis som The Pirate Code är de att se som riktlinjer, snarare än regler.

Om ni inte redan har gjort det, så rekommenderar jag er varmt att ni förkovrar er i Scrum och/eller Kanban. Kanske genom en certifiering (Scrum Alliance, http://www.scrumalliance.org) eller genom böcker, artiklar och How-Tos. Viktigt att komma ihåg är dock att dessa metoder, i sann agil andra, är under ständig utveckling och förändring, och att det inte finns Ett Rätt Sätt att använda agilitet i sina projekt. Jag tror att såväl agil produkt som agilt arbetssätt är här för att stanna och snarare kommer växa än krympa.

Pin It on Pinterest