Fortsätt till huvudinnehåll

Böter för sen ankomst = kontraproduktivt

Staffan Nöteberg, konsult och författare till Pomodoro Technique Illustrated, påpekar på sin blogg att det är kontraproduktivt att införa en "böter" för sen ankomst till det dagliga Scrum-mötet. Själv har jag aldrig använt mig av någon sådan böter, eftersom jag tycker det skulle vara nedlåtande. Jag skulle själv aldrig acceptera att betala något dylikt. Däremot accepterar jag att ta ansvar för och förklara min sena ankomst.

Staffan har en mer vetenskaplig motivation till varför det inte är någon bra idé att ta ut böter: den inre motivatorn att komma i tid för att det är rätt sak att göra trängs ut av den externa motivatorn, att undvika böter.

Jag har hört (kanske från Staffan?) om liknande försök att införa böter för sen lämning på dagis. Resultatet? Föräldrar inser att det bara kostar några tior att lämna barnet lite sent, vilket visar sig vara ett pris man är mer än villig att betala.

Läs Staffans blogg här.

Kommentarer

Gabriel sa…
Vi hade problem med sen ankomst och i allmänhet en lite för slapp hållning till när Scrum-mötena hölls. Lösningen blev en överenskommelse att man ska höra av sig om man uteblir eller är försenad. Glömde man det fick man en dödskalle ritad bredvid sitt namn på en av tavlorna.

Det fungerade perfekt. Vi behövde bara dela ut en handfull dödskallar innan allt började fungera som vi ville. Numera kommer alla i tid och när man inte gör det så hör man av sig!
Tobias Fors sa…
Tjena Gabriel! Tack för minifallstudien. Sättet ni löste problemet på har två avgörande komponenter: dels en uttalad och gemensam överenskommelse om en konkret ändring av ett beteende, dels en tydlig påminnelse när överenskommelsen bryts. Att rita en dödskalle känns lite brutalt, men jag gissar att det är helt OK i ert fall, eftersom ni tillsammans kommit överens om det, med glimten i ögat.

När jag handleder workshops, särskilt med grupper som inte arbetat mycket tillsammans tidigare, använder jag dessa två komponenter för att bygga upp en överenskommelse om beteenden i workshopen. Jag sätter upp ett tomt blädderblocksark på väggen, och skriver rubriken "Överenskommelser" på det. Sen ritar jag en första punkt i en blivande lista och skriver upp ett första förslag på överenskommelse, något okontroversiellt. Ofta blir det "inte ta mobilsamtal under workshopen".

Med punkten på väggen frågar jag gruppen om vi är överens om denna punkt. Det är vi sällan, så jag fortsätter med att fråga hur punkten måste formuleras om för att vi ska bli överens. Kanske lägger vi då till att man får svara i telefon om man väntar på samtal kring något kritiskt. Jag skriver upp den modifierade överenskommelsen, och frågar på nytt om acceptans.

Nästa punkt ber jag gruppen föreslå, och jag skriver upp den. Sen går vi igenom samma konsensusprocess tills dess att vi har en lista med grundläggande överenskommelser som är mycket konkreta och förhoppningsvis förstådda av samtliga.

Som en avslutning på detta frågar jag gruppen om jag har deras tillstånd att påminna deltagare som bryter mot överenskommelserna. Det får jag, eftersom det är ovanligt att någon _inte_ vill att workshopen ska vara effektiv.

Efter det frågar jag deltagarna om de ger varandra tillstånd att påminna om överenskommelserna. Detta är en viktig påminnelse om att jag inte är ensam ansvarig för att workshopen ska bli effektiv.

Med den här metoden har jag sett grupper som tidigare varit nästan oförmögna att arbeta tillsammans skapa en ny möteskultur som är lyssnande och produktiv.

En av grunderna till effektiva team är tydliga överenskommelser om hur arbetet ska bedrivas, både vad gäller att komma i tid och att bete sig på rätt sätt när man arbetar tillsammans.
Anonym sa…
Dan Pink omtalade exemplet med kontraproduktiva böter för daghemsförseningar i Drive.
Tobias Fors sa…
Perfekt, då vet vi var det kom ifrån! Har inte läst boken själv än, men har den på läslistan.

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…