Vad kan GTD och Scrum lära av varandra

När idéerna om agil utveckling av programvara började cirkulera så hade jag redan praktiserat Getting Things Done® i flera år. Jag minns att jag läste om Scrum och tänkte “det där är ju typ bara GTD med andra ord”. Sedan gick det några år och agila processer växte i popularitet, vilket även GTD gjorde. Intressant att notera är att det agila manifestet publicerades samma år som David Allens bok “Getting Things Done, the Art of Stress-Free Productivity” gavs ut. (Svenska titeln är “Få det gjort! : svart bälte i vardagseffektivitet”.)

Hur som helst kom jag att jobba med agila processer och läste en massa böcker om dem och om “lean” systemutveckling. Men hur är då Scrum GTD med andra ord?

Inom GTD såväl som inom systemutveckling behöver man ord för målsättningar på flera olika nivåer. Ordet projekt används i båda världarna och spänner över alla möjliga storlekar av “arbetspaket”. I GTD definieras ett projekt som en uppgift som kräver mer än en aktivitet och som kan slutföras inom ett år. Det är ingen hård regel, utan har att göra med att större målsättningar än så är svåra att mentalt greppa. Ett GTD-projekt kan vara betydligt mindre också; det kan vara en uppgift som tar några dagar, några veckor eller några månader. Om man i GTD behöver formulera en målsättning som tar längre tid än ett år i anspråk så sätter man upp det som ett mål, och så definierar man delmål som projekt. Inom systemutveckling brukar stora projekt delas upp i mindre delprojekt. Självklart kan man även dela upp kortare projekt i delar, särskilt om de olika delarna inte har så många beröringspunkter och kan pågå parallellt. I Scrum är inte ordet projekt definierat, men vanligt är att man pratar om user stories, features och epics som ges en klardefinition, en ”definition of done”. Gemensamt för alla dessa saker är att det är något som blir klart, en uppgift med ett mål som kan uppnås. I GTD-termer har de ett önskat utfall. Detta är nivå ett i GTD.

På nivå två hittar vi fokusområden, vilket motsvarar någon form av ansvarsområde eller roll. Efter det att ett system utvecklats till en nivå där det är användbart och det har driftsatts brukar man prata om att systemet övergår i förvaltning. Förvaltning är ett bra exempel på något som i GTD kallas fokusområde, dvs något som inte definieras av ett önskat utfall, utan något som behöver underhållas under överskådlig framtid. Dock fortsätter man att sätta nya mål för systemets vidareutveckling inom ramen för dess förvaltning. Ett annat bra exempel på fokusområden inom systemutveckling är kompetensutveckling.

I GTD definierar man sex nivåer, där den högsta nivån handlar om syfte, dvs vad ger mig mening och vad vill jag använda mitt liv till, med mellanliggande nivåer av allt högre abstraktioner av mål och värderingar. Detaljerna här ligger utanför ämnet för denna artikel, men kort kan vi säga att även en organisation har ett syfte med sin verksamhet, med värderingar och högre målsättningar som vägledning.

I Scrum jobbar man i perioder som man kallar sprintar och som ofta är två veckor långa, men kan vara både kortare eller längre. Med sig in i sprinten har man en sprintbacklogg med ett antal user stories, som man åtagit sig att implementera inom sprinten. I GTD motsvaras detta av en projektlista, dvs en rak lista över önskade utfall man just nu jobbar med. I GTD har man dock inga sprintar, så på så sätt liknar det mer “lean” och skulle man begränsa hur många önskade utfall man kan ha aktiva samtidigt, har man ett “personligt kanban-system”.

De user stories som hamnar i sprintbackloggen kommer från en produktbacklogg. Det är alla de user stories, features och buggrättningar som man identifierat som önskvärda att göra. De mest intressanta av dessa ligger överst i produktbackloggen. Produktbackloggen motsvaras i GTD av någongång/kanske-listan, dvs saker man skulle vilja göra någongång, kanske, men inte aktivt jobbar med.

I GTD gör man en veckogenomgång, då man sätter sig ner någon timme och ser över allt man håller på med. Scrum definierar tre “händelser” under en sprint som motsvarar veckogenomgången. I början av sprinten gör man en planering då man tittar mer i detalj på vad som ska göras och uppskattar vad man tror sig hinna med. Utifrån den planeringen sätter man upp sprintbackloggen. Den andra Scrum-händelsen är refinement då man funderar lite extra noga på de saker som ligger överst i produktbackloggen, saker som man alltså ännu inte åtagit sig att jobba med, för att förbereda den kommande sprintens planering. I slutet av sprinten har man en review, då man reflekterar över vad man gjorde klart eller inte.

