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.

Sprid kunskaperna i teamet

Efter att ha läst om arbetsgrupper där medlemmarna jobbar lite för separerat från varandra för dra nytta av ett teams sanna potential frågar en anonym läsare:

"Det vore intressant att läsa lite tips på hur man når dit. Om man nu är en grupp där man är lite för specialiserade. Vad gör man för att sprida kunskaperna på ett bra sätt?"

Här är några handfasta tekniker som gör att kunskap i ett mjukvaruutvecklingsteam sprids. Men först lite kort om själva förändringen i sig.

Grunden i all förändring är att behovet av förändring är känt. Så, om inte alla i teamet känner till att och varför det är en bra idé att jobba tajtare tillsammans måste ni prata om det. Hur skulle ni veta om ni jobbade bättre tillsammans? Vilka faktiska aktiviteter skulle ni göra? Hur skulle det kännas? På vilket sätt skulle resultatet bli bättre? Vilka nackdeler skulle ni se? Hur skulle ni hantera dem?

Så, några konkreta saker ni kan göra.

1. Planera aldrig ensam.  Klyschan är sann: planen är inget, planeringen är allt.  Ett team planerar sitt arbete tillsammans dels för att skapa en bättre plan, dels för att man genom att samarbeta med planeringen ökar sannolikheten att planen kommer att efterlevas. Tänk efter. Vilken plan är du själv mest benägen att följa - den som du fått släppt i knät, eller den du själv varit med att utforma. Tänk också på detta: vilken plan tror du att du bäst förstår - den någon annan gjort, eller den du själv är medskapare till? Du vet svaren. Av dessa anledningar deltar hela teamet och produktägaren aktivt i såväl releaseplanerings- som sprintplanerings-workshops. Scrum-team är små, så hela teamet arbetar tillsammans under planeringen. Att dela upp sig i mindre grupper under planeringen är kontraproduktivt. Visst kan planering vara över snabbare, men till priset av fragmenterade bilder av helheten.
2. Använd visuell styrning. Visuell styrning handlar om att få upp planen på väggen, så att den blir extremt synlig och extremt lättillgänglig. Sprintbackloggen är en självklar kandidat för visuell styrning. Istället för ett Excelblad eller tjusigt webbverktyg sätter man upp de utvalda behoven från produktbackloggen på väggen, tillsammans med de aktiviter som behöver genomföras för att implementera dem. Delar man sedan upp tavlan med linjer i block som visar mängden aktiviteter som väntar, är påbörjade, respektive avslutade så får teamet en direkt inblick i om man arbetar effektivt tillsammans för att göra klart värdefulla funktioner, eller om flaskhalsar och isolerat arbete leder till att uppgifter blir gjorda men inga resultat nås. 
3. Gemensamma designmöten. Sprintplanering, dagligt möte och sprintuppföljning är inte de enda tillåtna mötena i Scrum. Teamet bokar in alla möten de behöver för att arbeta effektivt tillsammans. Gör de det inte tar Scrum Mastern täten och förklarar varför gemensamma arbetsmöten är en smart grej att göra. Under ett gemensamt designmöte träffas en del av eller hela teamet för att arbeta med detaljplaneringen av något moment i sprinten. Självklart kör man även designmöten tvärfunktionellt, så att lösningen kan belysas från såväl programmerarnas, testernas och andras perspektiv.
4. Gemensamma granskningsmöten. Alla har nytta av att få ett eller flera par fräscha ögon som granskar ens arbetsresultat. Det behöver inte vara av någon från samma disciplin som en själv, tvärtom är det ofta nyttigt att försöka förklara vad man gjort och hur man tänkt för någon som inte är drabbad av samma bakgrund som en själv.
5. Parprogrammering. Inte direkt älskat av alla, om man ska uttrycka det milt, men vansinnigt effektivt när det väl tillämpas av personer som tror på värdet av att skriva kod tillsammans. Effekten är omedelbar: delad kunskap inte bara om hur koden fungerar, utan också om varför den ser ut som den gör.
6. Hjälp experter bli rådgivare. Även effektiva team kan kidnappas av en specialist. Det händer när en nischkompetens finns hos endast en eller två personer i teamet, och allt arbete inom det området måste gå genom experterna. Om dessa personer blir en flaskhals begränsas teamets resultat av hur mycket denna trånga sektor kan släppa igenom. Genom att hjälpa dessa personer att dels sprida sin kunskap, dels förklara för andra hur de kan jobba för att underlätta för experten kan effektiviteten i teamet öka. 
7. Hjälps åt under demon. Under sprintuppföljningens första del, demon, turas teammedlemmarna om att demonstrera en sak som implementeras under sprinten. Övriga antecknar synpunkter från åhörarna under tiden.
8. Återblickar varje sprint. Ett team som har svårt att arbeta tillsammans, och finner sig glida isär i två eller fler faktiska delgrupper, eller kanske bara har individuellt arbete, lägger extra fokus på denna fråga under sprintåterblicken. Som ett minimum pratar man om problemet, och det räcker med att någon tycker att situationen hämmar teamet för att det ska vara ett problem. Kan man försöker man vrida och vända på problemet för att hitta något man kan göra för att få teamet att smälta ihop mer effektivt.

