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.
Inlägg
