David Barnholdt

David Barnholdt

Improving productivity equals fun

Fysiska förutsättningar för effektivt teamsamarbete

På många arbetsplatser, för att inte säga de flesta, som jag har varit på så har de fysiska omständigheterna för effektivt team-samarbete varit undermåliga. Det vanliga är att man inte anpassar bordsplacering efter teamens behov utan efter estetiska principer och organisationens behov av flexibilitet med avseende på att kunna fördela ut skrivbord till nyanställda och konsulter.
Ovanpå detta är man ofta snål med datorer och whiteboards, vilket leder till att utvecklare allt för ofta sitter med sega maskiner och i avsaknad av bra ytor att rita och diskutera med. Resultatet är ofta ett enormt behov av konferensrum, för att komma bort från det kontorslandskap man sitter i, för att kunna prata i avskildhet. För det mesta finns det därför alltid alldeles för lite konferensrum. Ett problem som inte skulle existera om företagens team redan satt i bra “konferensrum”.

Enligt min mening håller fortfarande Kent Becks beskrivning av det ideala XP-rummet från eXtreme Programming boken.

De ställen där jag varit där det funnits rum enligt denna modell så har de team som kunnat sitta så ofta varit betydligt mer produktiva och haft roligare än de som suttit utspridda i kontorslandskap och med dålig placering i förhållande till varandra.

Så vad bör man ställa för krav på en vettig miljö för att få till effektivt team-samarbete? ;

Nedan bild visar ett bra XP-rum i mitt tycke.

Det ideala teamrummet
Det ideala teamrummet

Den uppfyller följande krav (utan någon ordning på viktighet även om placering av skrivborden är bland det allra viktigaste!);

  • Placering av skrivbord

Detta är kanske den enskilt viktigaste detaljen i den fysiska omgivningen för ett team för att få till effektivt team-samarbete. Skrivborden skall vara så placerade att det tar HÖGST 2-3 SEKUNDER för vilken team-medlem som helst att RULLA till vilken annan team-medlem som helst.
Detta är en förutsättning för att bra samarbete skall utvecklas mellan samtliga i teamet enligt min mening.
Detta innebär nästan alltid att det är bäst att sitta rygg mot rygg.

  • Avskildhet.

Teamet bör sitta hyfsat avskilda från resten av verksamhet så att de kan föra livliga och högljudda diskussioner om så önskas utan att störa omgivningen. De skall också kunna ha musik i bakgrunden om de vill, och helt enkelt själva kunna definiera vilken ljud och ljus miljö de vill ha för att de skall trivas och kunna vara effektiva.
Därmed inte sagt att de skall vara så avskilda att de är långt att nå resten av verksamheten, som lämpligtvis finns grannar med var de själva sitter, i samma korridor och våningsplan typ.

  • Whiteboards och Scrumboards

Teamet bör har tillgång till en stor whiteboard att ha sin Scrum eller Kanban board på. I tillägg till detta vill man ofta ha gärna 2 whiteboards till. En att ha skisser, domänmodeller och andra anteckningar som man vill ha synligt konstant, och en whiteboard för att stå och rita och prata vid.

  • Datorer och Skärmar

Numera är det tack och lov standard att ha 2 skärmar vid varje arbetsplats och jag har sett arbetsplatser för utvecklare där man haft 3 och till och med 4 vilket inte har varit till en nackdel.
Som utvecklare (och testare) är mycket skärmyta alltid en fördel.
Dessutom skall man självklart ha kraftfulla maskiner så att man slipper vänta på sin dator.
Bara att behöva vänta så mycket som 5 min per timme på sin dator blir snabbt kostnader som överstiger ev. investeringskosnad i ny hårdvara. Detta räknade vi på i ett företag jag satt och såg att kostnaden för nya datorer räknades hem på 2-3 månader.

  • Skrivbord och stolar

Skrivborden behöver sällan vara speciellt stora, men de skall väl rymma skärmar och tangentbord. En fördel är om de är utformade så att man kan sitta flera vid samma skärm, och därmed underlätta parprogrammering. Stolarna bör vara bekväma och lättrullade.
Min kollega Hans Brattberg kom med några utmärkta synpunkter kring skrivbord, han säger så här: “Stolar bör inte ha armstöd som gör att man hakar i varandra och som är i vägen när man vill sitta brevid varandra och parprogrammera. Dessutom är skrivbord som är skålade olämpliga, då hamnar en person för långt från skärmen när man försöker parprogrammera.” Han skickade med de 2 bilderna nedan, den ena visar tydligt vitsen med att ha ett skrivbord som åtminstone inte är skålat inåt för att möjliggöra parprogrammering.
Nästa bild visar en ritning på ett parprogrammerings skrivbord designat av de duktiga killarna på factor10.
Parprogrammeringsskrivbord
Parprogrammeringskrivbordet

  • Lek / Inspirationshörna

