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.

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

An exercise based on my PSL experience:The power of open-ended requirements

Today I held a class in Scrum and Lean.

I was then able to test some of my learnings from the PSL class in a exercises I made up just the day before.

The results were almost too good.

I divided the class in two groups (consisting of about 6 people each) and told them that they in this exercise would do a drawing during silence, following a requirement I would hand out.  The would only have one minute to complete the drawing.

I provided them with a number pencils in red, green and blue and one big piece of paper each.  Then I handed out one paper with the requirements to each group and started a visible timer counting down 60 seconds.

One of the groups got the following requirement:

Draw a beutiful summer meadow with blue and red flowers in green grass, some cows and birds under a shining sun.

The other group got the following requirement:

 

Draw a beutiful summer meadow with

  • 10 blue flowers with 5 petals each
  • 5 blue flowers with 6 petals each
  • 13 red flowers with 6 petals each
  • 2 cows with 3 black spots

  • 1 cow with 5 black spots
  • 2 cows with 4 black spots
  • 2 birds to reside in the upper left corner
  • 3 birds in the middle
  • one sun to the right with 5 sun beams

Before reading further, look at there drawings here and guess which drawing was made by which group.


Well, as you might have guessed, the drawing to the left was made by the group that got the open-ended requirements and the drawing to the right was made by the group with a lot of specification detail.  And that drawing does’nt even comply to the base requirement; a summer meadow.

And the cows are, although rich in detail, on the wrong angels.  – The group behind the right drawing had such focus on implementing every detail of the requirements that they forgot the main purpose of the “assignemnt”, to draw a meadow.

Do you recognize that from software development ?  I for certain do, and I do remember how boring it have felt implementing over-specified requirements.  I just wanted to get it over with.  Which I think is a very natural reaction when you are left with no opportunity for your own creativity. Or worse, find out obscure ways to put in your creativity anyway, in ways that might yeild even worse solutions.

I felt that the class got the same “ah” experience as I did myself on the PSL class.

Once again I have to give my appreciation to Jerry Wienberg, Esther Derby and Johanna Rothman.

The Problem Solving Leadership class continues to make a huge impact on my life.

It is the most expensive class I ever spent my money on in terms of actual swedish kronas, but not a cost but truly profitable in terms of the leverage it has on my consulting.

If you are a consultant like me and work with teams and leaders I think you can do no better investment than attending the next PSL class. It will be held in late march, check it out and click here!

Debrief of Problem Solving Leadership class

The PSL class was a remarkable experience different from any other class I ever attended in my life.   The following youtube clip shows how much fun it was, here when we in "The Red Team" made a "Musical Performance" which we had only one hour to invent and prepare. Remember to watch in high resolution if your bandwidth allows it.
Everyday was full of experiences and triggered strong emotions within and between us who attended.   Probably, the class will meet again many times, since we did a whole lot of bonding through the exhausting exercises.
Most of the exercises were simulations, that is they simulated situations we all where familiar with, but gave us a whole lot of different perspectives on.

In the biggest one, we simulated a whole company.  And during the simulation I found myself feeling distrust for what the "development team" where doing, myself being part of the sale-force of the company (actually, and I am proud of it, I was the first one to figure the whole sale-process, and I got the title Salesprocess manager! :-) ).
I have seen people outside development teams, sales people and managers expressing exactly this feeling, and now I felt exactly the same, and I even didn’t recognize that until after the simulation.
Very interesting!
Shows the importance of transparency and of trust I would say.
You might now wonder how did the simulation look like, but I will not blog about it, in case anyone reading this want to experience it themselves, I could risk ruin it for them if I would describe how the simulation worked.

So what did I learn ?   So much, and I am still processing the experience, but I will try to express some insights I got so far;

1.  "The problem is not the problem – it is coping with the problem"
Meaning, often we have a defined solution for a problem that is much more complex than needed.  Our, or better, my instinct to quickly find a solution for any "problem" I face, often leads to a bigger problem, which is implementing the solution, which might be real hard, if the solution is not appropriate, and not what others want.
If I instead try to wait with interpreting the situation too quickly and creating a solution before I actually understand what the problem is, I get much better results.

