I maj 2006 skrev jag tillsammans med min kurskamrat, Johan – idag verksam inom det framgångsrika bolaget Brikka Labs AB – en C-uppsats på temat “Att designa mjukvara för framtiden”. Vi studerade då systemvetenskap vid Karlstads Universitet och hade båda gott om både ungdomlig entusiasm och nyfikenhet.
Uppsatsen finns att läsa i DIVA för den som är intresserad. Arbetet belyser lite av varje, men inte minst finns däri en sektion om en av den tidens etablerade metoder för att bedriva systemutveckling – RUP. Rational Unified Process, ett verk av bland annat IBM. Den tillämpning av RUP som användes för just vårt praktikfall fokuserade på iterativt arbete med små, inkrementella delleveranser av mjukvara som gradvis bygger upp en mer och mer komplett produkt. Vi gillade “smaken” på detta sätt att utveckla, eftersom vi båda saknade decennier av erfarenhet inom IT-industrin och dessutom behövde ackumulera kunskap utifrån en relativ nollpunkt.
Bara några år innan, 2001 närmare bestämt, hade en grupp utvecklare tillsammans gått fram med sitt Manifest för Agil systemutveckling. Manifestet utgick från 4 övergripande utsagor och 12 vägledande principer för hur man metodiskt säkerställer bättre fungerande arbetssätt och bättre fungerande mjukvara. I korthet fokuserar principerna på tydlig kommunikation och empiriskt stöd för att förfina såväl verktyg som metoder – och inte minst fungerande mjukvara.
De övergripande utsagorna i det agila manifestet är enkla, tydliga – och kan tyckas självklara. De är skrivna på ett vis som syftar till att visa var tyngdpunkt och fokus bör ligga utan att förringa saker i den större kontexten som kan vara viktiga också.
Såhär nästan 25 år efter lanseringen av det agila manifestet och 20 år efter två anspråkslösa studenters skrifter om iterativt och inkrementellt arbete känns det som om det ändå är på sin plats att reflektera över agilismens barndom, de fundamentala principerna och hur de står sig idag.
Idag befinner jag mig mitt i en “agil leveransorganisation” som hämtat sitt upplägg ur både SCRUM och SAFe. Leveranserna sker näst intill uteslutande till en intern beställarorganisation och i form av olika IT-relaterade tjänster. Vi är primärt inte en produktutvecklande organisation.
Jag har passerat minst 5 olika verksamheter, tillika arbetsgivare – både i privat och i offentlig sektor där agilt arbete, SCRUM och SAFe alla funnits med i mixen. De betraktelser jag gör relaterar dem samtliga och är inget enskilt uttryck för den vardag jag just idag råkar befinna mig i. Längs denna väg har jag hunnit certifiera mig i SCRUM-rollerna Produktägare och ScrumMaster – båda genom CITERUS utmärkta utbildningar, levererade av Tobias, idag på Holifant.
Låt mig utgå från de 4 övergripande utsagorna i det agila manifestet:
- Individer och interaktioner framför processer och verktyg
Den första av det agila manifestets utsagor är kanske den som lättast hamnar i obalans – eller åtminstone är det min upplevelse av agilt arbete under åtminstone 15 års tid. Processer och verktyg är viktiga, men inte lika viktiga som individer och interaktioner. Problemet för de flesta organisationer som vill arbeta “agilt” är att de är väldigt hårt uppvaktade av verktygsleverantörer och agila coacher, vars existensberättigande utgår helt ifrån det som var det minst viktiga i utsagan. Jag vet inte hur många gånger jag och team runt mig fastnat i verktygsdiskussioner om hur man bäst åstadkommer en administrativ uppgift i JIRA, Azure DevOps, Miro, Trello, Zendesk eller annat verktyg. Diskussioner som sällan eller aldrig främjar individer och deras interaktioner, och ännu mer sällan leder till nytta för de vi levererar till. Lika många är de gånger där jag och team tvingats genomlida självskattningsövningar syftande till att berätta hur vår “agila mognad” egentligen ser ut. Överinvesterade kunskapslyft för till exempel ScrumMasters och Produktägare som på sin höjd berättar hur du genomför ett bra retrospektiv eller hur du kan prioritera en backlog. Agila termometerar och agila barometrar, men aldrig i syfte att stärka individer och interaktioner, utan hela tiden med fokus på att bli så duktig som möjligt på processen.
Vad kan vi då göra istället?
Till att börja med behöver alla stödjande roller runt ett team, t ex Produktägare och ScrumMasters, facilitera teamets interaktioner på ett sätt som skapar social trygghet och tillit i gruppen. Detta sker INTE genom att gå “laget runt” och berätta vilket husdjur man identifierar sig som. Det sker genom att använda empatisk styrning, genuint bry sig om kollegors och teammedlemmars mående – såväl fysiskt som psykiskt. Genom att erbjuda en miljö där misstag tillåts och aktivt verka för att skapa känslan av att gruppen ALLTID finns där för individen skapas starka individer med interaktioner som ger värde och resultat. Det finns gott om kloka sätt att gradvis ta en grupp med individer in i känslan av ett team, här förmedlat av den svenska försvarsmakten: M7739-352062_H_SAMBEF_BOK_WEBB-2.pdf
- Fungerande programvara framför omfattande dokumentation
Jag har sett väldigt olika balans i det agila manifestets andra utsaga i de olika verksamheter jag arbetat. Ibland finns så starka regulatoriska krav att omfattande dokumentation är en ren nödvändighet, och då ska det förstås finnas tillräckligt förmedlade resurser för att klara detta. Min upplevelse är också att de flesta verksamheter blir duktiga på att hålla fokus på fungerande programvara framför omfattande dokumentation, men kanske inte så mycket av det agila manifestets logik som av det faktum att de allra flesta människor i IT-sfären avskyr att författa och underhålla dokumentation. Tendensen att hålla sig med omfattande dokumentation är också väsentligt större i verksamheter som har en viss administrativ överbyggnad med projektkontor, svulstiga stabsfunktioner och Centers of Excellence.
Vad kan vi då göra istället?
Cyniskt, men enkelt: Det enda som egentligen är den faktor som ska utvärderas är teamets och leveransorganisationens förmåga att skapa värde för sina beställare eller brukare. Vanligen är detta värde i någon form av digital leverans. Dokumentation och andra administrativa leverabler kan vara och ÄR i många fall tätt knutna till den faktiska digitala leveransen, konfigurationer, körbar programkod etc. Undvik dock i möjligaste mån att iscensätta detta som en vattenfallsleverans som först skapar en analys, därefter en design eller arkitekturskiss, därefter en körbar lösning o s v…De allra bästa leveranserna jag sett har arbetat med samtliga leverabler parallellt igenom deras utföranden. Insikter från arkitekturarbete kan då naturligt spilla över i själva konstruktionen av digital komponent. Insikter från utvecklingsarbetet får direkt effekt på revisioner av arkitektur och justerad analys. Att hålla blicken fokuserad vid målet och realiserad nytta är extra viktig i organisationer som har sin tradition och hävd att primärt arbeta med att skriva fram dokument för beslut till olika organ, styrelser eller politiska nämnder.
- Kundsamarbete framför kontraktsförhandling
Kanske främst i offentlig sektor, med lång och trogen vana av långa listor på “väl” definierade krav och upphandlingar är konceptet med kundsamarbete framför kontraktsförhandling (eller dess motsvarighet) fortsatt något främmande. Nya upphandlingsformer och sätt att bedriva anskaffning rör sektorn i rätt riktning, men fortfarande finns en väg att vandra. I interna leveranser finns ett lite annat synsätt på hur denna kontrakts- eller behovsförhandling ska se ut men ofta missas poängen med det agila manifestets tredje utsaga. I allmänhet sitter kommunen, regionen eller myndigheten kvar i en teoretisk modell som mer än någonsin delar upp i beställare och utförare. Kärnprocess och stödprocess. Verksamhet och stab. Ett tydligt dokumenterat krav eller beskrivning tas som garant för framgång i utveckling.
Vad kan vi då göra istället?
En nyckelfaktor i frågan är insikten att “kunden”, behovsframställaren, verksamheten, sitter på kunskaper som den agila leveransorganisationen svårligen kan attrahera och upprätthålla själva. Dessa kunskaper behöver komma fram i ljuset på ett sätt som gynnar framtagandet av leverablerna, den digitala produkten och dess eventuella konfiguration. Det sker enligt mitt förmenande allra bäst där kunden eller verksamheten aktivt deltar i arbetet med tät frekvens och genom att tillgängliggöra nyckelkompetens, dokumentation, leverantörer till vilka beroenden finns och annat som främjar teamets framdrift. Det räcker inte med periodiska inhopp i samband med en sprints avslut, demotillfälle eller motsvarande. Modern digital utveckling kräver samskapande av många olika roller. Däribland behovsframställaren eller kunden själv.
- Anpassning till förändring framför att följa en plan
Hela idén med agilt arbete är att öka sin förmåga till att agera på förändring. Med erkännandet att vi tar som sämst beslut vid en tidpunkt då vi vet allra minst om förutsättningarna för en leverans är utgångspunkten att hela tiden objektivt betrakta sin egen progress och lära sig i enlighet med framdrift. Nya stenar vänds på, nya insikter tas. Slutsatser som var omöjliga att dra vid projektet eller utvecklingens start kan vara supertydliga bara ett par veckor in i arbetet. Det finns flera olika smaker av detta, hämtade ur olika sammanhang. Hit hör bland annat PDCA och OODA-loopen. Efterlevnad till denna, den fjärde av det agila manifestets utsagor följer varierande grad av svårighet. Redan vid införandet av överbyggnadsramverk så som SAFe inträder ett visst mått av planerings-overhead. Saker paketeras i agila releasetåg och leveranser ska koordineras mellan olika team. Om teamen dessutom saknar kompenserande åtgärder för uteblivna releaser till sitt respektive tåg äventyras kanske en helt komposit sammansatt produkt. Vid inträdet av koordination mellan olika team finns också en risk att emfas hamnar på den överliggande planen eller road mapen och efterlevnad till denna snarare än att adaptivt följa uppkomna händelser och insikter. Vanliga symptom här är återfall till sekventiellt arbete (där det inte är nödvändigt) och krav på rigorös administration där kort och tokens måste vara korrekt uppdaterade så att koordinerande krafter kan göra sin insats. Dessutom; för att förenkla tillvaron låses funktionalitet in i allt större tidsboxar så som planeringsinkrement motsvarande ett helt kvartals leveranser, ibland ännu längre.
Jag håller utmaningar i denna, den fjärde utsagan i det agila manifestet, som de viktigaste att adressera och arbeta mot lösningar för eftersom dålig hygien i förhållande till denna utsaga lätt tippar över och skapar antiproduktiva beteenden där allt fokus hamnar på process, dokumentation och tillämpning av diverse verktyg. Alltså direkta antipatterns för flera av det agila manifestets utsagor.
Vad kan vi då göra istället?
Att anpassa till förändring innebär fundamentalt att hela tiden förstå den tillvaro man befinner sig i och hur denna är under ständig förändring. Ny fakta och nya data tillkommer i ett allt högre tempo och i denna miljö blir kunskapen om hur man aktivt sållar bort allt brus som inte är relevant allt viktigare. Team och produktägare behöver aktivt och ofta hitta sina relevanta mätpunkter, utvärdera sin prestanda i förhållande till dessa och repetitivt ta korrigerande åtgärder om det krävs. I ett uppdrag kanske tidsdimensionen är kritisk medan andra lyfter kvaliteten i levererad produkt högre. Vissa leveranser har tydliga ekonomiska incitament, andra präglas av förmåge- och intelligenshöjande av delar av organisationen. I en sådan tillvaro är det sista man bör göra att slaviskt titta på de klassiska “KPI:erna” för agil utveckling så som burndown charts, cumulative flows, velocity och andra. Lägg lite tid åt att reflektera hur man faktiskt kan mäta framgång, identifiera underliggande data, samla in dessa, sammanställ dem och reflektera över dem tillsammans i teamet. Använd enkla tekniker för rotorsaksanalys för att förstå händelsekedjor om framgången ser ut att minska. Nyttja tiden i retrospektiv klokt och investera tid och resurser i korrektiva åtgärder tidigt för att slippa ackumulera teknisk och psykosocial skuld.
Framför allt: Var försiktig med att kontraktera en “agil coach”. Det finns gott om gårdfarihandlare och månglare av ormolja därute.
//@Stake