Hvad er agil produktstyring: Guide til processer og roller

Der findes en masse indhold, vejledninger, lærebøger, kurser og certificeringer inden for agil produktstyring. Helt ærligt har du ikke brug for det hele.

Agil produktstyring bygger grundlæggende på en enkel, menneskeorienteret filosofi. Mange af de processer, som Agile anvender, er enkle og lette at forstå. Kompleksiteten opstår imidlertid gennem misforståede forventninger, roller og processer.

I denne vejledning vil vi:

Udforske agil produktstyring, dens filosofi og de processer, som den kommer til udtryk gennem.
Se nærmere på de roller, som udgør et typisk agilt produktudviklingsteam, hvad de indebærer, og hvordan de samarbejder.

Det er vigtigt at forstå disse centrale områder. Det vil give dig værktøjerne til at implementere eller forbedre agil produktstyring i dit team eller din organisation.

Hvad er agil produktstyring?

Agile er en filosofi om, hvordan teams effektivt kan samarbejde om at nå et mål. Det oprindelige Agile-manifest, der blev offentliggjort i 2001, udtrykker Agile-principperne bedst:

Individer og interaktioner frem for processer og værktøjer
Fungerende software frem for omfattende dokumentation
Kundesamarbejde frem for kontraktforhandling
Reaktion på forandringer frem for at følge en plan

Det er essensen af agil produktstyring. Der nævnes hverken historiepoint eller svømmebaner. Ingen daglige statusmøder eller sprintforløb.

Selvom Agile-manifestet ikke foreskriver brugen af processer og værktøjer, nedtoner det deres betydning til fordel for et menneskefokuseret og tilpasningsdygtigt samarbejde. Når man arbejder med agil produktudvikling for første gang (eller blot genopfrisker sin viden), kan det være lærerigt at begynde med de grundlæggende principper i manifestet.

Når vi begynder at tale om de praktiske sider af Agile, er det vigtigt fortsat at have manifestet i tankerne. Processer, dokumentation og planlægning er alt sammen godt. Men hvis du befinder dig i en situation, hvor du eller dit team prioriterer dem over teamet eller et fungerende produkt, bør du være opmærksom på dette.

Lad os se nærmere på nogle af de finere aspekter af tankegangen bag agil produktudvikling.

Menneskefokuseret

Agil softwareudvikling fokuserer på at styrke de mennesker, der udgør dit produktteam. Hvis du vil praktisere det effektivt, skal du virkelig have tillid til dem, du arbejder sammen med. Uden tillid er dit teams psykologiske tryghed i fare, og det produktive samarbejde kan vakle.

Brugerfokuseret

Det er nødvendigt hele tiden at fokusere på dine brugere. For er det ikke dem, vi bygger til?

Et effektivt agilt team interviewer konstant brugere for at få feedback på deres produkter. De udsender og behandler spørgeskemaundersøgelser for at prioritere udviklingen af nye funktioner. Agile-produktchefer leder altid efter måder at opdele arbejdet i små, udgivelsesklare arbejdsopgaver, som kan valideres med brugerne undervejs, samtidig med at de er opmærksomme på at undgå funktionsudvidelse uden styring.

Hvis vi ikke regelmæssigt inviterer brugerne med til bordet, kan det, vi planlægger i dag, være ugyldigt i morgen.

Udfordrende

Agil produktstyring er utrolig udfordrende, men ikke af de grunde, du måske forventer.

Effektive agile teams har generelt færre processer og mindre formel rapportering end deres ikke-agile modparter. Det skyldes, at Agile fokuserer på en løbende strøm af arbejde og gennemsigtighed for at prioritere samarbejde frem for enkeltstående milepæle.

Manglen på processer medfører også for mange produktchefer en følelse af manglende kontrol. De har dog stadig en høj grad af ansvarlighed, som følger med rollen. Det er en kunst at finde balancen, så man ikke overskrider sine beføjelser og forstyrrer teamets fokus, og det kan variere fra team til team afhængigt af dynamikken.

