Fortsätt till huvudinnehåll

Proxy-produktägare förtar effekten

Ibland möter jag team och organisationer som har, eller tror sig kommer att få, stora svårigheter med att engagera de personer som de helst skulle vilja ha som produktägare. Deras försök till lösning kan ibland vara att ducka för problemet, och tillsätta en mindre lämplig person som produktägare.

Det kanske vanligaste exemplet är nog det här. En utvecklingsavdelning på ett företag är övertygad om att man aldrig kommer att lyckas övertyga sina produktchefer att ta på sig rollen som produktägare, så man utnämner istället representanter från tekniksidan som mellanproduktägare, eller som man ibland hör, produktägar-proxies.

Tanken med en produktägarproxy är att kunna fortsätta kalla den formellt ansvarige för utvecklingsarbetet för produktägare, men samtidigt acceptera att denne inte kommer kunna leva upp till sin roll.

Till en början kan detta verka som en lämplig strategi. Utvecklingsteamet får ju i proxyproduktägaren någon man kan gå till för såväl dagliga frågor som för planering och uppföljning, samtidigt som man inte utmanar den etablerade beslutsrätten hos den faktiska produktägaren.

Tyvärr leder strategin till ett problem som går på tvärs med en av Scrums grundtankar, som är att produktägaren och teamet ska ha ett direkt samarbete. Scrum är baserat på granskning och anpassning. Den som beställer produkten ska regelbundet granska den, för att kunna anpassa utvecklingen fortlöpande. Den som utvecklar produkten ska alltid ha tillgång till den som beställer. Målet med Scrum är att få till ett så effektivt samarbete mellan beställare och utförare som möjligt, alltså ett direkt samarbete mellan produktägaren och utvecklingsteamet.

När den faktiska produktägaren kliver åt sidan, och granskningen och anpassningen sköts av en proxy-produktägare, tappar den faktiska produktägaren insynen i arbetet. Utan insyn finns ingen möjlighet till granskning, och därmed ingen möjlighet till anpassningar baserade på faktiska observationer.

Det kan ta ett tag innan de negativa effekterna blir allmänt kända. Den faktiska produktägaren kliver in när en ny levarans planeras upp, och kommer tillbaks mot slutet av utvecklingstiden. Det är först då effekten av att inte ha en riktigt delaktig produktägare blir uppenbar. Produktägaren visar sig nu inte vara insatt i vad som hänt under de sprintar som lett upp till den senaste produktversionen, och blir med största sannolikhet överraskad över resultatet. Men vid det laget kan inte utvecklingsteamet längre med lätthet agera på feedback på produkten.

Hur kan man göra istället?

Jag tror att många som verkar i rollen som ansvariga för produkter och system gladeligen skulle kliva in i rollen som produktägare, om de bara visste vad som förväntas av dem, och vilken nytta de kan förvänta sig tillbaks. Det är Scrum Masterns jobb att hjälpa dem att förstå detta.

Om produktägaren har problem att interagera med teamet på daglig basis, pröva att låta den person som skulle tagit proxy-rollen kliva in i teamet som domänexpert. Då får den personen tillsammans med teamet göra åtaganden mot sprintmålen, och teamet har daglig tillgång till djup kompetens om problemdomänen. Den faktiske produktägaren kan nu samarbeta med teamet kring krav på hög nivå, alltså med en produktbacklog som har rätt abstraktionsnivå, medan teamet har den domänkompetens som behövs för att lösa detaljfrågorna.

Kommentarer

Anna Forss sa…
Jag kan inte mer än hålla med: efter ett år som product owner proxy kan jag säga att det är en riktigt dålig idé. Som Mike Cohn säger: a single wringable neck. Det är en product owner. Delat ansvar är ingens ansvar.

Det är en sak att flera personer känner ansvar men en person måste vara ansvarig.

När jag gick PO-kursen förstärkes detta intryck: många deltagare ville vara den som hade makten men de ville inte ta ansvaret. De tyckte de var för upptagna för att delta. Men det betyder ju att de inte tycker att projektet är så viktigt, eller?

Som du skriver: det är bättre att en person som är närvarande har ansvaret. Och genom att ge ansvaret till någon vilar det inom det ansvaret att ta in synpunkter från andra, det vill säga Den Viktiga Personen, som måste få tycka till.

Jag tror att PO proxyrollen har växt fram som en synergieffekt mellan Den Som Vill Bestämma och gamla projektledare som gärna vill att allt ska fortsätta som tidigare och genom att kombinera scrum masteriet med PO-proxeriet får båda vad de vill.

Men jag tror man förtar det bästa ur scrum
Tobias Hill sa…
Andra varianter som jag stött på är:

* En person i teamet är SM på halvtid och utvecklare på halvtid.

* En person i teamet är både SM och PO.

