Fortsätt till huvudinnehåll

Återblickslöshet får Scrum att stanna

Jag höll en tvådagars Certifierad Scrum Master-kurs åt ett större svenskt tjänsteföretag. Flera i gruppen var särskilt intresserade av större projekt, eftersom man jobbade tillsammans i ett sådant, och inte verkade helt nöjda med hur det gick. Jag berättade så gott jag kunde om mina erfarenheter av att använda Scrum för samordning av arbete i flera team och med flera samtidiga produkter, men jag märkte att mina svar inte var särskilt tillfredsställande.

För att få mer information om vad som egentligen eftersöktes vände jag på steken, och kastade ut en motfråga: vad pratade ni om på återblicken i er senaste sprint?

Svaret blev undvikande. Man hade inte haft någon återblick i den senaste sprinten. Jag modifierade frågan en smula: vad brukar ni prata om på era återblickar?

Nu blev svaret nästan lite skamset. Man hade aldrig haft en återblick i projektet. Definitivt inget de borde skämmas för, men lika säkert något de skulle kunna dra mycket nytta av att ändra på.

Scrum är inte bara ett arbetssätt, det är också ett ställningstagande. Med Scrum tar vi ställning för åsikten att den kompetens som behövs för att lösa våra organisationers problem finns ute i organisationen, hos alla oss som tillsammans gör jobbet, och vår gemensamma uppgift är att dra så mycket nytta av vår kollektiva kunskap som vi bara kan. Scrum är utformat för ge återkommande möjligheter att stanna upp, försöka förstå problem och formulera lösningar till dem.

Scrum Master, produktägare, team och andra kan förstås eliminera problem när som helst, men det extra stöd Scrum ger oss är återblicken. Återblicken är ett fokuserat moment i arbetet som återkommer sist i varje sprint. Under återblicken tittar vi tillbaks på arbetet, försöker förstå vad som hänt, och beslutar om justeringar framåt, så att vi ska bli mer effektiva och mer nöjda nästa sprint. Genom att göra återblicken till en inbyggd del i arbetsrutinen vill minska risken att vi hoppar över den. Det ska vara naturligt att stanna upp en stund i slutet av varje sprint och granska såväl produkt som utvecklingsprocess, och planera förbättringar av båda.

Återblicken är för Scrum vad bensin är för en bil: nödvändig för framfarten.

Att ta bort återblickarna ur Scrum och sedan undra varför man inte lyckas lösa sina problem visar på ett tydligt problem som måste lösas före alla andra: först måste förståelsen för Scrum som lärandemetod finnas. Innan den finns kommer vi att fortsätta leta efter färdigpaketerade lösningar till våra unika problem istället för att utnyttja idéerna som redan finns i vår egen organisation.

Kommentarer

Per Lundhom sa…
Hej! Såg din kommentar i min blogg. Jag tänkte väl att du var felciterad. Men som vi båda och många andra säger, skippa inte återblicken för då blir det aldrig bättre. JO, man kan vinna på Lotto, i o f s. Men oftast inte. :-)
Tobias Fors sa…
Hej Per! Tack för besöket på bloggen! Låt oss båda blogga mer om återblickar!

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