I en projektorganisation definierar vi vad som ska levereras, organiserar arbetet och följer upp hur det går. Scope bryts ner, aktiviteter planeras och status rapporteras. Vi kan se vad som är gjort, vad som återstår och om leveransen följer planen.
När vi går mot produktutveckling förändras målet. Vi försöker inte längre slutföra en på förhand definierad mängd arbete, utan åstadkomma en förflyttning; en effekt för kunder, användare eller verksamheten. Då förändras också vad vi behöver styra och följa upp.
Vi behöver fortfarande förstå vad som pågår, vad vi lägger vår kapacitet på och vad som hindrar oss. Men det utförda arbetet är inte längre det primära måttet på framsteg.
Det räcker inte att veta vad vi har gjort. Vi behöver veta vad det har lett till.
Ändå är det förvånansvärt lätt att införa produktbackloggar, Epics, Stories, Tasks och tavlor och samtidigt ta med sig den gamla logiken. Projektplanen har försvunnit, men frågorna är nästan desamma: Vad är klart? Vad återstår? Hur mycket har vi levererat? Följer vi planen?
Mer av arbetet har blivit synligt, men vi använder fortfarande strukturen framför allt för att följa arbetet och kontrollera vad som blir gjort.
Här finns en viktig skillnad mellan transparens och kontroll. I produktutveckling gör vi arbetet synligt för att de som arbetar med och finansierar produkten ska kunna förstå vad som händer, samordna sig, skapa lärande och fatta bättre beslut om vad som är klokt att göra härnäst.
Samma transparens kan användas för två helt olika syften: för att kontrollera arbetet eller för att styra mot effekt.
Kontrollogiken blir särskilt synlig när vi försöker ge allt arbete en plats i strukturen. Det kommer alltid att finnas underhåll, support, mindre rättningar, tekniskt arbete och annat som behöver hanteras, utan att det direkt kommer ur de förflyttningar vi har valt att åstadkomma.
Här är det lätt att börja använda Epics till något de inte är avsedda för: som behållare för olika typer av arbete. Underhållsuppgifter samlas kanske i en Epic som heter Underhåll, supportuppgifter i Support. Backloggen ser prydlig ut och allt har fått sin plats.
Men då har vi också tappat själva poängen med en Epic. Vad innebär det egentligen att prioritera Underhåll högre än Support? Enskilda uppgifter kan vara mer eller mindre viktiga, men behållarna beskriver inga förflyttningar vi kan välja mellan. De blir heller aldrig klara, eftersom nytt arbete hela tiden fylls på.
En Epic är inte en behållare för arbete. Den representerar en förflyttning vi vill åstadkomma.
Minska återkommande produktionsincidenter med 50 procent kan till exempel vara en Epic som beskriver en intern förbättring. Få dubbelt så många förstagångskunder att komma tillbaka inom en månad kan vara en annan, med en mer direkt effekt för kunden och verksamheten. Båda beskriver förflyttningar som vi kan prioritera mot andra förflyttningar, arbeta mot, mäta och så småningom uppnå.
Vissa underhållsuppgifter kanske bidrar till den första Epicen, andra gör det inte. Allt kan ändå vara synligt i produktbackloggen. En Task behöver inte en Epic bara för att ha någonstans att höra hemma.
Skillnaden mellan att följa upp arbete och att styra mot effekt blir kanske allra tydligast när vi upptäcker att vi inte behöver göra allt vi trodde.
Anta att vi tror att tio saker behövs för att skapa en viss effekt. Vi gör tre, mäter vad som händer och upptäcker att effekten redan är uppnådd.
Om vi följer upp arbetet ser vi sju saker som återstår. Om vi följer upp effekten har vi upptäckt sju saker som vi inte behöver göra.
Samma verklighet. Helt olika syn på framsteg.
Vi behöver inte heller känna till eller strukturera allt arbete i förväg. Incidenter, supportärenden och annat oplanerat arbete kommer att ta kapacitet utan att vi vet exakt vad det blir. Vi kan lämna utrymme för det och synliggöra arbetet när det uppstår. Och allt behöver inte bli en entitet i backloggen, bara för att arbetet går att följa upp betyder det inte att det är värdefullt att göra det.
Vi behöver alltså fortfarande förstå arbetet, kapaciteten och vad som händer. Men vi behöver inte bygga vår styrning kring att kontrollera att arbetet blir gjort.
Kontrollfällan uppstår när vi inför produktutvecklingens strukturer och transparens men fortsätter använda dem med projektlogikens fokus på scope, leverans och genomfört arbete och blir bättre på att följa upp vad vi gör än på att förstå vad vi åstadkommer.
Fler fällor
Det här är en av flera fällor i en serie: Fällor i övergången från projekt till produktteam
Se helheten
Kontrollfällan är ett exempel på vad som kan hända när vi förändrar vårt sätt att arbeta utan att fullt ut förändra den underliggande logiken.
Vår poster Project vs Product Organization in a Nutshell belyser den här förflyttningen ur flera perspektiv – bland annat strategi, genomförande, styrning, team, finansiering, kultur och organisation.
