Bevæg dit agile teams fokus fra output mod outcome. Det betaler sig!

‍Arbejder du i en feature fabrik?

‍Mange udviklingsteams arbejder i dag efter agile principper i den ene eller anden form. Der er for mig ikke tvivl om det positive ved den påvirkning, det har haft på den måde, vi i dag udvikler software siden 2001, hvor det agile manifest blev forfattet. Efter mange år, hvor især Scrum har fundet sin vej ind i mange udviklingsorganisationer, er der dog et bestemt billede, der tegner sig. For selvom vi er blevet bedre til at levere hurtigt og kontinuerligt i små bidder, så er vi mange steder et stykke fra mål.

Med fokus på principper og praktikker inden for Test Driven Development, DevOps, quality assurance og agile er vi blevet rigtig gode til at have stigende fokus på kvaliteten og hyppigheden af den funktionalitet, vi leverer til brugeren. Vi måler vores velocitet i teamet, så vi bedre kan forudse, hvad vi kan levere hvornår. Vi laver microservices og Domain Driven Design, så vi kan lave uafhængige releases, når det passer os.

Det er blevet populært på ledelsesgangen at snakke om High Performance Teams. Men ved vi, om vi reelt set leverer værdi til brugerne? Bliver de features, vi udvikler, overhovedet brugt i den grad, vi havde formodet?

Ofte sprøjter vi features ud af vores agile team uden at have fokus på det, som vi i yderste instans er sat i verden for — at skabe værdi for brugere og den virksomhed, vi udvikler for. Teamet optimerer efter hvor meget “output” der kommer ud af teamet, og ikke på effekten af det der kommer ud (det “outcome” der opnås).

Sat lidt på spidsen kan du komme til at stå i en situation, hvor det eneste, du får ud af at release en feature, er vedligeholdelse og større kompleksitet i din løsning, hvis du releaser funktionalitet, der aldrig bliver brugt.

For mig er “outcome” den effekt en ændring til produktet giver — positiv såvel som negativ. Det kan for eksempel være den tid en bruger sparer i et handlingsforløb, mere salg og dermed flere indtægter, besparelser og større kundetilfredshed. Det er effekten af ændringen, og den værdi den skaber.

Ved du om dit team giver den værdi, I formoder, når I starter udviklingen af en feature? Måler I om en leveret feature har givet den forventede værdi? Har I klare målbare kriterier for det?

Eller arbejder du måske også på en feature fabrik?

‍Sådan kommer du i gang

‍Det er nemt at sige, at vi skal skabe værdi for bruger og virksomhed, og ikke spilde tid på at bygge kvalitetssoftware, som ingen benytter sig af (eller som giver ingen eller negativ værdi for brugerne). Men hvordan kommer du igang med at ændre fokus til brugernes reelle behov?

Et godt sted at starte er at inddrage dem, der bruger dit produkt og få afdækket deres behov. Rigtig mange features og tiltag, der udvikles til et produkt, er baseret på formodninger, hypoteser, mavefornemmelser og “det konkurrenten har”. Det er langt fra altid, at hypoteserne bliver testet og valideret med brugere, inden de bliver tilføjet til produktet.

Så den simple måde at komme i gang på er: Spørg brugerne!

Der er mange måde at spørge på. Der findes et hav af UX/Discovery-teknikker, der kan bruges til at validere de formodninger, du og din virksomhed har om brugeres behov. Noget så simpelt som en papir eller pap mock-up kan være nok til at lære om din formodning er korrekt eller forkert.

Den afklaring kan potentielt spare dig og dit team for en masse spildt tid og indsats. Andre gange er det større skyts, der skal til for at afklare afgørende hypoteser, som eksempelvis usability tests og bruger interviews, eller for at køre den store kanon frem: Design Sprints. Brug som regel det værktøj, der med mindst indsats kan give dig afklaring (Hold øje med Path & Pattern, der kommer meget mere om Product Discovery fremover)

Et andet værdifuldt sted at sætte ind, er at indsætte målepunkter i produktet (og efterfølgende rent faktisk kigge i data). Brug data til at validere og teste om de hypoteser, du stiller op for en features værdi realiseres, når det kommer i hænderne på slutbrugeren. Sæt eksempelvis Google Analytics op på produktet, hvis det er muligt. Du får rigtig meget foræret og et godt udgangspunkt for bedre at forstå brugeres adfærd.
Jeg vil i kommende blogposts gå mere konkret i detaljer om, hvordan der kan indsættes målinger på, om formodet værdi bliver indfriet.

Uanset hvordan du og dit team griber det an, så vær bevidst om, at bare fordi vi er gode til at levere software efter agile principper, betyder det ikke nødvendigvis, at du leverer værdi til dine kunder (og til syvende og sidst din virksomhed). Med den erkendelse i baghovedet er du og dit team allerede ved at bevæge jer væk fra feature-fabrikken og mod et fokus på brugernes behov.

Start i det små, så er du og dit team godt fra land.

‍

‍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

‍