Om ett team har ett ställe med inspirerande leksaker, gärna passande för den uppgift de har (roliga mobiler för mobilutvecklare, videokameror för de som jobbar med videosystem osv), så skapar man förutsättningar för kreativitet och lekfullhet, vilket i förlängningen leder till högre produktivitet.

  • Frukt och dryck

Kunskapsarbete är rent fysiskt energikrävande.  Hjärnan är vår främsta muskel.  Genom att näring och vitaminjektioner ständigt tillgängliga kan vi utnyttja de 6-8 timmar vi spenderar på vår arbetsplats på bästa sätt.  På många arbetsplatser finns det ofta godis och kakor.  Det är dock bedrägligt, för även om de ger kortvariga energikickar så leder det också till att stora delar av personalen ofta är i sockerchock.  Vilket kan skapa dåligt humör när den klingar av och leder till dålig hälsa i förlängningen.

  • Test-miljöer, integrationsservrar mm

Allt detta hör ju också till den fysiska miljön för teamet, men är lite utanför scoopet på den här bloggposten. Men kort uttryckt tycker jag man kan säga att teamet skall ha tillgång till serverar på ett sådant sätt att de inte behöver trampa andra team på tårna eller vänta på något annat team när de vill integration och regressionstesta. Vill man vara effektiv behöver man kontinuerlig integration och därmed en server som kontinuerligt kan bygga och köra samtliga tester. Desto snabbare den är desto snabbare feedback till teamet och därmed högre produktivitet.

Fysiska förutsättningar för effektivt teamsamarbete

På många arbetsplatser, för att inte säga de flesta, som jag har varit på så har de fysiska omständigheterna för effektivt team-samarbete varit undermåliga. Det vanliga är att man inte anpassar bordsplacering efter teamens behov utan efter estetiska principer och organisationens behov av flexibilitet med avseende på att kunna fördela ut skrivbord till nyanställda och konsulter.
Ovanpå detta är man ofta snål med datorer och whiteboards, vilket leder till att utvecklare allt för ofta sitter med sega maskiner och i avsaknad av bra ytor att rita och diskutera med. Resultatet är ofta ett enormt behov av konferensrum, för att komma bort från det kontorslandskap man sitter i, för att kunna prata i avskildhet. För det mesta finns det därför alltid alldeles för lite konferensrum. Ett problem som inte skulle existera om företagens team redan satt i bra “konferensrum”.

Enligt min mening håller fortfarande Kent Becks beskrivning av det ideala XP-rummet från eXtreme Programming boken.

De ställen där jag varit där det funnits rum enligt denna modell så har de team som kunnat sitta så ofta varit betydligt mer produktiva och haft roligare än de som suttit utspridda i kontorslandskap och med dålig placering i förhållande till varandra.

Så vad bör man ställa för krav på en vettig miljö för att få till effektivt team-samarbete? ;

Nedan bild visar ett bra XP-rum i mitt tycke.

Det ideala teamrummet
Det ideala teamrummet

Den uppfyller följande krav (utan någon ordning på viktighet även om placering av skrivborden är bland det allra viktigaste!);

  • Placering av skrivbord

Detta är kanske den enskilt viktigaste detaljen i den fysiska omgivningen för ett team för att få till effektivt team-samarbete. Skrivborden skall vara så placerade att det tar HÖGST 2-3 SEKUNDER för vilken team-medlem som helst att RULLA till vilken annan team-medlem som helst.
Detta är en förutsättning för att bra samarbete skall utvecklas mellan samtliga i teamet enligt min mening.
Detta innebär nästan alltid att det är bäst att sitta rygg mot rygg.

  • Avskildhet.

Teamet bör sitta hyfsat avskilda från resten av verksamhet så att de kan föra livliga och högljudda diskussioner om så önskas utan att störa omgivningen. De skall också kunna ha musik i bakgrunden om de vill, och helt enkelt själva kunna definiera vilken ljud och ljus miljö de vill ha för att de skall trivas och kunna vara effektiva.
Därmed inte sagt att de skall vara så avskilda att de är långt att nå resten av verksamheten, som lämpligtvis finns grannar med var de själva sitter, i samma korridor och våningsplan typ.

  • Whiteboards och Scrumboards