2. "Finding a zero-level solution first makes it easier to develop a good solution onward"
Faced with any problem, it seems that if I first try to figure out what is the easiest and simplest possible solution for this situation, that requires the smallest amount of work, everything will be much smoother.
With the zero-level solution I get a security, that no matter what, there is a solution.
I can then build on it with small steps.  
Which is exactly how TDD works, but this works for anything, not only programming.

3. Going with the flow is much more effective leadership than trying to lead by trying to persuade other to go for your solution.
Being smooth and going with a flow in a team is much more effective leadership than trying to enforce your own will onto the group.  A process is always better than no process, and fighting about it waste a lot of time. 
Often fighting or being in the Big Game (the powerstruggle) hides the constructive path to find a good solution. 
As important it is to be honest about my opinions, it is important that I accept and commit to decisions made by the team.  There is never only one perfect solution.
The first priority must always be to find a solution, any solution.  Then we can refine it with the time and resources we are given.

4. "Problem-solving leadership may be defined as

The ability to enhance the environment
so that everyony is empowered
to contribute creatively
to solving the problem(s).
"
  – excerpt from the class

I think this is so beautiful – and true.  And it goes along the same lines as Patrick Lencionis work.   Leadership is making a team work, and anyone can execute it.

5.  Leadership and management is two different things.
Well of course.   Leadership can be executed by anyone.  It is of course good if a manager is a good leader, but it is not a necessitity.  If there are good leadership skills among the team members that might suffice to make an effective team.

6.  Doing nothing can be an important act of leadership.
Sometimes when a team is struggling, the best thing might be to do nothing, or rather just observe.   Through observations you might get a better understanding of what the problem really is, which often has little to do with anything else than the people themselves in the team.

7. A lot of specification will be bad for the teams creativity and yield in a worse solution.

Letting the team use it’s creativity to find their way to a solution open up for the possibility for the team to get into a creativity flow which probably will yield a better solution than if the team has to work towards a detailed specification.
Of course there are usually boundaries for any problem that has to be specified, but let the team have as much freedom of creativity as possible if you want high productivity and neat solutions.
This I experienced several times in the class simulations as I have in my career.

8. Simulations are a very effective way to learn.
I will remember to use much more practical exercises and simulations in my own classes in the future.  Some of us attending the class are also thinking about forming a society where we can meet and try out ideas for new simulations.
Simulations are not only effective learning – they are so fun! 
Maybe because they bring about so much emotions.

9. Keeping a hand-written journal and notebook helps me organize my life and be effective.

I’ve tried to have TODO lists on my computer, and in many other digital forms (PDAs, cell phones etc..) because my handwriting sucks.
Jerry gave me a personal gift.  A Uniball pen.  It has done a miracle for my life.
With a small notebook from the class, I am now able to anytime anywhere write down ideas and todos and reflections on my own behaviour. 
My life has taken a new direction, and only this little change has made a huge impact.
Slowly my handwriting will also be better.  And it is fun!  Writing notes on paper is actually fun!  I didn’t know that!  Thank you very much Jerry!

Jerry Weinberg, for those of you who don’t know him, is one of the foremost writers, speakers and thinkers when it comes to leadership. 
You can read about him on his website www.geraldmweinberg.com.
I just want to give you some small anectdotes he told me:
As a young programmer working for IBM, the computer he was in charge for was hired out to companies, and he came with the package so to speak.  At that time the computer he worked with, was 10% of the worlds total computer capacity.  Having the opportunity to program a lot before most people ever heard about programming might be one reason why he soon was ahead most the others in the business.
Beside being one of the developers of the first Operating system, and the Fortran language, Jerry also was the Chief architect for the NASA Mercury mission, sending the first american into space.
He almost missed that assignment, because he first turned it down being tired after a journey.  In the elevator down from the recruiter, someone told him about the mission of the project, and being very interested in anything concerning space and astronomy and sci-fi, he immediately went back and was able to get the assignment before anyone else took it!

For me Jerry stands out as the most impressive person in the IT business I’ve met so far. 

Johanna Rothman was the woman inspiring me to attend the class.  Watching her webcasts on InfoQ before the class, was what made me make up my mind.
She gave me such good advice on how to improve my consulting. I am very thankful to her for that.  She is a very bright woman having so much insights about effective teamwork.

Esther Derby insights about agile processes, and calm and clear leadership was also a guiding light through the week.

I bought some of their books, on the shelf now is "Becoming a technical leader" by Jerry.  "Manage IT!" by Johanna and "Agile retrospectives" by Esther.

