Jag läser en kurs i projektledning på universitetet som en del av I-programmet jag går på vid sidan av jobbet. Efter att ha sett tentan och insett att den refererar ganska tydligt till vad kursboken säger bestämde jag mig för att införskaffa den även om jag var lite tveksam till dess nytta. Så under helgen har jag försökt plöja igenom de ganska lättlästa 240 sidorna. Men trots det enkla språket tenderar jag att zona ut ibland. Jag vet inte varför, men det är något som skaver med boken.
Kanske är det språket, som är inte helt olika en kursbok i en gymnasiekurs, det pratas mycket om hur ett projekt ska genomföras, saker en projektledare ska göra och andra tips och råd, utan vidare förklaring om hur man vet att det är rätt. Måste en projektledare verkligen göra alla de saker som föreskrivs för att nå ett lyckat projektresultat? Om de inte görs, hur mycket sämre blir slutresultatet? Vilken studie baseras dessa slutsatser på? Det förekommer visserligen källhänvisningar, men det är långt emellan dem och kärnan i texten är oftast helt befriad från dylika företeelser.
Kanske är det byråkratin i det hela. Den organisation de implicit beskriver verkar väldigt fokuserad på det opersonliga, likt byråkratins läror. Det är många dokument som gärna ska skrivas och många processer och modeller som bör följas. Kommunikationen projektet ska ske enligt en kommunikationsplan och många fler problem som i första hand ska lösas genom att producera dokument och skriva avtal. Jag kommer att tänka på det agila manifestets inledande rad:
Individuals and interactions over processes and tools
Men nej, jag tror inte svaret är riktigt där. Jag tror det som skaver är känslan av att de simmar motströms. Någon gång när jag var liten lärde jag mig om hur man klarar sig om man av någon anledning hamnat mitt i en ström, jag tror det i scenariot dessutom ingick att den snart övergår i ett vattenfall eller en fors . Rådet var att inte försöka kämpa mot strömmen och sikta på närmaste punkt på stranden. Det är visserligen kortaste vägen till fast mark, men du kommer trötta ut dig fort i din strävan att hålla linjen rak. Det man istället bör gör är att simma medströms, snett mot stranden, visserligen hamnar du närmare eventuella faror längre fram. Men eftersom du inte kämpar mot strömmen längre så behåller du orken och kan snabbare nå strandkanten.
Korrektheten i rådet kanske kan ifrågasättas, men det har ändå följt mig under livet. Inte för att jag ofta hamnar mitt i strömmar, enklaste sättet att undvika ovan beskrivna dilemma är ju trots allt att inte hamna där från första början. Nej, snarare i överförd betydelse som livsfilosofi. Livet är som en flod med många starka strömmar som leder mot många olika faror. Det kan vara i form av instinkter som säger att det är bättre att spela tv-spel än att plugga och det kan vara människor i ens omgivning som har intressen som avviker från mina. Det kan också vara många andra ting, det kan vara folkmassor som inte vill gå på den utmarkerade vägen utan istället genar över den där gräsmattan som absolut ej får beträdas.
Vissa strömmar kan vara värda att kämpa emot, men den som väljer att kämpa emot varenda ström hen stöter på kommer snabbt bli uttröttad och inte orka. Men den som kan simma med strömmarna, kanske inte tvinga sig att plugga med klädnypor i ögonbrynen, utan kanske formulera om problemet. Jag gillar till exempel inte att räkna en massa uppgifter i matte-kurser. Så det jag brukar göra är att fokusera huvuddelen av min energi på att läsa boken och försöka förstå alla begrepp, jag hamnar ändå på stranden, bara en bit ner. För att inte hamna för långt ner jag kan behöva ta en bit motströms med övningsuppgifter också, men jag är ändå mer utvilad än om jag skulle kämpat från första början.
Detta resonemang kan som sagt appliceras på många sammanhang, inte minst i hur ett projekt kan drivas. Ett projekt möter många strömmar, omotiverade människor som inte vill jobba, beställare som inte vill specificera vad de vill ha, risker som inte går att förutse, och så vidare. Ett sätt att möta alla dessa är att kämpa emot. Skapa strukturer som försöker lösa problemet, i grupparbeten rekommenderas ibland ett så kallat gruppkontrakt, där specificerar man vad som gäller i ett projekt, då kan man hänvisa till det när någon inte orkar göra sitt. Om man avkräver en tydlig kravspecifikation från beställaren tidigt så kan den inte komma senare och säga att man levererar fel. Om man gör en riktigt komplett riskplan med jättemånga risker, som dessutom uppdateras regelbundet, då borde man ju tänka in allt till slut.
Alla dessa metoder försöker motverka fenomenet som de berör. På ett sätt som kommer kräva arbete, ansträngning och ofta gå emot vad som känns behagligt för såväl projektledare som för andra intressenter. Ett medströms-perspektiv försöker istället använda egenskaper i omgivningen som känns behagliga och hjälper till att nå målet.
En beställare som inte kan specificera sig kan också ses som öppen för förslag. Kanske kan man jobba mer tillsammans med beställare och skapa förtroende? När förtroende uppstår försvinner behovet av väldigt många konstruktioner och dokument.
Kanske är det så att medarbetaren som inte är motiverad helt enkelt är styrd av sina intressen, kan arbetsuppgifterna anpassas efter detta så kan hen kanske blomstra?
Så det som skaver med boken är att hela premissen är motströms. Åtgärderna som beskrivs är åtgärder som föreslagits som svar på problem som är vanliga inom projekt. Många av problemen har grundläggande psykosociala orsaker. Det handlar om motivation, förtroende, samstämmighet och kommunikation. Men lösningarna som föreskrivs bemöter inte dessa utan fokuserar på hur strukturer, processer, modeller och olika måsten ska upprättas för att lösa problemen. Detta dessutom utan att ens bevisa att det är rätt lösning.
Där tycker jag briljansen i det agila manifestet kommer fram, deras fyra principer för mjukvaruutveckling handlar i mina ögon om att simma medströms istället för motströms.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
— Manifesto for Agile Software Development