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

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…