Når en produktchef imidlertid indtager rollen som en tjenende leder, kan der være flere langsigtede fordele — og ironisk nok mere kontrol — end ellers. Det skyldes de gevinster, som det kan skabe at engagere sig fuldt ud i tillidsbaserede agile processer.

Det er også ideelt at have en arbejdskultur, der understøtter Agile. Det er muligt at komme i gang i en organisation uden støtte til Agile, men det vil være mere udfordrende, og du vil opleve, at du går imod strømmen. En organisation, der understøtter Agile, vil være fortrolig med bevidst vage planer, da den forstår, at planerne bliver mere klare, som tiden går.

Lean

At arbejde lean i praksis er afgørende. Et laserfokuseret fokus på resultaterne holder Agile-teams på vej mod målet med få forstyrrelser. Ved at fokusere på den mindste mængde arbejde, der kan udføres for at nå målet, hjælpes teamet med fortsat at bevæge sig fremad og opnå succes på markedet så hurtigt som muligt.

Agilt flow

Før vi gennemgår nogle af de specifikke processer, du kan bruge til at indføre agil produktstyring, lad os tale om det generelle procesflow og de trin i Agile-metoden, som de fleste processer vil følge.

Relateret læsning: Sådan implementerer du principperne for agil produktporteføljestyring

Strategi

God agil udvikling begynder med en god strategi og fælles retning. At samle alle på teamet i et rum (eller til et Zoom-møde) kan gøre underværker for at etablere en fælles produktvision og retning. Overvej at bruge engagerende, visuel samarbejdssoftware for at sikre, at folk ikke mister fokus.

Dette kan give teamet mulighed for at opnå en fælles forståelse af forretningsplanen, den visuelle retning, målbrugerne og meget mere. Det fungerer som et vigtigt fælles udgangspunkt, som teamet kan fokusere på.

Det er vigtigt at bemærke, at de planer og den dokumentation, der skabes i denne periode, behandles som antagelser. De er klar til regelmæssigt at blive gennemgået og videreudviklet, som tiden går.

Get Free Access to the Product Vault

We’ve collected the goods — AI prompts, exclusive deals, and a library of resources for product leaders. Unlock your account for access.

Have an account? Log In

Eksperiment

Alt er et eksperiment. Helt fra begyndelsen bør den første fokuserede del af arbejdet, du udfører, være tidsafgrænset og derefter testes med brugere. Dette arbejde kan være utroligt elementært, selv så simpelt som grove skitser, som du gennemgår sammen med nogen.

Pointen er at gå til arbejdet med den videnskabelige metode som tankegang. Vi arbejder med viden, og derfor handler vores fokus ikke udelukkende om udførelse. Det handler også om at skabe og opdage viden.

Test

Hvert eksperiment bør testes kvalitativt og kvantitativt. Ved regelmæssigt at gennemgå resultaterne får du de værktøjer, du har brug for, til at bekræfte, at det, dit team bygger, skaber værdi og vil blive accepteret på markedet.

Validér

Efter at du har lanceret en ny funktion, skal du løbende holde øje med den. Bliver den brugt? Finder folk den? Er andre områder af dit produkt blevet påvirket positivt eller negativt af, at denne funktion er blevet introduceret?

Ved regelmæssigt at gennemgå og følge op på det, du lancerer, efter at det er "færdigt", får du flere værktøjer og mere vejledning til at træffe endnu bedre beslutninger.

Gentag

Dette er det vigtigste trin. Vend løbende tilbage gennem Agile-procesflowet som en motor. Dette flow er bevidst cyklisk, ikke lineært, for at fremme læring. Lær af det. Tilpas dig ud fra det. Fejr det. Omfavn forandringens flow.

2 almindelige Agile-tilgange

Agile er en styrkende filosofi, der bringer teams sammen om et fælles mål gennem samarbejdsformer, som ikke er mulige med overdrevent strukturerede processer og rapportering.

Men nogle processer er gode. Når de implementeres korrekt og anvendes med hensyntagen til et teams unikke kultur, kan processer fungere som de rammer, der holder et team fokuseret på at nå sine mål, samtidig med at de understøtter kreativ frihed.