Under veckogenomgången i GTD tittar man bakåt i kalendern och man bockar av saker från att-göra-listor och projektlistor, en review. Scrums refinement motsvaras av en genomgång av det som ligger på någongång/kanske-listan för att se om det är dags för något där att aktiveras. Vidare tittar man framåt i kalendern, reflekterar över de aktiva projekten och identifierar alla de saker som behöver åtgärdas under den närmaste tiden, planering. I Scrum har man också ett dagligt möte för att koordinera arbetet, daily scrum, på liknande sätt som en GTD-utövare orienterar sig inför dagen genom att kolla kalender och relevanta listor.

Så långt likheter mellan Scrum och GTD, men finns det skillnader? En fjärde händelse i slutet av en Scrum-sprint är en demo av vad man utvecklat under sprinten. Frågan är hur relevant det är för GTD, men som individ kan man ju ha återkommande avrapporteringar och i så fall fångas detta upp av agenda-listor. I Scrum har man också ett retrospective, ett möte för utvecklingsteamet då de reflekterar över hur de jobbat och vad de kan göra för att jobba bättre. GTD’s veckogenomgång är ett tillfälle för reflektion och man skulle kunna införa ett explicit moment under veckogenomgången då man funderar över hur man kan praktisera GTD ännu lite bättre för att underlätta vardagen, minska tiden för rutinåtgärder och på annat sätt göra saker bättre.

Scrum-utövare å sin sida kan lära av GTD’s nästa aktivitet. Projekt hör som sagt till nivå 1 i GTD’s hierarki av horisonter, men det finns en nivå under, marknivån, där det konkreta, fysiska arbetet äger rum. På samma sätt som att vi inte kan “utföra” ett projekt, utan bara utföra de olika aktiviteterna som leder till projektets fullbordan, så är det inte teamet som jobbar, utan individerna i teamet. Att ta sig an en user story eller feature och identifiera nästa fysiska aktivitet är att praktisera GTD inom Scrum. Man inser också att man inte behöver planera så mycket i förväg, särskilt som det ofta är så att man inte vet vad som behövs förrän man kommit en bit på vägen. När medlemmar i ett Scrum-team är utövare av GTD blir deras kommunikation om vad som behöver göras tydligare och ingen uppgift blir liggandes utan ansvarig.

Det första steget i GTD’s arbetsflöde är att fånga allt det som är potentiellt viktigt. Det finns ingen motsvarighet i Scrum, ingen artefakt som representerar en kandidat till produktbackloggen, eller någon händelse där dessa kandidater omhändertas. Retrospektivet tjänar till viss del detta syfte och det skulle kunna kompletteras med en gemensam mental inventering (eng. mind sweep), som är en metod i GTD där man helt enkelt skriver ner allt det som rullar runt i tankarna. Utan att styra med specifika frågor avsätter en stund då var och en funderar tyst för sig själv, och sedan delar man med sig, bearbetar det som kommit fram samt formulerar eventuella nya önskade utfall och nästa aktiviteter.

Att Scrum saknar tydlig kanalisering av upptäckta brister och nya idéer gör att de riskerar de att tappas bort. Resultat från arbete som sker i spontana korridorsnack och andra informella och formella forum kan lätt rinna ut i sanden. Om de individer, som upptäcker bristerna, har idéerna eller är med i olika kreativa samtal, är vana vid att skriva ner och bearbeta det som kommer fram, så ökar chanserna att värdefullt tankearbete kommer till nytta. Organisationen som sådan behöver också sätta upp kanaler och processer för detta.

Slutligen vill jag lyfta fram hur GTD lägger grunden för tillit i och med att teammedlemmar inte glömmer bort vad de lovat varandra. I en produktivitetsstudie som gjordes på Google var det just tillit och trygghet i teamen, som visade sig vara nyckel till högpresterande team.

Kraften i nästa aktivitetstänk och individernas förmåga att hålla reda på allt potentiellt viktigt och allt de åtagit sig, är nog de bidragen till Scrum som jag tror är den främsta anledningen till att agila team, med David Allens ordval, “turbo-laddas” då medlemmarna också praktiserar GTD.

Boka ett möte

Klicka för att hitta en ledig tidpunkt som passar dig och boka ett möte direkt med Martin Haagen.

Martin Haagen portrait
Martin Haagen - Master Trainer

Estonia

Book a meeting
Paul Vahur - portrait
Paul Vahur
Rulla till toppen