Att jobba agilt verkar ha gått som ett mantra genom affärsvärlden de senaste åren. Och visst har vi nog alla fattat poängen, att det är bra att vara flexibel, anpassa sig på vägen och inte överplanera allt. Jag håller med, till en rimlighetens gräns.
Nyligen fick vi en pik av en annan leverantör i ett projekt där vi samarbetar med en gemensam kund. Det lät i princip så här från den leverantören: ”vi är mer vana och föredrar att jobba agilt”. Läs mellan raderna – hen tyckte att vi var oflexibla dinosaurier. En stark röst i mig sa genast, ”du har så in i bomben fel, vi är flexibla som bara ***” (notera att jag skriver en stark röst i mig, jag höll mig alltså lugn och utan motattacker). Invise är agila, men vi är det till en gräns. För en annan röst i mig visste i just det här fallet en annan sak, det agila höll på att få oss att gå över planering och över budget, trots våra upprepade uppmaningar om detta annalkande problem. Och i mitt intresse ligger alltid i kundens bästa. Att gå över budget kan vara nödvändigt ibland, men det ska alltid gå att motivera. Agilt arbete rätt utfört ska dessutom ge bättre resultat, men jag tror det är en sanning med modifikation.
Jag har varit med i projekt där ”alla ska få tycka till” och där ”myrsteg är bättre än sjumilakliv”. Men ärligt så säger det sig själv att någonstans kan dessa myrsteg leda till onödigt många vändor fram och tillbaka, att saker tar lång tid och att det finns risk att tappa fokus från helheten i ett projekt. Sånt kostar pengar. Det kostar också energi att låta för många vända och vrida på varenda liten detalj. Kan vara att detta är en misstolkning av hur agilt ska användas, men i så fall är det en vanlig misstolkning, upplever jag.
Hen tyckte att vi var oflexibla dinosaurier. En stark röst i mig sa genast, ”du har så in i helvete fel, vi är flexibla som bara ***
En del i vår verksamhet är att bygga hemsidor och ett av de första stadierna (efter ett inledande strategiarbete) är att designa hemsidorna. När vi designar försöker vi göra det noga, det är nämligen ritningen till det som ska byggas. På så sätt kan vi få alla på tåget (kund, projektledare, designers och vid behov även utvecklare) redan i designfasen. När vi väl lämnar design för att övergå till kod så vill vi att alla vet vad som ska levereras. Det var i det här skedet som jag satt i mötet och slets mellan att vara agil eller vara vad jag skulle kalla smart. Vi ombads nämligen vara agila i kodningen också.
Att bygga ett hus
Jag ska göra en liknelse som jag tror alla kan förstå. Låt säga att du ska bygga ett arkitektritat hus. Det finns ingen tidigare mall att följa, bara inspiration och kunskap från kunniga hantverkare. En bra projektledare ser såklart till att väga in alla experternas kunskap för att forma en helhet, där är vi nog alla överens. Men få byggare skulle sätta igång och bygga ett hus utan att ha en färdig och komplett ritning. Varför? Därför att det kostar skjortan och hela slipsen att i efterhand komma på att väggar måste rivas, rör dras om och kök flyttas. Inte bara är det dyrt, det gör att tiden sticker iväg som en raket och få byggare tycker att det är kul att slå upp en vägg de precis satt dit, det är bakåtsträvande och skapar negativ energi.
Jag ser detta hända precis hela tiden när det agila stigit personer åt huvudet. Folk ska vara så flexibla att det slår över. Det blir också en easy out – att säga att ”vi löser det där sen” bara för att komma vidare där man för tillfället.
Ska vi dissa det agila helt?
Så vad är det jag föreslår, att vi ska dissa det agila? Nej det ska vi inte – vi måste bara plocka tillbaka en del sunt förnuft, ledarskap, prioriteringsförmåga och tillit till de som är experter på sitt område. För sanningen är den att hur agila vi än är så måste beslut fattas som tar arbetet framåt. Dessa beslut kan sedan utvärderas på riktigt efter att de förverkligats, kanske extra mycket när man arbetar digitalt eftersom det då går det att mäta allt i efterhand. Väldigt många gånger har vi märkt att vi behöver göra justeringar som vi inte alls hade en aning om under projektets gång, utan som vi lär oss när vi är live med vårt arbete och får in riktig data och feedback.
Men vänta nu: vad är det jag säger – då måste ju väggar rivas, rör dras om och kök flyttas i efterhand. Mjo ibland kan det vara så, men då finns det massa bevis som backar upp att det är rätt beslut, att istället göra det i förväg innebär inte att man gör rätt ändringar. Och en sak till: ofta har vi lärt oss att små ingrepp kan ge långt bättre resultat än stora ”riva hela haket” ändringar. Just dessa ändringar är återigen lätta att göra när det finns konkret data att gå på!
Ohh boy, Fredrik – bli konkret: vad gör vi nu? 😨
Jag är ingen managementkonsult som slipat på detta länge och därmed kunnat jobba fram ett perfekt svar och en snygg modell (har du en perfekt modell så lyssnar jag gärna: f@invise.se.) Men med lite listighet ska jag nog kunna plita ned några punkter som kanske, med lite utvärdering i något roligt (agilt?) projekt, kan hjälpa:
- I ett projekt, oavsett vad, så bestäm vilken/vilka faser som är ok att ha tester/agilt tänk och håll det till dessa faser
- En person är ansvarig för helheten. Denna måste kunna dra i handbromsen och säga: nu tar vi ett beslut och går vidare, sen får framtiden avgöra om beslutet är rätt eller fel
- Är man osäker, låt personen som är mest kvalificerad på det specifika området ta ett beslutet och gå på det
- Försök i den mån det går att förflytta en del av det agila till test och optimering efter lansering/förverkligande. Alltså: gör vägen till förverkligande snabbare, och spar tid, pengar och energi från projektfasen till optimeringsfasen istället
Sist och mest
Applicera sunt förnuft och se till helheten, dessa två är banne mig viktigare än nästan allt annat. Det är galet lätt att fastna på fel ställen om inte sunt förnuft och förmågan att ta ett steg tillbaka och se till helheten lever igenom i alla projekt!