I will surely blog about what I learn after having read these books and in connection with what I am learning from the class.

I will also attend Jerry’s class on simulation design later this spring.

If you want to attend the PSL class yourself check out http://estherderby.com/workshops/ProblemSolvingLeadership.htm

The Amplifying Your Effectivness Conference is probably also a great place to be;
http://www.ayeconference.com/

If you are interested in designing and testing simulations please contact me and you can join us in  "The European Simulation Design Society".

//David :@

The five dysfunctions of a team – seminarium på Javaforum november 2008

“The five dysfunctions of a team”

The five dysfunctions

Slides

Teamsamarbete är inte en egenskap utan ett strategiskt val. För att uppnå det måste du acceptera de uppoffringar och kostnader som krävs för att åstadkomma det. Det handlar om att kunna bemästra några enkla koncept som de flesta säkert redan känner till men det svåra är att göra dem varje dag.

Mannen bakom modellen som jag här kommer presentera heter Patrick Lencioni och han är författaren till romanen och bestsäljaren “The Five dysfunctions of a team”

Han är en managementkonsult i USAch har utarbetat modellen “the five dysfunctions of a team” och ett program för att överbrygga dessa. Hans arbete har sedan återanvänts av managementkonsulter runt om i världen för att hjälpa team att fungera bättre och effektivare.

Patricks bok ”The five dysfunctions of a team” och hans bok ”Death by meeting” har tillsammans sålt i mer än 2.5 miljoner exemplar.

Jag tror liksom Patrick att fungerande teamsamarbete fortfarande är den mest outnyttjade konkurrensfördelen i näringslivet. Med ett tajt team kan man göra nästan vad som helst.

TeamWork

Grupper som har ett fungerande teamsamarbete, gör bättre och snabbare beslut än andra grupper.

De slipper slösa tid på politik, förvirring och destruktiva konflikter. Och ändå är det en ganska sällsynt företeelse, varför? Dels har termen teamwork blivit överutnyttjad och förlorat mycket av sin mening som så många andra buzz-words i näringslivet, det finns också en tendens att mystifiera teamwork, när det i praktiken är ganska enkelt, åtminstone i teorin. De flesta vet redan vad teamwork kräver, men i praktiken är det inte så lätt att få till därför att människor är komplicerade varelser och när man sätter en ett gäng utvecklare i ett rum så kommer problem uppstå.

För att få ett fungerande teamwork måste medlemmarna i teamet vara beredda på att satsa tid och energi för att åstadkomma det, men dessvärre är få organisationer beredda att investera i det.

Men för de organisationer som är beredda att göra vad som krävs, finns det stora vinster att hämta

Patrick Lencionis modell

Patrick

Det finns många modeller som beskriver hur team fungerar eller inte, men jag tycker Patricks modell är enkel och bygger på sunt förnuft utan allt för mycket hokus-pokus.

Jag föll för modellen för jag så väl kände igen problemen, dysfunktionerna, från många team som jag själv deltagit i. Grundproblemet är brist på tillit, dysfunktion nr 1, vilket leder till att människor döljer saker för varandra och ägnar sig åt politik på arbetet. Har man tur och tillit finns mellan teammedlammar, så är nästa problem konflikträdsla, vilket leder till att viktiga problem inte blir utredda för att man inte delar uppfattning kring dem. Brist på tillit och rädsla för konflikter leder till svårigheter för människor att åta sig, att committa till något, vilket i sin tur leder till att man inte heller förväntar sig något av någon, och därmed går det inte heller att vara resultatorienterad.

Tillit

trust

En viktig orsak till brist på tillit i en organisation är den s.k. “fundamental attribution error”, dvs att vi antar att andras negativa beteende beror på deras karaktär, medans vi ser vårt eget negativa beteende som ett resultat av omständigheterna och vice versa att andras framgång som ett resultat av omständigheterna, och vår egen framgång som ett resultat av vår egen förmåga!