Teamet bör har tillgång till en stor whiteboard att ha sin Scrum eller Kanban board på. I tillägg till detta vill man ofta ha gärna 2 whiteboards till. En att ha skisser, domänmodeller och andra anteckningar som man vill ha synligt konstant, och en whiteboard för att stå och rita och prata vid.

  • Datorer och Skärmar

Numera är det tack och lov standard att ha 2 skärmar vid varje arbetsplats och jag har sett arbetsplatser för utvecklare där man haft 3 och till och med 4 vilket inte har varit till en nackdel.
Som utvecklare (och testare) är mycket skärmyta alltid en fördel.
Dessutom skall man självklart ha kraftfulla maskiner så att man slipper vänta på sin dator.
Bara att behöva vänta så mycket som 5 min per timme på sin dator blir snabbt kostnader som överstiger ev. investeringskosnad i ny hårdvara. Detta räknade vi på i ett företag jag satt och såg att kostnaden för nya datorer räknades hem på 2-3 månader.

  • Skrivbord och stolar

Skrivborden behöver sällan vara speciellt stora, men de skall väl rymma skärmar och tangentbord. En fördel är om de är utformade så att man kan sitta flera vid samma skärm, och därmed underlätta parprogrammering. Stolarna bör vara bekväma och lättrullade.
Min kollega Hans Brattberg kom med några utmärkta synpunkter kring skrivbord, han säger så här: “Stolar bör inte ha armstöd som gör att man hakar i varandra och som är i vägen när man vill sitta brevid varandra och parprogrammera. Dessutom är skrivbord som är skålade olämpliga, då hamnar en person för långt från skärmen när man försöker parprogrammera.” Han skickade med de 2 bilderna nedan, den ena visar tydligt vitsen med att ha ett skrivbord som åtminstone inte är skålat inåt för att möjliggöra parprogrammering.
Nästa bild visar en ritning på ett parprogrammerings skrivbord designat av de duktiga killarna på factor10.
Parprogrammeringsskrivbord
Parprogrammeringskrivbordet

  • Lek / Inspirationshörna

Om ett team har ett ställe med inspirerande leksaker, gärna passande för den uppgift de har (roliga mobiler för mobilutvecklare, videokameror för de som jobbar med videosystem osv), så skapar man förutsättningar för kreativitet och lekfullhet, vilket i förlängningen leder till högre produktivitet.

  • Frukt och dryck

Kunskapsarbete är rent fysiskt energikrävande.  Hjärnan är vår främsta muskel.  Genom att näring och vitaminjektioner ständigt tillgängliga kan vi utnyttja de 6-8 timmar vi spenderar på vår arbetsplats på bästa sätt.  På många arbetsplatser finns det ofta godis och kakor.  Det är dock bedrägligt, för även om de ger kortvariga energikickar så leder det också till att stora delar av personalen ofta är i sockerchock.  Vilket kan skapa dåligt humör när den klingar av och leder till dålig hälsa i förlängningen.

  • Test-miljöer, integrationsservrar mm

Allt detta hör ju också till den fysiska miljön för teamet, men är lite utanför scoopet på den här bloggposten. Men kort uttryckt tycker jag man kan säga att teamet skall ha tillgång till serverar på ett sådant sätt att de inte behöver trampa andra team på tårna eller vänta på något annat team när de vill integration och regressionstesta. Vill man vara effektiv behöver man kontinuerlig integration och därmed en server som kontinuerligt kan bygga och köra samtliga tester. Desto snabbare den är desto snabbare feedback till teamet och därmed högre produktivitet.

Fysiska förutsättningar för effektivt teamsamarbete

På många arbetsplatser, för att inte säga de flesta, som jag har varit på så har de fysiska omständigheterna för effektivt team-samarbete varit undermåliga. Det vanliga är att man inte anpassar bordsplacering efter teamens behov utan efter estetiska principer och organisationens behov av flexibilitet med avseende på att kunna fördela ut skrivbord till nyanställda och konsulter.
Ovanpå detta är man ofta snål med datorer och whiteboards, vilket leder till att utvecklare allt för ofta sitter med sega maskiner och i avsaknad av bra ytor att rita och diskutera med. Resultatet är ofta ett enormt behov av konferensrum, för att komma bort från det kontorslandskap man sitter i, för att kunna prata i avskildhet. För det mesta finns det därför alltid alldeles för lite konferensrum. Ett problem som inte skulle existera om företagens team redan satt i bra “konferensrum”.

Enligt min mening håller fortfarande Kent Becks beskrivning av det ideala XP-rummet från eXtreme Programming boken.

