Fortsätt till huvudinnehåll

Vad är en scrum-coach?

Vad är en scrum-coach egentligen? Trots att jag sällan kallar mig scrum-coach har jag arbetat med att coacha andra i att använda Scrum sedan 2003, när jag först lärde mig om Scrum på allvar och började använda metoden i praktiken.

Jag brukar inte kalla mig för scrum-coach, utan för konsult. Om någon som pratar engelska frågar vad jag gör säger jag att jag är en “software management consultant”, vilket låter rätt pretentiöst när man väver in titeln i en svensk mening. På engelska låter det - i mina öron - som en saklig beskrivning av vad jag gör: jag jobbar med chefer, ledare och team för att förbättra hur man styr och leder sin mjukvaruutveckling. Kärt barn har förstås många fler namn. Andra som gör det jag gör använder titlar som mentor, rådgivare eller agile coach.

Eftersom jag arbetar som konsult i ordets ursprungliga bemärkelse (jag erbjuder en konsultativ tjänst) anpassar jag mitt engagemang hos kunden efter vad situationen kräver. Ibland gör vi en serie workshops, ibland finns jag på plats några dagar i veckan under ett längre förändringsarbete. Jag har bott i Uppsala sedan mitten på nittiotalet, när jag utbildade mig till systemvetare på Uppsala Universitet, och mina kunder finns utspridda lite här och där. De flesta finns i Stockholmstrakten, och några i Göteborg och Malmö. Lite flängigt ibland, men det är också uppfriskande med miljöbytena.

Men, om vi struntar i titlarna och fokuserar dels på syftet med att ha en scrum-coach, dels hur det kan gå till i praktiken, hur ser det ut då?

Syftet
Syftet med att ta in en coach i Scrum kan tyckas självklart. Det är väl att få hjälp att införa Scrum? Tja, det är en bra start, men verkligheten är inte fullt så enkel. Inget företag “inför” bara Scrum, och så är det bra så. Scrum är ett enkelt ramverk som hjälper sin användare att upptäcka vilket arbetssätt som fungerar bäst för just den egna organisationen.

Att börja med Scrum är heller inget självändamål. Om förändringen ska leda till något gott behövs ett mål som ligger bortom själva metoden. Något större, något mer lockande och mer relevant för verksamheten. Det kan handla om allt från att vi ska trivas bättre på jobbet till att vi ska bli mer effektiva. Ofta är det en blandning av många olika faktorer. Min erfarenhet är att det är oerhört viktigt att jobba med att identifiera vilka dessa större mål är, så att vi kan jobba mot dem över tiden.

En scrum-coach uppdrag är därför inte bara att hjälpa till att införa Scrum, det är att hjälpa människorna i en organisation lyckas med hjälp av Scrum. Det kan tyckas som en hårfin skillnad i formulering, men för mig är den avgörande. För mig betyder det att vi använder Scrum för att hitta det som behövs för just den specifika organisation jag jobbar med just nu. Det är skillnaden mellan att blint hamra in en metod, och att lyhört upptäcka vad som verkligen passar och behövs.

Hur
Scrum introduceras inte med en vattenfallsplan. Det är ingen idé att sätta sig ned och planera ut i detalj exakt vilka steg som ska tas för att rulla ut metoden. Det är inte så Scrum fungerar. Scrum bygger på granskning och anpassning. Vi formulerar en hypotes, testar den, och lär oss av resultatet. Skölj och upprepa vid behov. Jag gör på samma sätt i själva förändringsarbetet: en tillräckligt bra plan, så tydliga mål vi kan sätta upp, sedan itererar vi.

En erfaren scrumcoach hjälper sin kund att balansera fokus på de större mål man siktar på med regelbundna konkreta förbättringar. Märker jag till exempel att det fortfarande är otydligt hur prioriteringarna ser ut, så lär jag ut några enkla men kraftfulla visualiseringstekniker och förklarar för kunden hur de kan hjälpa oss att komma närmare målet “Alla känner till våra prioriteringar”. Vi anpassar kontinuerligt både förändringens innehåll och vår timing för att passa situationen.

Vad
Att börja med Scrum omfattar så oerhört mycket mer än att bara genomföra de ceremonier som beskrivs i metoden. Att komma igång med gemensam planering och uppföljning, upprätta en backlog och förtydliga teammedlemskapet kan vara nog så svårt, men de utgör ändå bara en bråkdel av en scrumresas omfång.

Scrum omfattar precis allt som påverkar de resultat vi presterar i vårt utvecklingsarbete. Scrums mål är ju att hjälpa oss lyckas uppnå våra mål på ett effektivt och tillfredställande sätt. Det betyder att Scrum också kräver att vi tar itu med vad det nu kan vara som hindrar oss från att lyckas.

Här är några saker som detta har inneburit för mig genom åren:

  • Utbilda organisationens chefer i värdet av arbetsro och fokus
  • Höja kunskapen om hur tvetydigt det skrivna språket är
  • Lära ett teams medlemmar ge varandra tydligare feedback
  • Utmana byråkratin
  • Lyfta fram och diskutera alla olika åsikter som finns om förändringen
  • Möblera om på kontoret
  • Rekrytera produktägare, eftersom ingen gått att hitta internt
  • Öva sig på att modellera på en tavla, istället för att bara prata om designval
  • Automatisera tekniskt arbete som stjäl tid
  • Ta fram effektiva dokumentationsmallar
  • Introducera digitala verktyg för att hantera krav
  • Sparka ut digitala verktyg för att hantera krav
  • Sätta upp pulsmöten för att synkronisera skilda avdelningar och grupper

Listan skulle kunna fortsätta i all oändlighet. Att börja med Scrum innebär mer än att bara börja med Scrum, skulle man kunna säga.

Scrum i annat än mjukvaruutveckling
Ännu bredare blir uppdraget när man inser att Scrum, och särskilt principerna bakom Scrum, kan användas även utanför mjukvaruutveckling. Över åren har det också blivit så att jag även jobbat med driftsgrupper och marknadsavdelningar. Om några år kanske jag suddar ut “software” helt ur min titel, men jag tror det kommer dröja. Mjukvara är ju trots allt det som ligger mig närmast om hjärtat, och de andra grupper jag jobbat med har alla verkat inom mjukvaruutvecklande företag som valt att satsa på lättrörlig utveckling.

Kommentarer

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…