← Insights
Jämförelse mellan nedbrytning av en bestämd lösning och slicing mot en önskad effekt.
Artikel6 minAv Elinor Lange

Nedbrytningsfällan i planering

Affisch för artikeln Nedbrytningsfällan i planering

Vi tror att vi gör slicing mot en önskad effekt, när vi egentligen fortfarande bryter ner en lösning som vi redan har bestämt oss för att bygga.

När vi har något stort framför oss behöver vi dela upp det i mindre, hanterbara delar. Om vi vet vilken lösning som behövs är det ganska okomplicerat. Ett huvudkrav kan brytas ner i systemkrav och sedan i allt mer detaljerade krav. Delarna blir mindre, men de är fortfarande delar av en helhet som redan är definierad. Vi bygger dem, sätter ihop dem och testar den färdiga lösningen.

I komplexitet fungerar det annorlunda. När effekten av det vi bygger beror på hur människor agerar eller hur ett större system reagerar kan vi inte veta på förhand vilken lösning som kommer att skapa den effekt vi vill uppnå. Vi kan ha data, erfarenhet och goda skäl att tro på en lösning, men tills vi ser vad som faktiskt händer har vi en hypotes, inte ett svar.

En effektorienterad Epic börjar därför inte med vad vi ska bygga, utan med den förändring vi vill åstadkomma. Till exempel: Öka andelen förstagångsgäster på restaurangen som kommer tillbaka inom två veckor från 18 till 35 procent. Vi vet vart vi vill, men ännu inte vad som behöver byggas för att komma dit.

Därför kan vi heller inte på förhand bryta ner Epicen i alla Stories som kommer att behövas. Istället väljer vi en liten bit fungerande funktionalitet som vi tror kan föra oss närmare den önskade effekten. Vi bygger den, ser vad som händer och låter det vi lär oss påverka vad vi väljer att bygga härnäst. Arbetet blir både inkrementellt och iterativt: vi bygger något fungerande samtidigt som vi lär oss vad nästa steg behöver vara.

Det avgörande är alltså inte hur små delarna är, utan vad de är delar av. Vid nedbrytning är de delar av en lösning vi redan har bestämt oss för att bygga. Med slicing är de istället steg mot en effekt, där varje steg ger oss möjlighet att lära innan vi bestämmer nästa.

Jämförelse mellan nedbrytning av en bestämd lösning och slicing mot en önskad effekt.

Det lämnar också mer av problemlösningen till teamet. Istället för att få en lösning där de viktigaste besluten redan är fattade kan teamet använda sin samlade kompetens, tillsammans med det användarna och systemet visar oss, för att avgöra vad som är värt att bygga härnäst.

Ibland är det mest värdefulla vi lär oss att vi inte behöver bygga det vi trodde från början. Om tre Stories skapar tillräckligt av den önskade effekten finns det kanske ingen anledning att bygga Story fyra till tio. De är inte ogjort arbete. De är sådant vi upptäckte att vi inte behövde bygga. Det är så vi kan skapa största möjliga effekt genom att bara bygga det som faktiskt behövs.

Och det är här skillnaden blir förvånansvärt lätt att missa. Vi kan ersätta krav med Epics och Stories, göra våra Stories små och leverera fungerande funktionalitet en Story i taget – och ändå ha bestämt på förhand vad som ska byggas.

Om en Epic är klar först när alla Stories vi definierade från början är klara arbetar vi fortfarande mot en fördefinierad lösning. Det vi lär oss längs vägen kan påverka hur vi bygger den, men inte besvara den betydligt viktigare frågan: Behöver vi överhuvudtaget bygga resten?

Det är nedbrytningsfällan: vi tror att vi gör slicing mot en önskad effekt, när vi egentligen fortfarande bryter ner en lösning som vi redan har bestämt oss för att bygga.

Den verkliga förflyttningen är inte från stora delar till små. Den är från att bryta ner en redan bestämd lösning till att steg för steg upptäcka vad som är värt att bygga.

Se helheten

Nedbrytningsfällan i planering ä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.

Postern Project vs Product Organization in a Nutshell.Project vs Product Organization in a Nutshell (PDF)

Fler artiklar i serien

Vill ni prata vidare om det här?

Vi resonerar gärna kring vad detta betyder i er organisation.