Det finns en logisk detalj med kuben som är avgörande och som man måste lära sig för att kunna bli en ninja på att lösa den. När jag fick förståelse för den specifika logiska detaljen gick jag ganska snabbt från hopplöst fumlande till att börja förstå hur det ens är möjligt att lösa den. Med insikt kring ett par detaljer om hur själva kuben fungerar och är uppbyggd så är det alltså  plötsligt möjligt att lösa den – och det till och med ganska enkelt.

Förstår man inte - ja, då kommer kuben fortsätta vara ett mysterium. Som uttrycket säger: ”Allt är lätt när man kan det”.

Under en inlärningsprocess (som den att lära sig Rubiks kub) parar synapserna i hjärnan ihop sig. Till slut är det till och med svårt att föreställa sig en tid när man inte hade den kunskapen man just fått. Men även om man behärskar en ny förmåga är det ofta svårt att förklara för någon annan. Synapserna kan inte kopplas ihop genom att läsa om det - eller prata med någon annan. Det måste komma från kombinationen av kunskap och självinsikt.

Och självinsikten - den kan bara komma inifrån.

Hur odlar vi då självinsikten? När det gäller kuben så finns det bara ett sätt - träna, träna och… ja, träna. Det är genom att öva och repetera (dvs göra) som det är möjligt att bygga upp insikt.

Jag säger det igen: det spelar ingen roll hur mycket man läser och pratar om det - om man aldrig gör,så kommer inte insikten. Det är först när man kombinerar tanke och praktik som vi når nästa nivå.

Från stressad chef till inspirerande ledare!

Känner du dig överväldigad i din ledarroll? I så fall är du inte ensam. Med onlineutbildningen Leda mig själv, går du från stress och reaktivitet till självledarskap, fokus och starka teamresultat.

Kolla in vårt specialerbjudande på denna kraftfulla 1-timmesutbildning.

Transformera ditt ledarskap nu!

Det här gäller givetvis även på jobbet. Det är därför Agila metoder vinner mark över de tidigare mer etablerade vattenfallsmetoderna.

Vattenfall

Vattenfall är ett samlingsbegrepp för metoder att bygga mjukvara där man delar upp arbetet i distinkta faser; t.ex behovsanalys, planering, design, test, införande, underhåll.

Namnet härstammar från att man ska vara klar med en fas innan man går vidare till nästa  - vattnet flyter enbart åt det ena hållet. Men det är egentligen ett begrepp som används idag för att förringa och nedvärdera de mer traditionella och etablerade metoderna som lägger mycket fokus på att planera och dokumentera så mycket som möjligt i förväg.

Även om den klassiska beskrivningen av vattenfall inte finns i verkligheten - de flesta metoder tillåter faktiskt att man hoppar mellan de olika faserna vid behov och därmed beter man sig ändå inte som fallande vatten - så lider många metoder av samma problem. Nämligen att metoden förutsätter att det går att förstå hela systemet innan man börjar bygga det...

Det är i själva verket en omöjlighet eftersom vi än så länge inte kommit på något sätt att blicka in i framtiden. Egentligen är det ju precis tvärtom - det är snarare så att kunskapen om systemet ökar i takt med att systemet skapas. Det är den erfarenhet som bygget i sig skapar som också blir den kunskap som hjälper dig att fortsätta jobba åt rätt håll.

Vi behöver en arbetsmetod som är utformad efter det tankesättet.

Agilt...

Agilt, som en process, skapades i mjukvarubranschen som ett svar på att majoriteten av vattenfallsprojekt blev på något sätt misslyckade. De gick över budget och drog ut på tiden. Framförallt var slutprodukten ofta av dålig kvalitét eftersom den inte tillfredsställde kundens behov. Om det går två år från idé till färdig produkt är det inte så konstigt att behovet på marknaden hinner förändras under tiden.

Grundtesen i agilt är: det spelar ingen roll hur mycket du planera för något - det är först när du börjar bygga ett system som du verkligen kan förstå det. Det är först när du görnågot, som de riktiga insikterna kommer.

Varje mjukvaruprojekt är okänt till en början. Om problemet du ska lösa redan vore känt och väldefinierat går det förmodligen att köpa lösningen i en App Store redan... Och bara för att några skäggiga arkitekter sitter i ett rum och filosoferar över kundens problem, betyder inte det att de kan komma fram till en riktigt djup förståelse för de problem som måste lösas: det finns alltid oförutsedda detaljer som kommer att få ett alltför planerat projektet att spåra ur.

Så. Vi människor vill gärna skapa en plan - men om vi redan från början vet att den inte kommer hålla, varför låtsas vi ändå? Kanske för att det känns tryggare och mer kontrollerat att ha planerat allting i mikroskopisk detalj i förväg? Detaljkunskap som, vill jag hävda, är fullständigt onödig - ett slöseri med tid.

Att jobba agilt är att acceptera att sann insikt kommer inifrån. I projektet kommer insikterna när vi är mitt i att bygga lösningen. Det lönar sig aldrig att planera för mycket i början. Självklart måste vi förstå vad det är som vi ska bygga - men vi behöver inte bestämma oss för hur vi ska bygga allting innan vi ens börjar. 

Den agila strategin är att samla allt vi kan och diskutera det med kunden. Är vi överens om alla begrepp som vi använder? Har vi förståelse för vad kunden menar med alla krav och behov?  Vilka är de viktigaste? Det går alltid att peka på några få behov som ger mest värde. Fokusera på dem först och glöm de andra - vi kommer inte kunna tänka på hela lösningen än i alla fall. Det är för mycket som är komplext och okänt.

Även kunden är ofta osäker – vad vill vi egentligen ha? Genom att fokusera på att bygga en lösning för några få (men viktiga) saker så lär vi oss mer om projektet i processen.

När vi är klara med första omgången så börjar vi om. Men den här gången så kan vi lite mer om kundens behov och de problem vi ska lösa. Vi har packat några lärdomar i ryggsäcken och omprogrammerat några synapser. Saker vi inte förstod förr har vi djupare kunskap om nu - och då, med den nyvunna kunskapen, kanske kan göra förändringar i våra prioriteringar i projektet. Plötsligt är något som vi trodde var centralt för projektet inte alls lika viktigt längre.

Ju mer detaljerad planen är - desto större är risken att den är fel.

Fail fast, fail often

Öka fokus med hjälp av en tomat. Snabbkurs i Pomodoro-metoden.

Det finns ett känt agile-begrepp på engelska: fail fast, fail often. Med det menas att det är att föredra att bara köra igång, misslyckas, och dra lärdomar - hellre den vägen än att inte våga starta projektet för att man tror att man har för lite information. Ju tidigare man kan misslyckas desto bättre för projektet - hellre se problemen efter ett par dagar än att vänta fler månader.

Men det är förstås viktigt att man lär sig något av misslyckandet. Som att testa en vetenskapligt hypotes: påstå något, göra, dra slutsats.  

Rädslan för att misslyckas plågar oss alla: vi tar hellre säkra beslut än att chansa. Men jag vill påstå att i större projekt så är det just det som är farligt. Om man vägrar att ens hålla i en Rubiks kub tills man känner sig helt säkert på att kunna lösa den på första försöket - vad är oddsen att du gör det?

Vad är då hemligheten bakom Rubiks kub? Man löser inte ytor. Man löser bitar - och varje bit i kuben har bara en rätt plats där den kan vara.

Det låter enkelt - men den rätta insikten måste komma inifrån, och det gör du bäst genom att göra. Om och om och om igen…