När vi går från att organisera arbete i projekt till att arbeta i produktteam förändras inte bara organisationsformen. Även logiken för hur vi prioriterar, planerar, organiserar och följer upp arbetet behöver förändras.
Det är lätt att byta språk och strukturer utan att förändra den underliggande logiken. Krav blir Epics, projektplaner blir Product Backlogs och vi inför nya sätt att visualisera arbetet, samtidigt som vi fortsätter fatta beslut och styra ungefär som tidigare.
På ytan kan mycket alltså se annorlunda ut, medan gamla sätt att tänka lever kvar. Vi bestämmer fortfarande lösningar tidigt, klassificerar vad som ska få plats i projektets scope, bryter ner redan bestämda lösningar i mindre delar, låter några få planera åt många och följer upp om det planerade arbetet blir gjort.
Språket har förändrats. Strukturerna har förändrats. Men logiken bakom hur vi styr och organiserar arbetet är densamma.
Det här fällor som jag återkommande ser i den förflyttningen.
| Fälla | Projektlogiken | Förflyttningen | Fällan |
|---|---|---|---|
| Lösningsfällan i prioritering | Vi prioriterar vilka krav och lösningar som ska ingå i projektet. | Prioritera vilken förflyttning vi vill åstadkomma innan vi väljer vad vi ska bygga. | Vi byter krav mot Epics, men fortsätter prioritera vad vi ska bygga. |
| Klassificeringsfällan i prioritering | Vi klassificerar vad som måste, bör eller kan ingå i projektets scope. | Prioritera mellan förflyttningarna och välj vilken som ska få fokus nu. | Vi klassificerar varje Epic som exempelvis High, Medium eller Low, men väljer inte vad som ska gå först. |
| Förhandlingsfällan i prioritering | Olika delar av organisationen driver sina behov och vi förhandlar om vad som ska få plats. | Prioritera tillsammans utifrån vad som är viktigast för helheten. | Vi samlar arbetet i en gemensam backlog, men fortsätter prioritera genom förhandling mellan olika delar av organisationen. |
| Nedbrytningsfällan | Vi bryter ner en bestämd lösning i mindre delar som tillsammans ska byggas. | Utgå från den önskade förflyttningen och bygg en liten fungerande slice. Använd feedback för att se om vi rör oss i rätt riktning och låt lärandet styra vad vi bygger härnäst. | Vi kallar helheten Epic och delarna Stories men bryter fortfarande ner en redan bestämd hel lösning. |
| Effektivitetsfällan i planering | Några få planerar arbetet åt många för att använda människors tid effektivt. | Låt de relevanta perspektiven mötas när besluten behöver fattas och kunskapen finns. | Projektplanen blir en detaljerad backlog och några få tänker fortfarande åt många långt i förväg. |
| Kontrollfällan | Vi organiserar arbetet i en plan och följer upp att det blir gjort. | Organisera kring önskade effekter och använd transparensen för att se vad arbetet leder till, vad vi lär oss och vad vi behöver göra härnäst. | Vi byter projektplanen mot produktstrukturer, men använder dem fortfarande för att organisera och följa upp arbetet. |
Det som förenar fällorna är att vi kan förändra strukturerna utan att förändra tankesättet bakom dem. Vi kan kalla något en Epic och fortfarande behandla den som ett stort krav. Vi kan ha en Product Backlog och fortfarande använda den som en projektplan. Vi kan ha produktteam och fortfarande bestämma vad de ska göra långt i förväg.
Att gå över till produktteam betyder inte att vi slutar planera, formulera krav, leverera eller synliggöra arbetet. Det som förändras är vad vi använder dessa saker till.
Utmaningen är inte att införa nya strukturer. Det är att upptäcka när vi använder dem för att fortsätta arbeta enligt samma gamla projektlogik.
Se helheten
Förflyttningen från projekt till produktteam påverkar fler delar av organisationen, bland annat strategi, styrning, finansiering, team, kultur och organisationsstruktur.
Vår poster Project vs Product Organization in a Nutshell visar den större förflyttningen ur flera perspektiv.
