Fortsätt till huvudinnehåll

Alla måste inte kunna allt

"Tvärfunktionella team låter så bra, men i vårt företag är det inte så enkelt. I Scrums utvecklingsteam förväntas ju alla kunna göra allt, men våra utvecklare är inte vana testare, och våra testare kan inte programmera. Hur ska vi kunna använda Scrum?"

Idéen om tvärfunktionella team kan vara provocerande. Personer från helt olika discipliner ska plötsligt arbeta tillsammans på daglig basis för att bygga en produkt av hög kvalitet. Få av oss har förstås varit helt skyddade från kontakter med personer från andra specialiteter, men oftast kanske kontakten har skett vid mer eller mindre formella "överlämningstillfällen". Fasbaserade utvecklingsmodeller går ju ut på att varje funktion i företaget gör sin del så noggrant som möjligt, för att vid en given tidpunkt kunna lämna över sitt arbetsresultat till nästa funktion i företaget, ungefär som de tävlande i ett stafettlopp springer var sin sträcka så fort som möjligt, och gör en tydlig överlämning till näste löpare.

I Scrum springer vi inte stafett, vi spelar rugby. Vi arbetar med små team som bygger kompletta inkrement av högkvalitativ produkt, i (typiskt) månadslånga iterationer. För att varje iterations arbete ska kunna resultera i produkt av tillräckligt hög kvalitet vill vi ha ett team som innehåller all den kompetens som behövs för att bygga klar produkt. I mjukvaruutveckling betyder det att vi vill ha testare, programmare, domänexperter, och ofta andra typer av specialister, med i teamet. Detta kallar vi ett tvärfunktionellt team, eftersom personerna ofta kommer från olika funktioner, eller avdelningar, inom ett företag.

Vi brukar säga att medlemmarna i ett scrumteam inte har några roller. Det har de förstås, om inte kring specialiteter så kring vem som leder gruppen vid vilket tillfälle, vem som är gruppens talman och vem som är den tystlåtne strategen, och så vidare. Men, det vi som lär ut Scrum menar med att scrumteam inte har några roller är att vi lägger större tonvikt på att teamet fungerar som helhet än på att upprätthålla gränserna mellan traditionella specialistroller. I varje väl fungerande team hjälper nämligen medlemmarna varandra att uppnå teamets mål, även om det betyder att man får sträcka sig utanför sitt specialistområde eller sin personliga komfortzon för en stund. En för alla, alla för en.

När man går in i ett scrumteam tar man alltså av sig experthatten, och sätter på sig teamhatten. Det betyder emellertid inte att alla i teamet ska kunna göra allting lika bra. Produktutveckling är komplicerat arbete, och vi behöver specialister för att lyckas - men vi behöver specialister som kan samarbeta.

Visst vore det underbart om "alla kunde göra allt", men tills den drömmen blir sann är det samarbetsförmåga som är den viktigare nyckelkompetensen för medlemmar i ett Scrumteam.

Kommentarer

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

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

Introduktion till story points

Estimering med storlekspoäng är en sån där sak som somliga älskar och andra tycker är totalt förvirrande. Jag gillar det lugna sköna tempot i den här korta snutten om story points från Rally Software.

Hur lång ska en sprint vara?

Jag fick en fråga på mailen som löd: "Fick frågan av min chef varför vi har 3 veckors sprintlängd. Vet inte riktigt vad jag ska svara, det bara blev så. Vad säger du?" En sprint i scrum är en synonym för iteration. Det som utmärker scrums sprintar är att vi vill att de ska vara väldigt fokuserade och att de ska sluta i klar, potentiellt levererbar, produkt. Potentiellt levererbar betyder att om vi ville  så kunde vi skeppa ut produkten med ganska lite efterarbete. Tydlig och regelbunden feedback krävs för att styra utvecklingsarbete. Längre sprintar betyder att det blir längre tid mellan större avstämningar av nuläget, vilket ökar risken att vi drar iväg i fel riktning, eller att omvärlden ändrar sig så mycket under sprinten att det vi bygger hinner bli irrelevant. Ibland kan det kännas som om man lägger för mycket tid på planerings- och uppföljningsworkshops, vilket leder till idén att göra sprintarna längre. Jag vill hellre börja med att undersöka om arbetsmötena k