De ställen där jag varit där det funnits rum enligt denna modell så har de team som kunnat sitta så ofta varit betydligt mer produktiva och haft roligare än de som suttit utspridda i kontorslandskap och med dålig placering i förhållande till varandra.

Så vad bör man ställa för krav på en vettig miljö för att få till effektivt team-samarbete? ;

Nedan bild visar ett bra XP-rum i mitt tycke.

Det ideala teamrummet
Det ideala teamrummet

Den uppfyller följande krav (utan någon ordning på viktighet även om placering av skrivborden är bland det allra viktigaste!);

  • Placering av skrivbord

Detta är kanske den enskilt viktigaste detaljen i den fysiska omgivningen för ett team för att få till effektivt team-samarbete. Skrivborden skall vara så placerade att det tar HÖGST 2-3 SEKUNDER för vilken team-medlem som helst att RULLA till vilken annan team-medlem som helst.
Detta är en förutsättning för att bra samarbete skall utvecklas mellan samtliga i teamet enligt min mening.
Detta innebär nästan alltid att det är bäst att sitta rygg mot rygg.

  • Avskildhet.

Teamet bör sitta hyfsat avskilda från resten av verksamhet så att de kan föra livliga och högljudda diskussioner om så önskas utan att störa omgivningen. De skall också kunna ha musik i bakgrunden om de vill, och helt enkelt själva kunna definiera vilken ljud och ljus miljö de vill ha för att de skall trivas och kunna vara effektiva.
Därmed inte sagt att de skall vara så avskilda att de är långt att nå resten av verksamheten, som lämpligtvis finns grannar med var de själva sitter, i samma korridor och våningsplan typ.

  • Whiteboards och Scrumboards

Teamet bör har tillgång till en stor whiteboard att ha sin Scrum eller Kanban board på. I tillägg till detta vill man ofta ha gärna 2 whiteboards till. En att ha skisser, domänmodeller och andra anteckningar som man vill ha synligt konstant, och en whiteboard för att stå och rita och prata vid.

  • Datorer och Skärmar

Numera är det tack och lov standard att ha 2 skärmar vid varje arbetsplats och jag har sett arbetsplatser för utvecklare där man haft 3 och till och med 4 vilket inte har varit till en nackdel.
Som utvecklare (och testare) är mycket skärmyta alltid en fördel.
Dessutom skall man självklart ha kraftfulla maskiner så att man slipper vänta på sin dator.
Bara att behöva vänta så mycket som 5 min per timme på sin dator blir snabbt kostnader som överstiger ev. investeringskosnad i ny hårdvara. Detta räknade vi på i ett företag jag satt och såg att kostnaden för nya datorer räknades hem på 2-3 månader.

  • Skrivbord och stolar

Skrivborden behöver sällan vara speciellt stora, men de skall väl rymma skärmar och tangentbord. En fördel är om de är utformade så att man kan sitta flera vid samma skärm, och därmed underlätta parprogrammering. Stolarna bör vara bekväma och lättrullade.
Min kollega Hans Brattberg kom med några utmärkta synpunkter kring skrivbord, han säger så här: “Stolar bör inte ha armstöd som gör att man hakar i varandra och som är i vägen när man vill sitta brevid varandra och parprogrammera. Dessutom är skrivbord som är skålade olämpliga, då hamnar en person för långt från skärmen när man försöker parprogrammera.” Han skickade med de 2 bilderna nedan, den ena visar tydligt vitsen med att ha ett skrivbord som åtminstone inte är skålat inåt för att möjliggöra parprogrammering.
Nästa bild visar en ritning på ett parprogrammerings skrivbord designat av de duktiga killarna på factor10.
Parprogrammeringsskrivbord
Parprogrammeringskrivbordet

  • Lek / Inspirationshörna

Om ett team har ett ställe med inspirerande leksaker, gärna passande för den uppgift de har (roliga mobiler för mobilutvecklare, videokameror för de som jobbar med videosystem osv), så skapar man förutsättningar för kreativitet och lekfullhet, vilket i förlängningen leder till högre produktivitet.

  • Frukt och dryck

Kunskapsarbete är rent fysiskt energikrävande.  Hjärnan är vår främsta muskel.  Genom att näring och vitaminjektioner ständigt tillgängliga kan vi utnyttja de 6-8 timmar vi spenderar på vår arbetsplats på bästa sätt.  På många arbetsplatser finns det ofta godis och kakor.  Det är dock bedrägligt, för även om de ger kortvariga energikickar så leder det också till att stora delar av personalen ofta är i sockerchock.  Vilket kan skapa dåligt humör när den klingar av och leder till dålig hälsa i förlängningen.

  • Test-miljöer, integrationsservrar mm

