[Detta är ett utdrag av ett sk blixt-tal jag höll på Lean Tribe Gathering 11 i Malmö, den 20 november, 2012. Video finns här. ]
I år har jag har upplevt Scrum på två väldigt olika sätt. Jag har varit produktägare i en mycket stort företag (10,000+) och kämpat uppför i vattenfall. Och så har jag infört Scrum på ett mycket litet företag (<10).
Jag tänkte dela med mig av saker som har hänt, och berätta hur vi gjorde i de situationerna.
Jag menar inte att det vi gjorde var det rätta sättet. Jag bara berättar att det var så här vi gjorde, och det blev bättre än innan.
Tvär-funktionella team & Vattenfalls-projekt
Den första handlar om tvär-funktionella team.
Alla som försökt köra Scrum i en stor organisation har många problem att del men dig av. Det jag upplevt som allra störst är detta.
Tvär-funktionella team är ju en kritisk del av Scrum. Problemet är att i ett vattenfalls-projekt är tanken att varje enskild funktion aktiveras under endast en specifik del, som på ett löpande band.
Så t ex från vecka 1 till 10 kanske Design görs under 3 till 4. De andra veckorna är alla designers upptagna i andra projekt. Det är utifrån detta projektledare och mellanchefer planerar allt arbete.
Problemet är att ett Scrum-team vill kunna leverera potentiellt släpp-bara produkter redan från vecka 1 och till vecka 10. Det är kärnan i iterativ utveckling.
Ofta är det personer med någon slags specialkompetens. T ex testare, designers eller översättare.
Ett tydligt symptom på detta problem är när vissa team-deltagare plötsligt försvinner. Detta skapar förstås problem om man just planerat en sprint och gjort uppskattningar.
Ett vanligt förslag i ett detta skede är att dela upp storyn på ett, på pappret logiskt sätt: det vi kan göra och det vi inte kan göra. Förslaget är att göra det vi kan nu och göra resten sedan. T ex om en grafisk designer saknas kan vi bygga allt utom just den grafiska designen, dvs utseendet. Jag har också hört förslaget, då testare saknades, att vi utvecklar i denna sprint och testar i nästa…
Varje gång jag gått med på att göra så här har det slutat dåligt.
Man ska inte bryta mot den grundläggande principen att leverera potentiellt släpp-bara funktioner. Funktioner som inte har något UI, fast de borde ha det, eller som har fel UI, ska man inte bygga. När man väl gör designen, kommer man även på att funktionen ska vara annorlunda.
Det icke så konstruktiva, men egentligen korrekta, sättet att agera är förstås att teamet inte åtar sig att utföra arbeten de inte kan slutföra (eftersom de saknar kritiska funktioner).
Det något mer konstruktiva sättet är att underlätta för de olika resurs-ägarna, mellancheferna, i deras planering genom att tydligt märka upp vilka stories i backloggen som kräver specialkompetens, som inte finns permanent i teamet. Typiskt t ex att markera alla ”UI stories”. De märkta story:sarna kan sedan fördelas till de resurs-ägare som en slags ”sub-backlogg”.
(Obs att detta inte alls är samma sak som att ha en backlogg-av-backlogg. Man har fortfarande bara en backlogg. Det är bara det att beroende vem som läser den, så har den olika innehåll: designerns ser design-stories, etc. )
Sprint-mål i ett litet företag
Kanske det allra roligaste med att jobba i ett litet företag är att alla verkligen gör allt. Ena dagen är man säljare. Dagen efter är man vaktmästare.
Att skapa tvär-funktionella team i ett litet företag är inget problem. Alla som är med sitter runtomkring och jobbar i samma team. Teamet == Företaget.
Men en utmaning som ett litet företag har, som tycker man behöver strukturera upp sin utveckling, är att komma ifrån att alla gör olika saker samtidigt.
När man försöker skriva ett tydligt sprint-mål, något alla ska jobba emot, är det svårt när alla jobbar med helt olika saker.
Två saker verkar fungera ganska bra.
- Enligt GTD, skilj tidigt på saker som kan utföras direkt på kort tid och sådant som kommer kräva tid och hårt arbete. Utse en person (kan rotera) som tar inkommande korta-saker, enligt KanBan, inte Scrum. Lägg allt annat i en stor backlogg.
- Kör ett Scrum-team som omfattar större delen av företaget. För att få fokus, prioritera allt som ska göras så att man gör en sak per sprint. Det är bättre att ha sju man på en sak i två veckor, än sju man på sju saker som aldrig blir klara.
Sprint-genomgång för 100+ personer
Man kan tro att i ett stort företag med många möten, att det skulle vara enkelt att få många deltagare till sprint-genomgångar. Det är det ofta. Problemet är att det är inte ovanligt att man kommer upp i 20-30 mellanchefer, ett tiotal vice-presidenter och ytterligare andra personer som kan, enligt Scrum, identifieras som ”stakeholders” även om deras intresse mest är att bevaka vad som sker.
Eftersom, i mitt fall, var dessutom organisationen utspridd på två kontinenter med tidsskillnad, var det omöjligt att hitta tider alla kunde.
Med hjälp av mobiltelefoner och enkla video-kameror började vi ta som vana att spela in varje enskild story-demo. Inte hela sprint-genomgången, det skulle ingen orka se.
Filmerna skickade vi ut via e-post och interna wiki-sidor.
Förutom den uppenbara fördelen att alla kunde se enskilda storys, blev det också en bra berättelse om hur produkten utvecklats från första sprinten till sista; från skakiga enkla funktioner till de mest avancerade på slutet.
Tack för ni lyssnade.
Peter
The post Scrum i små/stora företag appeared first on PETER STARK OM AGIL PRODUKTUTVECKLING.