Driv igenom förändring – utan att trampa någon på tårna
Om förändringsledning underifrån. Hur man får saker att hända utan att skapa motstånd.
Jag ville få ett team att börja skriva tester. Jag var konsult och hade inget mandat att ändra deras arbetssätt. Men samma delar av koden gick sönder igen och igen, och teamet lade för mycket tid på att laga det de nyss byggt.
Att säga ”ni borde skriva tester” hade knappast varit en nyhet för någon. Frågan var hur vi skulle få plats med det i arbetet.
Börja där felet redan kostar tid
Jag skrev ett test för en del av koden som ofta krånglade. När samma fel dök upp igen upptäckte testet det innan det nådde produktion.
Det gav oss något konkret att prata om. En kollega ville se hur testet fungerade och började sedan skriva ett eget för en annan del av koden.
Vi hade inte infört en ny teststrategi. Vi hade visat att ett litet test kunde hjälpa mot ett återkommande problem.
”Jag hinner inte” är en invändning att ta på allvar
En senior utvecklare tyckte fortfarande att tiden saknades. Vi pratade om buggen han nyligen lagt två dagar på att fixa och om ett test hade kunnat upptäcka den tidigare.
Det gjorde kostnaden synlig. Men det trollade inte fram mer tid i sprinten. För att få plats med tester behövde vi också prata om vad teamet skulle hinna leverera.
När projektledaren undrade varför vi lade mer tid på tester kunde vi peka på omarbetet. Samma funktion hade behövt göras om flera gånger. Det var också utvecklingstid, även om den inte syntes som en egen post i planen.
Låt teamet vara med och bestämma
I retrospektivet tog vi upp vad som hade kunnat hjälpa oss att upptäcka felen tidigare. Fler tester var ett av förslagen. Nu fanns erfarenhet i teamet att bygga vidare på, och fler började använda dem.
Det är skillnad på att bjuda in folk och att manipulera dem till att tro att din idé var deras. De måste få ifrågasätta upplägget och ändra det. Annars har du bara paketerat ett färdigt beslut lite snyggare.
Vad jag tar med mig
Börja med ett problem folk redan vill bli av med. Gör ett litet försök och visa vad som hände. Prata sedan om vad det kostar att fortsätta och vad som behöver prioriteras bort.
Det här passar förändringar som går att prova i liten skala. Större beslut om säkerhet, arkitektur eller ansvar behöver förankras innan någon börjar experimentera.
Ett fungerande exempel kan göra mycket av jobbet. Men någon måste fortfarande ge teamet utrymme att arbeta på det nya sättet.
Exemplen är förenklade och bygger på situationer från verkligheten. Dialoger och detaljer är bearbetade för att göra resonemanget tydligt.