Skip to main content

Det finns mycket innehåll, guider, läroböcker, kurser och certifieringar tillgängliga om agil produktledning. Ärligt talat behöver du inte allt det.

I grunden bygger agil produktledning på en enkel, människoorienterad filosofi. Många av de processer som Agile använder är enkla och lätta att förstå. Komplexiteten uppstår däremot genom missförstådda förväntningar, roller och processer.

I den här guiden kommer vi att:

Continue Reading for Free

Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.

  • Utforska produktledning enligt Agile, dess filosofi och de processer som den tar form genom.
  • Gå igenom rollerna som ingår i ett typiskt agilt produktutvecklingsteam, vad de innebär och hur rollerna samarbetar.

Det är viktigt att förstå dessa nyckelområden. Det kommer att ge dig verktygen för att införa eller förbättra agil produktledning inom ditt team eller din organisation.

Vad är agil produktledning?

Agile är en filosofi kring hur team effektivt kan samarbeta för att arbeta mot ett mål. Det ursprungliga Agile-manifestet, som publicerades 2001, uttrycker Agiles principer bäst:

  • Individer och samspel framför processer och verktyg
  • Fungerande programvara framför omfattande dokumentation
  • Kundsamarbete framför avtalsförhandling
  • Att reagera på förändringar framför att följa en plan

Det är kärnan i agil produktledning. Det nämns inget om story points eller swim lanes. Inga dagliga avstämningar eller sprintar.

Även om Agile-manifestet inte föreskriver användning av processer och verktyg tonar det ner deras betydelse till förmån för människofokuserat och anpassningsbart samarbete. När du närmar dig agil produktutveckling för första gången (eller till och med bara vill fräscha upp dina kunskaper) kan det vara lärorikt att börja med grunderna i manifestet.

När vi börjar prata om de praktiska aspekterna av Agile är det viktigt att fortsätta ha manifestet i åtanke. Processer, dokumentation och planering är alla bra. Men om du hamnar i en situation där du eller ditt team prioriterar dem framför teamet eller en fungerande produkt bör du ta detta på allvar.

Vi ska titta närmare på några av de mer detaljerade aspekterna av tankesättet inom agil produktutveckling.

Människofokuserat

Agil programvaruutveckling fokuserar på att ge människorna i ditt produktteam möjlighet att lyckas. För att tillämpa det på ett bra sätt måste du verkligen lita på dem du arbetar med. Utan tillit riskerar teamets psykologiska trygghet att försämras, och ett produktivt samarbete kan börja vackla.

Användarfokuserat

Det är ett måste att hela tiden fokusera på användarna. Det är trots allt för dem vi bygger, eller hur?

Ett effektivt agilt team intervjuar kontinuerligt användare för att få feedback på sina produkter. Teamet skickar ut och bearbetar enkäter för att styra prioriteringen av utvecklingen av nya funktioner. Agila produktchefer letar alltid efter sätt att dela upp arbetet i små, leveransbara delar som kan valideras med användarna längs vägen, samtidigt som de är noga med att undvika funktionsglidning.

Utan att regelbundet bjuda in användarna till bordet kan det vi planerar idag vara ogiltigt imorgon.

Utmanande

Agil produktledning är otroligt utmanande, men inte av de skäl du kanske förväntar dig.

Effektiva agila team har i allmänhet färre processer och mindre formell rapportering än sina icke-agila motsvarigheter. Det beror på att Agile fokuserar på ett kontinuerligt arbetsflöde och transparens för att prioritera samarbete i stället för enstaka milstolpar.

Med brist på processer följer också en känsla av bristande kontroll för många produktchefer. Samtidigt har de fortfarande ett stort ansvar som följer med rollen. Att hitta balansen så att man inte går för långt och stör teamets fokus är en konst och något som kan variera från team till team beroende på dynamiken.

När en produktchef däremot intar rollen som tjänande ledare kan det finnas fler långsiktiga fördelar – och ironiskt nog mer kontroll –  än annars. Det beror på de vinster som kan uppstå när man fullt ut förlitar sig på välfungerande agila processer.

