Kom igång med ditt agila arbete

Fler och fler organisationer beslutar sig för att anamma Agila metoder för sin utvecklings- och applikationshantering. Här är några handfasta tips från våra erfarenheter hur man gör för att snabbast komma igång med Agilt arbete.

Det Agila tankesättet utgår från en samling värderingar definierade i Manifest för Agil Systemutveckling. Namnet kommer från engelskans ”agile”, som betyder lättrörlig.

Vad betyder det att arbeta agilt?

Till att börja med måste vi definiera vad vi menar med att arbeta Agilt. Lite förenklat så menar vi att vi inser och förstår att (framför allt) systemutveckling har en inneboende komplexitet som gör att vi på förhand inte alltid kan veta exakt hur en lösning ska se ut. Och att vi därför måste jobba explorativt i små korta iterationer med tydliga feedbackmekanismer. Allt i syfte att minska ledtiden från det att vi fångar krav till dess att vi börjar leverera på dem.

Vad är vår målsättning med agilt?

Det här måste naturligtvis också stämma överens med vår målsättning för en Agil transformation. För att nå framgång så måste vi definiera vad framgång är. Om vårt mål tex endast är att sänka kostnader så finns det enklare sätt än att ge sig på en Agil transformation. Då kan vi helt enkelt minska personal- och eller konsultmängden (och därmed acceptera lägre kvalitet eller värde i vår leverans). Om vi däremot önskar uppnå t.ex. kortare ledtider, ökad kundnöjdhet, ökad nyttjandegrad/anpassning till affärskrav eller minskad risk så kan Agila arbetssätt vara en utmärkt katalysator.

Passar agila metoder oss?

Den andra frågan man bör ställa sig är ”passar vår organisation/våra förutsättningar för agila metoder”? Det finns inget som säger att alla måste arbeta ”Agilt” men i regel tycker vi att fördelarna överväger potentiella nackdelar för de flesta organisationer. Ett korrekt tillämpat Agilt arbetssätt bör över tid innebära kortare ledtider i leveranser och bättre kvalitet på det som levereras. Samtidigt som vi får mer motiverad personal och en bättre förmåga att realisera önskat affärsvärde där applikationen (eller produkten som den oftast omnämns) används.

Om vår utveckling är outsourcad?

Vad gäller om vi har utvecklingen outsourcad? Generellt kan man säga att det är lättare att utveckla sin egen organisation än sin leverantörs. Men med ett korrekt partnerskap (snarare än kund-leverantörsförhållande) kring utvecklingen kan man absolut arbeta utifrån Agila metoder även i en sourcad miljö. Att tänka på dock är att det mellan produktägare och utvecklare ska finnas en hög nivå av förtroende och regelbundet utbyte. Oavsett om man är anställda i två olika organisationer. Det funkar bäst när man fysiskt sitter nära varandra, pratar samma språk och inte befinner sig i väsentligen olika tidszoner. Slutligen finns alltid en risk i en outsourcad lösning att leverantören har en annan agenda/strategi än den ni (som beställare av utveckling) har vilket potentiellt kan skapa bekymmer.

Kom igång med agilt arbete i 7 enkla steg

1. Identifiera, informera och tillsätt en Produktägare

Ett Agilt arbetssätt förutsätter ett nära samarbete mellan (affärs)verksamheten och utvecklarfunktionen. Utan denna nära koppling blir det mycket svårt, om inte omöjligt för utvecklarna att få den nödvändiga feedbacken på det man levererar. Vidare behöver också utvecklarna ha ett tydligt gränssnitt för vem de ska prata med. Om det finns många kravställare på en utvecklarfunktion så blir det omöjligt för dem att hantera prioritetsordning på de önskemål som kommer in. Detta är bland annat en av de viktigaste uppgifter som en produktägare utför.

För den person som ska axla rollen som produktägare är det viktigt att de också förstår vilka förväntningar och krav som de ska möta. Det finns mycket skrivet i ämnet och vi har själva lagt in vårt bidrag till debatten här. För verksamheten kan denna roll få en stor påverkan vilket innebär att det är viktigt att vi ordentligt diskuterar igenom rollen, ansvaret, arbetsuppgifter etc med verksamheten så att de verkligen förstår vad det innebär för deras nuvarande mekanismer och styrprinciper (budgetering, rapportering, orderföljd etc.).

