Fortsätt till huvudinnehåll

Återblickens grundregel

En av de svåraste utmaningarna i tider av förändring är att effektiv förändring kräver trygghet. Precis när allt är som osäkrast behöver vi göra som mest för att skapa en situation där alla i organisationen vågar bidra med sina idéer om hur verksamheten kan utvecklas. En artikel i DN om hur anställda på SJ inte vågar kritisera brister, och en om en lokförare som blev uppsagd, fick mig att reflektera över detta.

Oavsett vad som hänt i just detta fall, är det ett faktum att när ledningen bestraffar kritik, så försvinner kritiken ur organisationen. Det kan kännas aldrig så skönt för ledningen, men hur jobbig den än är, så är kritik information om organisationen. Till och med kritik som i sak är helt irrelevant är användbar: den kan till exempel få oss att fundera på varför vi har medarbetare som ger osaklig kritik. Medarbetare som mår bra och trivs ägnar sig inte åt att sprida osaklig kritik. Varför har vi medarbetare som inte mår bra och inte trivs, är frågan som en kompetent ledning då frågar sig.

För den som leder en organisation finns ett problem som glöms bort ibland. Det är väldigt svårt för en högt uppsatt chef att få information om vad som verkligen händer i verksamheten. Självklart får man sina rapporter, sin statistik och sina briefings från den närmast underlydande, men förståelsen för verksamheten och vad som verkligen händer lyser ofta med sin frånvaro. Inte så konstigt egentligen: få vill riskera sin karriär genom att leverera aldrig så viktiga data till en chef som ända bara skjuter ned budbäraren.

I Scrum använder vi, bland annat, genomgångar och återblickar för att samla in data och information om vad som faktiskt händer i verksamheten. Nyckeln till en lyckad återblick stavas trygghet. Grundregeln i retrospektiv är den här:

"Alla gjorde sitt bästa givet förutsättningarna"
En återblick handlar aldrig om att hitta skyldiga, och alltid om att förstå och förändra. Förståelse föregår förändring, och förståelse kan bara uppstå i en situation där alla inblandade på ett tryggt sätt kan förena sina skilda perspektiv till en gemensam bild av vad som verkligen hände och vad som verkligen behöver göras.

Jag brukar rekommendera att varje team som genomför en återblick avslutar den genom att ta två beslut om saker man själva, inom teamet, kan bestämma sig för och genomföra. Jag rekommenderar också att man ger exakt en rekommendation till den omgivande organisationen kring något som, om det gjordes, skulle göra att teamet kunde göra ett ännu bättre jobb. Rekommendationen går vidare till ledningen ovanför teamet, besluten genomförs autonomt av teamet.

Alltså: 2 beslut + 1 rekommendation.

Sitter du i en ledande position? Får du verkligen den information du behöver om verksamheten? Hur vet du det? Vad gör du för att försäkra dig om att du inte bara inbillar dig att du vet vad som verkligen händer?

Kommentarer

Unknown sa…
Instämmer i att trygghet är grundläggande. Jag har använt liknande formuleringar som din när jag inleder retrospektiver (brukar skriva upp dem på tavlan). Brukar dessutom förstärka det genom att påpeka att "det vore larvigt att anta något annat, vi är alla vuxna, professionella". Min projekt-kollega Jim Svensson formulerade det som att det "är en fråga om att visa respekt", vilket jag tycker också är en rimlig vändning.

Har länkat hit från min beskrivning av Blitz-Retro.
Tobias Fors sa…
Hej Dan! Tack för kommentaren. Jag önskar att det vore så enkelt som att vara vuxna och professionella. Jag kommer att tänka på Jerry Weinbergs utförliga artikel om hur även vuxna proffs kan ägna sig åt motsatsen till trygghetsskapande: anklagande. Mycket läsvärd: http://www.ayeconference.com/beyondblaming/

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