Är du agil? Ett resonemang kring agilt och vattenfall
Är ”agil” och ”vattenfall” bra etiketter att använda för arbetssätt som ibland skiljer sig väldigt mycket åt, men som också ibland har överlapp? Jag började fundera på det, inspirerad av Rolf Olofsson, psykolog och ledarutvecklare, som var hos oss på Moment för några veckor sedan. Hans huvudnummer var att ge oss en introduktion till beteendeanalytisk organisationsutveckling. Han gav oss bland mycket annat insikter om vikten av att fokusera på vad vi faktiskt ser i form av beteenden i vårt samspel med andra istället för att utgå från de olika etiketter i pannan i form av personlighetstyper som diverse tester klistrar på oss.
Etiketter ger upphov till antaganden
Rolfs argument mot att använda etiketter även om det är bekvämt och en del av vårt sätt att förstå världen, är övertygande och dessutom baserade på vetenskaplig evidens. Med etiketterandet följer antaganden om hur någon ”är”. Etiketten får oss att tillskriva andra diverse egenskaper och beteenden som de borde ha enligt vår förståelse av etiketten, men som kanske inte alls motsvaras av hur de tänker eller beter sig i verkligheten. Etiketten är ett väldigt trubbigt verktyg för att försöka förutsäga hur någon kommer att bete sig och förstå varför man beter sig på ett visst sätt.
Hur fungerar det att tillämpa principen att se mer på vad vi gör än på etiketten för det som vi ganska slarvigt kallar ”agilt” eller ”vattenfall” eller något annat? Både ”vattenfall” och ”agilt” är etiketter som i sig rymmer en massa antaganden och föreställningar om kravhantering, ledarskap, leveransstrategi, planering, mål, förutsägbarhet, lärande, flexibilitet, organisering, samverkan, visualisering, o.s.v.
Etiketterna ”vattenfall” och ”agilt” har också kommit att laddas med känslor och värderingar på ett sätt som jag inte tycker är konstruktivt. Vad ser du själv framför dig när du hör ”agil”? Är det företag och människor som har utvecklat helt nya, fantastiska sätt att leda och att leverera mer värde snabbare, eller ser du framför dig en samling flummare som inte ens kan tala om när de kommer att leverera och än mindre kan säga vad du får och till råga på eländet har hittat på en massa nya namn på gamla företeelser, så att du knappt fattar vad de pratar om?
Och när du hör ”vattenfall”, vad ser du då? Det enda rimliga sättet att leverera stora, komplexa infrastrukturprojekt, värmeverk, hus, standardsystem och det enda som ger dig en sportslig chans att få reda på när det blir klart? Eller ser du äldre människor som är hopplöst fast i det förgångna, höga chefer som missbrukar projekttrianglar, ställer stelbenta och orealistiska krav på förutsägbarhet i en komplex värld och som inte vill ta till sig nya och bättre sätt att organisera och driva utveckling i komplexa miljöer?
Jag ser allt detta och lite till. Men jag vill slippa etiketterna och se till vad vi faktiskt gör och i vilka situationer olika verktyg och strategier fungerar bäst. Det finns ett talesätt som säger att ”om det enda du har är en hammare så ser allt ut som spik”. Det är en bra metafor för övertygelsen om Det Enda Rätta.
Googla ”Scrum is not agile” så får du över tre miljoner träffar. En massa människor ägnar sig alltså på fullaste allvar åt att diskutera en fråga med marginell betydelse för om man levererar bra eller inte. Det finns ganska många som ägnar sig åt att predika att ”agilt” är Den Enda Rätta Vägen och det finns en del som ser ned på ”hippieagilisterna”. En del hävdar att ”agila” projekt är en självmotsägelse och här är jag partisk eftersom jag tycker att de har fel. Varför skulle det inte kunna finnas ”agila” projekt? Ingenstans i det agila manifestet eller de tolv principerna står det något om bannlysning av projekt som arbetsform. Ett projekt som utvecklar sekventiellt och levererar två gånger, med en möjlighet till korrigering av leveransen är i mina ögon dubbelt så ”agilt” som ett som bara levererar en gång, även om projektgruppen aldrig har hört talas om Scrum. I stället för att bry mig om etiketterna är jag mycket mer intresserad av vilka verktyg som ger effekt i en viss situation och en viss miljö.
Släpp etiketterna och se möjligheterna
De flesta organisationer som av tradition eller pga förutsättningarna driver utveckling sekventiellt (”vattenfall”) skulle vinna mycket på att ta till sig de agila principerna, manifestet och använda en del agila verktyg och tillvägagångssätt. Inte minst gäller det för den strategiska nivån i företag, där det verkligen är dags att något börjar hända.
En del företag tillämpar ändå mer iterativa sätt att arbeta på, på olika sätt. Jag har t ex en kund vars största projekt går igenom 4 faser: en förstudie, en feasibility study, bygge av pilotanläggning och därefter en genomförandefas med bygge av fullskaleanläggning. De tre första faserna kan ta ett år var och varje fas kan kosta uppåt 100 miljoner. Genomförandefasen är flerårig och kostar miljarder. Är det ”agilt” eller ”vattenfall”? Det är en tydlig vattenfallsprocess med faser och beslutspunkter, men man itererar faktiskt fram behov och lösningar i de tre första faserna. Därefter låser man designen och alla specar och kör. Bättre än att speca allt i en fas och därefter starta uppförandet av fullskaleanläggningen och i mina ögon åtminstone delvis ”agilt” utifrån förutsättningarna. Den här typen av projekt kör dessutom dagliga ståuppmöten (som man nog gjort i byggbranschen åtminstone sedan pyramiderna).
Jag har också arbetat i verksamheter med ”superagila” tillvägagångssätt som faktiskt hade mått bra av en gnutta mer sekventiell planering, inte minst för att överbrygga klyftan i form av skilda förväntningar och behov mellan affärsledningen och utvecklingsteamen. Sedan har jag andra kunder som har valt att tillämpa både devops, ”agila” projekt och ”vattenfall” som utvecklingsformer för olika typer av system.
Jag har som projektledare kortslutit en väldigt sekventiell projektmodell genom att använda en prioriterad backlog mot en fast kostnadsram. Alla kraven var specade i förväg, vi hade ett Ganttschema för kommunikation mot omgivningen men ingen detaljerad plan. Vi arbetade i sprintar, hade inga user stories men använde Fibonnaci-skalan för sizing av våra nedbrutna leveranser. Scrum fanns inte på kartan. Vi reducerade dokumentationen till ett minimum. Tillvägagångssättet minskade genomförandetiden med tre månader (av totalt drygt ett år). Var det ”agilt”? Jag tycker det.
I ett annat projekt med stora organisationsförändringar åstadkom vi genom att använda prioriterade backlogs att medarbetare (användare av resultatet) som från start var fientligt inställda, efter ett tag insåg att deras prioriterade behov faktiskt skulle komma att tillgodoses. Vi fick ett väldigt bra samarbete i tvärfunktionella team i en mycket stuprörsstyrd organisation. Var det ”agilt”? Nä, knappast. Vi körde ”vattenfall” men lånade ett ”agilt” verktyg med bra resultat.
Min slutsats är att det finns bra och mindre bra sätt att göra saker på, delvis beroende på vilken miljö man verkar i och oavsett vad vi kallar det eller om det finns beskrivet som en metodik eller inte. Världen är inte binär. Vi som arbetar med att leda eller praktiskt arbeta med att utveckla, bygga och förändra system, tjänster, organisationer, arbetssätt, industrianläggningar, fordon, flygplan, läkemedel eller vad det nu kan tänkas vara tjänar på ett flexibelt och öppet förhållningssätt till olika modeller, metoder och verktyg. Jag vill ha nya verktyg i min verktygslåda hela tiden, men fortsätter att använda de gamla när jag tycker att de är bäst.
Vi borde undvika etiketterna och fokusera på lärande och praktiska, situationsanpassade tillämpningar. Jag tycker att den värld som jag är yrkesverksam i har blivit polariserad helt i onödan och till ingen nytta. Det Enda Rätta finns inte och jag börjar bli trött på etiketter, ordkrig och attityden ”vi” och ”de andra”. Tyvärr begränsar sig inte polariseringen till yrkeslivet, vilket min f.d. kollega Ulrika Park bland annat skrev om i ett tänkvärt blogginlägg i augusti förra året, med titeln Tribes have no place in modern society and organisations. Läs det!