2. Organisation, team och roller

För att praktiskt komma igång med agilt arbete är det nu dags att sätta ihop ett utvecklarteam som kan axla ansvaret att sköta utvecklingen. Till att börja med brukar man säga att ett team inte ska vara för stort eller för litet (6 +/- 3 personer ofta rekommenderat). I teamet så ska man kunna dela uppgifter med varandra. Dvs vi ska inte tillsätta en front-endprogrammerare, en UX designer, en testare etc. med tanken att det är enbart de som skall vara specialister i sitt team. Teamet får gärna ha resurser som har varierad kompetens inom de olika områdena men de måste kunna avlasta varandra. Därmed också ha ambitionen att lära sig att axla den arbetsuppgift som är viktigast att utföra just nu, snarare än fungera som flaskhalsar i produktionen. Det är trots allt teamet som helhet som utför det tekniska och praktiska utvecklingsarbetet och inte individerna i det.

Vanligt är också att man tillsätter en Agil Coach, en Scrum Master eller liknande. Ibland är dessa samma person och roll, ibland inte. Vi brukar förhålla oss agnostiska till titeln, den är inte det viktiga. Vad som är viktigt är att man har en person med erfarenhet av att arbeta i Agila metoder som kan hjälpa teamet att utveckla sina egna processer och metoder. Agila Coachen/Scrum Masterns uppgift är att undanröja hinder för teamet att utföra sitt arbete. Det kan vara frågor om att öka kompetens hos beställare, hjälpa teamet hitta lämpliga verktyg. Eller sätta upp visualiseringsverktyg såsom Kanban, etablera en backlog eller liknande. Vad som helst som hindrar teamets effektivitet (till och med mjuka faktorer som hur samarbetar vi i teamet).

3. Utveckla det självstyrande teamet

I en sant Agil set-up vill vi också frisläppa kraften från de individer vi har satt i teamet. Detta görs primärt genom att utveckla självstyrande team. De har hjälp och stöd utifrån från den Agila Coachen men måste själva få definiera sitt arbete så mycket det går. Prioritetsordning (vad:et) sätts av produktägaren men metodiken och verktygen (hur:et) ska ligga inom ramen för teamets egna ansvar. Då blir det också viktigt att vi lägger tid på att skapa ett fungerande team.

Grunden för detta ligger i att man i teamet litar på varandra. Vi jobbar ofta med enkla medel och övningar för att skapa bättre kännedom om varandra i teamet men också att sätta gemensamma mål och målsättningar. Ge teamet en tydlig kontext både i termer av arbetsplatsens utformning, såväl som i stödverktyg som används. Och viktigast av allt: var transparent, ge dem problemkontexten och lita på att de själva löser den på bästa sätt.

4. Sätta grundregler för arbetet

En del av att bygga teamet och skapa effektiva interna rutiner är att sätta grundregler för arbetet. Reglerna kan variera från ett team till ett annat men nedan har vi ett axplock av sådant som vi normalt brukar försöka etablera så tidigt som möjligt.

• Hur långa iterationer ska vi ha?
• Vad värderar vi högst (ta gärna hjälp av det Agila Manifestet)?
• Vilka principer har vi för att dela arbete med varandra?
• Hur viktigt är det att vi gör saker på ett likartat sätt?
• När ska man vara fysiskt på plats och när kan man jobba hemma och vilka möten har vi?
• Vad är vår ”definition of done” (dvs när är en leverans klar, inkluderar det testning, dokumentation, incheckning av kod etc)?
• Hur och var bygger vi upp vår backlog för produkten?
• Hur säkerställer vi att teamet också kan bidra/ge input till backlog samt prioritet för detta i syfte att både säkerställa löpande underhåll av teknisk plattform (ibland refererat till som teknisk skuld) såväl som till nya idéer för att utveckla affären genom produkten?

Låt teamet diskutera och etablera alla dessa grundregler. Dokumentera dem gärna synligt för alla i teamet att se och återkom till dem regelbundet för att utvärdera, förfina och utveckla. Och kanske viktigast av allt, se till att teamet verkligen tar sig tid för att etablera och över tid förfina sina regler, metoder och processer.