Det är också idealiskt att ha en arbetskultur som stödjer agilt arbete. Det går att komma igång i en organisation utan stöd för agilt arbete, men det blir mer utmanande och du kommer att märka att du arbetar mot strömmen. En organisation som stödjer agilt arbete är bekväm med avsiktligt vaga planer, eftersom den förstår att planerna blir tydligare allt eftersom tiden går.

Lean

Att arbeta enligt Lean i praktiken är avgörande. Ett kompromisslöst fokus på resultaten håller agila team på väg mot målet med få distraktioner. Genom att fokusera på minsta möjliga arbetsinsats som krävs för att uppnå målet kan teamet fortsätta framåt och nå framgång på marknaden så snabbt som möjligt.

Agilt flöde

infografik över agilt flöde
Det allmänna flödet i den agila metoden, från strategiarbete till experiment, testning och validering. Processen upprepas för att främja kontinuerlig iteration.

Innan vi går igenom några av de specifika processer du kan använda för att införa agil produktledning ska vi tala om det allmänna processflödet och de steg i den agila metoden som de flesta processer följer. 

Relaterad läsning: Så implementerar du principer för agil produktportföljhantering

Strategi

En framgångsrik agil utveckling börjar med en bra strategi och samsyn. Att samla alla i teamet i ett rum (eller i ett Zoom-möte) kan göra underverk för att skapa en gemensam produktvision och riktning. Överväg att använda engagerande, visuell samarbetsprogramvara för att säkerställa att människor inte tappar koncentrationen.

Detta kan vara ett tillfälle för teamet att skapa samsyn kring affärsplanen, den visuella riktningen, målgruppen och mycket mer. Det fungerar som en viktig gemensam utgångspunkt för teamets fokus.

Det är viktigt att notera att de planer och den dokumentation som skapas under denna tid behandlas som antaganden. De är redo att regelbundet granskas och vidareutvecklas allt eftersom tiden går.

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

Experiment

Allt är ett experiment. Direkt från start bör den första fokuserade arbetsinsatsen du genomför vara tidsbegränsad och sedan testas med användare. Detta arbete kan vara oerhört enkelt, till och med så enkelt som grova skisser som du går igenom tillsammans med någon.

Poängen är att närma sig arbetet med den vetenskapliga metoden som utgångspunkt. Vi är kunskapsarbetare och därför ligger vårt fokus inte enbart på genomförande. Det handlar också om att skapa och upptäcka kunskap.

Test

Varje experiment bör testas kvalitativt och kvantitativt. Genom regelbunden granskning av resultaten får du de verktyg du behöver för att bekräfta att det teamet bygger skapar värde och kommer att accepteras på marknaden.

Validera

Efter att du har släppt en ny funktion till användarna bör du hålla koll på den. Används den? Hittar människor den? Har andra delar av produkten påverkats positivt eller negativt av att funktionen infördes?

Genom att regelbundet granska och följa upp det du släpper efter att det är "klart" får du fler verktyg och mer vägledning för att fatta ännu bättre beslut.

Upprepa

Detta är det viktigaste steget. Fortsätt att gå tillbaka genom det agila processflödet, som en motor. Detta flöde är avsiktligt cykliskt, inte linjärt, för att främja lärande. Lär av det. Anpassa dig efter det. Fira det. Omfamna förändringens flöde.

2 vanliga agila arbetssätt

Agilt arbete är en stärkande filosofi som för samman team mot ett gemensamt mål på samarbetsinriktade sätt som inte är möjliga med alltför strukturerade processer och rapportering.

Men vissa processer är bra. När processerna implementeras och används på rätt sätt och med hänsyn till teamets unika kultur kan de fungera som skyddsräcken som håller teamet fokuserat på att nå sina mål, samtidigt som de stödjer kreativ frihet.

