Smidig produktledelse: Veiledning i prosesser & roller

Det finnes mye innhold, veiledninger, lærebøker, kurs og sertifiseringer tilgjengelig om smidig produktledelse. Ærlig talt trenger du ikke alt dette.

I kjernen bygger smidig produktledelse på en enkel, menneskeorientert filosofi. Mange av prosessene som smidig produktledelse består av, er enkle og lette å forstå. Kompleksiteten oppstår imidlertid gjennom misforståtte forventninger, roller og prosesser.

I denne veiledningen skal vi:

• Utforske produktledelse, filosofien bak og prosessene den tar form gjennom.
• Se nærmere på rollene som utgjør et typisk smidig produktutviklingsteam, hva de innebærer og hvordan rollene samarbeider.

Det er viktig å forstå disse sentrale områdene. Det vil gi deg verktøyene du trenger for å innføre eller forbedre smidig produktledelse i teamet eller organisasjonen din.

Hva er smidig produktledelse?

Smidig er en filosofi for hvordan team effektivt kan samarbeide for å arbeide mot et mål. Det opprinnelige Agile-manifestet, som ble publisert i 2001, uttrykker de smidige prinsippene best:

• Individer og samspill fremfor prosesser og verktøy
• Fungerende programvare fremfor omfattende dokumentasjon
• Samarbeid med kunden fremfor kontraktsforhandlinger
• Å reagere på endringer fremfor å følge en plan

Det er selve sjelen i smidig produktledelse. Det nevnes ikke noe om brukerhistoriepoeng eller svømmebaner. Ingen daglige statusmøter eller sprinter.

Selv om Agile-manifestet ikke foreskriver bruk av prosesser og verktøy, nedtoner det betydningen av disse til fordel for menneskefokusert og tilpasningsdyktig samarbeid. Når du nærmer deg smidig produktutvikling for første gang (eller bare trenger en oppfriskning), kan det være nyttig å begynne med grunnprinsippene i manifestet.

Når vi begynner å snakke om det praktiske ved smidig arbeid, er det viktig å fortsette å ha manifestet i tankene. Prosesser, dokumentasjon og planlegging er alt sammen bra. Men hvis du befinner deg i en situasjon der du eller teamet ditt prioriterer dette fremfor teamet eller et fungerende produkt, bør du være oppmerksom på det.

La oss se nærmere på noen av de mer detaljerte aspektene ved tankesettet for smidig produktutvikling.

Menneskefokusert

Utvikling av smidig programvare fokuserer på å styrke menneskene som utgjør produktteamet ditt. For å praktisere dette godt må du virkelig stole på dem du arbeider sammen med. Uten tillit står teamets psykologiske trygghet i fare, og produktivt samarbeid kan svekkes.

Brukerfokusert

Det er helt nødvendig å ha et utrettelig fokus på brukerne dine. Det er tross alt dem vi utvikler for, er det ikke?

Et effektivt smidig team intervjuer kontinuerlig brukere for å få tilbakemeldinger på produktene sine. Teamet sender ut og behandler spørreundersøkelser for å styre prioriteringen av utviklingen av nye funksjoner. Smidige produktledere ser alltid etter måter å dele opp arbeidet i små, lanserbare arbeidsoppgaver som kan valideres med brukerne underveis, samtidig som de passer på å unngå funksjonsutglidning.

Hvis vi ikke jevnlig inviterer brukerne med i prosessen, kan det vi planlegger i dag, være ugyldig i morgen.

Krevende

Smidig produktledelse er utrolig krevende, og ikke av de grunnene du kanskje forventer.

Effektive smidige team har vanligvis mindre prosess og formell rapportering enn de ikke-smidige motstykkene sine. Dette skyldes at smidig arbeid fokuserer på en kontinuerlig arbeidsflyt og åpenhet for å prioritere samarbeid fremfor enkeltstående milepæler.

Mangelen på prosesser fører også til at mange produktledere føler at de mangler kontroll. Likevel har de fortsatt en høy grad av ansvarlighet som følger med rollen. Det er en kunst å finne balansen slik at man ikke går for langt og forstyrrer teamets fokus, og dette kan variere fra team til team avhengig av dynamikken.