OK. Det var några handfasta tips att pröva om man finner sig i en arbetsgrupp som vill jobba mer samspelt tillsammans, som ett riktigt team. Det är också en lista som visar varför Scrum Master-rollen inte är en lätt syssla. Inget av tipsen i listan ovan är rocket science, likväl görs de ofta inte. Att förstå varför inte, och justera saker och ting så att de börjar hända är Scrum Masterns ansvar. Det betyder inte att det är förbjudet för andra att ta sig an dem - tvärtom. Ett av kännetecknen hos ett fungerande team är att det är ok för vem som helst att kliva fram och ta ansvar för förbättringar.

Sega möten: ett tecken på djupare problem

Som en kommentar till det jag skrev om motstånd mot dagliga morgonmöten i "Pragmatisk eller dogmatisk? Progmatisk!", skriver Magnus Ljadas:

"En anledning till motstånd till morgonmöten, enligt min erfarenhet, kan vara att arbetet i projektet bedrivs väldigt specialiserat. Jag gör bara sånt som har med utskrifter att göra; du sysslar bara med webbformulär; och ingen av oss rör någonsin nånting som har med databasen att göra, för det är Staffans baby. Vi har liksom väldigt få naturliga beröringspunkter.

Stor fråga kanske, men hur tar man sig ur/bryter en sån situation?"

Verkligen en stor fråga, men vi prövar ett sätt att närma sig den.

En bra teknik är att utgå från att människor vars beteende man inte håller med om eller förstår sig på faktiskt beter sig så rationellt som möjligt, men självklart med utgångspunkt från deras egna aktuella modeller av hur verkligheten fungerar.

Tänker man så kan man i det här fallet fråga sig vilken modell av verkligheten man behöver ha för att tycka att det mest rationella är att dela upp arbetet så strikt mellan sig som personerna i gruppen Magnus beskriver gör?

Kanske tänker de att något eller några av följande argument är sanna.

a) Om man delar upp arbetet i strikta delar, med tydliga ansvarsområden, får man möjlighet att specialisera sig i en modul eller teknik, och då blir det lättare att verkligen lära sig den på djupet.

b) Man undviker konflikter när man råkar göra mindre bra ändringar i varandras kod och dokument, eftersom man bara gör ändringar i sina egna grejor.

c) Man vet vem man ska gå till när något går fel i en viss del.

d) Man slipper kommunicera med varandra hela tiden, så man kan jobba fokuserat på sina saker lättare.

e) En karriär byggs bäst på ett smalt expertområde. Att dela med sig av sin kunskap är att minska sina möjigheter att bli expert, och därmed att göra karriär.

f) Om man gör sin del som man ska har man gjort ett bra jobb och kan vara nöjd med sin insats.

För att gruppen ska vilja jobba mer tajt tillsammans behöver de byta ut sin nuvarande mentala modell av vad som är rationellt mot en alternativ modell.

En alternativ modell av verkligheten skulle kunna se ut så här.

a) Det är bra att ha mer eller mindre inblick i alla delar av systemet, så att man kan samarbeta lättare i teamet, och kanske till och med hoppa in och göra ändringar i fler delar än bara en enda som man specialiserat sig på. Det minskar risken vid till exempel sjukdom och ledighet, och är särskilt skönt när man själv är den som vill vara ledig.

