Arbejder jeres teams mod at indfri en projektplan eller mod at løse reelle behov hos jeres kunder? I agil softwareudvikling er produktejerskab den samlende kraft. I denne artikel beskriver vi styrken i en produktorienteret organisation med klart forankret produktejerskab.
Den traditionelle tilgang til produktudvikling er i høj grad centreret omkring projekter. Når et nyt produkt skal på markedet eller eksisterende produkter skal udvides er den klassiske fremgangsmåde, at definere et projekt med en projektleder i spidsen. Projektledere er en central figur, der er ekspert i at styre projekter fra specificeringen af krav og gennem en række faser til den endelige lancering og idriftsættelse.
Om man arbejder med digitale eller fysiske produkter, vil et projektforløb repræsentere en investering. Investeringen vil først begynde at give afkast, når det resulterende produkt er tilgængeligt for kunderne. Udviklingen af digitale produkter adskiller sig markant fra udviklingen af fysiske produkter. En af de primære forskelle findes i, at digitale produkter ikke fysisk skal produceres. Vejen fra at nye produkter eller produktudvidelser forlader udviklernes hænder til det kan distribueres til kunderne er derfor meget kortere og med mulighed for at levere en tidlig og inkrementel værdiskabelse. Som en direkte konsekvens heraf er lange faseopdelte projektforløb ikke en fremgangsmåde, der naturligt understøtter udviklingen af digitale produkter.
Anden artikel, tror du eller ved du, i denne serie blev dedikeret til den usikkerhed, der er en integreret del af udviklingen af nye produkter. Det er gældende for både digitale og fysiske produkter. Derfor muliggør et iterativt udviklingsforløb en tidligere verificering af dit produkt, og er et stærkt værktøj til mindske risikoen for at ressoucer investeres forkert. Dette er illustreret nedenfor.
Er dit fokus på leverancen?
Indenfor udviklingen af digitale produkter kan en klassisk projektorienteret tilgang til produktudvikling være en begrænsning for den forretningsmæssige gennemslagskraft. En væsentlig årsag er, at projekter ofte baseres på en grundlæggende præmis om at indholdet er kendt på forhånd. Det er sjældent tilfældet at man som virksomhed har den nødvendige vished før projektet startes. Som følge heraf bliver fokus for projektorganisationen ofte leverancen af det specificerede scope indenfor projektets budget- og tidsrammer.
En visuel repræsentation af en traditionel og en agil tilgang til udvikling af software ses nedenfor. I den traditionelle tilgang til projektledelse er scope fastlagt i starten af projektet, hvor budget- og tidsrammen for at levere scopet er estimeret. Som modsætning er det budget- og tidsrammen der er fastlagt i den agile tilgang, hvor det estimeres hvilket scope, der bedst indfrier forretningens mål.
En agil tilgang til produktudvikling er i langt højere grad understøttende for at arbejde ud fra et produktorienteret tankegang. En produktorienteret tankegang kendetegnes ved at udviklingen baseres på en holistisk end-to-end forståelse af produktet, hvor outcome står over output. Altså at den forretningsmæssige gennemslagskraft prioriteres over listen af indfriede krav og er drivkraften for udviklingsteamet.
Uden et stærkt fokus på produktet er det meget besværligt at få success med at implementere agile metoder. Uden det rigtige fokus i organisationen har de agile teams ikke de nødvendige rammer, og de implementerede agile metoder bliver primært en operationel øvelse for, hvordan det fastlagte scope nedbrydes og eksekveres.
Tør du release?
I forbindelse med udviklingen af et nyt produkt vil der altid være en fase i udviklingsforløbet før produktet sættes på markedet. Det er dog nødvendigt, at produktet releases hurtigt for at etablere en organisation, der arbejder ud fra en produktorienteret tankegang. I den forbindelse er et svært og altid tilstedeværende spørgsmål; hvad og hvornår skal vi release?
Et meget kendt eksempel, hvor den helt rigtige balance blev fundet er i udviklingen af Danske Banks “MobilePay” der i dag er en af de mest udbredte og benyttede apps i Danmark. MobilePay blev udviklet af Danske Bank i et kortere forløb, hvor produktet blev taget fra koncept til release på 6 måneder. I samme periode blev en konkurrerende løsning, Swipp, udviklet i et samarbejde mellem en lang række andre banker i Danmark. MobilePay og Swipp blev lanceret inden for få måneder, men Danske Bank lykkedes med at vinde markedet. MobilePay som case er meget spændende netop fordi mange af de nødvendige forudsætninger for at udvikle succesfulde digitale produkter var tilstede. I tråd med emnet for denne artikel er der særligt to ting der bør fremhæves. Danske Bank kom først og de lancerede et produkt, der løste det primære behov for deres brugere. Ved at fokusere på det vigtigste behov formåede de at finde balancen mellem at release tidligt og samtidigt lancere et værdiskabende produkt.
At release et produkt, der ikke indeholder alle features på ønskelisten kan være svært for mange virksomheder. Det er dog vigtigt ikke at sætte alle ens visioner som forudsætninger for at release. Derimod er det heller ikke en god strategi at release et produkt, der ikke løser nogle reelle behov hos kunderne. Det er en balance og vi anbefaler at den første release skal fokuseres mod at løse det vigtigste behov hos kunden. Det kan være grænseoverskridende og kræve mod at release tidligt. Men det er en mindre risikabel tilgang og den videre udvikling af produkterne vil i højere grad kunne afstemmes brugernes reelle behov og ønsker. En god illustration for inkrementel udvikling af et produkt ses nedenfor.
I en organisation hvor en projektorienteret tankegang er meget udbredt, findes projektlederen som en central figur. I en organisation, der arbejder ud fra en produktorieteret tankegang er produktejeren i højere grad den samlende kraft. Det er meget vigtigt, at have et stærkt forankret produkejerskab i organisationen. Dette gør sig gældende ved, at der i organisationen er en eller flere “produkt evangelists”, der har produktet helt ind under huden, og som bærer visionerne og retningen for produktets udvikling. Produktejerskab skal ikke udelukkende være forbeholdt enkelte personer, men skal være forankret i de teams, der udvikler og drifter produktet. Det er vigtigt, at de pågældende teams arbejder mod fælles mål, der baseres på at drive en værdiskabende udvikling af produktet frem for at indfri en række krav i et projekt.
Produktejernen, som rollen er defineret i Scrum er meget udbredt, men er meget svær at udfylde. Det er en kompliceret rolle, der indeholder kræver mange forskelligartede kompetencer. Udover at være en krævende rolle, er det også en svær rolle at implementere for organisationen. Omkring produktejeren er der en lang række anti-patterns. Blandt de mest hyppige er, at produktejeren ikke bemyndiges til at tage beslutninger. Hvis produktejeren ikke får den nødvendige bemyndigelse, ender vedkommende ofte med agere som en proxy for en eller flere stakeholders. Rollen reduceres i sådanne tilfælde til en backlog administrator, der efter bedste evne indsamler og prioritere ønsker, der ikke nødvendigvis er afstemte med at maksimere værdiskabelsen.
Key takeaways:
- For at få vedvarende succes med udviklingen af værdiskabende produkter er det vigtigt, at organisationen arbejder ud fra en produktorienteret tankegang med fokus på outcome over output
- For hurtigt at gå fra projekt til et produkt er det vigtigt at release tidligt
- I en produktorienteret organisation er produktejerskab, frem for projekledelsen, den samlede kraft
- For at forankre produktejerskab i organisationen er det vigtigt, at produktejeren og udviklingsteamet bemyndiges til at tage beslutninger
Se nedenfor for mere information om MobilePay casen
- MobilePay vandt ved at gøre det komplekse enkelt
- Hvad projektledere kan lære af Danske Bank
- Bag om manden bag MobilePay
Dette er den sidste artikel i en serie af fem, hvor vi deler nogle af vores erfaringer i udviklingen af succesfulde digitale produkter. De forrige artikler kan findes her.
Vil du vide mere om os?