Allt detta hör ju också till den fysiska miljön för teamet, men är lite utanför scoopet på den här bloggposten. Men kort uttryckt tycker jag man kan säga att teamet skall ha tillgång till serverar på ett sådant sätt att de inte behöver trampa andra team på tårna eller vänta på något annat team när de vill integration och regressionstesta. Vill man vara effektiv behöver man kontinuerlig integration och därmed en server som kontinuerligt kan bygga och köra samtliga tester. Desto snabbare den är desto snabbare feedback till teamet och därmed högre produktivitet.

Fysiska förutsättningar för effektivt teamsamarbete

På många arbetsplatser, för att inte säga de flesta, som jag har varit på så har de fysiska omständigheterna för effektivt team-samarbete varit undermåliga. Det vanliga är att man inte anpassar bordsplacering efter teamens behov utan efter estetiska principer och organisationens behov av flexibilitet med avseende på att kunna fördela ut skrivbord till nyanställda och konsulter.
Ovanpå detta är man ofta snål med datorer och whiteboards, vilket leder till att utvecklare allt för ofta sitter med sega maskiner och i avsaknad av bra ytor att rita och diskutera med. Resultatet är ofta ett enormt behov av konferensrum, för att komma bort från det kontorslandskap man sitter i, för att kunna prata i avskildhet. För det mesta finns det därför alltid alldeles för lite konferensrum. Ett problem som inte skulle existera om företagens team redan satt i bra “konferensrum”.

Enligt min mening håller fortfarande Kent Becks beskrivning av det ideala XP-rummet från eXtreme Programming boken.

De ställen där jag varit där det funnits rum enligt denna modell så har de team som kunnat sitta så ofta varit betydligt mer produktiva och haft roligare än de som suttit utspridda i kontorslandskap och med dålig placering i förhållande till varandra.

Så vad bör man ställa för krav på en vettig miljö för att få till effektivt team-samarbete? ;

Nedan bild visar ett bra XP-rum i mitt tycke.

Det ideala teamrummet
Det ideala teamrummet

Den uppfyller följande krav (utan någon ordning på viktighet även om placering av skrivborden är bland det allra viktigaste!);

  • Placering av skrivbord

Detta är kanske den enskilt viktigaste detaljen i den fysiska omgivningen för ett team för att få till effektivt team-samarbete. Skrivborden skall vara så placerade att det tar HÖGST 2-3 SEKUNDER för vilken team-medlem som helst att RULLA till vilken annan team-medlem som helst.
Detta är en förutsättning för att bra samarbete skall utvecklas mellan samtliga i teamet enligt min mening.
Detta innebär nästan alltid att det är bäst att sitta rygg mot rygg.

  • Avskildhet.

Teamet bör sitta hyfsat avskilda från resten av verksamhet så att de kan föra livliga och högljudda diskussioner om så önskas utan att störa omgivningen. De skall också kunna ha musik i bakgrunden om de vill, och helt enkelt själva kunna definiera vilken ljud och ljus miljö de vill ha för att de skall trivas och kunna vara effektiva.
Därmed inte sagt att de skall vara så avskilda att de är långt att nå resten av verksamheten, som lämpligtvis finns grannar med var de själva sitter, i samma korridor och våningsplan typ.

  • Whiteboards och Scrumboards

Teamet bör har tillgång till en stor whiteboard att ha sin Scrum eller Kanban board på. I tillägg till detta vill man ofta ha gärna 2 whiteboards till. En att ha skisser, domänmodeller och andra anteckningar som man vill ha synligt konstant, och en whiteboard för att stå och rita och prata vid.

  • Datorer och Skärmar

Numera är det tack och lov standard att ha 2 skärmar vid varje arbetsplats och jag har sett arbetsplatser för utvecklare där man haft 3 och till och med 4 vilket inte har varit till en nackdel.
Som utvecklare (och testare) är mycket skärmyta alltid en fördel.
Dessutom skall man självklart ha kraftfulla maskiner så att man slipper vänta på sin dator.
Bara att behöva vänta så mycket som 5 min per timme på sin dator blir snabbt kostnader som överstiger ev. investeringskosnad i ny hårdvara. Detta räknade vi på i ett företag jag satt och såg att kostnaden för nya datorer räknades hem på 2-3 månader.

  • Skrivbord och stolar