b) Man undviker konflikter bättre om man är överens om att man har gemensamt ansvar för hela produktens kvalitet. Det är allas fel om det finns en defekt i systemet.

c) Det går snabbt att lösa problem om mer än en person behärskar en given del av produkten.

d) Man kommunicerar effektivare med varandra när man har bättre inblick i fler delar av systemet, eftersom det blir färre missförstånd.

e) En karriär byggs bäst på att ha deltagit i team som levererat lysande resultat, och på de relationer med nya personer i och utanför teamet som man därmed byggt upp.

f) Om man bygger en bra produkt tillsammans, som kunden och användarna gillar, då har man gjort ett bra jobb och kan känna sig nöjd.

En grupp som betraktar världen genom den alternativa modellen kommer att välja att jobba nära varandra. För den gruppen kommer morgonmöten att kännas användbara, eller, om de är verkligt effektiva, kanske till och med lite överflödiga.

Vad kan få en individ eller grupp att byta ut vad man tycker är en fungerande modell mot en helt ny?

Tja, en anledning kan vara att man en dag förväntas arbete i ett team som medvetet satts samman för att vara tvärfunktionellt, med uppdraget att bygga värdefull, testad och dokumenterad mjukvara var trettionde dag. Scrum sätter på detta sätt upp ramar som ska stötta teamet att själva upptäcka värdet av nära samarbete. Ibland händer det som av sig självt, ibland inte, därav Scrum Masterns ansvar att hjälpa andra förstå och lyckas med Scrum.

Pragmatisk eller dogmatisk? Progmatisk!

Scrum är ett enkelt ramverk. Några få regler bildar tillsammans ett system av aktiviteter som kan användas för att styra komplext arbete. Att ta bort en väsentlig del ur ett fungerande system påverkar alltid systemet som helhet. Tar man till exempel bort återblickarna ur Scrum minskar sannolikheten för framgång omedelbart.

Man får lika stora problem, om inte större, om man försöker applicera Scrum dogmatiskt. Den som aldrig kan tänka sig att kompromissa kommer inte att ha någon framgång när det gäller att driva förändring. Har du själv jobbat med någon som aldrig kan kompromissa förstår du varför.

Så hur ska man göra? Följa Scrum dogmatiskt för att inte förstöra arbetsmetodens effektivitet, eller vara pragmatisk för att inte alienera sig från andra människor?

Jag föreslår en kompromiss. Låt oss kalla den en progmatisk hållning.

Den progmatiska hållningen fungerar så här. Vi är å ena sidan aldrig rädda för att tänka själva och göra förändringar i Scrum, men å andra sidan gör vi inte ändringar utan att först ha reflekterat över om vi verkligen förstår konsekvenserna av de ändringar vi gör.

Ett exempel förtydligar.

Mats är Scrum Master för ett Scrumteam. Teamet är ganska litet, bara fem personer. Två personer som mest programmerar, men även hjälper till med test, två personer som mest testar, dels explorativt, dels med automatiserade testverktyg, och en domänexpert.

Sedan man började med dagliga statusmöten tycker Mats att han fått en mycket bättre insyn i projektet, men hans kollegor är inte lika nöjda. Alla teammedlemmarna är överens om att det skulle räcka med morgonmöten måndagar, onsdagar och fredagar. Mats har presenterat de argument han tycker talar för ett dagligt möte (det blir kortare, information sprids snabbare med mera), men han lyckas inte övertyga teamet. Mats sätter sig med teamet en halvtimme för att bestämma hur de ska göra.

Mats börjar med att gå igenom syftet med morgonmötet igen. Det visar sig att alla är överens om att man vill ha daglig koll på läget i projektet. Alla är också överens om att man ska uppdatera planeringsväggen varje dag, så att alla har en bra bild av vad som händer.

Teamet presenterar sina argument mot ett dagligt möte. Det här är inte första gången man jobbar tillsammans. Samtliga är seniora utvecklare, och gruppen har en effektiv dynamik. Man sitter tillsammans i ett stort rum, med egna avgränsade platser så att man får avskiljdhet, men så nära att man lätt kan byta information med varandra och fånga upp vad som händer. Teamet menar att man sedan länge har lärt sig att kommunicera frekvent om mål, uppgifter och hinder, och deras track record visar att det inte bara är prat.