Når en produktleder inntar rollen som en tjenende leder, kan det imidlertid gi flere fordeler på lang sikt – og ironisk nok mer kontroll –  enn ellers. Dette skyldes gevinstene som kan oppstå når man fullt ut tar i bruk velprøvde smidige prosesser.

Det er også ideelt å ha en arbeidskultur som støtter agil metodikk. Det er mulig å komme i gang i en organisasjon uten støtte for agil metodikk, men dette vil være mer utfordrende, og du vil oppleve at du må gå mot strømmen. En organisasjon som støtter agil metodikk, vil være komfortabel med bevisst vage planer, ettersom den forstår at planene blir tydeligere etter hvert som tiden går.

Lean

Å praktisere Lean er avgjørende. Et laserfokus på resultatene holder agile team i bevegelse mot målet med få distraksjoner. Ved å fokusere på minst mulig arbeid som kan utføres for å nå målet, kan teamet fortsette å bevege seg fremover og oppnå markedssuksess så raskt som mulig.

Agil flyt

Før vi går gjennom noen av de spesifikke prosessene du kan bruke for å ta i bruk agil produktledelse, la oss snakke om den generelle prosessflyten og trinnene i den agile metodikken som de fleste prosesser vil følge. 

Relatert lesing: Slik implementerer du prinsipper for agil produktporteføljestyring

Strategi

God agil utvikling starter med en god strategi og samordning. Det kan gjøre underverker å samle alle på teamet i et rom (eller i et Zoom-møte) for å etablere en felles produktvisjon og retning. Vurder å bruke engasjerende, visuell samhandlingsprogramvare for å sikre at folk ikke kobler ut.

Dette kan være en anledning for teamet til å samordne seg om forretningsplanen, den visuelle retningen, målbrukerne og mer. Det fungerer som et viktig felles utgangspunkt for teamets fokus.

Det er viktig å merke seg at planene og dokumentasjonen som blir laget i denne perioden, behandles som antakelser. De er klare for å bli gjennomgått og videreutviklet regelmessig etter hvert som tiden går.

Eksperiment

Alt er et eksperiment. Allerede fra start bør den første fokuserte arbeidsmengden du utfører, avgrenses tidsmessig og deretter testes med brukere. Dette arbeidet kan være svært rudimentært, til og med så enkelt som grove skisser som du går gjennom sammen med noen.

Poenget er å nærme seg arbeidet med den vitenskapelige metoden som tankesett. Vi er kunnskapsarbeidere, og derfor handler fokuset vårt ikke bare om gjennomføring. Det handler også om å skape og oppdage kunnskap.

Test

Hvert eksperiment bør testes kvalitativt og kvantitativt. Ved å gjennomgå resultatene regelmessig får du verktøyene du trenger for å bekrefte at det teamet ditt bygger, har verdi og vil bli akseptert i markedet.

Valider

Etter at du har lansert en ny funksjon, bør du følge med på den. Blir den brukt? Finner folk den? Har andre deler av produktet ditt blitt positivt eller negativt påvirket av at denne funksjonen ble introdusert?

Ved regelmessig å gjennomgå og følge opp det du lanserer etter at det er «ferdig», får du flere verktøy og mer veiledning til å ta enda bedre beslutninger.

Gjenta

Dette er det viktigste trinnet. Fortsett å gå tilbake gjennom den agile prosessflyten, som en motor. Denne flyten er bevisst syklisk, ikke lineær, for å oppmuntre til læring. Lær av den. Tilpass deg etter den. Feir den. Omfavn endringsflyten.

2 vanlige agile tilnærminger

Agilitet er en styrkende filosofi som samler team rundt et felles mål på samarbeidende måter som ikke er mulige med overdrevent strukturerte prosesser og rapportering.

Men noen prosesser er gode. Når de implementeres riktig og brukes med hensyn til teamets unike kultur, kan prosesser fungere som rekkverk som holder teamet fokusert på å nå målene sine, samtidig som de støtter kreativ frihet.

Vi skal se nærmere på noen av de mer populære prosessene som setter den agile filosofien ut i praksis.

Scrum

Scrum er kanskje den mest populære agile prosessen, og det med god grunn: Den deler opp forpliktelser og læring i bestemte tidsblokker med arbeid som kalles «sprinter». Dette oppmuntrer til en sunn mengde læring og flere muligheter til å tilpasse seg det man lærer.

