Fortsätt till huvudinnehåll

Sega möten: ett tecken på djupare problem

Som en kommentar till det jag skrev om motstånd mot dagliga morgonmöten i "Pragmatisk eller dogmatisk? Progmatisk!", skriver Magnus Ljadas:
"En anledning till motstånd till morgonmöten, enligt min erfarenhet, kan vara att arbetet i projektet bedrivs väldigt specialiserat. Jag gör bara sånt som har med utskrifter att göra; du sysslar bara med webbformulär; och ingen av oss rör någonsin nånting som har med databasen att göra, för det är Staffans baby. Vi har liksom väldigt få naturliga beröringspunkter.

Stor fråga kanske, men hur tar man sig ur/bryter en sån situation?"
Verkligen en stor fråga, men vi prövar ett sätt att närma sig den.

En bra teknik är att utgå från att människor vars beteende man inte håller med om eller förstår sig på faktiskt beter sig så rationellt som möjligt, men självklart med utgångspunkt från deras egna aktuella modeller av hur verkligheten fungerar.

Tänker man så kan man i det här fallet fråga sig vilken modell av verkligheten man behöver ha för att tycka att det mest rationella är att dela upp arbetet så strikt mellan sig som personerna i gruppen Magnus beskriver gör?

Kanske tänker de att något eller några av följande argument är sanna.

a) Om man delar upp arbetet i strikta delar, med tydliga ansvarsområden, får man möjlighet att specialisera sig i en modul eller teknik, och då blir det lättare att verkligen lära sig den på djupet.

b) Man undviker konflikter när man råkar göra mindre bra ändringar i varandras kod och dokument, eftersom man bara gör ändringar i sina egna grejor.

c) Man vet vem man ska gå till när något går fel i en viss del.

d) Man slipper kommunicera med varandra hela tiden, så man kan jobba fokuserat på sina saker lättare.

e) En karriär byggs bäst på ett smalt expertområde. Att dela med sig av sin kunskap är att minska sina möjigheter att bli expert, och därmed att göra karriär.

f) Om man gör sin del som man ska har man gjort ett bra jobb och kan vara nöjd med sin insats.

För att gruppen ska vilja jobba mer tajt tillsammans behöver de byta ut sin nuvarande mentala modell av vad som är rationellt mot en alternativ modell.

En alternativ modell av verkligheten skulle kunna se ut så här.

a) Det är bra att ha mer eller mindre inblick i alla delar av systemet, så att man kan samarbeta lättare i teamet, och kanske till och med hoppa in och göra ändringar i fler delar än bara en enda som man specialiserat sig på. Det minskar risken vid till exempel sjukdom och ledighet, och är särskilt skönt när man själv är den som vill vara ledig.

b) Man undviker konflikter bättre om man är överens om att man har gemensamt ansvar för hela produktens kvalitet. Det är allas fel om det finns en defekt i systemet.

c) Det går snabbt att lösa problem om mer än en person behärskar en given del av produkten.

d) Man kommunicerar effektivare med varandra när man har bättre inblick i fler delar av systemet, eftersom det blir färre missförstånd.

e) En karriär byggs bäst på att ha deltagit i team som levererat lysande resultat, och på de relationer med nya personer i och utanför teamet som man därmed byggt upp.

f) Om man bygger en bra produkt tillsammans, som kunden och användarna gillar, då har man gjort ett bra jobb och kan känna sig nöjd.

En grupp som betraktar världen genom den alternativa modellen kommer att välja att jobba nära varandra. För den gruppen kommer morgonmöten att kännas användbara, eller, om de är verkligt effektiva, kanske till och med lite överflödiga.

Vad kan få en individ eller grupp att byta ut vad man tycker är en fungerande modell mot en helt ny?

Tja, en anledning kan vara att man en dag förväntas arbete i ett team som medvetet satts samman för att vara tvärfunktionellt, med uppdraget att bygga värdefull, testad och dokumenterad mjukvara var trettionde dag. Scrum sätter på detta sätt upp ramar som ska stötta teamet att själva upptäcka värdet av nära samarbete. Ibland händer det som av sig självt, ibland inte, därav Scrum Masterns ansvar att hjälpa andra förstå och lyckas med Scrum.

Kommentarer

Anonym sa…
Det vore intressant att läsa lite tips på hur man når dit. Om man nu är en grupp där man är lite för specialiserade. Vad gör man för att sprida kunskaperna på ett bra sätt?
Tobias Fors sa…
Hej anonym! Tack för besöket och följdfrågan. Se min senaste post för några konkreta tekniker.
Hej,
man skulle kunna tänka sig en ytterliggare post i den första listan:
g) Om inte alla har sina egna uppgifter riskerar vi att inte alla har full beläggning och därmed att vi inte jobbar med full kapacitet
Tobias Fors sa…
Hej Anders! Ja just det - att hela tiden eftersträva full beläggning är många av oss alltför duktiga på. Tyvärr är ju inte full beläggning något bra sätt att maximera effektiviteten i arbetet. Alla är sysselsatta, men inget blir gjort, lite som när en motorväg är fullt belagd med bilar. Stau - som man säger på autobahn.

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