Köp Boken Scrumtips!

Om du vill ha alla scrumtipsen samlade i ett bekvämt format som fungerar i både läsplattan och på mobilen, så köp ett exemplar av min bok Scrumtips. Du sätter själv priset!

21 december, 2011

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.

12 december, 2011

Är vi klara snart, eller?

Vad betyder det egentligen att vara klar med något? Det är svårt att komma överens om det, eftersom vi har olika mål, perspektiv och behov. En begriplig och gemensam definition av vad det innebär att vara klar med en ny funktion kan göra utvecklingsarbetet både effektivare och mindre frustrerande för alla inblandade.

Utvecklare tycker ibland att arbetet är klart när de funktioner som efterfrågats finns implementerade i kod. Testare brukar vilja fylla i med att funktionerna måste vara testade också. Folk i supporten brukar lägga till att buggarna man hittade under test gärna får vara lösta innan man levererar ut funktionen till användarna. Nyanställda utvecklare brukar gräma sig över att den kod som skrevs innan man själv började är så grötigt skriven att det nästan är omöjligt att sätta sig i den. Därför vill de lägga till att koden ska vara snyggt skriven och väl designad.

Scrums definition på att vara klar med något är ganska krävande. De flesta organisationer får jobba länge på att lära sig nå upp till Scrums klarkriterium.

I Scrum är en funktion klar när:
  • Funktionen fungerar som den ska för användaren, som därför kan använda den nya funktionaliteten för att uppnå sina mål och lösa sina problem.
  • Den är implementerad i välskriven kod som går att jobba vidare med.
  • Vi har testat funktionen så att vi kan göra ett tryggt uttalande om produktkvaliteten.
  • Buggar som vi hittat under testningen har fixats inom ramen för sprinten (”what happens in the sprint stays in the sprint”) och behövs det användardokumentation har vi tagit fram den med.
  • Dessutom har funktionen de kvaliteter som vi förväntar oss av den, när det gäller till exempel snabbhet och säkerhet.
  • Det enda sättet att uppnå Scrums krävande klardefinition sprint efter sprint är att bryta ned arbetet i små fristående delar, och utveckla delarna en i taget.
Målet är att varje sprint ska sluta med potentiellt levererbar produkt.

Potentiellt levererbar betyder att om vi skulle vilja leverera produkten till användarna, så skulle vi kunna göra det. Det betyder inte att vi alltid gör en leverans till användarna efter varje sprint. Ibland väntar vi med leveransen av affärsmässiga skäl. Några sådana skäl kan vara att:
  • Vi vill invänta mer funktionalitet för att produkten ska bli mer komplett
  • Vi inte vill tynga användarna med att lära sig ny funktionalitet för ofta
  • Vi vill synkronisera leveransen med marknadsaktiviteter
I praktiken är det oerhört utmanade att utveckla potentiellt leverbar produkt i varje sprint. Att vara klar i Scrum är kräver ett dubbelt fokus: dels behöver vi samsyn om hur slutmålet ser ut, dels behöver vi samsyn kring hur utvecklingsarbetet ska genomföras. Med andra ord: vi behöver både tydliga krav och en gemensam utvecklingsprocess.

Oklart arbete: kraven
När det är svårt för utvecklingsteamet att verkligen bli klara med något i sprinten kan det tyda på att vi lyfter in krav som inte är redo. I Scrum är ett krav redo när utvecklingsteamet tillsammans med produktägaren bedömer att kravet är möjligt att realisera i sprinten. Det betyder att när vi har ett stort och otydligt projekt att genomföra, så behöver vi bryta ut en liten väl definierad bit och utveckla den i sprinten. Idealet är att varje sprint slutar med att vi demonstrerar faktiskt användbar produkt, något som användaren inte kan vänta på att få lägga vantarna på.

Ett effektivt sätt att bedöma om vi har samma förväntningar på slutresultatet är att fantisera om att vi redan sitter på sprintgenomgången och får en demo av den planerade funktionaliteten. Vi berättar helt enkelt för varandra vad vi tänker oss att vi ser på demonstrationen. De detaljer som kommer upp ser vi till att fånga upp skriftligen (gärna på en whiteboard så att alla kan se). Sedan diskuterar vi tills vi är överens om vad som ska ingå i sprinten, och vad som inte ska ingå.

Oklart arbete: utvecklingsprocessen
En annan stor anledningen till att vi inte blir klara med funktionalitet vi lyfter in i sprinten är att vår utvecklingsprocess ännu inte räcker för att ta oss hela vägen från krav till potentiellt levererbar produkt under en sprint. För att lyckas med detta krävs solida utvecklarpraxis, till exempel:
  • Förmågan att skapa och upprätthålla en design på kodnivå som går att jobba vidare med, utan att vara överdrivet generaliserad
  • Att kunna testa med en kombination av mänsklig och automatiserad testning för att säkerställa att ny funktionalitet fungerar som den ska, samtidigt som vi har koll på att sådant som brukade fungerar inte har gått sönder nu
  • En effektiv bygg- och leveransprocess som är automatiserad så långt som möjligt
  • Fortlöpande integration och testning av hela produkten
  • Gemensamt ansvar för den tekniska kvaliteten, så att vi inte får ”fickor” av hög eller låg kvalitet i produkten baserat på vem i utvecklingsteamet som jobbat med en viss funktion
Framgång med Scrum kräver att vi satsar på att snabbt utveckla såväl vår förmåga att arbeta effektivt med kraven, som vår förmåga att effektivt gå hela vägen från krav till potentiellt levererbar, klar, produkt under sprinten.