Vi dykker ned i nogle af de mere populære processer, der omsætter Agile-filosofien til praksis.

Scrum

Scrum er måske den mest populære Agile-proces, og det er der en god grund til: Den opdeler forpligtelser og læring i dedikerede tidsblokke med arbejdsindsats, kaldet "sprints". Det fremmer en sund mængde læring og flere muligheder for at tilpasse sig denne læring.

Centralt i disse sprints står selve scrum-teamet. I scrum er der ingen titler: Alle producenter på teamet har rollen som "udvikler". Det fremmer et intenst teamfokus på samarbejde og på at nå målet for hvert sprint.

I praksis betyder det, at hvis en testingeniør venter på en funktion, der skal testes, kan vedkommende bruge tiden på at gå i gang med at kode en ny funktion. Denne tværfunktionelle tankegang er utrolig, når den fungerer, fordi det betyder, at et team kan skabe fantastiske resultater.

Scrum arbejder på at minimere møder for at fremme fokuseret udviklingstid. Derfor er der en række tilbagevendende møder eller ceremonier:

Sprintplanlægning: Bruges til at planlægge det arbejde, teamet ønsker at forpligte sig til i det nye sprint.
Sprintevaluering (demonstration): Et tidspunkt, hvor man kan demonstrere fremskridt for hinanden og interessenter samt gennemgå eventuelle læringer.
Sprintevaluering: Et ærligt tidspunkt, hvor teamet ser tilbage på det foregående sprint og drøfter, hvad der gik godt, hvad der ikke gjorde, og hvor der kan være muligheder for udvikling.
Backlogforfinelse og estimering: Dette er en tilbagevendende tidsblok til gennemgang og prioritering af den konstant foranderlige produktbacklog baseret på forretningsmæssige og tekniske læringer. Når der er enighed om elementerne i backloggen, estimeres de med henblik på planlægning.
Daglige statusmøder: Et fast tidspunkt hver dag, hvor teamet deler, hvad de afsluttede i går, hvad de arbejder på i dag, og om noget blokerer dem.

For at forbinde det sprintfokuserede arbejde med det store billede opfordrer scrum til brugen af "historiepoint" til estimering gennem strukturerede sprintplanlægningssessioner. Disse angiver et vilkårligt arbejdsomfang, som teamet tildeler hvert element i backloggen.

Silvia DakeProduktchef
Share This Quote on:

Det utroligt stærke ved dette er, at det understøtter brugen af sporing af hastighed. Det vil sige det gennemsnitlige antal historiepoint, teamet afslutter i hvert sprint. Efter nogle indledende sprints bør dette tal være fastlagt og kan bruges til målrettet prognosticering og planlægning af udgivelser.

Hvis disse værktøjer anvendes konsekvent sammen med teamet og ledes af en erfaren scrummaster, kan scrum være en effektiv proces, der understøtter fokuseret agil udvikling og giver rig mulighed for effektiv iteration.

Kanban

Kanban låner meget fra scrum og indeholder mange velkendte elementer såsom backlogforfinelse, en tavle, der minder om et sprintboard, og meget mere.

Hvor scrum fokuserer på en lille mængde arbejde, lægger kanban dog vægt på et kontinuerligt arbejdsflow.

Centralt i denne proces står kanbantavlen. Elementer prioriteres løbende til venstre og bevæger sig gennem teamets tilpassede proces mod højre, hvor de ender som "færdige". For at afbalancere arbejdsbelastningen kan hver kolonne ofte have en WIP-grænse (igangværende arbejde) for, hvor mange opgaver der må arbejdes på ad gangen.

Kanban er velegnet til supportarbejde eller teams, der har uregelmæssig mulighed for at forpligte sig.

SAFe, XP og andre

Der findes mange yderligere varianter af agile processer, som hver især er tilpasset specifikke organisatoriske behov og kulturelle normer.