Skrivborden behöver sällan vara speciellt stora, men de skall väl rymma skärmar och tangentbord. En fördel är om de är utformade så att man kan sitta flera vid samma skärm, och därmed underlätta parprogrammering. Stolarna bör vara bekväma och lättrullade.
Min kollega Hans Brattberg kom med några utmärkta synpunkter kring skrivbord, han säger så här: “Stolar bör inte ha armstöd som gör att man hakar i varandra och som är i vägen när man vill sitta brevid varandra och parprogrammera. Dessutom är skrivbord som är skålade olämpliga, då hamnar en person för långt från skärmen när man försöker parprogrammera.” Han skickade med de 2 bilderna nedan, den ena visar tydligt vitsen med att ha ett skrivbord som åtminstone inte är skålat inåt för att möjliggöra parprogrammering.
Nästa bild visar en ritning på ett parprogrammerings skrivbord designat av de duktiga killarna på factor10.
Parprogrammeringsskrivbord
Parprogrammeringskrivbordet

  • Lek / Inspirationshörna

Om ett team har ett ställe med inspirerande leksaker, gärna passande för den uppgift de har (roliga mobiler för mobilutvecklare, videokameror för de som jobbar med videosystem osv), så skapar man förutsättningar för kreativitet och lekfullhet, vilket i förlängningen leder till högre produktivitet.

  • Frukt och dryck

Kunskapsarbete är rent fysiskt energikrävande.  Hjärnan är vår främsta muskel.  Genom att näring och vitaminjektioner ständigt tillgängliga kan vi utnyttja de 6-8 timmar vi spenderar på vår arbetsplats på bästa sätt.  På många arbetsplatser finns det ofta godis och kakor.  Det är dock bedrägligt, för även om de ger kortvariga energikickar så leder det också till att stora delar av personalen ofta är i sockerchock.  Vilket kan skapa dåligt humör när den klingar av och leder till dålig hälsa i förlängningen.

  • Test-miljöer, integrationsservrar mm

Allt detta hör ju också till den fysiska miljön för teamet, men är lite utanför scoopet på den här bloggposten. Men kort uttryckt tycker jag man kan säga att teamet skall ha tillgång till serverar på ett sådant sätt att de inte behöver trampa andra team på tårna eller vänta på något annat team när de vill integration och regressionstesta. Vill man vara effektiv behöver man kontinuerlig integration och därmed en server som kontinuerligt kan bygga och köra samtliga tester. Desto snabbare den är desto snabbare feedback till teamet och därmed högre produktivitet.

Fysiska förutsättningar för effektivt teamsamarbete

På många arbetsplatser, för att inte säga de flesta, som jag har varit på så har de fysiska omständigheterna för effektivt team-samarbete varit undermåliga. Det vanliga är att man inte anpassar bordsplacering efter teamens behov utan efter estetiska principer och organisationens behov av flexibilitet med avseende på att kunna fördela ut skrivbord till nyanställda och konsulter.
Ovanpå detta är man ofta snål med datorer och whiteboards, vilket leder till att utvecklare allt för ofta sitter med sega maskiner och i avsaknad av bra ytor att rita och diskutera med. Resultatet är ofta ett enormt behov av konferensrum, för att komma bort från det kontorslandskap man sitter i, för att kunna prata i avskildhet. För det mesta finns det därför alltid alldeles för lite konferensrum. Ett problem som inte skulle existera om företagens team redan satt i bra “konferensrum”.

Enligt min mening håller fortfarande Kent Becks beskrivning av det ideala XP-rummet från eXtreme Programming boken.

De ställen där jag varit där det funnits rum enligt denna modell så har de team som kunnat sitta så ofta varit betydligt mer produktiva och haft roligare än de som suttit utspridda i kontorslandskap och med dålig placering i förhållande till varandra.

Så vad bör man ställa för krav på en vettig miljö för att få till effektivt team-samarbete? ;

Nedan bild visar ett bra XP-rum i mitt tycke.

Det ideala teamrummet
Det ideala teamrummet

Den uppfyller följande krav (utan någon ordning på viktighet även om placering av skrivborden är bland det allra viktigaste!);

  • Placering av skrivbord

Detta är kanske den enskilt viktigaste detaljen i den fysiska omgivningen för ett team för att få till effektivt team-samarbete. Skrivborden skall vara så placerade att det tar HÖGST 2-3 SEKUNDER för vilken team-medlem som helst att RULLA till vilken annan team-medlem som helst.
Detta är en förutsättning för att bra samarbete skall utvecklas mellan samtliga i teamet enligt min mening.
Detta innebär nästan alltid att det är bäst att sitta rygg mot rygg.

  • Avskildhet.