Vi ska gå igenom några av de mer populära processerna som omsätter den agila filosofin i praktiken.

Scrum

Scrum är kanske den mest populära agila processen, och det av goda skäl: den delar upp åtaganden och lärande i särskilda tidsblock för arbete, så kallade "sprintar". Detta främjar en hälsosam mängd lärande och fler möjligheter att anpassa sig efter dessa insikter.

Scrumteamet självt står i centrum för dessa sprintar. Inom Scrum finns inga titlar: varje teammedlem har rollen som "utvecklare". Detta främjar ett intensivt teamfokus på samarbete och på att uppnå målet för varje sprint. 

I praktiken innebär detta att om en testingenjör väntar på en funktion att testa, kan hen ägna tiden åt att börja koda en ny funktion. Detta tvärfunktionella tankesätt är fantastiskt när det fungerar, eftersom det innebär att ett team kan uppnå fantastiska resultat.

Scrum arbetar för att minimera möten för att främja fokuserad utvecklingstid. För att göra detta finns det ett antal återkommande möten, eller ceremonier:

  • Sprintplanering: Används för att planera det arbete som teamet vill åta sig under den nya sprinten.
  • Sprintexamination (demo): En tid för att visa upp framsteg för varandra och intressenter samt gå igenom eventuella lärdomar.
  • Sprintretrospektiv: En uppriktig stund då teamet ser tillbaka på den föregående sprinten och diskuterar vad som gick bra, vad som inte gick bra och var det kan finnas möjligheter till utveckling.
  • Förfining och uppskattning av backloggen: Detta är ett återkommande tidsblock för att granska och prioritera den ständigt föränderliga produktbackloggen, baserat på affärsmässiga och tekniska lärdomar. När teamet har enats om posterna i backloggen uppskattas de i planeringssyfte.
  • Dagliga ståmöten: En regelbunden tid varje dag då teamet delar vad de slutförde i går, vad de arbetar med i dag och om något hindrar dem.

För att koppla det sprintfokuserade arbetet till helheten uppmuntrar scrum användningen av ”berättelsepoäng” för uppskattning genom strukturerade sprintplaneringssessioner. Dessa utgör en godtycklig arbetsinsatsnivå som teamet tilldelar varje post i backloggen.

Jag brukar använda berättelsepoäng mer än tidsuppskattningar. Om jag ser en hög nivå av berättelsepoäng nära slutet av en sprint vet jag att vi behöver ta itu med det eller bryta ner det.

Silvia Dake

Det som är otroligt kraftfullt med detta är att det stöder användningen av att följa leveranshastigheten. Det vill säga det genomsnittliga antalet berättelsepoäng som teamet slutför under varje sprint. Efter några inledande sprintar bör detta tal vara finjusterat och kan användas för målinriktade prognoser och planering av lanseringar.

Om dessa verktyg används konsekvent med teamet och vägleds av en erfaren scrummästare kan scrum vara en kraftfull process som stöder fokuserad agil utveckling och ger goda möjligheter till effektiv iteration.

Kanban

Kanban lånar mycket från scrum och innehåller många välbekanta delar, såsom förfining av backloggen, en tavla som påminner om en sprinttavla och mycket annat.

Där scrum fokuserar på en liten mängd arbete betonar kanban däremot ett fokus på ett kontinuerligt arbetsflöde.

Central för denna process är kanbantavlan. Poster prioriteras kontinuerligt till vänster och rör sig genom teamets anpassade process åt höger, tills de hamnar i ”klart”. För att ofta balansera arbetsbelastningen kan varje kolumn ha en gräns för pågående arbete (WIP), det vill säga hur många uppgifter som får bearbetas samtidigt.

Kanban passar utmärkt för supportarbete eller team som har oregelbunden möjlighet att åta sig arbete.

SAFe, XP och andra

Det finns många ytterligare varianter av agila processer, var och en anpassad för specifika organisatoriska behov och kulturella normer.

