7 min

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.

Michael Hansson

Jag skulle få ett team att börja skriva tester.

Inte för att någon bad mig. Jag var konsult, inte teamledare. Jag hade ingen titel. Inget mandat.

Men jag såg att teamet bröt sönder samma grejer varje vecka. De buggade ner produktion. De spenderade mer tid på att fixa än att bygga nytt.

Jag kunde ha gått till projektledaren och sagt: “Ni måste börja skriva tester.”

Men jag visste vad som skulle hända. Hon skulle nicka. Säga “Ja, absolut, bra idé.” Och sen skulle ingenting hända.

För folk vill inte bli förändrade.

De vill förändra sig själva.

Så jag gjorde det här istället.

Vecka 1: Jag började smått

Jag skrev inte ett memo. Jag bokade inte ett möte. Jag sa inte “vi måste börja skriva tester.”

Istället skrev jag ett test. Ett enda.

För den del av koden som buggade mest. Den som bröt varje vecka. Den som alla var trötta på.

Jag pushade det. Sa ingenting.

Nästa dag buggade samma kod igen. Men den här gången caught testet det innan det nådde produktion.

Någon i teamet sa i standup: “Vad bra att det testet fanns. Det räddade oss.”

Jag sa: “Ja, det var nice.”

Inget mer.

Vecka 2: Någon annan började också

En utvecklare kom till mig. “Kan du visa hur du skrev det där testet?”

Jag visade. Tog 10 minuter.

Nästa vecka skrev han ett test själv. För en annan del som buggade ofta.

Det funkade.

Någon annan märkte. “Fan, bra idé.”

De började prata om det i Slack. Inte för att någon sa att de skulle. Utan för att det hjälpte.

Vecka 3: Motståndet började

En senior utvecklare sa i standup: “Jag hinner inte skriva tester. Vi har för mycket att leverera.”

Jag sa ingenting.

Men efter standup gick jag fram till honom. “Hur mycket tid spenderade du på att fixa den buggen i produktion förra veckan?”

“Två dagar.”

“Vad tror du, om du hade haft ett test - hade du upptäckt det innan du deployade?”

Tystnad.

“Troligtvis.”

“Så du hade sparat två dagar på 10 minuter.”

Han nickade. “Okej, jag fattar. Men jag hinner fortfarande inte.”

“Du behöver inte skriva alla tester. Börja med den del som buggar mest.”

Nästa vecka skrev han sitt första test.

Vecka 4: Jag frågade istället för att säga

I retrospektivet frågade jag: “Vad tror ni är anledningen till att vi fick göra om featuren tre gånger den här sprinten?”

Någon sa: “Vi visste inte att vi bröt den gamla koden.”

Jag frågade: “Hur kunde vi ha vetat det tidigare?”

Någon annan sa: “Om vi hade tester hade vi sett det direkt.”

Inte jag. Någon annan.

Jag sa: “Bra idé. Ska vi börja skriva fler tester?”

Folk nickade. För det var deras idé nu. Inte min.

Vecka 5: Projektledaren började ifrågasätta

Projektledaren kom fram till mig efter standup.

“Varför spenderar teamet så mycket tid på tester nu? Det tar ju tid från features.”

Jag sa: “Hur många buggar fixade vi förra sprinten?”

“Fem.”

“Och de tog hur lång tid?”

Hon tittade i sina anteckningar. “Cirka åtta dagar totalt.”

“Vad tror du de hade tagit om vi hade tester som caught dem innan deploy?”

Tystnad.

“Okej, jag fattar. Men stakeholders frågar varför vi levererar långsammare.”

“Vi levererar inte långsammare. Vi buggar mindre. Förra sprinten gjorde vi om samma feature tre gånger. Nu gör vi den en gång.”

Hon nickade. “Okej. Jag ska förklara det för dem.”

Vecka 6: Teamet började äga det

Jag hörde två utvecklare prata i lunchrummet.

“Ska du skriva tester för den här featuren?”

“Självklart. Annars buggar jag ner det igen.”

“Fan, bra. Kan du visa mig hur du gör?”

Jag sa ingenting. Blandade mig inte i.

För nu var det inte mitt initiativ längre. Det var deras.

Vecka 8: Det blev standard

Projektledaren frågade i standup: “Ska ni skriva tester för den nya featuren?”

Teamet sa: “Ja, självklart. Varför skulle vi inte göra det?”

Hon sa: “Bra initiativ.”

De sa: “Tack.”

Jag sa ingenting.

För det var inte mitt initiativ längre. Det var deras.

Och det var därför det funkade.

Varför det funkade

Jag tvingade ingen. Jag sa inte “vi måste.”

Jag visade istället. Jag planterade idén. Jag lät dem hitta den själva.

Folk äger saker de känt att de varit med och skapat.

De försvarar beslut de känt att de påverkat.

Så om du vill få igenom en förändring - tvinga inte. Bjud in.

Principerna från testprojektet

1. Börja så litet att ingen kan säga nej

Ett test. Ett enda. För den kod som buggade mest.

Inte “vi måste införa testdriven utveckling”. Det hade skrämt folk.

Utan: “Jag skrev ett test för den här grejen som buggar varje vecka.”

Så litet att det nästan var löjligt att protestera mot.

2. Visa värdet innan du pratar om det

Testet caught en bugg innan produktion. Folk såg att det funkade.

Jag behövde inte sälja in idén. Den sålde sig själv.

3. Låt andra komma på idén

I retrospektivet frågade jag: “Hur kunde vi ha vetat det tidigare?”

Någon annan sa: “Om vi hade tester.”

Inte jag. Någon annan.

Då blev det deras idé. Inte min.

4. Gör första steget löjligt lätt

“Du behöver inte skriva alla tester. Börja med den del som buggar mest.”

Om första steget känns för stort - ingen gör det.

Om det känns hanterbart - folk börjar.

5. Hantera motståndet tidigt

När senior utvecklaren sa “jag hinner inte” - jag argumenterade inte.

Jag frågade: “Hur mycket tid spenderade du på att fixa buggen förra veckan?”

Låt dem själva räkna ut att de sparar tid.

6. Bygg stöd innan du öppnar munnen

Jag skrev testet först. Någon annan började också. Sen i retro blev det “officiellt”.

Inte tvärtom.

Om jag hade börjat med retro hade hälften himla med ögonen.

Men när det redan funkade för två personer - då blev det självklart.

7. När de börjar äga det - backa

Vecka 6: Jag hörde utvecklare prata om tester i lunchrummet.

Jag sa ingenting. Blandade mig inte i.

För nu var det deras. Inte mitt.

Och det var därför det höll.

Samma principer funkar för allt

Det här är inte bara om tester.

Samma principer funkar för allt - från UX till infrastruktur till processer.

Börja smått. Visa värdet. Låt andra hitta idén. Gör det lätt att börja.

På måndag

1. Skriv ett test. Inte för att någon bad dig. För den kod som buggar mest.

2. När nästa bugg caught - säg ingenting. Låt folk märka.

3. När någon frågar hur du skrev det - visa. Ta 10 minuter. Gör det lätt.

Förändring utan titel handlar inte om att ha rätt.

Det handlar om att göra det så lätt att säga ja att folk väljer det själva.

Och när du lyckas med det - då är förändringen äkta.

För folk gjorde den inte för att de blev tvungna.

De gjorde den för att de ville.

Delar i serien

Denna artikel är del 4 av 5 i serien "Leda utan titel"

1
2
3
4
Du läser denna del nu
5

Framsteg i serien

100% komplett

5 av 5 delar publicerade