Det pratas mycket om agil coaching och om vikten av att arbeta på rätt sätt. Samtidigt slås jag många gånger av hur skevt stöd och hjälp fördelas i utvecklingsprocessen. Vi lägger timme efter timme på att diskutera om estimering ska ske i timmar eller story points, på ändlösa bataljer kring om en sprintlängd på en vecka är mer agilt än tvåveckorssprintar och inte minst på workshops kring hur man bäst river loss en Post-It-lapp.
När det kommer till själva kärnan i det vi håller på med, nämligen att skapa mjukvara och skriva kod, lämnas utvecklarna allt som oftast åt sitt eget öde. Här är det inte tal om att handplocka in externa ess som hjälper teamet att utvecklas inom de tekniska aspekterna av det agila hantverket. Detta trots att stinkande, rutten kod är lika svårförvaltad även om den utvecklats i en puristisk Scrum-värld dikterad och välsignad av självaste Jeff Sutherland. I mina ögon borde det därför vara minst lika självklart att ge utvecklingsteam teknisk coaching som det är att coacha Scrum Masters, produktägare och ledningsgrupper i agila arbetssätt.
Vad är teknisk coaching?
Grundbulten i teknisk coaching är att få utvecklingsteam och dess medlemmar att växa som utvecklare, att de ska förädla sina kunskaper och inte minst att utvecklas gemensamt som team. Det jag anser ha absolut högst prioritet rent tekniskt är att få utvecklarna att se nyttan, att behärska och att använda sig av de grundläggande tillämpningar som beskrivs i XP (eXtreme Programming). När väl dessa pusselbitar är på plats kan det vara läge att bygga vidare med mer situationsanpassad coaching utifrån de förutsättningar som finns i den specifika organisationen. Inom bankväsendet skulle det till exempel kunna vara aktuellt att fördjupa sig inom säker utveckling.
Hur kommer du igång med teknisk coaching?
På många arbetsplatser finns det idag en “lead developer”, en arkitekt eller liknande som ansvarar för teams kollektiva utveckling. I praktiken har jag väldigt sällan sett detta fungera. Personer med sådana roller är ofta upptagna av att springa på möten, läsa kravspecar, hjälpa säljorganisationen, skriva styrdokument och slåss med ledningsgrupper. Tiden de har att lägga på teknisk coaching är i princip lika med noll.
Det behövs en attitydsförändring hos såväl de som sitter i de ledande utvecklarrollerna som hos de som håller i prioriteringsordning och pengapåsar. Organisationens framtida överlevnad hänger många gånger på att bibehålla och bygga kompetens även inom teknikområdet.
Självklart finns det ingen universallösning på hur man ska lyckas. Till viss del hänger det också på vilken nivå team och teammedlemmar befinner sig. Oavsett tillvägagångssätt är dock prio ett att skapa acceptans för aktiviteten inom organisationen. Att höja kompetensen bland utvecklarna är något som alla drar nytta av och det bör därför vara en prioriterad och kontinuerlig aktivitet som är väl förankrad hos såväl utvecklare som projektledare, ledningsgrupp och andra intressenter.
När detta väl är gjort är det dags att sätta igång. Jag har under åren noterat ett framgångskoncept som, med relativt liten insats, ger bra återbetalning. Det jag syftar på är korta, återkommande sessioner med gruppcoaching. När väl detta fungerar brukar även bitar som mentorskap och lärande komma mer eller mindre automatiskt.
Fem enkla tumregler för teknisk gruppcoaching
1. Hela teamet deltar
Alla som utvecklar i teamet ska vara med och delta. Inga undantag. Det finns många fördelar med detta. Den största poängen är att medlemmarna börjar kommunicera och prata kod med varandra – inte bara bästa polarna utan även den där introverta hackern i hörnet börjar diskutera testramverk med den nya tjejen. Till och med han som alltid morrar så fort någon pratar med honom kommer visa sig vara ganska trevlig. Den här kommunikationen kommer gruppen att ta med sig även utanför coachsessionerna. Det är guld värt för teamdynamiken.
En fälla att se upp med är att det nästan alltid är någon som tror sig ha en uppgift som är viktigare än gruppcoaching. Kortsiktigt är det kanske så. Fråga dig då: kommer företaget förlora miljontals kronor om han lägger 90 minuter på kompetensutveckling? Kommer någon att dö? Om svaret är nej så ska han vara med. Punkt.
Nästan lika vanligt är det med “jag kan redan det här”-primadonnan som inte ser någon poäng i att vara med. Detta är ett knepigare fall men också en strålande möjlighet. Är personen i fråga verkligen så vass som hon tror? I sådana fall är det ju ett utmärkt tillfälle att skola in ytterligare en teknisk coach och mentor.
2. Mobbprogrammera
Jag brukar förespråka gruppcoaching i form av mobbprogrammering. I dessa sessioner turas alla om att parprogrammera där navigatören alltid är den som styr vad som ska göras och kommunicerar detta till personen i förarstolen. På så vis undviks situationer där den som har fingrarna på tangentbordet kodar på i tystnad medan övriga försöker hänga med.
Några andra riktlinjer att förhålla sig till är:
- Byt plats ofta, var femte minut kan vara en bra tumregel.
- Alla ska prova på att vara såväl driver som aktiv navigatör, varje session.
- Den som håller i tangentbordet ska ta “små steg” framåt. Det är snudd på omöjligt för omgivningen att hänga med om det görs stora förändringar i ett svep eller om de magiska kortkommandona används alltför friskt.
- Telefoner, laptops och liknande är förbjudet. Fullt fokus från alla på skärmen/duken.
3. Använd XP-principerna
Som jag nämnde ovan är ett av huvudmålen med teknisk coaching att få teamet att anamma XP-principerna. Det kan då verka onödigt att påpeka att man ska använda XP i coachsessionerna. Men det kan faktiskt vara lätt att bara fokusera på en eller två av tillämpningarna och glömma bort de andra tio. Ha därför de tolv tillämpningarna i bakhuvudet hela tiden. Se till att checka in ofta, håll er till en gemensam kodstandard, refaktorisera kontinuerligt bort onödig komplexitet, skriv automatiska tester och så vidare. Det här ska sätta sig i ryggmärgen hos utvecklarna, inte bara vara något man tar till vid utvalda tillfällen.
4. Produktionskod/produktionsproblem
Fabricerade problem ger ofta tillrättalagda lösningar som är svåra att anpassa till verkligheten. Jobba istället i den vanliga kodbasen. Ta utgångspunkt i en svårlöst bugg, refaktorisera en obskyr klass med 3000 rader eller skriv automatiska tester för den där modulen som saknar testtäckning. Det spelar egentligen inte så stor roll vad ni gör så länge ni jobbar med verkliga problem. Utvecklarna kommer att känna igen sig på ett helt annat sätt och dessutom slår man två flugor i en smäll. Dels lyfter man den generella kompetensen inom teamet, dels skapas nytta och affärsvärde under tiden.
5. Ha det så roligt
Coachingsessionerna ska vara något som teamet ser fram emot. Det ska inte vara en börda. Jag förordar därför kortare pass, en till två timmar. Sena kvällar, måndagmorgon och andra skumma tider är inte att föredra. Försök istället göra något positivt av det och se det som en investering som på sikt kommer att betala av sig med ränta.
Börjar teamet skruva på sig och titta på klockan? Ta en paus och gå och fika.
Känns det som att ni står och stampar och inte kommer vidare? Gör något annorlunda nästa gång – bjud in frontendarna och hacka Javascript.
Avslutande ord
Självklart är inte detta enda vägen framåt men det är en möjlig väg som visat sig fungera under vitt skilda förutsättningar. Förvänta dig dock inte att coachsessioner någon gång i månaden är det enda som behöver göras för att maximalt boosta teamet. Dock är det en strålande start. Kombinerat med andra insatser som utbildning, självstudier och mentorskap på individnivå, kan det vara nyckeln som förvandlar ditt utvecklingsteam från ett halvtrött team till ett högpresterande superteam.