SAFe är ett omfattande agilt system för att införa agilt arbetssätt i stor skala inom en organisation, vanligtvis ett stort företag. Det består av flera ”agila lanseringståg”, som i praktiken är individuella scrumteam. Flera roller och ceremonier ingår för att säkerställa att alla team arbetar mot gemensamma organisatoriska mål och lanseringsplaner.

Extrem programmering (XP), DevOps, Modern Agile och andra metoder finns för att rikta agila användningsområden mot specifika roller eller kulturer.

Det är sunt att experimentera med olika agila arbetssätt. Det kan leda till en effektiv förståelse av vad som fungerar för just din organisation.

Certifieringar inom agil produktledning

Du har förmodligen sett de många certifieringar som du kan ta inom olika agila processer. De marknadsförs för att få dig att känna att deras process är det enda sättet och att du utan att genomgå en kostsam certifiering inte verkligen kommer att kunna tillämpa processen.

Strunta i det.

Förhoppningsvis kommer den här guiden att ge dig tillräcklig drivkraft för att ge dig in på ett eget lärandespår. Agila metoder är en verktygslåda för praktiker, inte något du kommer att examineras på. Det är värdefullt att känna till den process, de ceremonier och den dokumentation som är unika för varje process, men med manifestet som utgångspunkt är det viktigare att involvera ditt team i införandet av den agila process du väljer. Det finns organisationer som ägnar sig åt att skapa och upprätthålla certifieringar; det ligger naturligtvis i deras intresse att främja process framför människor.

Är det verkligen agilt?

Allt detta för att säga att det här helt enkelt är en varnande berättelse när du ger dig ut på din egen agila läranderesa. Certifieringar kan vara värdefulla. Om du går en workshop kan det vara ett målinriktat sätt att snabbt lära dig alla detaljer i en specifik process. Vissa organisationer värdesätter att se att du är certifierad som ett sätt att snabbt bygga förtroende.

Om en certifiering hjälper dig att uppnå det önskade resultatet och kräver en minimal arbetsinsats för att uppnå det, så gör det. Men om du inte behöver en certifiering är experimenterande och kontinuerligt lärande om hur man implementerar agilt det mest effektiva sättet att göra framsteg på din agila resa.

Relaterat: 4 bästa onlinecertifieringarna inom agil produktledning

Vilka roller finns inom agil produktutveckling?

Genom att gå igenom agila processer har vi börjat nämna en uppsättning centrala roller som utgör ett agilt produktutvecklingsteam. Dessa roller omfattar:

  • Produktchef
  • Produktägare
  • Utvecklare
  • Designer
  • Testingenjör / QA

Varje organisation har i allmänhet sitt eget sätt att se på vad dessa roller innebär. Till exempel kan en produktchefs ansvarsområden på ett företag ligga närmare det ansvar som en produktägare har på ett annat. Med denna flexibilitet i åtanke ska vi titta på några bredare definitioner som beskriver rollerna i ett produktteam.

Ofta finns det en viss överlappning mellan produktägare, produktchefer och projektledare, och team kan ha en, två eller alla tre rollerna. Produktchefer eller produktägare tar ofta på sig projektledaransvar när det inte finns någon projektledare i teamet.

Produktchef

Så, vad gör en produktchef? Produktchefen ansvarar för att, ja, hantera produkten.  Produktledarrollens huvudansvar är att säkerställa att allt är samordnat för att uppnå viktiga resultat baserat på användartester, teamets synpunkter och strategisk planering.

Effektiv produktledning handlar dock om att ge produktteamet mandat. Därför är produktchef en generalistroll. Det innebär att personen behöver kunna ha breda färdigheter för att vara effektiv, men behöver inte nödvändigtvis vara en skicklig utvecklare eller designer (även om det är vanligt att personer i produktroller går över till produktledning).

En generalistisk kompetensuppsättning ger produktchefen möjlighet att vara en empatisk, tjänande ledare för sitt team. Genom att ha tillräckligt god förståelse för vad utveckling kräver kan produktchefen hjälpa till att leda teamet mot en effektiv produktdefinition och planering, samtidigt som hen inte står i vägen för teamets kompetenser.

