Stanna inte vid klipp-och-klistra
Under en lunch för inte så länge sen hamnade jag och en kollega i diskussionen om paragrafryttare, de som ska följa varenda liten skrivelse i ett ramverk konstant för att annars ’bryter vi mot ramverket’. Under konversationen sa jag att eftersom jag är en person med ’regler är till för att brytas’-mentalitet, kan man väl säga att jag har väldigt svårt att klicka med personer som alltid ska ha regelboken i högsta hugg och vägrar tumma på linjen.
Så kom frågan, ’Men Kattarina, du är ju kravanalytiker, du skriver ju krav som i princip är regler, hur går det ihop?’ – Jo det ska jag försöka svara på.
Jag älskar ramverk som bygger struktur man kan luta sig tillbaka på, och som förenklar vardagen genom att man vet hur man ska gå till väga. Men jag avskyr när regler eller processer slutat uppfylla sina egentliga syften och syftet blir i stället att enbart följa processen. När en process följs slaviskt utan att någon förstår varför man gör som man gör, och vad man försöker uppnå genom att göra så, då försvinner min kärlek till processen och jag förbereder min mentala brottningsposition för att börja ifrågasätta.
Att jag i mitt jobb som kravanalytiker – eller kravare som jag lite trivialt brukar kalla det – alltid ställer frågan ’Varför?’ har sin grund i min frustration för processer utan syfte. Att ställa frågan varför, gärna gång på gång, har inte bara att göra med att det är en vedertagen strategi för felsökning och problemlösning, utan för att det är ofta så man kan komma till syftet för ett steg i en process eller hela processen. Kort och gott – varför gör vi så här?
Och ännu viktigare – måste vi göra så här?
Så när någon då säger ’Nej det kan vi inte göra för det bryter mot vår process’ så blir min första fråga alltid varför spelar det någon roll att det gör det? Detta är speciellt sant när någon säger ’Detta bryter mot vår agila process.’
En av de 4 grundvärderingarna för agil utveckling är ju just: Individer och interaktioner över processer och verktyg. Och den värderingen kan hårdras till att så fort man bygger en process för att vara agil, så är man inte längre agil.
Faktum är att det är denna värdering som får organisationer att göra raka motsatsen, att inte ha några processer eller verktyg alls med argumentet att det är agilitet. Det finns en gnutta sanning i det, att en avsaknad av process och verktyg leder till interaktioner mellan individer som helt enkelt löser problem när de dyker upp.
Men det har också blivit ett etablerat frikort för organisationer att slippa bygga processer med argumentet ’Det är agilt’. Se till exempel Colin Bryar och Bill Carrs artikel ”Have we taken agile too far” i Harvard Business Review, som pratar just om det och hur man applicerar agilitet på allt i en organisation bara för att vara agil.
Det kan lätt bli så att ju mer man följer ett ramverk om agilitet utan att man applicerar den autonomi som det ska rymma, desto mindre agilt blir det, och det blir snabbt mer oflexibelt än vattenfall och mer micromanagement än något annat. Syftet brukar också försvinna från processerna så fort man accepterar att man ska följa processen bara för att – och slutar ifrågasätta, förbättra och förnya dem.
Det finns lite olika sätt för hur man adopterar agila processer utan att bli en regelryttare som inte ifrågasätter, bland annat Shu-Ha-Ri som stöds av bland annat av Martin Fowler, en av skaparna av ’Agile Manifesto’.
Konceptet kommer från japansk kampsport och kan förenklas till;
- Shu – Följ regler
- Ha – Böj/Bryt regler
- Ri – Bli/Lev dina regler
Många ser Shu-Ha-Ri som en nödvändig del av den agila verksamheten för att snabbt komma in i det agila arbetssättet och för att fortsätta driva igenom förändringar även när de agila processerna är etablerade.
Shu-Ha-Ri liknar också en vanlig strategi inom programmering som jag och mina kursare använde i princip alla programmeringskurser, och som lever kvar inom arbetslivet:
- Kopiera – Hitta en lösning som gör typ det du vill och plagiera den
- Applicera – Vrid lösningen att lösa ditt problem
- Optimera – Effektivisera lösningen till att göra exakt det den ska och ta bort onödiga reliker
De som stannade efter första punkten blev inga bra programmerare, och hade vissa svårigheter med att klara kurser när de fick frågan varför de löste uppgiften som de gjorde – det är inte ett accepterat svar att säga ’för att det var lösningen jag hittade på stack overflow’.
Det borde inte heller vara ett accepterat svar i arbetslivet att säga ’det var så processen såg ut som jag hittade från (valfri teori eller ramverk)’.
Speciellt då ramverk och teorier om det mest effektiva arbetssättet inom utveckling, oavsett om det är produkt-, system-, verksamhets- eller ledarskapsutveckling, byts ut mot nya hela tiden. Det kommer inte vara första eller sista gången din organisation måste förändra sina processer och ramverk.
Det är därför jag som kravare fortsätter att vara en regelbrytare, eller i alla fall ifrågasättare, genom att kontinuerligt ställa frågan varför – för att inte vi inte ska följa processen bara för att processen ska följas, och för att vi inte ska stanna vid klipp-och-klistra.
Om du också gillar att utmana ’så har vi alltid gjort’ eller processer som tappat sitt syfte – anmäl dig till Kravdagen 2022! I år har konferensen temat ’utmana status quo’ och är en heldag med spännande talare, så som Fredrik Härén, Ida Hult och Knowits egna Niclas Åström som kommer prata effektkartläggning.