Introduktionsvideo för agila produktägare i scrum

Det viktigaste ni som är traditionella projektledare måste förstå är att det inte finns några projektledare i scrum.

Det helhetsansvar en traditionell projektledare har delas i scrum upp mellan produktägaren, scrum mastern och utvecklingsteamet, där teamet som helhet har ett gemensamt ansvar.

Om det behövs en övergripande projektledare för att sköta planering, koordination och budget för mer än ett scrum team/delprojekt vid väldigt stora projekt, så är denne inte heller den som har arbetsledningsansvaret över teamen utan är en av intressenterna som i första hand produktägaren kommunicerar med.

Sen kan en projektledare även gå över till rollen produktägare om denne vill eftersom den är mest lik, men måste inse att det ni då i huvudsak ansvarar för är kravfångst, kravhantering och prioriteringen av dessa i form av en backlog.

Produktägare arbetsleder inte utvecklingsteamet och bestämmer vem som ska göra vad och när utan förhandlar med teamet om vad som kan göras i sprintplaneringen som görs i starten på varje sprint, där utgångsbudet är att det som är högst upp i backloggen ska tas med först om det är möjligt och redo att genomföras den sprinten, men det är ibland inte möjligt av olika skäl.

Produktägaren tar alltså fram och bestämmer över kraven genom att kommunicera med intressenterna, bestämmer deras inbördes prioritetsordning i form av en backlog och tar fram acceptanskriterierna som avgör om en uppgift är färdig och redo att releasas.

Denna ska även samarbeta med resten av teamet vid framtagande och förfining av kraven till genomförbara uppgifter innan en sprintplanering, och är bara en av medlemmarna i teamet med specialansvar för kravframtagningen, acceptanskriterierna och prioriteringen av backloggen.

Det är sedan utvecklingsteamet som bestämmer vem som tar en viss uppgift, hur de på bästa sätt ska implementera dessa krav, testa, deploya och jobba under en sprint.

Detta eftersom utvecklingteamet är de som vet mest om sitt jobb, och är bäst lämpade att styra över den biten.

Ovan video är en mycket bra introduktionsvideo för agila produktägare i scrum som på 15 minuter tar upp det viktigaste med att vara en agil produktägare så ni förstår konceptet.

Längst ner i detta inlägg finns även bra länkar till sidor som tar upp specifika delar av produktägarens uppgifter mer i detalj så läs igenom dem med om ni är ny i rollen.

Läs även mitt inlägg om Instruktionsvideos om scrum för nybörjare och se de rekommenderade videorna där med, så ni får en grundförståelse för hur hela scrum teamet jobbar och inte bara er egen roll.

När utvecklarna jobbar enligt scrum innebär det att alla som är någon sorts traditionella projektledare eller produktägare kan betraktas som agila produktägare ur scrum teamets synvinkel, för det är så de bör jobba med scrum teamet för att systemet ska fungera bra och göra det möjligt för scrum teamet att göra sitt jobb på ett bra sätt.

I en organisation där det finns många produktägare med varsin produktbacklog som anlitar samma scrum team så anlitas scrum teamet förslagsvis genom att alla produktägare som har uppgifter de behöver få genomförda inför nästa sprint går till ett gemensamt produktbacklogmöte där de tillsammans förhandlar fram vilka uppgifter som är viktigast för organisationen att få gjorda nästkommande sprint, och rangordnar dessa i en lista som i vissa organisationer kallas för gemensam produktbacklog.

Innna dess bör de olika produktägarna i samråd med scrum teamet har gått igenom produktbackloggen och förfinat de user stories som ska tas med till nästa sprint så dessa är tillräckligt bra och förstådda innan det gemensamt produktbacklogmötet för alla produktägare.

Sedan har scrum teamet ett sprintplanneringsmöte vid varje sprintstart tillsammans med en eller flera produktägare om det behövs, där de utifrån den kapacitet de vet att de har och vilka uppgifter de bedömmer vara möjliga att göra den sprinten väljer ut x antal av de högst rankade från (den gemensamma) produktbackloggen.

