Fortsätt till huvudinnehåll

Skapa ett teamrum

Jag var scrum master för ett litet team som bestod av ett par utvecklare och en testare. Utvecklarna satt sedan länge bredvid varandra i samma rum, men vår testare satt i ett annat rum med flera andra testare från andra projekt. Jag förklarade för vår testare att jag gärna skulle se att hon flyttade in i samma rum som oss andra. Jag förklarade också att jag absolut inte tänkte tvinga henne, men att jag verkligen trodde att det skulle gynna både henne och teamet. Efter en tids tvekan rullade hon över sin stol och dator till oss andra. När vi några månader senare under ett retrospektiv utvärderade hur olika viktiga faktorer utvecklats kom vi in på frågan om teamsamarbete. Utvecklarna indikerade att situationen förändrats svagt till det positiva sedan jag kom in i projektet. Vår testare gav däremot utvecklingen högsta betyg. Jag frågade vad det berodde på. Hon sa att det framför allt berodde på att hon nu satt tillsammans med utvecklarna. Äntligen, sa hon, kände hon sig riktigt delaktig i utvecklingsarbetet.

Den placering som först användes var att ha utvecklarna på ett ställe och testarna på ett annat. En sån placering återspeglar den organisation som fanns i företaget: funktionellt uppdelad med grupper för utvecklare respektive testare. Det föll sig helt naturligt att sitta var och en på sitt hörn, för att kunna samordna arbetet inom specialistgrupperna.

Scrum kan användas i funktionella organisationer, men bygger på tvärfunktionella team. Dessa team som sätts ihop av specialister från olika funktioner inom företaget, till exempel marknad, R&D och QA. Resultatet blir team som innehåller all kompetens som behövs för att bygga klar produkt varje sprint.

När man jobbar i ett tvärfunktionellt team är ens dagliga samarbetspartners inte bara experter från den egna disciplinen, utan alla de andra teammedlemmarna som kallats in från olika områden. Målet är en frekvent och effektiv kommunikation över expertgränserna, så att vi snabbt kan nå verkliga resultat.

Tvärfunktionella team kan drabbas av en hel del konflikter, vilket är helt naturligt. En orsak är att medlemmarna har helt olika bakgrund och helt olika syn på de problem man brottas med. Innan teamet lärt sig uppskatta och utnyttja dessa skillnader tar de sig uttryck som konflikter.

Om vi vill snabba upp teamets utveckling mot att bli högpresterande är teamrum ett attraktivt alternativ. Att sitta på samma plats är ingen garanti för att man pratar med varandra, men det ökar åtminstone sannolikheten, och att prata med varandra ofta är en förutsättning för att snabbt reda ut konflikter.

Många har dåliga erfarenheter av att sitta i öppna kontorslandskap. Att försöka samlokalisera team behöver inte handla om kontorslandskap. Ett eget teamrum ger teamet möjligheten att jobba tillsammans, samtidigt som man slipper det störande i att sitta i stora öppna landskap. Om kontorslandskap är det bästa som går att få kan man ändå förbättra situationen genom att avgränsa en teamyta med hjälp av skiljeväggar och växter.

Somliga har dåliga erfarenheter av att inte ha sitt eget kontorsrum. Min erfarenhet är att det är mest störande att sitta tillsammans med personer som tillhör andra team. Om man å andra sidan sitter tillsammans med personer i det egna teamet kan man vara säker på att de samtal som uppstår handlar om saker man är intresserad av.

Även om man har ett teamrum kan för mycket prat och avbrott bli kontraproduktivt. Vem som helst kan därför ta initiativ till att sammanställa teamets gemensamma regler för att man ska kunna arbeta effektivt. Syftet med att sitta i samma rum är ju att underlätta kommunikationen, men det måste också finnas en möjlighet att jobba fokuserat ensam.

Väggarna i ett teamrum ska vara användbara. Det betyder minst en eller två whiteboards i rummet, och möjlighet att klistra upp stora blädderblocksark på övriga väggar. Allra minst vill jag ha upp sprintbackloggen, alltså planen för den innevarande iterationen, på väggen. Där vill jag kunna se vilka uppgifter som valts ut från produktbackloggen, och hur de brytits ned i aktiviteter. Jag vill också kunna se vem som jobbar med vad, hur mycket tid som återstår, och en klarkurva (burndown chart).

På väggen vill jag också ha upp aktuella hinder, vilka som ingår i teamet och deras kontaktinformation, tidplaner från resten av organisationen och annat som är viktigt för teamets arbete. Ingen ska behöva leta efter väsentlig information.

På dörren till teamets rum vill jag kunna läsa vilket team som finns i rummet: vad teamet kallar sig och vad man jobbar med. Det kan verka uppenbart för de som deltar i teamet men, särskilt i större organisationer, är det otroligt givande för andra som råkar gå förbi att snabbt kunna se vilka som finns i rummet och vad de gör. Att posta en liten affisch på dörren är ett enkelt sätt för teamet att marknadsföra sig.

Somliga väljer att införa teamrum genom att göra ett kontorsrum tillgängligt för teamet, som teammedlemmarna kan använda om de vill. Alla behåller sina individuella platser, men om man vill sitta tillsammans kan man göra det i teamrummet.

När jag berättar om tanken om teamrum blir somliga provocerade. Så mycket lediga lokaler har man minsann inte på sitt kontor. Så kanske det är, men är inte kostnaden för mer ändamålsenliga lokaler försvarlig om det ökar chansen att projektet lyckas?

De flesta skulle säga att det är värt att satsa på bra lokaler, men sen är det kanske ändå en lokalchef som bestämmer hur det blir i slutänden. Att låta en så viktig framgångsfaktor som teammedlemmarnas lokaler avgöras av någon som inte har ansvar för projektets framgång är en suboptimering som finns i alltför många företag. Som scrum master är ditt jobb att verka för att även lokalerna blir en faktor som hanteras på ett medvetet sätt i era utvecklingsprojekt.

Kommentarer

Anna Forss sa…
håller med om att detta är en viktig fråga, och att man här inte glömmer produktägaren. Som produktägare sitter jag inte i "utvecklarnas" (och där räknar jag in test) rum men jag har sett till att ha en plats där. Detta för att signalera att jag också är en del av teamet. Så nu växlar jag plats och sitter ibland i verksamheten, ibland bland utvecklarna.

Som gammal testare kan jag bara hålla med om att de inte ska sitta i ett eget rum.
Tobias Fors sa…
Hej Anna! Tack för denna påminnelse!

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