Motstånd mot förändring – en kort genomgång

Som de som regelbundet läser denna blogg är jag ju “en av de där agila snubbarna”. Självpåtagna världsförbättrare som evangeliserar om hur underbart det är att vara lättrörlig, flexibel, smidig, “agil”. Vi försöker förtvivlat att få den värld som utvecklar produkter och system att förstå att förändring är något positivt som vi kan utnyttja och att vi inte kan eliminera människan ur arbetsmetoder för människor. Bland annat.

Det låter väl inte så farligt, kan jag tycka, men många avskyr oss – med viss rätt ibland, när ivern att förbättra går över styr. En insikt som många som arbetar med förändring gör förr eller senare är att människor inte vill förändras. Om de ska förändra sitt beteende måste de göra det på sina egna villkor och på sitt eget sätt. De måste vilja det själva. Det här krockar ibland med folk som brinner av iver att “förbättra” (förändra).

Ibland är det dock andra saker som står ivägen. Jag tänkte ta upp några varianter som jag har stött på. En del som ogillar agilt verkar göra det under förevändningen av sund skepsis. Det här personer som är stolta över att vara de som är “lite besvärliga”. De njuter nästan av att vara den ensamme som går mot strömmen. De kanske tänker:

“Jag köper minsann inte vad som helst. Att det där snacket om att ‘älska förändring’ skulle ha någon effekt kan dom ju försöka slå i någon annan. Och förresten, det vi gör idag fungerar väl rätt bra. Vi behöver bara att bli bättre på att dokumentera kraven innan vi börjar jobba.”

Missförstå mig inte nu, skepsis är nyttigt. Att ha en djävulens advokat i teamet är viktigt. Men agila metoder har utmanat och förbättrat sättet på vilket vi utvecklar mjukvara i snart 10 år nu och grundtankarna har ju ca 40 år på nacken så jag kan tycka att det kanske är dags att coola ner skepticismen vid det här laget.

En annan motståndsgrupp är de som målat in sig i ett hörn. De började som öppna skeptiker och har nu svårt att öppet ändra sig. De kan mycket väl ha sett vilken effekt det här kan ha på ett team, men de är låsta i sina positioner. De har tagit ställning emot det från början (“flum!!”) och kan ju inte gärna backa nu utan att förlora ansiktet. De verkar tro att deras prestige står på spel om man öppet ändrar sig. (En kommentar om det: Jag måste säga att jag tvärtom har respekt för personer som först hävdat det ena och sedan öppet går ut och säger att man hade fel. Det tyder ju i alla fall på att man ständigt reflekterar över vad man tycker.)

Det intressanta är att det enda som behövs för att dessa personer ska ändra sig är att de byter jobb. Jag har sett personer som varit ointresserade av agila metoder eller rent av öppet fientliga bli chefer för agila avdelningar på sitt nästa jobb. De har ju jobbat på ett “agilt företag” så det borde väl kunna det där. Som ett litet sidospår vill jag passa på att avslöja en sak: Det finns inga agila konsultbolag. Allt som finns är personer som i sin inställning är mer eller mindre agila. På ett konsultbolag av, säg 100 personer, finns allt ifrån personer med stor kunskap och lång erfarenhet till nybörjare till folk som är helt oagila i de sätt de arbetar. Det finns små konsultbolag där en större andel av personerna besitter mer kunskap, men även här skiljer det sig mellan individer. Hur som helst, prestige kan vara ett överraskande stort hinder.

Ytterligare en variant av motstånd som jag har stött på är de som är motståndare av, ska vi kalla det, personliga skäl. En grupp är personer med någon form makt, teknisk eller politisk. De tycker sig inte ha någon anledning att införa ett arbetssätt som de, kanske fördomsfullt, tror kommer att beröva dem den makten. Det kan vara systemarkitekter med bristande ödmjukhet som tycker sig veta bättre än övriga omkring sig trots att de lämnat “kodandet” bakom sig. Eller projektledare med stort kontrollbehov och smått sadistiska drag:

“Varför vara jämlikar när jag kan vara på rätt sida av piskan?”