Team som saknar tillit,

  • Döljer sina svagheter och misstag (eftersom de inte litar på varandra)

  • Tvekar att be om hjälp (eftersom de är rädda för att bli avslöjade)

  • Hjälper inte till med uppgifter utanför sin eget ansvarsområde (eftersom de inte vågar riskera att visa sig okunniga)

  • Har fördomar om andras avsikter och förmågor (eftersom de inte vet så mycket om de andra i teamet)

  • Tar inte del av andras kompetens och erfarenhet (återigen på grund av att ingen delar med sig av rädsla för att bli ”avslöjad” som inkompetent)

  • Slösar tid och energi på att spela roller inför varandra (för att framstå i bästa möjliga dager inför varandra)

  • Bär på missnöje (det är ju inget roligt att inte känna tillit och inte kunna vara sig själv)

  • Undviker att vara med varandra annat än om det är nödvändigt (man vill ju inte umgås med de som är orsaken till ens vantrivsel)


Vilken slags tillit ?

Den typ av tillit vi behöver i ett välfungerande team skall inte vara tillit i att vi kan förutse varandras beteende genom att vi jobbat tillsammans länge, vilken är en slags tillit som alltid kommer utvecklas i ett team bara man jobbar tillräckligt länge ihop.

Men verklig tillit som skapar ett effektivt team måste bygga på sårbarhet. Dvs att man vågar vara ärlig och öppen mot varandra om sina svagheter, sin inkompetens och självklart också ens styrkor och kompetens.

Hur byggs tillit ?

Det finns flera verktyg för att bygga tillit i ett team, varav Patrick föreslår några relativt enkla och lätta att genomföra.

En övning är den s.k. personliga historie övningen. Det är en övning där man helt enkelt genom att berätta om sin personliga bakgrund i livet för varandra, lär känna varandra på ett personligare plan än vad man inte annars får tillfälle till. Man berättar sin livshistoria i korthet (alltså inte någon djuplodande självutlämnande berättelse, utan bara kort var man föddes, hur många syskon man har, var man växte upp osv). Man berättar också sin yrkeshistoria fram till nu, lite om de projekt man varit med i, vilka som varit lyckade och vilka som varit misslyckade, varför och hur det kändes etc.

Detta brukar ge snabbt en betydligt bättre insikt om varandra än någonsin våta ölkvällar eller ”teambuildingskonferenser” där man åker bil med två rattar och dylikt. Inte för att det är fel att göra den typen av aktiviter också, men man skall inte lita på att de bygger tillit mellan teammedlemmar.

Ett annat verktyg, är att utnyttja s.k. Beteende profilering, dvs att man genom t.ex. ett Myer-Briggs Type Indicator test, eller på annat sätt, försöker beskriva hur man fungerar i olika situationer.

Inte för att värdera, utan för att skapa förståelse inom ett team, på vilket sätt var och en i teamet föredrar att handskas med olika situationer, och hur ens egen självbild ser ut. Personlighets beskrivande test som MBTI testet är hyfsat kvasivetenskapliga och används ofta i rätt destruktiva sammanhang tycker jag, som t.ex. vid rekrytering. Men i ett sammanhang som detta tycker jag de kan vara värda att prova på, mest som ett sätt att få lite adjektiv att diskutera utifrån.

Vi är ju mer intresserade här av att ta del av varandras självbild än att få någon exakt psykiatrisk personlighetsbeskrivning (om nu någon sådan ens vore möjlig).

Konflikträdsla

Conflict

Teammedlemmar som inte litar på varandra kommer inte vara benägna att engagera sig i ofiltrerade passionerade diskussioner kring viktiga frågeställningar. Istället kommer de dölja vad de tycker, välja sin strider och ta konflikterna “offline”, i korridoren, och jobba för att åstadkomma vad Patrick kallar “artificiell harmoni”. Artificiell harmoni är ett varningstecken på ett team som inte fungerar bra. Dvs alla verkar ha så trevligt tillsammans och är så positiva, men under ytan jäser motsättningarna.

Team som skyr konflikter;

  • har tråkiga möten (för ingen vågar dryfta de verkliga ämnena)

  • odlar politik och ägnar sig åt personliga attacker (ofta bakom ryggen på de som attackeras) (för att de är endast med andra som delar samma åsikt som medlemmarna vågar säga vad de tycker)

  • ignorerar att ta upp och reda ut viktiga och kontroversiella frågeställningar som är kritiska för teamets framgång (eftersom motsatta uppfattningar aldrig diskuteras och reds ut)

  • missar att fånga upp och lyssna på varje teammedlems åsikt och perspektiv (speciellt mindre högljudda teammedlemmar)

  • slösar tid och energi på att förställa sig (eftersom medlemmarna i teamet inte står för vad de tycker)