SAFe er et omfattende agilt system til implementering af agilitet i stor skala i en organisation, typisk en stor virksomhed. Det består af flere "agile udgivelsestog", som i praksis er individuelle scrumteams. Der indgår flere roller og ceremonier for at sikre, at alle teams arbejder hen imod fælles organisatoriske mål og udgivelsesplaner.

Ekstrem programmering (XP), DevOps, Modern Agile og andre metoder findes for at målrette agile anvendelsesområder til specifikke roller eller kulturer.

Det er sundt at eksperimentere med forskellige agile praksisser. Det kan føre til en effektiv forståelse af, hvad der fungerer for netop jeres organisation.

Certificeringer inden for agil produktledelse

Du har sikkert set de mange certificeringer, man kan tage inden for enhver bestemt agil proces. De markedsføres på en måde, der får dig til at tro, at deres proces er den eneste måde, og at du uden at gennemføre en dyr certificering ikke virkelig vil kunne praktisere processen.

Ignorér det.

Ideelt set vil denne guide give dig tilstrækkeligt momentum til at begynde på din egen læringsrejse. Agile-metoder er en værktøjskasse for praktikere, ikke noget, du bliver testet i. Kendskab til den proces, de ceremonier og den dokumentation, der er særegen for hver proces, er værdifuldt, men når vi går tilbage til manifestet, er det vigtigere at involvere dit team i implementeringen af den agile proces, du vælger. Der findes organisationer, der beskæftiger sig med at skabe og vedligeholde certificeringer; det er naturligvis i deres egen interesse at fremme processer frem for mennesker.

Er det virkelig agilt?

Alt dette for at sige, at dette blot er en advarende fortælling, når du begiver dig ud på din egen agile læringsrejse. Certificeringer kan være værdifulde. Hvis du deltager i en workshop, kan det være en målrettet måde hurtigt at lære alle detaljerne i en specifik proces på. Nogle organisationer lægger vægt på at se, at du er certificeret, som en måde hurtigt at opbygge tillid på.

Hvis det at tage en certificering hjælper dig med at opnå det ønskede resultat og kræver en minimal indsats, så gør det. Men hvis du ikke har brug for en certificering, er eksperimentering og kontinuerlig læring om implementering af agile metoder den mest effektive vej på din agile rejse.

Relateret: De 4 bedste onlinecertificeringer inden for agil produktledelse

Hvilke roller findes der inden for agil produktudvikling?

Ved at gennemgå agile processer er vi begyndt at navngive et sæt centrale roller, som udgør et agilt produktudviklingsteam. Disse roller omfatter:

Produktchef
Produktejer
Udvikler
Designer
Testingeniør / QA

Hver organisation har generelt sin egen tilgang til, hvad disse roller indebærer. En produktchefs ansvarsområder i én virksomhed kan for eksempel i højere grad svare til en produktejers opgaver i en anden. Med denne fleksibilitet in mente kan vi se på nogle af de bredere definitioner, der illustrerer rollerne i et produktteam.

Der er ofte et vist overlap mellem produktejere, produktchefer og projektledere, og teams kan have én, to eller alle tre roller. Produktchefer eller produktejere påtager sig ofte projektledelsesansvar, når der ikke er en projektleder på teamet.

Produktchef

Så hvad laver en produktchef? Produktchefen er ansvarlig for – ja, at lede produktet. Det centrale ansvar for rollen inden for produktledelse er at sikre, at alt er afstemt med henblik på at opnå de vigtigste resultater baseret på brugertest, input fra teamet og strategisk planlægning.

Effektiv produktledelse handler dog om at bemyndige produktteamet. Derfor er produktchef en generalistrolle. Det vil sige, at produktchefen skal kunne favne bredt kompetencemæssigt for at være effektiv, men ikke nødvendigvis være en dygtig udvikler eller designer (selvom det er almindeligt, at personer i produktroller bevæger sig over i produktledelse).

Et generalistisk kompetencesæt gør produktchefen i stand til at være en empatisk, tjenende leder for sit team. Ved at have lige præcis tilstrækkelig forståelse for, hvad udvikling kræver, kan produktchefen hjælpe med at lede teamet hen imod en effektiv produktdefinition og planlægning uden samtidig at stå i vejen for teamets kompetencer.

