På senare år har det utvecklats en effektiv och pragmatisk metod att utveckla mjukvara, ”Agile software development”. Jag frågar mig nu om man kan använda samma eller liknande metoder för att utveckla lösningar och förändringar som medför minskad miljöbelastning, ökad ”hållbarhet” och andra mål som hänger i luften och där det mest är stora organisationer och riktiga entusiaster som idag har möjlighet att positioner sig rätt.
Nedan följer en 15 minuter lång video där Henrik Kniberg går igenom principerna tillämpade på systemutvecklingsprojekt. Henrik är en passionerad föregångare när det gäller Scrum, XP, Agile och liknande metoder som vänder upp och ner på gamla tröga och långsamma och metoder.
Scrum, XP och Agile development anpassar sig till verkligheten, både omgivningens krav, konkurrenter, kostnader och det egna teamets förmågor att leverera. Det är helt enkelt en verklighetsbaserad metod att utveckla mjukvara och att göra det på ett sätt som medför att man levererar det nödvändigaste först, och i tid, för att därefter bygga vidare utefter förutbestämda visioner och med hänsyn till erfarenheter man plockar upp på resans gång.
Min fråga är nu om man kan använda samma eller liknande metoder för att lösa några av de många miljöproblem som vi människor har skapat. Vare sig det handlar om systemförändringar, incitament, prylar, tjänster eller nya funktioner som gör att vi gör mer rätt och mindre fel.
Vilka individer eller beslutsfattare skulle sitta på de olika positioner som Henrik belyser i videon? Vilka är PO (Produktägare) och vilka visioner har de? Vilka är Stakeholders (Intressenter)? Vilka User stories har vi? Hur får vi resurser att genomföra det vi vill utveckla?
Efter ett antal konferenser och workshops upplever jag att det ofta uppstår konflikter mellan det perfekta och det tillräckliga. Skall man få något gjort får man göra som när man bestiger berg: Börja gå i rätt riktning. Det är också viktigt att ha en realistisk uppfattning om hur lång tid saker tar att genomföra. En viktig funktion i det sammanhanget är att kunna säga nej till alltför fantastiska produkter, börja med realistiska mål och gör det som är viktigast först.
En annan viktig sak Henrik lyfter fram är att vi inte vet exakt hur framtiden ser ut. Det kan jag skriva under på. Men vi kan veta ungefär i vilken riktning den utvecklas -den står i alla fall inte still!
En bit in i videon kommer han till en punkt som många projektägare säkert stött på: Skall vi bygga rätt produkt, skall vi bygga produkten rätt eller skall vi bygga den snabbt? Givetvis vill man uppfylla alla tre, men vi måste då även inse att vi inte kan prioritera alla tre. Vi tvingas göra lite avkall på var och en för att fånga tillräckligt mycket alla tre.
Precis samma problem har man i miljö- och klimatfrågor. Vi behöver ställa om från verksamheter som genererar växthusgaser, aerosoler (partiklar), skogsskövling, överfiske, övergödning, utrotning av växter och djur, spridning av gifter mm… Vi måste göra det nyss, men gör man det så skapar man andra helt oacceptabla problem, tex brist på mat och energi, ekonomisk och geopolitisk instabilitet mm.
Det håller inte.
Nu börjar det hända saker, inte bara bland entusiaster utan just nu kanske främst bland institutionella placerare, investerare och multinationella företag. En del formligen springer fram för att positionera sig rätt när man nu ser att marknaden flyttar sig. Jag kommer nyligen från två olika seminarier där stora organisationer som Maersk, SCA, LKAB, Volvo, GE, Storebrand, KPA och AP-fonderna visat tydlig riktning om vart de är på väg. De gör det inte främst av moraliska skäl utan för att generera bra riskjusterad avkastning på kapital. Man vill positionera sig relativt globala trender och man strävar efter finansiell stabilitet.
Frågan är inte om marknaden förändras utan var, när och hur. Agile och Scrum kan hjälpa liten som stor att hänga med. Både att förflytta samhället i rätt riktning och att positionera sig själv när samhället förändras. Det handlar mindre om att bygga saker och mer om att förstå hur systemet förändras och vilka incitament som kommer att förändras och i vilka riktningar.
På 15 minuters video hinner Henrik gå igenom en hel del och lite till. Första gången kan man se den bara för att förstå Agile mjukvarutveckling.
Se den sedan en gång till och fundera på hur man kan använda Agile för att finna lösningar på miljö- och klimatproblem!
/Martin
Agile, Scrum och alla andra närbesläktade arbetsmetoder innehåller mycket vettigt som man säkert kan tillämpa på andra områden.
Dock är det inte lika enkelt att i verkligheten tillämpa det här på något så avgränsat som systemutveckling. Att då rakt av ta en metod och använda den på något som är mycket mer komplext och där feedback-looparna är så mycket längre känns inte vettigt.
Feedbacklooparna inom systemutveckling är i bästa fall några timmar eller dagar. I klimatfrågan antar jag att dessa är betydligt längre? Alltså borde man jobba med ett antal frågor parallellt även om det blir mer komplext att utvärdera resultaten.
Om vi nu pratar om tekniska system så får du Martin nu här klä skott för ”Klarts” nya tekniska inovationer.
Varje gång jag går in på klarts väderhemsida från min smartfån så känner hemsidan på något sätt av detta och leder mig till en infantil dagisvariant av sidan, mer lämpad för smartfååns enligt Klart, så jag måste backa ur och svara att, nej jag vill inte till nån sida jämförbar med TV3/ZTV. Jag vill till den jag har lagt in som bokmärke. Jag vet att det är svårt att påverka vädret, men detta kan du väl fixa ?
Hej.
OK, jag tar med mig det. Vi valde den temporära lösningen då web-sajten inte är så lyckad i smartphones.
Just nu sliter våra utvecklare med att färdigställa den nya iOS-appen. När den är ute och vi fått till något som är några snäpp bättre än en MVP (minimum viable product) så har vi två viktiga projekt: Sajten och android-app.
Precis som Henrik beskriver i videon så handlar det hela tiden om att prioritera. Att se till att sajten (som inte är appar) fungerar ännu bättre/exemplariskt på olika plattformar är viktigt, men ännu viktigare är att skapa apparna för iOS och Android.
Låter fint .. men varför skulle det få genomslag hos de som har mycket investeringar redan i fossil energi portföljer att ändra sig och dra sig ur dessà?
Verkligheten är ju den att det är där ’kampen’ fär en ok framtid ligger.
Här är den ekonomiska verkligheten och den klimatologiska verkligheten som överlappar varandra.
Vad tycks?
https://www.youtube.com/watch?v=10cXRvC3crg
Bra film, eftersom den samtidigt som den visar på hotet också visar på att det är ekonomiskt möjligt att avvärja. D.v.s. KAN vara möjligt att avvärja. OM de ekonomiska intressen som nu har makten och är knutna till fossilbränsleindustrin kan trängas tillbaka. Precis som du Torun skriver i ditt förra inlägg är det vad det handlar om. En politisk kamp som vi har långt kvar till att klara av, men måste föra.
Det går utmärkt. Problemet är precis som i så många andra fall politiskt.
Det där låter som arbetsgången man försökte få till för en avdelning på ett företag jag jobbade hos vid sekeskiftet. Själv satt jag precis efter ’tratten’. Projekledare och teamledare pratade ihjäl sig om vår brandbekämpning och framhöll proaktiva åtgärder som vi framförde men omöjligt hann.
De där erfarenheterna säger mig att det blir fort ohyggligt jobbigt när det blir lite större, än utveckling av mjukvara.
Annars är tanken fin. Har alla en klar målbild drar alla åt samma håll och är beredda att stå tillbaka med sina egna viljor för att helheten ska röra sig fortare framåt, vilket alla tjänar på.
Avdelningen jag nämnde hade alla förutsättningar för att lyckas eftersom kunderna tillhörde samma bolag, men lösningen blev likväl, lite senare, outsourcing. Det kan man inte tillämpa för hela planeten. Eller? 🙂
Intressant tanke, Martin, men jag håller ändå med Daniel (om snabb feedback kontra lååååångsam).
Dessutom fungerar Agiler bäst där designen och kodbasen är lätta att modifiera om och om igen. Det är knappast särskilt likt elnätet eller följetongen kring (kontraproduktiv) beskattning av småskaliga prosumers.
IMO förutsätter Agilt inom både mjukvara och energisystem ett mått av inbyggd flexibilitet i produkterna, dvs inbyggda variabilitetsmekanismer i förväg (för att klara omställningar/anpassningar till en låg och förutsägbar kostnad), men utgångsläget är väldigt olika. Energisystem liknar mer ”systemarvet” (Cobol, Fortran, PL/1, Assembler osv) – ofta dåligt modulariserade och låsta til 1 teknisk plattform (Anti-Pattern: Vendor Lock-in), vilket gör förändringar mer tids- och kostnadskrävande…
Som gammal miljömupp med fötterna i tekniken och huvudet i demokratiskt sinnad organisationsutveckling har jag grunnat på det här sen slutet av 80-talet. Efter att ha insett att det i mångt och mycket är det hierarkiska och linjära tänket som sätter käppar i hjulen för oss, så intresserade jag mig för andra sätt att se på verkligheten.
Jag har det senaste året nosat en hel del på agile istf ganttiska modeller för att hitta ett sätt att skaka liv i en gammal ingrodd ideell organisation jag råkade bli styrelseledamot för. Inget annat än min egen modell som skapades redan 1996 gjorde dock jobbet. Denna metod/modell kallar jag OLSON (Organiskt Ledningssystem för Själv-Organiserande Nätverk). De flesta som tittar på den kallar den briljant, genialisk osv, medan äldre män kliar sig i skallen och säger ”jag begriper inte riktigt, men den är väldigt intressant”.
OLSON är organisk och fraktal. Ett specialfall i den är den linjära varianten där man går från vänster till höger, från A till B, men den går att använda till analys, planering och som organisationsschema. Om jag bara kunde fått tag i någon med programmeringskunskaper vill jag göra ett program där man kan skapa en hel inbördes relaterad väv av saker, arbetsuppgifter osv. Det här är en modell som bortrationaliserar chefer bara för att de är chefer. (Roller för samordning och syntetisering finns det fortfarande plats för.)
Ytligt liknar den en mindmap, men inte i praktiken. Den som är intresserad kan kontakta mig. En bok håller jag på att skriva, men just nu tar nytt jobb och uppdraget i den där organisationen (användandet av OLSON i praktiken) det mesta av min vakna tid.
Sedan årsmötet för en vecka sen har jag fått enormt mycket uppskattning för allt som hänt det senaste året och jag har fått klart för mig att OLSON har nåt som många saknar. Ett uppdrag någonstans för att testa den i skarpt läge är min dröm.
Var på kurs i Agile härom året. Föreläsaren var så entusiastisk och berättade om de otroliga vinster de gjort efter införandet. Kunde själv konstatera att vi redan jobbat på Agilelikt sätt i 20 år utan att ha haft ett moderiktigt namn på arbetssättet.
Att få effektivitet i politik verkar svårt. Det beror dels på demokratins uppbyggnad. Det är viktigare att alla får säga sitt än att styret blir bra. På gott och ont.
Om du visste hur många hundratals miljoner som har gått till spillo pga av agil systemutveckling (vi sätter igång direkt med utvecklingen, det går alltid att refaktorera senare…ooops det var visst inte så enkelt att refaktorera ett år senare…).
Ett problem man t.ex. lider av nu är att ändra på upplösningen i klimatmodellerna, inte lätt med åratal av utveckling utan ett stabilt ramverk och många inblandade utvecklare.
Kom att tänka på denna artikel igen, klickade aldrig i ’meddela’ tidigare.
Jag tycker man borde öppna upp klimatforskningen ännu mer. Även runt klimatforskningen finns det riktigt nördiga människor som definitvt kan komma med bra idéer. Bra idéer får man aldrig nog av.
Här är ett försök, http://www.arcus.org/sipn
Mer sånt, släpp in nördarna och öppna upp för mer dynamik. En av de saker som gnölas lite om, såvitt jag förstår, är just modellkörningar och tillgänglig data. Man ser resultaten, men inte vad som pågår och då kan man inte heller påverka eller ge synpunkter.
Jämför mot open source inom IT. Det fungerar.
Människor älskar att jobba gratis. 🙂