Hur skapas en positiv konfliktkultur ?

Förutsättning är förstås att ha börjat bygga tillit i gruppen. Den typen av konflikter vi vill ha är konstruktiva idealogiska konflikter, inte destruktiva personliga konflikter.

Samtidigt skall man veta att i skalan från helt intetsägande diskussioner till affekterade destruktiva katastrofer, så sker de mest konstruktiva konflikterna någonstans mittemellen, på gränsen till att vara destruktiva. Vilket betyder att i ett välfungerande tajt team, så kommer det hända till och från att någon eller några går över gränsen till destruktiva beteenden. Vilket är okey, om vi bara har verktyg för att hantera det.

En övning man bör börja med, enligt Patrick, för att få bli av med konflikträdsla är s.k. konfliktprofilering. Med utgångspunkt från beteendeprofilen från tillitsövningarna, gör man övningar som har till syfte att teammedlemmarna skall förstå varandras olika sätt att hantera konflikter, var och ens s.k. konfliktprofil.

När man gjort detta kan man gå vidare med Konfliktnormering – Dvs man diskuterar och bestämmer normer för vad som är juste och inte juste beteende i konflikter i just detta team, och hur man skall hantera situationer när någon eller några har gått över gränsen.

Ledaren för teamet bör också vid tillfällen göra s.k. ”Real time permission”, dvs se till att fånga upp situationer när konflikter uppstår, och i en kort stund avbryta konflikten, och bekräfta för de inblandade i konflikten att vad de gör är bra och att de skall fortsätta. Det brukar ofta ta bort den känslomässiga udden från konflikter och ge de inblandade en större trygghet att genomföra konflikten konstruktivt. Konflikter kan ju vara skrämmande och obehagliga även när de är konstruktiva och nödvändiga.

Ledaren i gruppen bör också jobba för att fånga upp konflikter som ligger under ytan eller så fort antydan till en sådan dyker upp, genom att pressa/uppmuntra teammedlemmarna till att ta diskussionen snarast och klargöra vad de tycker. Inte för att uppnå konsensus, men för att tydlighet skall uppstå vari skilda uppfattningar ligger, så att man sedan kan ta beslut och gå vidare.

De flesta har inte heller några problem med att ställa upp på ett beslut om deras uppfattning har fått komma till uttryck och tagits i beaktande.

Brist på åtagande

commitment

Team som saknar åtagandekultur och inte tar på sig arbete på ett seriöst sätt, som kanske fyller en sprintbacklogg, men inte tror på den, osv, ;

  • skapar osäkerhet om prioriteringar och mål (för ingen vet vad man egentligen gör)

  • missar tillfällen att agera på grund av överdriven analys (för man är orolig för att man inte tror på vad man gör)

  • odlar misstro och en rädsla för att misslyckas (vem kan lita på vad som görs när ingen gör det på allvar)

  • återupptar igen och igen redan tagna diskussioner och river upp gjorda beslut

I den här presentationen finns inte utrymme att i detalj gå igenom alla dysfunktionerna och hur de åtgärdas, så jag skall kort sammanfatta hur man åtgärdar de 3 ”översta” dysfunktionerna brist på åtagande, avsaknad av prestationsförväntan och brist på resultatfokus.

  • Brist på åtagande åtgärdas genom
    ->konstruktiva konflikter
    ->tydliga mål

  • Brist på prestationsförväntan åtgärdas genom
    ->Team effektivtets övningen, en övning som är som en retrospektiv fast man bara tittar på vad som gör var och en mer och mindre effektiv.

    ->Transparans på vilket arbete vad och en gör genom t.ex. dagliga möten, en öppen whiteboard baserad taskboard, allt sådant som Scrum och Lean ger.

  • Brist på resultatfokus övervinns bl.a. genom
    ->Att man belönar teamet och inte individen.
    ->Att man mäter framstegen teamet gör, på olika sätt
    ->Och återigen genom att man har tydliga både långsiktiga och kortsiktiga mål

Övergripande

Övergripande bör man speciellt initialt när man just startat upp ett team, ta teamet på en off-site event för att under ett par dagar, jobba igenom alla dysfunktionerna och skapa insikt i teamet att detta är något man kommer behöva arbeta med. Detta kan man med fördel upprepa då och då.