5. Utveckla ledarskapet

För att komma igång med Agilt arbete räcker det inte att vi säger åt ett gäng glada anställda att de är numera Agila och borde därför fungera bättre eller annorlunda mot hur de gjorde tidigare. Vi måste också se till att ledning, ledningsfilosofi och allmänt ledarskap taktar i den utvecklingen. Många chefer beskriver sig som delegerande men ibland av deras personal som att ”chefen dumpar omöjliga uppgifter på oss hela tiden…”.

En bra chef tror vi är en chef som är närvarande, kunnig och insatt, som aktivt visar sin tillit till personalen och som inte försöker lösa personalens problem åt dem. Vidare tror vi att en bra chef måste vara fokuserad på att skapa en aktiv dialog inom teamet, snarare än en monolog mot teamet. Det är också en dålig idé att göra chefen till produktägare och/eller agil coach. Den Agila filosofin deklarerar att man ska skapa egna ledare av sina medarbetare och det ligger något i det. Det vore dumt att bara använda folks leder när de är begåvade med en så stor hjärna, vars förmågor vi vill kroka in i och nyttja!

Fastna dock inte i fällan av att inte leda. Även autonoma team behöver veta åt vilket håll de ska sträva – OBS, inte vilken väg, utan vilket håll! Alignment och Autonomy kan och bör samexistera!

6. Skala av och förenkla

Precis som den Agila utvecklingsmetodiken av produkten så anser vi att man också i transformationen måste utvecklas iterativt och i många små steg snarare än att få till den perfekta lösningen först. Börja enkelt, reflektera ofta (boka upp tid i kalendern för detta), se till att teamet lär sig och i små steg löpande utvecklar sitt arbetssätt. Håll det så enkelt som möjligt, undvik allt som känns svårt och komplext eller som kräver avancerade verktygslösningar. Med tiden kanske vi har anledning att ta till oss dem när vi känner att vår effektivitet hindras utan dem. Men i början behöver vi hålla det så enkelt som möjligt för att så snabbt som möjligt komma igång.

7. Lär ut de nya rutinerna

När vi nu önskar att teamet ska börja jobba i en Agil cykel så är det viktigt att vi bygger upp teamets kompetens i metoden. Det kan göras på många olika sätt och det kanske vanligaste är väl någon form av kurs eller workshop. På marknaden finns många alternativ men vi tror att de 5 viktigaste stegen man måste lära sig för att komma igång med agilt arbete är:

• Planning: Detta moment handlar om att sätta upp en backlog samt skapa ett urval av leveranser/komponenter som vi avser att leverera inom en definierad (kortare) tidsram.
• Production: Är alltså själva produktionstiden (vi skriver kod etc.) samt hur vi löpande plockar och utför arbete. Helst vill vi också synliggöra progressen i arbetet.
• Pulse meeting: Hur vi löpande stämmer av progress och säkrar att prioriteringar är korrekta eller behöver anpassas.
• Review: Hur vi demonstrerar för produktägare (och potentiellt annan omvärld) resultatet av vår produktion för att inhämta feedback och bekräftelse på om vi gjort rätt saker.
• Retrospective: Hur vi gör en tillbakablick och reflektion över vårt arbete i den period vi just tagit oss igenom och identifierar vad som kan eller borde förbättras/utvecklas i vårt arbetssätt för nästkommande leveransperiod (ibland kallad Sprint).

Fem steg/ceremonier i den agila cykeln

Lämna din epost i fältet nedan och ladda hem en högupplöst version av ”An Agile Cycle” i A3 PDF-format.

När är vi Agila?

Frågan är om vi någonsin blir klara med vår Agila transformation? Det viktiga, och det som vi vill förmedla med denna text, är att det viktigaste är att komma igång med agilt arbete. Men den Agila cykeln kommer vi alltså att fortsatt repetera över tid fram till dess att vi finner att det inte längre är tillräckligt värdeskapande i relation till de kostnader vi uppbär. Då är det dags att montera ner teamet och fördela dem på nya spännande uppgifter. Och vem vet, kanske ta några av våra nyförvärvade Agila kunskaper och sprida dem vidare till andra delar av vår organisation?