Relaterad läsning: Varför produktledning är viktigt

Produktchefens ansvarsområden

Produktägare

Medan produktchefen har ansvaret för produktens taktiska framgång är den agila produktägaren ansvarig för den affärsmässiga och marknadsmässiga framgången.

Generellt sett är produktägaren en central affärsroll som ibland också kan vara en central intressent för produktteamet. Deras marknadskunskap och fokus på verksamheten från 50 000 fots höjd gör dem till en viktig och kunnig resurs som kan hjälpa till att optimera produktteamet för framgång. 

Produktägarens ansvarsområden

  • Produktframgång 
  • Marknadsundersökningar och kunskap
  • Affärsutveckling
  • Finansiering
  • Utslagsgivare

En vanlig utmaning är överlappningen mellan och skillnaderna i rollerna som produktägare och produktchef. Ibland är den här rollen en del av produktchefsrollen och vice versa. När de två rollerna är separata finns det ofta en överlappning mellan rollerna. Vissa organisationer byter till och med plats på produktchefens och produktägarens ansvarsområden.

Det är dock helt okej!

Trots de utmaningar som kan uppstå kan dessa roller tillsammans hitta en sund balans genom kompletterande samarbete, vilket kan leda till fantastiska resultat. Exempelvis kan den ena rollen vara kompromisslöst fokuserad på produkten, medan den andra fokuserar på verksamheten. Den ena kan fokusera på produktens detaljer och grundläggande delar, medan den andra fokuserar på positioneringen på marknaden på en övergripande nivå.

När dessa två roller sedan samarbetar kan banbrytande strategiska insikter uppstå av en lycklig slump och påverka produktens och teamets framgång positivt. Två huvuden är trots allt bättre än ett!

Utvecklare

I ett effektivt produktteam handlar utvecklarrollen inte bara om att skriva kod: utvecklaren samarbetar med alla roller kring strategisk och teknisk planering samt rekommendationer.

Utvecklare som har goda kunskaper om verktyg för produktutveckling, användarnas behov och produktens marknadsmål kan skapa en teknisk plan som passar produkten perfekt. Att ge utvecklingsteamets medlemmar denna kunskap och förmåga att fatta viktiga tekniska beslut kan vara skillnaden mellan en utvecklingstid på en månad och en utvecklingstid som är flera gånger längre, på grund av de tekniska avvägningar som följer med dessa beslut.

När dina utvecklare integreras i utvecklingsteamets produktrelaterade arbete kan de mångdubbla teamets framgång.

Utvecklarens ansvarsområden

  • Produktutveckling
  • Teknisk planering och undersökningar
  • Rådgivning kring teknikstacken
  • Funktionell prototypframtagning
  • Enhetstestning
  • DevOps (ibland en separat roll)
    • Skapande och hantering av driftsättningspipeline

Designansvarig

På samma sätt som utvecklare inte bör begränsas till att bara skriva kod bör designansvarigas räckvidd i ett produktteam sträcka sig längre än till att skapa design. Faktum är att några av de bästa samarbetena i ett produktteam sker mellan den här rollen och produktchefsrollen.

Designansvariga i produktteam börjar med att strategiskt granska produktstrategin och verksamheten. De är ofta teamets främsta företrädare för användarnas perspektiv. Dessa insikter gör det möjligt för dem att sedan utforma design, om än med ett riktat fokus.

Att möjliggöra effektiviseringar för utveckling och lärande är ett viktigt fokusområde för designroller. Genom att skapa designsystem kan utvecklare snabbt bygga nya funktioner med hjälp av arbetsflöden för kontinuerlig integration. Interaktiva visuella prototyper möjliggör användartester innan en enda kodrad har skrivits, så att ytterligare investeringar kan valideras.

Designansvarigas ansvarsområden

Testingenjör / QA