Det är viktigt att coachen eller ledaren för teamet föregår med gott exempel, dvs, visar sig sårbar, fångar upp och tillstyrker konstruktiva konflikter, etc.

Teamet måste också jobba med detta varje dag, och har man en bra Scrum process på plats så är retrospektiven utmärkta tillfällen för att diskutera hur teamet fungerar med avseende på dem fem dysfunktionerna och ta fram åtgärder på de punkter man känner att man behöver förbättra sig.

Patricks verktygslåda kan här vara till stor hjälp.

Kurs i The Five Dysfunctions

Jag kommer den 4 februari genomföra en kurs i ”The five dysfunctions of a team” med syfte att i detalj gå igenom de fem dysfunktionerna samt verktygen och övningarna för att bearbeta dem.

För de som inte orkar vänta tills dess, kommer jag också genomföra ett morgonseminarium på Crisp lokaler på Sveavägen 31, den 16 december kl 9-10, där denna presentation, utökad till en del, kommer ges.

My speech at Agile Sweden 2008

The slides from my speech (productive teams) are now available at: docs.google.com/Presentation

Productive Teams

What can you do to make a team productive ?

From the outside you can not make a team productive, but you can provide the right circumstances for a team to be productive. 
But as a team-member on the other hand, there is a lot of things you can do to make your team more productive;

Use agile principles, try to implement TDD, be open, communicative and transparent.
And in my view the most important thing you can do is to keep an positive attitude.
Spread positive vibrations, be positive to your team-member, listen and be empathic, and give a lot of credit when they done something good can make a huge difference on the mental atmosphere in the team.
Productivity has a strong connection to joy and joy is nurtured by feeling safe, well and positive.
All of us can contribute to this on our work, by focusing on contributing as good as we can in the given circumstances.

There are som great obstacles that can destroy a positive mental atmosphere in a team though, and in my opinion the worst two ones are these:


1. Bad self-esteem
2. Negative feelings around some types of challenging tasks (e.g. bugs).

Bad self-esteem is a sickness that is everywhere in the industry.  It has to be fought every day, within yourself and your colleagues.  Everybody feels insufficient and incompetent waiting to be disclosed at any time.  One reason is that we as developers often work with cutting edge technology and have therefore naturally not yet learnt everything.  Almost noone has. But we have unrealistisc expectations on ourselves that we should.  We do know most of what was cutting edge a few years ago but we don’t give ourselves credit for that.  Instead we feel bad for not having studied all new stuff enough.  Stupid. 
Another reason for low self-esteem is the lack of feedback in the organizations we work in. The cure is to give credit, positive feedback and encouragement.
Every day, to all of your team-members!
Giving credit has a double-sided positive effect, both the one giving it and the one getting it feels better and might therefore be more productive.

Challenging problems is a natural part of our work. But all to often we view it as something negative. We let demanding tasks lower our temper and create negative feelings.  This often happens when we face errors in our constructions and don’t know where the errors are.

But our profession is to be problem-solvers, so why don’t we view the problems/challenges for what they actually are: a source for inspiration and development of our competence.
The harder to solve, the more interesting it is, whether it is a bug or a complex construction we need to create.
And if it is a bug we have two interesting problems to solve;
1. How can we identify it and remove it.
2. How did it get there, and how can we change our way of doing things so we don’t create another one the same way.

To be able to think positive and contribute to a productive atmosphere we need to view our team-comrades positive.  That is easiest if we can learn to appreciate them just as they are with their faults and short-comings. Some of them are negative and complaining, others are perfectionists, some are much more competent than we are and others might be pretty incompetent, compared to us we think.
All these assessments is better to put aside and instead view the team as one body, a unity of which we are part in.  If we shall contribute in the best possible way we need to be helpful and willing to do good for our team-members.
Help them to develop when we can share of our ourselves and our own competence. Be humble and understand when we ourselves have a chance to develop by listening and learning.


There is so much more to say about mental attitudes and circumstances we can help to create to raise the productivity like the importance of having fun, the importance of finding the meaning in ones work, the importance of trust.

I will write about these things further on, but in the meantime I must say thank you that you took time for reading my blog.
If you have time to make the effort I will be even more thankful if you write comments irrespective if you have other complimentary or differing thoughts in these matters.