Relateret læsning: Hvorfor produktledelse er vigtigt

Produktchefens ansvarsområder

Produktejer

Hvor produktchefen har ansvaret for produktets taktiske succes, er den agile produktejer ansvarlig for den forretningsmæssige og markedsmæssige succes.

Generelt er produktejeren en central forretningsrolle, som nogle gange også kan være en central interessent for produktteamet. Produktejerens markedsviden og fokus på forretningen fra 50.000 fods højde gør vedkommende til en vigtig og vidende ressource, der kan hjælpe med at optimere produktteamet med henblik på succes.

Produktejerens ansvarsområder

Produktsucces
Markedsundersøgelser og viden
Forretningsudvikling
Finansiering
Udslagsgivende faktor

En almindelig udfordring er overlapningen og forskellene mellem rollen som produktejer og produktchef. Nogle gange er denne rolle en del af produktchefrollen og omvendt. Når de to roller er adskilte, er der ofte overlap mellem rollerne. Nogle organisationer bytter endda om på ansvarsområderne for produktchef- og produktejerrollerne.

Det er dog helt i orden!

På trods af de udfordringer, der kan opstå, kan der opnås utrolige resultater, når disse roller arbejder sammen om at finde en sund balance gennem et komplementært samarbejde. For eksempel kan den ene rolle være ubønhørligt fokuseret på produktet, mens den anden fokuserer på forretningen. Den ene kan fokusere på produktets tekniske detaljer, mens den anden fokuserer på markedspositionering på højt niveau.

Når disse to roller derefter samarbejder, kan der tilfældigt opstå strategiske indsigter, som ændrer spillet og har en positiv indvirkning på produktets og teamets succes. To hoveder tænker trods alt bedre end ét!

Udvikler

I et effektivt produktteam består udviklerrollen ikke kun i at skrive kode: udviklerne samarbejder med alle roller om strategisk og teknisk planlægning samt anbefalinger.

Udviklere, der har et solidt kendskab til værktøjer til produktudvikling, brugerbehov og produkt-markedsmål, vil kunne udarbejde en teknisk plan, der passer perfekt til produktet. Når man giver sine udviklere denne viden og mulighed for at træffe vigtige tekniske beslutninger, kan det være forskellen mellem en udviklingstidsplan på én måned og en tidsplan, der er mange gange længere, på grund af de tekniske afvejninger, der følger med disse beslutninger.

Når dine udviklere integreres i den produktorienterede del af dit udviklingsteam, kan de mangedoble teamets succes.

Udviklerens ansvarsområder

Produktudvikling
Teknisk planlægning og undersøgelser
Rådgivning om teknologistak
Funktionel prototypeudvikling
Enhedstest
DevOps (nogle gange en separat rolle)
- Oprettelse og administration af implementeringspipeline

Designer

Ligesom udviklere ikke bør være begrænset til kun at skrive kode, bør designernes rækkevidde på et produktteam strække sig ud over at skabe et design. Faktisk finder nogle af de bedste samarbejder på et produktteam sted i samarbejdet mellem denne rolle og produktchefrollen.

Designere på produktteams begynder med strategisk at se på produktstrategien og forretningen. De er ofte teamets stærkeste fortaler med fokus på brugerne. Denne indsigt gør det muligt for dem derefter at designe, om end med et målrettet fokus.

Effektivisering af udvikling og læring er et centralt fokusområde for designroller. Oprettelse af designsystemer gør det muligt for udviklere hurtigt at bygge nye funktioner gennem arbejdsgange med kontinuerlig integration. Opbygning af interaktive, visuelle prototyper gør det muligt at teste med brugere, før der skrives en eneste linje kode, så yderligere investering kan valideres.

Designerens ansvarsområder

Produktdesign
Mockupmodeller
Prototypeudvikling
Oprettelse af stilguide
Oprettelse og vedligeholdelse af designsystem
Brugertest i samarbejde med produktchefen
Løbende brugerundersøgelser