Sentralt i disse sprintene står selve Scrum-teamet. I Scrum finnes det ingen titler: Alle som produserer på teamet, har rollen som «utvikler». Dette oppmuntrer til et intenst teamfokus på samarbeid og på å nå målet for hver sprint. 

I praksis betyr dette at dersom en testingeniør venter på en funksjon som skal testes, kan vedkommende bruke tiden på å begynne å programmere en ny funksjon. Denne tverrfunksjonelle tankegangen er fantastisk når den fungerer, fordi den betyr at et team kan oppnå fremragende resultater.

Scrum arbeider for å minimere møter for å fremme konsentrert utviklingstid. For å oppnå dette finnes det et sett med tilbakevendende møter, eller seremonier:

• Planlegging av sprint: Brukes til å planlegge arbeidet teamet ønsker å forplikte seg til i den kommende sprinten.
• Sprintgjennomgang (demonstrasjon): En anledning til å demonstrere fremgang for hverandre og interessenter, samt gjennomgå det man har lært.
• Sprintretrospektiv: En åpen anledning for teamet til å se tilbake på den forrige sprinten og diskutere hva som gikk bra, hva som ikke gikk bra, og hvor det finnes muligheter for forbedring.
• Bearbeiding og estimering av backlog: Dette er en tilbakevendende tidsblokk for å gjennomgå og prioritere den stadig skiftende produktbackloggen, basert på forretningsmessig og teknisk læring. Når det er enighet om elementene i backloggen, estimeres de for planleggingsformål.
• Daglige statusmøter: Et fast tidspunkt hver dag der teamet deler hva de fullførte i går, hva de arbeider med i dag, og om noe hindrer dem.

For å knytte det sprintfokuserte arbeidet til det store bildet oppmuntrer Scrum til bruk av «historiepoeng» for estimering gjennom strukturerte planleggingsøkter for sprinten. Dette er et vilkårlig mål på arbeidsinnsats som teamet tildeler hvert element i backloggen.

Det som er utrolig kraftfullt med dette, er at det støtter bruk av sporing av hastighet. Det vil si det gjennomsnittlige antallet historiepoeng teamet fullfører i hver sprint. Etter noen innledende sprinter bør dette tallet være godt innarbeidet og kan brukes til målrettet prognostisering og planlegging av lanseringer.

Hvis disse verktøyene brukes samvittighetsfullt sammen med teamet og veiledes av en erfaren Scrum-master, kan Scrum være en kraftfull prosess som støtter fokusert smidig utvikling og gir gode muligheter for effektiv iterasjon.

Kanban

Kanban henter mye fra Scrum og inkluderer mange kjente elementer, som bearbeiding av backloggen, et brett som minner om et sprintbrett, og mer.

Mens Scrum imidlertid fokuserer på en liten mengde arbeid, legger Kanban vekt på en kontinuerlig arbeidsflyt.

Sentralt i denne prosessen står Kanban-brettet. Elementer prioriteres kontinuerlig til venstre og beveger seg gjennom teamets tilpassede prosess mot høyre, før de ender i «ferdig». For å balansere arbeidsbelastningen kan hver kolonne ofte ha en grense for arbeid under utførelse (WIP), som angir hvor mange oppgaver det kan arbeides med samtidig.

Kanban passer godt for støttearbeid eller team som har uregelmessig kapasitet til å forplikte seg.

SAFe, XP og andre

Det finnes mange andre varianter av smidige prosesser, og hver av dem er tilpasset bestemte organisatoriske behov og kulturelle normer.

SAFe er et omfattende smidig system for å innføre smidig arbeidsmetodikk i stor skala i en organisasjon, vanligvis en stor virksomhet. Det består av flere «smidige lanseringstog», som i praksis er individuelle Scrum-team. Flere roller og seremonier inngår for å sikre at alle team arbeider mot felles organisatoriske mål og lanseringsplaner.

Ekstrem programmering (XP), DevOps, moderne smidig metodikk og andre metoder finnes for å rette seg mot smidige bruksområder for bestemte roller eller kulturer.

Det er sunt å eksperimentere med ulike smidige praksiser. Det kan føre til en effektiv forståelse av hva som fungerer for akkurat din organisasjon.

Sertifiseringer i smidig produktledelse

Du har sannsynligvis sett de mange sertifiseringene du kan ta for ulike smidige prosesser. De markedsføres på en måte som skal få deg til å tro at prosessen deres er den eneste riktige, og at du ikke virkelig vil kunne praktisere prosessen uten å gjennomføre en kostbar sertifisering.

Se bort fra det.

Ideelt sett vil denne veiledningen gi deg nok fremdrift til at du kan følge ditt eget læringsspor. Smidige metoder er et verktøysett for praktikere, ikke noe du skal testes i. Det er verdifullt å kjenne til prosessen, seremoniene og dokumentasjonen som er unik for hver prosess, men når vi går tilbake til manifestet, er det viktigere å involvere teamet ditt i implementeringen av den smidige prosessen du velger. Det finnes organisasjoner som arbeider med å utvikle og opprettholde sertifiseringer; det er naturligvis i deres interesse å fremheve prosess fremfor mennesker.

Er det virkelig smidig?

Alt dette for å si at dette ganske enkelt er en advarende fortelling når du legger ut på din egen smidige læringsreise. Sertifiseringer kan være verdifulle. Hvis du deltar på et kurs, kan det være en målrettet måte å raskt lære alle detaljene i en bestemt prosess på. Noen organisasjoner setter pris på å se at du er sertifisert, som en måte å raskt bygge tillit på.

Hvis det å ta en sertifisering hjelper deg med å oppnå det ønskede resultatet og krever minimal innsats, bør du gjøre det. Men hvis du ikke trenger en sertifisering, er eksperimentering og kontinuerlig læring om hvordan man implementerer smidige metoder, den mest effektive veien på den smidige reisen din.

Relatert: De 4 beste nettbaserte sertifiseringene innen smidig produktledelse

Hva er rollene innen smidig produktutvikling?

Ved å gå gjennom smidige prosesser har vi begynt å navngi et sett med sentrale roller som utgjør et smidig produktutviklingsteam. Disse rollene omfatter:

• Produktleder
• Produkteier
• Utvikler
• Designer
• Testingeniør / QA

Hver organisasjon har som regel sin egen tilnærming til hva disse rollene innebærer. For eksempel kan ansvarsområdene til en produktleder i én virksomhet samsvare mer med ansvaret til en produkteier i en annen. Med denne fleksibiliteten i tankene kan vi se nærmere på noen bredere definisjoner som illustrerer rollene i et produktteam.

Det er ofte noe overlapp mellom produkteiere, produktledere og prosjektledere, og team kan ha én, to eller alle tre. Produktledere eller produkteiere påtar seg ofte prosjektlederansvar når det ikke finnes en prosjektleder i teamet.

Produktleder

Så, hva gjør en produktleder? Produktlederen har ansvar for å, vel, lede produktet. Det viktigste ansvaret for rollen som produktleder er å sørge for at alt er samordnet for å oppnå viktige resultater basert på brukertesting, innspill fra teamet og strategisk planlegging.

Effektiv produktledelse handler imidlertid om å gi produktteamet myndighet. Derfor er produktlederrollen en generalistrolle. Det vil si at produktlederen må kunne ha bredde i ferdighetene sine for å være effektiv, men trenger ikke nødvendigvis å være en dyktig utvikler eller designer (selv om det er vanlig at personer i produktroller går over til produktledelse).

Et generalistisk ferdighetssett gjør produktlederen i stand til å være en empatisk, tjenende leder for teamet sitt. Ved å ha akkurat nok forståelse av hva utvikling innebærer, kan produktlederen hjelpe teamet med å styre mot effektiv produktdefinisjon og -planlegging, samtidig som vedkommende ikke kommer i veien for teamets ferdigheter.

Relatert lesning: Hvorfor produktledelse er viktig

Produktlederens ansvarsområder

• Produktresultater
• Styring av produktkøen
• Interessenthåndtering
• Brukertesting
• Skrive brukerhistorier
• Tilrettelegging for tverrfunksjonelle team
• Styring av produktets veikart
• Produktanalyse

Produkteier

Mens produktlederen har ansvar for produktets taktiske suksess, er den smidige produkteieren ansvarlig for den forretningsmessige og markedsmessige suksessen.

Generelt er produkteieren en sentral forretningsrolle som noen ganger også kan være en sentral interessent for produktteamet. Markedskunnskapen deres og fokuset på virksomheten fra 50 000 fots høyde gjør dem til en viktig og kunnskapsrik ressurs som kan bidra til å optimalisere produktteamet for å lykkes. 

Produkteierens ansvarsområder

• Produktsuksess 
• Markedsundersøkelser og -kunnskap
• Forretningsutvikling
• Finansiering
• Utslagsgiver

En vanlig utfordring er overlappet og forskjellene mellom rollen som produkteier og produktsjef. Noen ganger er denne rollen en del av rollen som produktsjef, og omvendt. Når de to rollene er separate, er det ofte overlapp mellom rollene. Noen organisasjoner bytter til og med om på ansvarsområdene til rollene som produktsjef og produkteier.

Dette er imidlertid helt greit!

Til tross for utfordringene som kan oppstå, kan disse rollene oppnå utrolige resultater når de samarbeider for å finne en god balanse mellom komplementært samarbeid. Én rolle kan for eksempel være kompromissløst fokusert på produktet, mens den andre fokuserer på virksomheten. Den ene kan fokusere på produktets detaljer, mens den andre fokuserer på markedsposisjonering på overordnet nivå.

Når disse to rollene samarbeider, kan det dessuten dukke opp banebrytende strategiske innsikter som har positiv innvirkning på produktets og teamets suksess. Tross alt er to hoder bedre enn ett!

Utvikler

I et effektivt produktteam handler utviklerrollen ikke bare om å skrive kode: utvikleren samarbeider med alle rollene om strategisk og teknisk planlegging samt anbefalinger.

Utviklere som har god kunnskap om verktøy for produktutvikling, brukerbehov og produkt- og markedsmål, vil kunne lage en teknisk plan som passer perfekt til produktet. Når utviklingsteamets medlemmer får denne kunnskapen og muligheten til å ta viktige tekniske beslutninger, kan det utgjøre forskjellen mellom en utviklingstidslinje på én måned og en tidslinje som er flere ganger så lang, på grunn av de tekniske avveiningene som følger med disse beslutningene.

Når utviklerne dine er integrert i produktdelen av utviklingsteamet, kan de mangedoble teamets suksess.

Utviklerens ansvarsområder

• Produktutvikling
• Teknisk planlegging og undersøkelser
• Rådgivning om teknologistakk
• Funksjonell prototyping
• Enhetstesting
• DevOps (noen ganger en separat rolle)
  • Opprettelse og administrasjon av distribusjonspipeline

Designer

På samme måte som utviklere ikke bør begrenses til å bare skrive kode, bør designerens rolle i et produktteam strekke seg lenger enn å lage et design. Faktisk oppstår noe av det beste samarbeidet i et produktteam i samarbeidet mellom denne rollen og rollen som produktsjef.

Designere i produktteam begynner med å se strategisk på produktstrategien og virksomheten. De er ofte teamets sterkeste talsperson for brukerne. Denne innsikten gjør det mulig for dem å deretter utforme design, riktignok med et målrettet fokus.

Å legge til rette for effektivitet i utvikling og læring er et viktig fokusområde for designroller. Ved å opprette designsystemer kan utviklere raskt bygge nye funksjoner gjennom arbeidsflyter for kontinuerlig integrasjon. Interaktive, visuelle prototyper gjør det mulig å teste med brukere før en eneste kodelinje er skrevet, slik at videre investeringer kan valideres.

Designerens ansvarsområder

• Produktdesign
• Skisser
• Prototyping
• Opprettelse av stilguide
• Opprettelse og vedlikehold av designsystem
• Brukertesting i samarbeid med produktsjefen
• Løpende brukerundersøkelser

Testingeniør / QA

En testingeniør (noen ganger omtalt som kvalitetssikrer eller QA) kan være en av de mest betydningsfulle rollene i et produktteam. Selv om hovedfokuset deres er å teste produktets funksjoner før det lanseres for brukerne, kan det skarpe blikket deres bidra til å effektivisere teamets fokus før en ny funksjon bygges.

Testingeniører bør involveres fra de tidligste stadiene av produktutviklingen. Dette gjør at rollen kan definere akseptansekriterier for produktets brukerhistorier, som brukes til å veilede resten av teamet i arbeidet med å fullføre oppgaven.

Med et brukerfokusert tankesett kan testingeniører varsle om potensielle konsekvenser av en kommende lansering. Når denne rollen kan gi produkteieren strategiske råd, kan det ha en konkret innvirkning på om en ny lansering til brukerne blir vellykket eller mislykket for virksomheten.

Ansvarsområder for testingeniør/QA

• Funksjonell testing
• Regresjonstesting
• Utforskende testing
• Definering av akseptansekriterier
• Kontinuerlige risikovurderinger og analyser

Andre roller

Selv om de tidligere nevnte rollene utgjør et produktteam, finnes det mange roller utenfor teamet som støtter teamets resultatorienterte fokus.

Disse rollene inkluderer markedsføring, salg, kundestøtte og mer. Vanligvis blir disse rollene hentet inn i organisasjonen for å støtte produktet når det oppnås suksess i markedet. De er vanligvis ikke en del av produktteamet. Et sterkt og samarbeidsorientert forhold til disse rollene bidrar imidlertid ytterligere til å skape forretningsmessig suksess.

Samarbeid

Selv om hver rolle har sitt eget ekspertiseområde i et produktteam, forutsettes det at alle samarbeider. Når hver rolle bringer med seg en "T-formet" tankegang til teamet, kan alle bidra med sin spesialitet, samtidig som de har fokus på produktet som en del av hverandres rolledefinisjon. Alle går i dybden på sin egen ekspertise, samtidig som de går i bredden på alle andre ferdighetssett for å lykkes sammen som en enhet.

Samarbeid i et produktteam innebærer et urokkelig fokus på produktresultater og brukeropplevelse. Alle involveres i å realisere denne visjonen og bevege seg fremover sammen som et sammensveiset team.

Konklusjon

Viktigste punkter

• Agil produktledelse er en filosofi med fokus på mennesker og brukere for å levere riktig resultat raskere.
• Selv om agilitet i utgangspunktet er enkelt, introduseres kompleksitet og utfordringer gjennom prosesser, organisasjonskultur og mer.
• Smidige prosesser og roller kan styres av prosesser som scrum, kanban, SAFe og mer.
• Rollene som utgjør et agilt produktteam, inkluderer utviklere, designere, testingeniører, en produktleder og en produkteier.

Agil produktledelse er utrolig enkel, og det er helt bevisst. Det er en kraftfull filosofi som kan mangedoble verdien teamet ditt kan skape. Jo dypere du imidlertid går inn i prosessene og rollene som støtter den, desto mer kompleks risikerer den å bli.

I denne kompleksiteten skjuler det seg muligheter for å styrke produktteamet og organisasjonen din. Det er en balansegang å bruke disse taktikkene med teamet ditt samtidig som du sikrer at de ikke skaper utilsiktet organisatorisk treghet gjennom det daglige samarbeidet.

Agilitet kan imidlertid, når den implementeres godt og med en eksperimenterende holdning, drive fremtiden for produktteamets suksess.

Har du sett agilitet bli implementert, eller har du erfaring med det? Har det vært likt eller forskjellig fra det som forklares i denne veiledningen? Fortell oss gjerne i kommentarfeltet! Ikke glem å abonnere på nyhetsbrevet vårt for produktledere for flere innsikter og veiledninger.

Eller fortsett læringen ved å sjekke ut denne podkasten, som du enkelt kan lese/se/lytte til: Samsvar gjennom produktveikart (med Brandon Blackman fra Crema)

Relatert lesning:

• Hva er en agil episk sak? Beste praksis, mal og eksempel
• Slik lager du et agilt veikart
• Livssyklusen for programvareutgivelser (SRLC): Forstå de 6 hovedfasene

Også verdt å sjekke ut:

• Slik bruker du monday.com til produktledelse
• Slik lager du en effektiv stillingsbeskrivelse for en agil produktleder (+eksempel)
• De 15 beste rammeverkene for prioritering av produktfunksjoner: Hvilket er best?
• 8 beste fremgangsmåter for funksjonsflagg du bør kjenne til
• Gratis maler for produktveikart som imponerer interessentene dine
• Slik skriver du effektive versjonsmerknader for programvare som begeistrer brukerne
• Visuelle rapporteringsverktøy for produktdata
• Kanban-verktøy for produktledelse