Feature fabrikken: Et agilt anti-pattern

Sidste år skrev jeg blogposten “Hvilke karakteristika og udfordringer har dit team?”. Det stod hurtigt klart, at jeg blev nødt til at supplere med en vigtig pointe. Dette indlæg handler om et anti-pattern som jeg ser igen og igen i produktteams. Nemlig det faktum, at mange teams blindt bygger det kunderne beder om. Men hvor ligger problemet egentligt i det? Skal vi ikke lytte til vores kunder og gøre dem glade?

"If I had asked people what they wanted, they would have said faster horses."

Selvom Henry Ford formentligt aldrig officielt har udtalt ovenstående er det sandt, at kunder, slutbrugere og andre stakeholders ofte har stærke holdninger til hvad teams skal bygge. De definerer løsninger og funktionalitet på baggrund af holdninger og antagelser, og som en sideeffekt af det opstår featurefabrikken.

Falling in Love with the Problem

Mange teams har ansvaret for et eller flere produkter. Det kunne for eksempel være en mobilbank. Andre teams har ansvaret for en eller flere features i et produkt — eksempelvis ‘Overfør penge’ eller ‘Betal regning’. Disse teams kalder vi ofte for produktteams eller featureteams. Men allerede i denne navngivning og organisering har vi indbygget en potentiel fare ved at fokusere på en løsning.

Jeg ser to udfordringer her:

1. Vi er som mennesker hard-wired og opdraget til at gå i løsnings-mode (bare tænk på vores skolesystem). Derfor er det naturligt at kunder og stakeholders hopper i løsningsfælden.
2. Vores kunder og stakeholders er jo ikke professionelle produktudviklere — det er derfor vi har produktteams. Til gengæld er de eksperter i de problemer der skal løses. Og så er det jo nærliggende at spørge dem.

Så… hvilket problem er det egentligt vi forsøger at løse?

Spørgsmål er jo i sig selv ret enkelt, men det kræver at teamet (som regel inklusiv en Product Owner) har indbygget product management og product discovery-kompetencer. Det er der desværre mange teams, der ikke har, fordi man bevidst eller ubevidst har frataget dem ansvaret for problemet. Det ansvar skal de have tilbage for at blive et team med end-to-end ansvar for at levere værdi.

Et produktteam bør have indbygget product management og product discovery kapabilitet

Organisér produktteams omkring outcome

Hvis teamet blot bliver bedt om (og ofte målt på) at levere output, fjerner man også eksplicit fokus fra værdi og outcome. Det vil jeg ikke gå i detaljer med her, men henvise til denne artikel skrevet af Peter Lindberg.

Jeg vil samtidig foreslå, at man begynder at organisere produktteams omkring outcome. Ultimativt er din virksomheds strategiske initiativer defineret omkring netop outcome og impact. Dvs. de strategiske initiativer besvarer spørgsmål som:

• Hvilken værdi vil vi levere til vores kunder?
• Hvad er det vi som virksomhed forsøger at opnå?

Det bør forretningen naturligvis definere. Det er derfor vi kalder det forretningen. Giv dernæst produktteams ansvaret for at indfri på denne værdi fremfor at fortælle dem hvilke løsninger de skal levere.

I eksemplet med føromtalte mobilbank vil det betyde, at et team eksempelvis får ansvaret for aktivering og onboarding af nye brugere på tværs af mobilbanken (activation) og et andet team kunne få ansvaret for at fastholde brugernes kontinuerlige brug af mobilbanken (retention). Det vil være let for forretningen at definere succeskriterier for disse mål. Samtidig vil disse teams få et målbart ansvar for noget andet end output. Altså ansvaret for outcome, impact og ikke mindst for at udforske og løse problemer.
‍

Vil du vide mere om agile? Kom med Backstage!
Hold dig opdateret med den nyeste viden inden for agile og digital produktudvikling. Tilmeld dig 👉🏻 syndicate.dk/backstage

‍