Mina erfarenheter är inte särskilt goda av någon av dessa varianter. Vilka är dina?
Tobias Fors sa…
Hej Tobias! Att någon är både SM och PO tror jag inte jag stött på. Man skulle väl kunna argumentera för att många "traditionella projektledare", om man får säga så, försöker sig på den kombinationen, och det har sällan funkat bra i de projekt jag varit med i.

Att man är både Scrum Master och utvecklare har jag sett fungera ok åtminstone en gång. Det verkade fungera ok eftersom teamet var hyfsat fristående från resten av organisationen, ganska moget (hade jobbat länge tillsammans och kunde sina grejor), och ledningens stöd för Scrum var extremt högt.

Annars kan det vara tufft att kombinera tror jag, i varje fall om man vill ha några högre ambitioner med Scrum Master-rollen, som att utveckla teamets produktivitet och utveckla hela organisationen runt omkring teamet. Tyvärr verkar många ha en bild av Scrum Mastern som en rätt passiv typ som bara "låter teamet självorganisera sig", och då kanske man inte ser behovet av att ha rollen som en heltidsroll. Det är inte så hjälpsamt.

Men, till syvende och sidst hänger det som alltid på sammanhanget. Det jag tycker man ska göra om man är osäker är välja en approach, dokumentera vilka resultat man förväntar sig och inte förväntar sig, och officiellt slå fast ett datum när man följer upp den valda vägen mot dessa kriterier.
Tobias Hill sa…
Instämmer att dissonansen var (eller egentligen _är_ om jag skall vara ärlig) betydligt större i det fall där PO/SM kombinerats.

Utvecklare/SM har fungerat bättre men inte direkt bra där jag sett det. Precis som du också poängterar inträdde personen i SM-rollen framförallt vid administrativa sysslor ... utan att ha några större katalyserande ambitioner.

Populära inlägg i den här bloggen

Vad sprintplanering och glassinköp har gemensamt

En missuppfattning som lever kvar kring lättrörliga metoder är att de inte har tillräckligt med planering. Det är precis tvärtom, vi gör massor av planering. Dels gör vi så mycket planering som behövs när vi ska starta ett nytt projekt, dels gör vi granskning och revidering av planerna med en regelbunden rytm. Eftersom vi planerar så mycket behöver vi vara mycket effektiva planerare.

Varje sprint i Scrum börjar med en planeringsworkshop där produktägaren och teamet tillsammans väljer ut rätt mängd viktigt arbete för sprinten. Planeringsarbete kan lätt dra ut på tiden, särskilt när vi eftersträvar precision. Just därför är sprintplaneringen i Scrum begränsad till max en arbetsdag: sprintens första dag. Vissa team märker efter några sprintar att man inte ens behöver hela dagen för att göra en bra plan.

En effektiv sprintplanering kräver att samtliga inblandade kommer väl förberedda. Då kan planeringen genomföras inom tidsramen, och sluta med ett genuint åtagande från samtliga inblandade a…

Sprintbacklog på väggen, produktbacklog elektroniskt

En artikel på InfoQ om för- och nackdelar med att sätta upp sina planer och sin information på väggen fick mig precis att komma ihåg att jag har några tips att dela med mig av.

Sprintbackloggen är, som du redan vet, utvecklingsteamets eget verktyg för att hantera sitt åtagande i sprinten. Med hjälp av sprintbackloggen kan teamet granska och anpassa sitt arbeta på daglig basis. Detta är viktigt, eftersom utvecklingsteamet är själva motorn i Scrum. För att sprintbackloggen ska vara relevant och användbar måste den vara aktuell. Det kommer den att vara givet att två förutsättningar är uppfyllda.

Den första förutsättningen är att teamet verkligen tagit på sig ansvaret att planera och följa upp sitt eget arbete, eftersom man ser nyttan med att göra det och därför vill göra det.

Den andra förutsättningen är att det är extremt enkelt att hålla sprintbackloggen uppdaterad. Vanliga orsaker till att det inte är enkelt är att man lagrar sprintbackloggen i ett verktyg som alla inte behärskar till fu…

Både Scrum Master och teammedlem?

En vanlig fråga som jag brukar få har att göra med vad som händer när en person bemannar två roller i Scrum. Frågan lyder: kan man vara både Scrum Master och medlem i utvecklingsteamet?

Först lite bakgrund till svaret. Mitt standardsvar på alla frågor som börjar med orden "kan man" eller "får man" är ett rungande ja. Självklart kan man göra som man vill, och självklart får man själv (eller snarare tillsammans med sina kollegor) bestämma hur man ska göra. Man behöver inte tillstånd från en expert eller en arbetsmetod. Det kan tyckas som en detalj, men språket styr tanken. Därför tycker jag det är mer hjälpsamt att börja frågan på ett annat sätt. Så här: Vad kan konsekvenserna av att vara både Scrum Master och teammedlem bli?

För mig är det lättast att hitta till ett begripligt svar om jag börjar med att fråga mig själv vad syftet är med att dela på Scrum Master och teammedlemsrollen.
En anledning till uppdelningen är att redan i förväg bygga en beredskap för framtida…