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.
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
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
* 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?
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.
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.