Jimmy Janlén "Den Scrummande Konsulten"

Många företag och organisationer kämpar med att få till en bra dialog kring prioriteringar och kravdetaljer med beställare och verksamhet.

I större organisationer som inte i mål med att forma om sig för att stötta agila projekten i sina leveranser blir ofta just produktägaren (och verksamhets- experter) en flaskhals.

För några dagar sedan fick jag detta mail:

.

Hej Jimmy!

Tack för en bra blogg. Såg att du gärna mottog frågor om Scrum så tänkte maila om det jag funderar på.

Vår nuvarande Product Owner har inte varit närvarande och han har haft massa sidouppgifter. Tanken är nu att han ska blir Chief Product Owner med underordnade Product Owner för olka delar av vårt system då det är stort och komplext. Till detta så kommer det även för stories att finnas kravägare som man får för sig att varje team ska vända sig till med frågor. Mina funderingar om detta:

1. Om vi har en huvud produktägare, visst borde denna kallas Chief Product Owner istället för Product Manager?

2. De under ordnade produktägarna bord väl kallas Product Owner of Function A och inte Functional managers vilket ger associationer till något helt annat?

3. Ska verkligen kravägare vara den som teamet pratar med? Bör det inte vara produkägarna som teamet kommunicerar med i det? För som jag förstått det så ska produkägaren/ägarna har väldigt god koll på alla stories?

Hej #####,

Roligt att du tycker om bloggen! Och tack också för din fråga. 

Såhär tänker jag…

. 

1. Om vi har en huvud produktägare, visst borde denna kallas Chief Product Owner istället för Product Manager?

Jag håller med om att Chief Product Owner är ett lämpligare namn. Det är vedertaget och har en betydelse inom den agila litteraturen och inom Scrum-metodiken. Viktigare än namnet är dock såklart rollens syfte och förväntad roll i projektet.

.

2. De under ordnade produktägarna bord väl kallas Product Owner of Function A och inte Functional managers vilket ger associationer till något helt annat?

Personligen gillar jag beteckningen ”Area Product Owner <Functional Area>” fast ”Product Owner of Function A” tror jag säkert fungerar lika bra. Dock blir jag lite fundersam över begreppet ”Function” här. Det låter som om risken finns att det blir ett för smalt område, men å andra sidan har jag ju ingen insikt i ert system.

Men jag håller med om att ”manager” ger helt fel associationer. Att vara produktägare handlar inte om ”management”, det handlar om att representera kunden och förmedla en vision, roadmap och kunskap kring features och funktioner till teamet. Produktägaren är en del av teamet, inte en av teamets managers.

Vidare, om man har en hierarki med produktägare (vilket man bör ha när man skalar upp Scrum till flera team) så är det viktigt att definiera och farankra vilket mandat produktägarna har över sin egen produktbacklogg. På sätt och vis utgör produktägarna ett virtuellt team vars förmåga och vilja att samarbeta kring roadmaps och prioriteringar är centralt. Varje team ska inkludera en produktägare som bistår teamet i diskussioner kring vision, roadmaps och prioriteringar – på daglig basis, aktivt och proaktivt. Vidare ska varje team ha sin egen produktbacklogg. Om flera team delar samma produktbacklogg anser jag att man hamnar man i flera trassliga situationer.

I detta virtuella ”Product Owner Team” är det viktigt att diskutera och enas kring vilket mandat Chief Product Owner förväntas besitta? Vilket mandat och ansvar blir över till Area Product Owner?

.

3. Ska verkligen kravägare vara den som teamet pratar med? Bör det inte vara produkägarna som teamet kommunicerar med i det?

Jag kan ju bara gissa vad ”kravägare” betyder hos er.

Alt 1. Kravägaren är personen som beställt en viss funktion av produktägaren (alt. produktägarteamet). Personen har ingen detaljerad åsikt kring exakt hur funktionen ska implementeras men är väldigt mån om att få funktionen levererad.

Alt 2. Kravägaren har på uppdrag av produktägaren ett ansvar att konkretisera funktionen och har mandat att utforma detaljerna i kravet.

Alt 3. ?

Oavsett vad – om det finns någon utanför teamet som har speciell verksamhetsexpertis eller kunskap om vad användarna vill ha som inte produktägaren besitter ska denna person vara en del av teamet, åtminstone under den period man jobbar med det kravet.

Han eller hon ska stötta produktägaren i att konkretisera kravet till PBI:er (Product Backlog Items/User Stories), splittra upp det i flera beståndsdelar och sedan förklara affärsvärdet för var och en av de mindre delarna så att produktägaren kan göra en bra prioritering av produktbackloggen.

Vidare, när det är dags att förvandla kravet till värdefull fungerande mjukvara ska personen göras till en teammedlem som på deltar på det dagliga mötet, designworkshoppar och diskussioner samt kan vara med och diskutera de sista detaljerna med testare och utvecklare när kravet faktiskt överstätts till fungerande kod. Teamet (med eller utan ”kravställare”) har inte mandat att utöka/minska omfattningen av funktionen utan att rådgöra med produktägaren – teamets uppgift är att förvandla tydligt definierade och avgränsade krav (User Stories) till fungerande värdefull mjukvara efter produktägarens prioriteringar.

Har inte produktägaren tid till detta (dvs formedla kunskap eller ha åsikt kring kravdetaljerna), eller inte sitter inne med den verksamhetsexpertis eller kundkunskap som behövs, ja då ska teamet utökas med en person som faktiskt har det. Återigen, titeln är inte det viktiga – fokusera på syftet och samarbetsformen.

.

Jag hoppas dessa kommentarer och reflektioner ger dig något av värde och kan hjälpa er i ert arbete och diskussioner.

Jag kan också rekommendera en bra bok som bland annat adresserar dessa frågeställningar och utmaningarna när man skalar upp till flera Scrum team som tillsammans bygger en produkt/ett system.

Den heter ”Scaling Lean & Agile Development – Thinking and Organizational Tools for Large-Scale Scrum” och är skriven av Craig Larman och Bas Vodde.