Categories
Metod

Måste utvecklare vara supermänniskor?

“Jag blir tokig på honom, han måste förstå att han är en del av ett team!” sa personen tvärsöver bordet upprört till mig. “Han vill inte vara social. Han vägrar prata med beställarna, vi måste tvinga iväg honom eller prata med dem åt honom, han vill bara sitta i sitt hörn ostört och arbeta! Han måste skärpa sig!”

sofia_cirveriusBara några veckor innan denna diskussion hade jag sett ett bra TED-talk vid namn “The power of introverts” och läst två bra artiklar om skillnaderna mellan den introverta personlighetstypen och den extroverta. “Kan det kanske vara så att han verkligen tycker att det är jobbigt att gå iväg och prata med beställarna?” frågade jag försiktigt. Svaret kom omedelbart “Han får skärpa sig, det är en del av jobbet och det vet han!”. “Men om det verkligen inte är hans grej?”

En gång i tiden var jobbet som utvecklare perfekt för den som gillade logiskt och pragmatiskt tänkande och ville sitta i lugn och ro och koncentrera sig på sin egen kammare. Idag kräver vi mycket av våra utvecklare. Den ultimata utvecklaren i ett agilt team är inte bara en grym programmerare, utan även social, har lätt för att samarbeta och stötta sina kollegor, parprogrammerar gärna, kodgranskar andras kod och lägger fram konstruktiv kritik på ett bra sätt. Utvecklaren ska givetvis vara bekväm med att prata med beställare, kunder eller verksamhetsmänniskor och dessutom lyckas kommunicera med dem på ett språk de förstår. Utvecklaren är också bekväm med att göra snygga demos av produkten, vara med på oändliga möten, och kan både skriva bra och tala inför folk.

“Man blir ju inte utvecklare för att man tycker om att prata med människor” brukar jag ofta skämtsamt säga, men ändå med ett visst mått allvar. Det finns ett skäl till att de flesta utvecklare inte är säljare eller marknadskommunikatörer. De värdesätter förmodligen mer logiskt tänkande, pragmatiska lösningar och att brottas med problem, än att småprata om vädret och bygga relationer över en kaffekopp. Vi begär inte att en kommunikatör ska kunna sätta upp en databas, utveckla en knepig funktion mot ett bökigt API eller kunna läsa Perl. Däremot förväntar vi oss gärna att en utvecklare ska ha fantastiska kommunikativa egenskaper, kunna göra snygga presentationer och kunna skriva både bra dokumentation och informationstexter. Är utvecklare alltid supermänniskor?

Om tanken med agila metoder i allmänhet och scrum i synnerhet är teamansvar och förtroende för människor, borde inte alla typer av människor passa in då? Är inte första punkten i agile manifesto “Individuals and interactions over processes and tools”/”Individer och interaktioner framför processer och verktyg”? Borde inte det innebära att en duktig introvert i ett team är viktigare än att följa processen – Scrum, till punkt och pricka?

artikelbild_superutvecklare
Exempel på hur olika teammedlemmars kompetens kan överlappa och komplettera varandra.

Om ett team innehåller någon som inte trivs med att kommunicera utanför teamet, som vill arbeta lite mer enskilt, bör inte teamet då gemensamt hitta ett sätt att förhålla sig till det? Om Lisa är grym på att skriva automattester och kodgranska, men inte lika bra på att knepiga serverapplikationer, är inte det okej då? Om Stefan är fantastisk på knepiga algoritmer men bör hållas långt borta från grafiska gränssnitt, så gör inte det något för att Tomas älskar front-end-utveckling. Så om Fredrik tycker att det är påfrestande att prata inför mycket folk på daily standup eller demos, och föredrar att prata i mycket små grupper och inte trivs med att småprata med beställare, bör vi inte kunna lösa det i ett välfungerande team?

Jag ser och hör gång på gång exempel på personer som anser att vissa personlighetstyper inte passar in i agila team och att de väl “får söka sig någonannanstans”, samtidigt som de är övertygade om att agila metoder är bäst för systemutveckling. Individer över processer och verktyg. Gemensamt teamansvar. Bör inte det innebära något även i det här fallet?

Leave a Reply

Your email address will not be published.