Teamet bör sitta hyfsat avskilda från resten av verksamhet så att de kan föra livliga och högljudda diskussioner om så önskas utan att störa omgivningen. De skall också kunna ha musik i bakgrunden om de vill, och helt enkelt själva kunna definiera vilken ljud och ljus miljö de vill ha för att de skall trivas och kunna vara effektiva.
Därmed inte sagt att de skall vara så avskilda att de är långt att nå resten av verksamheten, som lämpligtvis finns grannar med var de själva sitter, i samma korridor och våningsplan typ.

  • Whiteboards och Scrumboards

Teamet bör har tillgång till en stor whiteboard att ha sin Scrum eller Kanban board på. I tillägg till detta vill man ofta ha gärna 2 whiteboards till. En att ha skisser, domänmodeller och andra anteckningar som man vill ha synligt konstant, och en whiteboard för att stå och rita och prata vid.

  • Datorer och Skärmar

Numera är det tack och lov standard att ha 2 skärmar vid varje arbetsplats och jag har sett arbetsplatser för utvecklare där man haft 3 och till och med 4 vilket inte har varit till en nackdel.
Som utvecklare (och testare) är mycket skärmyta alltid en fördel.
Dessutom skall man självklart ha kraftfulla maskiner så att man slipper vänta på sin dator.
Bara att behöva vänta så mycket som 5 min per timme på sin dator blir snabbt kostnader som överstiger ev. investeringskosnad i ny hårdvara. Detta räknade vi på i ett företag jag satt och såg att kostnaden för nya datorer räknades hem på 2-3 månader.

  • Skrivbord och stolar

Skrivborden behöver sällan vara speciellt stora, men de skall väl rymma skärmar och tangentbord. En fördel är om de är utformade så att man kan sitta flera vid samma skärm, och därmed underlätta parprogrammering. Stolarna bör vara bekväma och lättrullade.
Min kollega Hans Brattberg kom med några utmärkta synpunkter kring skrivbord, han säger så här: “Stolar bör inte ha armstöd som gör att man hakar i varandra och som är i vägen när man vill sitta brevid varandra och parprogrammera. Dessutom är skrivbord som är skålade olämpliga, då hamnar en person för långt från skärmen när man försöker parprogrammera.” Han skickade med de 2 bilderna nedan, den ena visar tydligt vitsen med att ha ett skrivbord som åtminstone inte är skålat inåt för att möjliggöra parprogrammering.
Nästa bild visar en ritning på ett parprogrammerings skrivbord designat av de duktiga killarna på factor10.
Parprogrammeringsskrivbord
Parprogrammeringskrivbordet

  • Lek / Inspirationshörna

Om ett team har ett ställe med inspirerande leksaker, gärna passande för den uppgift de har (roliga mobiler för mobilutvecklare, videokameror för de som jobbar med videosystem osv), så skapar man förutsättningar för kreativitet och lekfullhet, vilket i förlängningen leder till högre produktivitet.

  • Frukt och dryck

Kunskapsarbete är rent fysiskt energikrävande.  Hjärnan är vår främsta muskel.  Genom att näring och vitaminjektioner ständigt tillgängliga kan vi utnyttja de 6-8 timmar vi spenderar på vår arbetsplats på bästa sätt.  På många arbetsplatser finns det ofta godis och kakor.  Det är dock bedrägligt, för även om de ger kortvariga energikickar så leder det också till att stora delar av personalen ofta är i sockerchock.  Vilket kan skapa dåligt humör när den klingar av och leder till dålig hälsa i förlängningen.

  • Test-miljöer, integrationsservrar mm

Allt detta hör ju också till den fysiska miljön för teamet, men är lite utanför scoopet på den här bloggposten. Men kort uttryckt tycker jag man kan säga att teamet skall ha tillgång till serverar på ett sådant sätt att de inte behöver trampa andra team på tårna eller vänta på något annat team när de vill integration och regressionstesta. Vill man vara effektiv behöver man kontinuerlig integration och därmed en server som kontinuerligt kan bygga och köra samtliga tester. Desto snabbare den är desto snabbare feedback till teamet och därmed högre produktivitet.

What is the purpose of trying to improve estimates ?