Tillsammans bestämmer Mats och teamet sig för att vara progmatiska. Man har förstått värdet i ständig insyn i projektets status och kontinuerligt utbyte av information i teamet. Man tycker att ett dagligt möte utöver den fungerande och mogna kommunikation man redan har känns märkligt, som något man skulle göra "bara för att metoden säger det", och den känslan är man överens om är demotiverande. Man köper helt enkelt inte att en paketerad arbetsmetod skulle veta bättre än deras samlade erfarna omdöme.

Teamet och Mats beslutar att pröva att ha scrum-möten tre gånger per vecka under några sprintar framöver. Mats gör en notis i sin Scrum Master-dagbok. Först skriver han ned datumet, sen skriver han ned vilket beslut de tagit, varför, och vilket resultat de förväntar sig av det. Sist skriver han ned när han ska följa upp om det blev som de tänkte sig. Sen känner han sig helt nöjd med utkomsten. En av tankarna med Scrum var ju trots allt självorganiserande team, tänker han, medan han tillsammans med sina kollegor städar undan kaffekopparna från det gemensamma arbetsbordet i teamrummet.

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 utmaningar. När ett projekt får upp farten kavlar folk upp ärmarna och kör så det ryker. Finns en deadline runt hörnet ökar trycket ännu mer.

Utvecklingsteamet i Scrum har som uppgift att arbeta tillsammans för att bygga produkten. De kommer att vara under tryck från både sig själva och omgivningen att få mycket gjort på kort tid.  Produktägarens ansvar är att göra produkten till en framgång. Framgången hänger på att rätt funktionalitet kommer ut i rätt tid, till rätt kostnad. Både teamet och produktägaren kommer med andra ord att känna det fulla trycket av ett utmanande projekt.

Scrum Mastern är också med i matchen, men från ett lite annat perspektiv. På ett sätt kan man säga att Scrum Masterns jobb är att behålla ett nyttigt lugn när alla andra blir galna. Scrum Masterns roll är att hjälpa alla andra att uppnå sina mål med hjälp av Scrum. I den mån andra beter sig kontraproduktivt är det Scrum Masterns jobb att belysa detta på ett sätt som gör att en beteendeförändring kommer till stånd.

Genom att redan från början identifiera Scrum Master-rollen som separat från utvecklingsteamet och produktägaren kan vi i någon mån redan från början vara överens om att det är någons explicita ansvar att backa ett par steg när börjar gå undan, och betrakta situationen från en viss distans.

Så: kan man vara både Scrum Master och teammedlem på samma gång? Självklart, men här är några av konsekvenserna:

• När organisationen som mest behöver någon som lugnt och rationellt kan observera en kaotisk situation, och styra mot en anpassning - en Scrum Master - är den personen med stor sannolikhet precis som alla andra upptagen med att släcka bränder.
• Även om tempot i projektet för tillfället är lugnt och produktivt finns det alltid långsiktiga utmaningar att jobba med. Min erfarenhet är att det är lätt att försaka en av de roller man tagit på sig, av gammal ohejdad vana. En utvecklare som också är Scrum Master är förmodligen mer benägen att göra ett testskott på en ny intressant teknik, än att gå till företagets lokalchef och diskutera möjligheten att förbättra kontorslayouten.
• Att växla mellan två uppgifter betyder inte att man kan lägga femtio procent av tiden på respektive uppgift. En del tid, ofta mer än man tror, går åt till att växla mellan och koordinera de olika uppgifterna.

Är det då alltid en dålig idé att vara både teammedlem och Scrum Master? Nej, jag vill inte vara så kategorisk. I några situationer har jag sett det fungera alldeles utmärkt. Det har varit i organisationer där ledningen gett sitt fulla stöd åt användningen av Scrum, och därför aktivt hjälpt teamet på alla sätt och vis. I den situationen är trycket mindre på Scrum Mastern att jobba med lång- och kortsiktig hindereliminering, och därför har en person kunnat bära både Scrum Masterns och teammedlemmens hattar.