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

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…