I sometimes hear people talk about how to do better estimates. 
This often happens when the velocity for a team is going down and sometimes when it is going up too and when the estimated and actual velocity is much different.
Teams in these situations often seem to feel they have failed at estimating and thinks they should try to do a better job estimating.  
In my view this stems from a misunderstanding of the purpose of agile estimating.
I believe as many others, that estimates are always wrong, especially if you try to make them in actual time rather than relative size.
But even if you make them in relative size (story points) they are never anything more than guesses.
And with velocity tracking this is not a problem. There is really no big win in trying to "improve" your estimates.
The purpose of velocity tracking is to automatically correct the inherent error in estimates.
So let the automation built into the process work.

Suppose your team actually could get real accurate estimates.
Then your team would be able to pick the right amount of work for each sprint, and have a stable velocity.  

But then you can get this situation as easy with ordinary inaccurate estimates too, as long as the team makes about the same size of estimation error every time. 

Which they usually will given the same team members and a well-known problem domain.
So what should we do then when actual velocity starts to differ much from estimated velocity, is that not a sign of that the team is doing a worse estimation job? 
Not in my view.  Yes the estimates are apparently more inaccurate, but what is the reason for that ?
That is good information!   

The reason could be some of the following:

  • There is a new problem domain which the team is not used to
  • The team has got new members
  • The team has lost members
  • The team have moved or changed their physical environment
  • The team have started with some new practice
  • The team have stopped doing some practice
  • The team have got a new product owner
  • The team has grown tighter
  • The team has lost its energy
  • etc etc…

If you during a retrospective can try to find out why your estimated and actual velocity have started to differ you have good information to improve your effiency as a team and in the long run get more productive (not necessary higher velocity).

Just don’t try to estimate better.
And furthermore, don’t be *sorry* if your actual and estimated velocity differ!  It is natural that it happens, and will happen to most teams in a changing world.
I would be more worried if I were in a team with constantly stable velocity.
That would to me be a warning sign of stagnation.

And if you really want higher velocity, just start multiply your estimates with any high number.  In that way you can get as high velocity as you want.
Why you now would want that ?  :-)

Any good insight in this post I attribute to Mike Cohn.
He have taught me so much through his books "Agile Estimating and Planning" and "User Stories Applied" and his seminars. 
His teaching has been one of the most influental for me.
Find out more at his site: www.mountaingoatsoftware.com

What is the purpose of trying to improve estimates ?

I sometimes hear people talk about how to do better estimates. 
This often happens when the velocity for a team is going down and sometimes when it is going up too and when the estimated and actual velocity is much different.
Teams in these situations often seem to feel they have failed at estimating and thinks they should try to do a better job estimating.  
In my view this stems from a misunderstanding of the purpose of agile estimating.
I believe as many others, that estimates are always wrong, especially if you try to make them in actual time rather than relative size.
But even if you make them in relative size (story points) they are never anything more than guesses.
And with velocity tracking this is not a problem. There is really no big win in trying to "improve" your estimates.
The purpose of velocity tracking is to automatically correct the inherent error in estimates.
So let the automation built into the process work.

Suppose your team actually could get real accurate estimates.
Then your team would be able to pick the right amount of work for each sprint, and have a stable velocity.  

But then you can get this situation as easy with ordinary inaccurate estimates too, as long as the team makes about the same size of estimation error every time. 

Which they usually will given the same team members and a well-known problem domain.
So what should we do then when actual velocity starts to differ much from estimated velocity, is that not a sign of that the team is doing a worse estimation job? 
Not in my view.  Yes the estimates are apparently more inaccurate, but what is the reason for that ?
That is good information!   

The reason could be some of the following:

  • There is a new problem domain which the team is not used to
  • The team has got new members
  • The team has lost members
  • The team have moved or changed their physical environment
  • The team have started with some new practice
  • The team have stopped doing some practice
  • The team have got a new product owner
  • The team has grown tighter
  • The team has lost its energy
  • etc etc…

If you during a retrospective can try to find out why your estimated and actual velocity have started to differ you have good information to improve your effiency as a team and in the long run get more productive (not necessary higher velocity).

Just don’t try to estimate better.
And furthermore, don’t be *sorry* if your actual and estimated velocity differ!  It is natural that it happens, and will happen to most teams in a changing world.
I would be more worried if I were in a team with constantly stable velocity.
That would to me be a warning sign of stagnation.

And if you really want higher velocity, just start multiply your estimates with any high number.  In that way you can get as high velocity as you want.
Why you now would want that ?  :-)

Any good insight in this post I attribute to Mike Cohn.
He have taught me so much through his books "Agile Estimating and Planning" and "User Stories Applied" and his seminars. 
His teaching has been one of the most influental for me.
Find out more at his site: www.mountaingoatsoftware.com