”A common concern is that one dominating personality, such as a tech lead, will decide that self-organization means he or she gets to make all decisions. Or one dominating personality will force his or her will on the team before the team even has a chance to discuss an issue.”
Self-Organizing Teams Are Not Put Together Randomly
I vissa agila team kan problemet ofta vara för intolerant och dominant beteende från vissa ”lead developers”, för vissa utvecklare som jobbat länge enligt det traditionella sättet och varit van att ha en sorts lead developer position och vara den som bestämmer mycket kan ha väldigt svårt att ställa om till ett agilt arbetssätt som bör vara rätt demokratiskt där alla i teamet ska få ta plats och utvecklas.
Sen detta med teamsammansättningen, ska man jobba med en viss teknologi, plattform eller ramverk bör teamet bestå av folk som vill göra det med vilket bara är sunt förnuft, så grundtanken med scrum och agilt är inte att arbetsuppgifterna ska anpassas till teamet eller en dominant lead developers personliga preferenser, utan att teamet ska anpassas till arbetsuppgifterna.
Det är arbetsgivaren som bestämmer dessa men bör självklart rådfråga teamet med så dessa får rimliga förutsättningar för att göra dem i form av verktyg, utbilding och kanske tillskott av personer med den nya kompetensen.
Ni ska sträva efter ett fungerande agilt team där alla tillåts ta plats och utvecklas, och inte ett team där en gammaldags egocentrisk lead developer dominerar allt och kväver de andras utveckling och vill ha som denne vill jämt.
Att ni därför ibland har en annan åsikt eller lösningsförslag än dessa kan kanske uppfattas som provokativt av dem och ibland kanske det trampar dem på tårna, men fundera då på hur låg nivå på deras intolerans ni ska behöva anpassa er till om dessa samtidigt själva jämt påstår att de vet allt bäst och kör över alla andra?
Anpassar man sig för mycket så blir det så att en dominant lead developer tar över och kväver teamets utveckling vilket inte är bra, och dessutom blir det oftast en för ensidig syn på vilka lösningar man ska välja.
Det kan även finnas tillfällen när ett projekt är både tids och verksamhetskritiskt och den gammeldags lead developern för att denne jämt ska ha som den vill insisterar på att teamet ska göra det han vill inom områden där denne inte vet bäst eller väldigt lite, och får teamet att göra saker som slösar bort så mycket tid på antingen överkomplicerade bra att ha finesser som inte är nödvändiga, eller leder in teamet på fel spår och riskerar att projektet inte kommer hinna bli klart i tid.
I sådana lägen måste ni om ni är den i teamet som vet bäst inom just det området direkt utmana denne och försöka styra in projektet och teamet på rätt väg igen, för i ett sånt läge kanske man inte kan vara för diplomatisk om de övriga i teamet går i lead developern ledband av gamla vana, så då kan ni själva bli tvungna att bete er som en dominant lead developer i vissa sakfrågor för projektets bästa.
”So how does an agile leader achieve the subtle balance between command and influence? Suppose you are a Scrum Master for a team. You’ve noticed that one team member, Jeff, is domineering and no one is willing to stand up to him. This team has self-organized—it has chosen to let Jeff make all key decisions. As the Scrum Master for this team, though, you recognize that if Jeff continues to make all the decisions on his own it will impede the team’s efforts to improve.”
The Role of Leaders on a Self-Organizing Team
När ert team har retrospektiv ska ni även utnyttja tillfället till att var raka och ärliga med era egna åsikter utan att vara onödigt otrevliga eller personkritiska, och ta tillfället i akt att utmana för dominanta och egocentriska lead developers där med.
Men ni ska inte utmana bara för utmanandets egen skull utan bara när ni tycker ni har ett bättre förslag, ser felaktigheter i deras eller tycker teamet behöver diskutera och tänka igenom den dominanta medlemmens förslag bättre först, så det ska finnas verkliga skäl till det.
”This is a strong retrospective for bringing issues up to the surface. Instead of just one person expressing an issue as a positive or a negative, the whole team feedbacks about the importance of the issue. The team then decides which issues to tackle. The retrospective also exposes issues where there is not common view, and highlights areas of alignment. It also allows the team to ask tough questions in a safe environment.”
Observera också att en dominant team medlem inte nödvändigtvis behöver vara aggressiv och utåtriktad utan kan vara av den skenheliga passivt dominanta typen som när saker diskuteras är lite mer av typen påstridig besserwisser, och om andra inte gillar hans lösningsförslag så gör som den vill i alla fall om det är en uppgift personer kan göra helt själv, och blir sur och distanserad om man inte tycker som denne.
Den typen av personer kan även vara rätt bakfalska och springa till cheferna och klaga om de inte får som de vill, eftersom de oftast inte tar direkta konflikter men ändå vill få som de vill i alla fall, och dessa kan vara betydligt svårare att hantera än den aggressivt dominanta typen.
Sen finns en annan typ av dominanta personer som egentligen bara är väldigt pratglada och tycker om att diskutera saker, och ibland kanske de vill övertyga andra för att teamet ska undvika kostsamma misstag, men dessa vill inte nödvändigtvis alltid få som de vill utan vill kanske bara diskutera saker och vara hjälpsamma.
Oavsett vilken sorts dominanta personlighet ni har att göra med så kan nedanstående tips vara bra.
Robert Forsström's Blogg 