Ja, varför? För att det kanske är trevligare för alla parter? För att det kanske är bättre för företaget i stort?

En något oväntad version av detta är hjälteprogrammeraren, som ofta kan vara en stor motståndare. Det är främst arbetssätt som testdriven utveckling och parprogrammering som de hakar upp sig på. Det här kan i vissa fall även här vara ett uttryck för en uppblåst syn på sig själv och sitt bidrag. Många verkar tänka så här:

“Mitt jobb är att skriva den bästa och mest perfekta koden, inte slösa tid på att lära upp massa n00bs som aldrig kommer att fatta något ändå. Och varför testa när jag skriver felfri kod direkt?”

Det är synd, för det är svårt att bli duktig på ett hantverk som programmering om man inte har en mäster bredvid sig som hjälper en att bli det. Förutom ett uppblåst ego finns ofta en hel del rädsla involverat. Kanske har de en gnagande känsla av att de kanske inte är så bra som de påstås vara och ett nära samarbete med andra skulle obönhörligen avslöja ett och annat?

Sen finns det folk med ett legitimt skäl att inte tycka om agila metoder: Okunskap. Det är de här människorna som har blivit lärda från början att tro att vi kan ta reda på alla krav i början, att vi måste låsa fast saker för att förhindra “kravglidning” (deras ord, inte mitt), att vi kan gå enkelriktat från krav till design till program till test och att planer är till för att hållas, inte visa verkligheten. De här personerna har jag personligen mycket enklare att hantera. De har ingen dold agenda, inte till att börja med i alla fall.

Gemensamt för alla personer av den sista sorten är att de aldrig har programmerat, möjligen i preskriberad tid på universitet på någon kurs eller på första jobbet för några decennier sedan. Det är slående hur väl det här stämmer. Och ändå är de så tvärsäkra på hur världen är inrättad. Alla proffs (de som har programmering som en del av sitt yrke) vet hur det ligger till. Ändå vankar vi av och an som oroliga föräldrar, reflekterar och experimenterar. Var det inte så han sa, Bertrand Russell,

Felet med vår värld är att de dumma är så säkra på sin sak och de kloka så fulla av tvivel“.

4 thoughts on “Motstånd mot förändring – en kort genomgång

  1. Jag tycker nog att den “sunda skepsismen” egentligen är ganska sund. Att utveckla agilt är dels att gilla förändring, refaktorisera så det blir snyggt etc, men också att ha en väl uppbyggd verktygslåda med bland annat testmetodik så att man klarar av att hantera förändringarna.

    Om man sätter igång att refaktorisera utan att ha täckande tester så är det stor risk att det blir fel, och om man skriver en massa tester för kod man ändå aldrig vågar ändra på har man lagt ned onödigt mycket tid på testerna.

    För att lyckas med agil utveckling krävs det ganska mycket insikt i vad agil utveckling egentligen innebär, annars blir det lätt “business as usual”, fast man kastar bort en kvart om dagen på att lyssna på medarbetare berätta saker man inte begriper om vad de håller på med.

    Ett bra sätt att lära sig agil utveckling (eller i alla fall ett sätt som kändes bra för mig) är att ifrågasätta allt och ha en mentor eller två som trycker på och motiverar. Tack till dig och Ulrika för att ni hade tålamod med mig! 🙂

    • Hej Rasmus! Tack för det och för den mycket insiktsfulla kommentaren. Jag håller med dig, sund skepsis är bra och behövs. Det är när skepsisen har blivit en ryggmärgsreflex som förhindrar mig att se bättre eller att prova saker och förbättras som den blir ett hinder. Det var den typen jag avsåg i inlägget.

  2. Jag tror att du kan lägga på ca 1 miljard år till de 40 du du nämner. Vissa grundtankar är ju snarare hur naturen beter sig, tex iterativ, inkrementell och evolutionär utveckling i generationer med Darwinistisk eliminering av slöseri, återkoppling i neurala nätverk tom på rundmasknivå mm.

    Det kanske inte är en slump att en av de första “agila” metoderna hette Evo…😉

    Tack för intressant läsning!

Comments are closed.