Testingeniør / kvalitetssikring

En testingeniør (nogle gange kaldet kvalitetssikring eller QA) kan være en af de mest indflydelsesrige roller på et produktteam. Selvom deres primære fokus er at teste produktets funktioner, før det lanceres for brugerne, kan deres skarpe blik hjælpe med at strømline teamets fokus, før en ny funktion bygges.

Testingeniører bør inddrages fra de tidligste stadier af produktudviklingen. Det giver rollen mulighed for at definere acceptkriterier for produktets brugerhistorier, som bruges til at vejlede resten af teamet i at færdiggøre arbejdet.

Med en brugercentreret tankegang kan testingeniører advare om potentielle konsekvenser af en kommende lancering. Når denne rolle kan rådgive produktejeren strategisk, kan det have en håndgribelig indvirkning på en ny lancerings forretningsmæssige succes eller fiasko hos brugerne.

Testingeniør-/QA-ansvar

Funktionel test
Regressionstest
Udforskende test
Definition af acceptansekriterier
Løbende risikovurderinger og -analyse

Andre roller

Selvom de tidligere nævnte roller udgør et produktteam, findes der mange roller uden for teamet, som understøtter teamets resultatorienterede fokus.

Disse roller omfatter marketing, salg, kundesupport og meget mere. Normalt integreres disse roller i organisationen for at understøtte produktet, efterhånden som der opnås succes på markedet. Typisk er de ikke en del af produktteamet. Men et stærkt og samarbejdsorienteret forhold til disse roller bidrager yderligere til forretningsmæssig succes.

Samarbejde

Selvom hver rolle har sit eget ekspertiseområde på et produktteam, antages det, at alle samarbejder. Når hver rolle bidrager med en "T-formet" tankegang til teamet, giver det alle mulighed for at bidrage med deres specialviden, samtidig med at de har fokus på produktet som en del af hinandens rolledefinition. Alle går i dybden med deres egen ekspertise, samtidig med at de går i bredden inden for alle andre kompetenceområder for at opnå succes sammen som en enhed.

Samarbejde i et produktteam betyder, at der er et vedvarende fokus på produktresultaterne og brugeroplevelsen. Alle inddrages i at realisere denne vision og bevæge sig fremad sammen som et samlet team.

Konklusion

Vigtigste pointer

Agil produktledelse er en filosofi med fokus på mennesker og brugere, der skal levere det rigtige resultat hurtigere.
Selvom agil udvikling grundlæggende er enkel, introduceres kompleksitet og udfordringer gennem processer, organisationskultur og meget mere.
Agile processer og roller kan styres af metoder som Scrum, Kanban, SAFe og meget mere.
Rollerne på et agilt produktteam omfatter udviklere, designere, testingeniører, en produktchef og en produktejer.

Agil produktledelse er utroligt enkel og bevidst enkel. Det er en stærk filosofi, der kan mangedoble den værdi, dit team er i stand til at skabe. Men jo dybere du går ind i de processer og roller, der understøtter den, desto mere kompleks risikerer den at blive.

I denne kompleksitet gemmer der sig muligheder for at hjælpe med at styrke dit produktteam og din organisation. Det kræver balance at bruge disse taktikker med dit team og samtidig sikre, at de ikke skaber utilsigtet organisatorisk træghed i det daglige samarbejde.

Men når agil udvikling implementeres godt og med en eksperimenterende tilgang, kan det drive fremtiden for dit produktteams succes.

Har du set agil udvikling blive implementeret eller har du erfaring med det? Har det lignet eller adskilt sig fra det, der forklares i denne guide? Fortæl os det i kommentarerne! Glem ikke at tilmelde dig vores nyhedsbrev for produktchefer for at få flere indsigter og guides.

Eller fortsæt med at lære ved at tjekke denne podcast ud, som du så bekvemt kan læse/se/lytte til: Overensstemmelse gennem produktkøreplaner (med Brandon Blackman fra Crema)

Relaterede artikler:

Også værd at tjekke ud:

Agil produktstyring: Guide til processer & roller