Produktägarna som fått med en eller flera uppgifter samarbeter sedan med teamet om dessa och finns tillgänglig för teamet att kontakta för diskussioner och frågor när det behövs tills dess uppgifterna är färdiga.

Varje ny produktägare i en organisation bör informeras om hur systemet med att ta fram en produktbacklog och ev gemensam produktbacklog och scrum fungerar så dessa vet hur de ska jobba med scrum teamet, och samarbetet kan fungerar smidigt och bra.

En organisation där utvecklarna jobbar enligt scrum bör införa någon sorts introduktionsutbildning för de produktägare som aldrig jobbat enligt scrum förut, så dessa får en kickstart och inte behöver återuppfinna hjulet själva varje gång och lära sig den hårda vägen.

För fler frågor om produktägararollen och hur den skulle kunna säkerställas hos er kan ni lämpligen kontakta scrum mastern för ert scrum team.

Scrum mastern är ansvarig för att se till att scrums ritualer och procedurer följs av alla involverade parter, och att coacha folk i scrum så systemet fungerar som det ska, och även den som kan bestämma om enstaka undantag från dess regler och procedurer får göras i akuta fall.

Scrum mastern fungerar även som teamets proxy i de flesta fall så de ska få jobba ostört och produktivt, för teamet i sig är självstyrande och sin egen arbetsledare till skillnad från traditionella team, så en agil produktägare är ingen arbetsledare utan i huvudsak en kravhanterare som samarbetar med teamet.

Jag tror inte det skulle vara allt för svårt för dem som redan är traditionella projektledare att bli agila produktägare i stället, för ni jobbar fortfarande med krav och planering men på ett agilt sätt i stället.

Sen är det precis som allt annat i livet en läroprocess, en resa och ett äventyr för man blir aldrig fullärd, men agilt är ett mer verklighetsanpassat, dynamiskt och tillfredställande sätt att jobba på som även traditionella projektledare kommer gilla när de lärt sig ”the tricks of the trade” och sett hur bra det kan fungera.

Utskriften av det som sägs i videon hittar ni här:

Agile Product Ownership in a nutshell

Ytterligare produktägarresurser

Även Atlassian som gör det agila teamverktyget Jira för att skapa och hantera scrum boards för agila team har rätt bra introduktionssmaterial till agilt, och här för produktägare/”projektledare”.

Läs gärna igenom detta så ni får en bra förståelse för hur man jobbar med krav och plannering inom agilt, för skillnaden är att man gör det mer lättviktigt, rätt övergripande på lång sikt och detaljerat på kortare sikt för att snabbt kunna anpassa sig till nya erfarenheter och verkligheten när kartan inte stämmer överrens med terrängen.

För att ta ett exempel så hade man i ett projektet för en viss typ av applikation börjat med att göra klart enklast den viktigaste funktionaliteten först.

Sen utökar man den steg för steg och gör den mer avancerad så länge tid fortfarande finns, i stället för att i sann vattenfall anda göra en big bang design och hoppas på att tiden räcker till för att få allt att fungera.

Detta för att det inte ens är säkert att big bang designen blir helt rätt då man inte har alla fakta på hand i det läget, så även om man fick allt att fungera kan man ha byggt fel sak på rätt sätt och kastat bort en massa jobb i onödan.

Inom agilt gör man klart den viktigaste funktionalliteten först och sen utökar man steg för steg en applikation med nya funktioner så länge tid och yttetligare krav fortfarande finns.

Slutresultatet blir att man får en applikation som innehåller den funktionallitet kunden anser är viktigast och som fungerar precis så som kunden vill och har behov av, så man bygger rätt sak på rätt sätt och minimerar overhead och waste.

Från början har man bara en övergripande produktvision om ungefär vad man vill applikationen i fråga ska göra och user stories så det räcker för 2 sprintar framåt, och inte en detaljerad från ax till limpa kravspecifikation och projektplan som tar upp allt som ska göras, exakt hur det ska göras och vilka som ska göra det och när.

Waterfall versus agile

Agile Project Management

What is an agile product roadmap?

Product requirements documents, downsized

Agile User Stories

Product Management