En testingenjör (ibland kallad kvalitetssäkringsansvarig, eller QA) kan vara en av de mest betydelsefulla rollerna i ett produktteam. Även om kärnfokuset ligger på att testa produktens funktioner innan den lanseras för användarna kan testingenjörens noggrannhet bidra till att effektivisera teamets fokus innan en ny funktion byggs.

Testingenjörer bör involveras redan i de tidigaste faserna av produktutvecklingen. Detta gör det möjligt för rollen att definiera acceptanskriterier för produktens användarberättelser, vilka används för att vägleda resten av teamet när arbetet ska slutföras.

Med ett användarfokuserat synsätt kan testingenjörer förutse potentiella konsekvenser av en kommande lansering. När den här rollen kan ge produktägaren strategiska råd kan den få en konkret inverkan på affärsframgången eller misslyckandet för en ny lansering till användarna.

Ansvarsområden för testingenjör/QA

  • Funktionstestning
  • Regressionstestning
  • Explorativ testning
  • Definition av acceptanskriterier
  • Löpande riskbedömningar och analyser

Andra roller

Även om de tidigare nämnda rollerna utgör ett produktteam finns det många roller utanför teamet som stödjer teamets resultatinriktade fokus.

Dessa roller omfattar marknadsföring, försäljning, kundsupport och mycket mer. Vanligtvis integreras dessa roller i organisationen för att stödja produkten när framgång på marknaden börjar uppnås. Vanligtvis är de inte en del av produktteamet. En stark och samarbetsinriktad relation med dessa roller bidrar dock ytterligare till att driva verksamhetens framgång.

Samarbete

Även om varje roll har sitt eget expertområde i ett produktteam förutsätts det att alla samarbetar. När varje roll bidrar med ett ”T-format” tankesätt till teamet kan alla bidra med sin specialitet, samtidigt som de omfamnar ett fokus på produkten som en del av definitionen av varandras roller. Alla går på djupet inom sitt eget expertområde, samtidigt som de går på bredden inom alla andra kompetensområden för att tillsammans nå framgång som en enhet.

Samarbete i ett produktteam innebär ett kompromisslöst fokus på produktresultat och användarupplevelse. Alla involveras i att förverkliga denna vision och gå framåt tillsammans som ett sammansvetsat team.

Slutsats

Viktiga slutsatser

  • Agil produktledning är en människo- och användarfokuserad filosofi för att leverera rätt resultat snabbare.
  • Även om agilt arbete är enkelt i grunden tillkommer komplexitet och utmaningar genom processer, organisationskultur och annat.
  • Agila processer och roller kan vägledas av processer som Scrum, Kanban, SAFe med flera.
  • Rollerna i ett agilt produktteam omfattar utvecklare, designers, testingenjörer, en produktchef och en produktägare.

Agil produktledning är otroligt och avsiktligt enkel. Det är en kraftfull filosofi som kan mångdubbla det värde som teamet kan skapa. Ju djupare du går in i de processer och roller som stöder den, desto mer komplex riskerar den dock att bli.

I denna komplexitet döljer sig möjligheter att hjälpa till att stärka ditt produktteam och din organisation. Det är en balansgång att använda dessa taktiker med teamet och samtidigt säkerställa att de inte skapar oavsiktliga hinder för organisationen i det löpande samarbetet.

När agilt arbete däremot implementeras väl och med en experimenterande inställning kan det driva framtida framgång för produktteamet.

Har du sett agilt arbete implementeras eller har du erfarenhet av det? Har det liknat eller skiljt sig från det som förklaras i denna guide? Berätta för oss i kommentarerna! Glöm inte att prenumerera på vårt nyhetsbrev för produktchefer för fler insikter och guider.

Eller fortsätt lära dig genom att ta del av denna podcast, som du bekvämt kan läsa, titta på eller lyssna på: Samordning genom produktfärdplaner (med Brandon Blackman från Crema)

Relaterad läsning:

Värt att kolla in också: