Obs! Detta inlägg kan upplevas som intressantare än vad rubriken får dig att tro.
Är allt som är agilt bra? Och är allt som är bra agilt? Nej, inte riktigt. Men ett belysande sätt att beskriva fördelarna med agila respektive mer traditionella arbetssätt är att dela upp dem i prediktiva respektive empiriska processer.
Agile kommer ursprungligen från mjukvaruutveckling, där majoriteten av all utveckling tidigare skedde enligt den så kallade vattenfallsmodellen. Namnet kommer av att varje steg i utvecklingsprocessen (exempelvis strategi > design > kodning > testning) måste vara helt klart innan man går vidare till nästa. Nackdelarna med denna typ av utvecklingsmodell är dock många:
- Den tar inte hänsyn till att förutsättningarna kan komma att förändras (vilket de nästan garanterat kommer att göra på ett eller annat sätt)
- Det blir extremt långa feedbackloopar (och eftersom kunden inte kan verifiera om det som görs skapar värde riskerar projektet att både bli riskfyllt och ineffektivt eftersom det bli så dyrt att göra om)
- Modellen förutsätter att alla (inkl. kunden) vet precis vad som ska göras och hur (när kunskapen om vad produkten ska innehålla och hur den ska byggas snarare blir betydligt större ju längre in i projektet man kommer)
Vattenfallsmodellen är en typisk prediktiv process. En sådan process börjar med en tydlig kravspecifikation av vad som ska göras, och slutar när dessa krav uppfyllts. Vad historien visat är att vattenfallsmetoden sällan passar inom mjukvaruutveckling. I sådan komplex process finns det sällan något större värde skapa en detaljerad plan redan från början.
En central del av Agile är att istället ha empiriska processer. En empirisk process börjar med ett mål och ett antal prioriterade krav, och slutar när målet är uppfyllt. Det antas vara bättre att hela tiden kunna anpassa sig till förändring än att försöka uppfylla ett mål som nödvändigtvis inte skapar värde för kunden. Genom att arbeta i korta iterationer kan värde till kunden levereras löpande samtidigt som ett ständigt lärande om vad och hur produkten kan utvecklas på bästa sätt byggs in.
Fördelen med en prediktiv process är att den, åtminstone teoretiskt, är lättare att kontrollera och styra eftersom hela processen är tydlig. Kontrollen i en empirisk process ser lite annorlunda ut och bygger snarare på synlighet, granskning och anpassningsbarhet.
Kontroll är inte på något sätt av ondo. Inom exempelvis Scrum finns ett antal kontroller, exempelvis sprintplaneringsmötena, de dagliga mötena och återblickarna. Det handlar om att hitta en balans. Ju mer komplext ett projekt är, desto bättre passar en empirisk approach.
Fler exempel på prediktiva processer:
- Forskning
- Jag skriver en packlista, som jag sedan bockar av allt på när jag lagt ner det i resväskan
Fler exempel på empiriska processer:
- Jag lagar en soppa av rester, och smakar hela tiden av om det är något som den behöver mer av
- Jag åker tåg med SJ (och har därmed inte en aning när jag kommer fram)
Ledarskapet påverkas också. Prediktiva processer har ett tydligt command-and-control-tänk där beslutsfattandet är begränsat till ett fåtal. Detta blir helt enkelt det mest effektiva sättet att lägga upp arbetet på. En empirisk process bygger på mer att de som är närmast verksamheten ska kunna vara med och ta beslut.
HR-processer kan både vara prediktiva och empiriska. De flesta medarbetare vill ha sin lön den 25:e varje månad, vilket kräver att ett antal kontroller i form av lönekörningar, bankfiler etc en viss tid i månaden. Men andra HR-processer skulle kanske skapa mer värde om var empiriska. Traditionell performance management är ett exempel. Mål sätts i början av året och följs sedan upp i slutet. Graden av måluppfyllelse kopplas sedan till lönesättningen. Att sätta årliga mål är dock för många hopplöst svårt. Då kanske det passar bättre att ha en empirisk approach där man sätter kortare mål som ständigt följs upp.
Hur ser dina processer ut? Skulle de skapa mer värde om de blev mer prediktiva eller empiriska?