Fake it!

Læsetid: 2 minutter

 Fake it till you make it!

Sætningen er en floskel. Men den er fortsat aktuel, især når det kommer til at afprøve nye idéer.

Når du sidder i en udviklingssituation, er hypoteser og fast helt fundamentalt. Du skal nemlig ikke spilde tiden med at udvikle noget, der ikke giver værdi i det lange løb. Du skal fake it!

Hvis dit produkt tager et halvt år at bygge, og 90 % skal være færdigbygget før det kan testes, så vil det tage knap fem en halv måned førend du kan finde ud af, om du har ramt rigtigt eller forkert. Det er er dyrt, ikke smart og giver ingen mening.

Men der skal typisk ikke særlig megen effort til, før du kan teste dit produkt, og det er typisk lettere at bygge end du måske tror. Nogle teorier foreskriver, at du kan bygge en prototype og teste den på blot to dage. To dage! Den har kostet dig ganske lidt og derfor, hvis den fejler, er den ikke dyrt at smide ud.

Derfor er test af en facade vejen frem. Hvis du eksempelvis skal udvikle en webshop, så kan du teste den via PowerPoint- eller Keynote-slides med aktive knapper. Det samme kan lade sig gøre, hvis du skal udvikle en afstemningsrapport for dine forretningspartnere. Den faglige korrekthed i data kan ikke testes via en facadebaseret prototype, men du kan få testet om brugerfladen er som kunden ønsker.

Du kan selvfølgelig sagtens bygge en mere realistisk prototype, men det vil tage meget mere tid, og derved længere tid før du finder ud af, om du er på rette vej. Men lad os være ærlige – ikke alle idéer er vinderidéer. Uanset om du løber en risiko med en fed idé, og du er bare ikke sikker på dit produkt, så er det bedre at finde ud af om idéen virker så tidligt som muligt. At spilde tid på forkerte ting er no go.

Frit fortolket over udviklingsgrafer fra Sprint (2016) af Jake Knapp et al., s. 167

 

Hvad er en Product Owner?

Læsetid: 2 minutter

The product owner represents the product’s stakeholders and the voice of the customer; and is accountable for ensuring that the team delivers value to the business. The product owner defines the product in customer-centric terms (typically user stories), adds them to the product backlog, and prioritizes them based on importance and dependencies. Scrum teams should have one product owner. This role should not be combined with that of the scrum master. The product owner should focus on the business side of product development and spend the majority of their time liaising with stakeholders and should not dictate how the team reaches a technical solution.

Ovenstående er taget fra Wikipedia, og uddraget viser, at der er mange facetter i Product Owner’ens rolle. Jeg vil i det følgende fokusere på tre delelementer, nemlig PO’en som vidensbankallestedsnærværende og beslutningstager.

Vidensbank

Først og fremmest er Product Owner’en en vidensbank, hvor al viden om et given produkt skal være forankret. PO’en kan ikke træffe beslutninger uden, at det er gjort på et videnbaseret grundlag. Derfor bør en Product Owner være ekspert inden for et (del)produkt. Det er såmænd helt i orden for PO’en at bede hjælp fra forretningseksperter ved komplekse beslutninger, men som vidensbank for informationer skal Product Owner’en sammen med sine tekniske eksperter (fx applikationsarkitekter) have tilstrækkelig viden til de fleste daglige beslutninger, så man ikke forsinker produktudviklingen unødigt.

Viden på ekspertniveau er ligeledes vigtigt for at støtte det agile udviklingsteam, da medlemmerne højest sandsynligt vil have spørgsmål til de enkelte forretningsbehov under et udviklingsforløb. Derfor er det vigtigt, at Product Owner’en opbygger tiltrækkelig viden om det produkt, som virksomheden eller organisationen ønsker – eller kende til de forretningseksperter, som kan svare på disse spørgsmål. Bred og dyb viden er essentiel for, at PO’en kan prioritere de enkelte features op mod hinanden.

Allestedsnærværende

Product Owner’en skal være allestedsnærværende, slet og ret. Det tager tid. En masse tid. I en verden, hvor produkter udvikler sig med lynets hast og hvor kravene til samme ændrer sig endnu hurtigere, da er det vigtigt, at PO’en til alle tider er tilgængelig for at indsamle viden og træffe afgørelser på tværs af organisationen.

Ofte er virksomheder og organisationer, der kun lige er begyndt på en agile transformation, alt for optimistiske i forbindelse med, hvor meget tid der kræves af Product Owner’en under udviklingen af et produkt. Viden er key og viden tager tid.

Beslutningstager

Hver eneste dag er der hundredevis af beslutninger for en Product Owner. Det er alt lige fra godkendelse af små ændringer til fastsættelse af prioriteter for de forskellige forretningsmål. Det er vigtigt, at PO’en kan træffe de rette afgørelser. Hvis der er for store ændringer, som kan kræve godkendelse fra en given sponsor(gruppen) eller en anden instans i organisationen, så skal disse inddrages, men Product Owner’en skal i de fleste tilfælde have beføjelse til at træffe beslutninger selvstændigt.

Product Owner’en er ikke en traditionel projektleder, der sikrer, at faste krav opfyldes i fast plan og fast budget. PO’en skal kunne træffe beslutninger om produktet i tide – og når det er relevant.