Feature fabrikken: Et agilt anti-pattern

What’s a Rich Text element?

The rich text element allows you to create and format headings, paragraphs, blockquotes, images, and video all in one place instead of having to add and format them individually. Just double-click and easily create content.

Heading 1

Heading 2

Heading 3

Heading 4

Heading 5

  • asdfasdf
This is a quote

Static and dynamic content editing

A rich text element can be used with static or dynamic content. For static content, just drop it into any page and begin editing. For dynamic content, add a rich text field to any collection and then connect a rich text element to that field in the settings panel. Voila!

How to customize formatting for each rich text

Headings, paragraphs, blockquotes, figures, images, and figure captions can all be styled after a class is added to the rich text element using the "When inside of" nested selector system.

Ole Rich Henningsen

Head of Syndicate Aarhus

orh@syndicate.dk

3

min. læsetid

March 11, 2020

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