Vi behöver inga processer, vi är agila!

Många organisationer introduceras för agila koncept under sin övergång till molntjänster. Vissa har redan genomgått större transformationer och arbetar med att förbättra dessa, medan andra antingen är mitt i processen eller står inför att påbörja den. Oavsett var du är i resan så slängs det med många agila begrepp och jag har hört många ursäkter för att slippa göra både det ena och det andra för att “stoppa in valfritt agilt begrepp”, slut diskussion. Så hur är det egentligen? Måste man bli agil för att man flyttar system till molnet? Får verkligen utvecklarna göra sig fria från alla uppsatta processer bara för att vi gör en agil transformation?

Först behöver vi som vanligt reda ut lite begrepp. Jag tänkte ta de vanligaste, Agile, Lean, Scrum, Kanban och SAFe och DevOps. Det finns också vanliga metoder och ramverk tex 5s, Sex Sigma och Just in Time, men eftersom dessa mer vanligtvis används inom industri och produktion och inte IT så väljer jag att inte diskutera dessa.

Agile

Begreppet Agile, som betyder smidig, flexibel eller anpassningsbar, används frekvent och grundar sig i en rad värderingar som ursprungligen uppstod inom mjukvaruutveckling. Men de kan också appliceras på alla former av produktutveckling oavsett om det ska skrivas kod eller inte. Grunden till agil mjukvaruutveckling är det agila manifestet.

Värderingar

• Individer och interaktioner över processer och verktyg.

• Fungerande programvara över omfattande dokumentation.

• Kundsamverkan över kontraktsförhandling.

• Att reagera på förändring över att följa en plan.

Principer

1. Kundnöjdhet genom tidig och kontinuerlig leverans av värdefull mjukvara.

2. Välkomna förändrade krav, även i sen utvecklingsfas.

3. Leverera fungerande mjukvara ofta (veckovis snarare än månadsvis).

4. Nära, daglig samverkan mellan affärsfolk och utvecklare.

5. Projekt byggs kring motiverade individer, som bör litas på.

6. Ansikte-mot-ansikte-kommunikation är den bästa formen av kommunikation.

7. Fungerande mjukvara är det primära måttet på framsteg.

8. Hållbar utveckling, kapabel att upprätthålla ett konstant tempo.

9. Kontinuerlig uppmärksamhet på teknisk excellens och god design.

10. Enkelhet – konsten att maximera mängden arbete som inte görs – är avgörande.

11. De bästa arkitekturerna, kraven och designerna uppstår från självorganiserande team.

12. Regelbundet reflekterar teamet över hur man kan bli mer effektiva och justerar därefter.

Agile som helhet är alltså mer en kultur, hur agerar vi mot varandra och mot kunder. Det betyder inte att vi saknar processer, verktyg, dokumentation, kontrakt och planer. Bara att vi värderar personal, fungerande produkter, kundkommunikation och att förändras med marknaden mer. Jag tror den punkt som skapar mest kontrovers och diskussioner egentligen är punkt 11 med de självorganiserande teamen, men jag tror i slutändan att det inte handlar om att alla team helt plötsligt ska blir självorganiserade, utan att med tiden kan förmågan till självorganisation ökas i takt med ansvaret och organisationens nivå av agilitet.

Lean

Termen Lean myntades 1988 av affärsmannen John Krafcik och fick sedan en djupare definition av forskarna James Womack och Daniel Jones 1996. Alla hade studerat Toyotas produktionssystem som sprang ur mellankrigstidens Japan. Toyota behövde hantera flera utmaningar med att producera i ett land utan egna tillgångar och kom på ett eget system för att lyckas att producera mer med mindre tillgångar. Mycket handlade i slutändan om att eliminera slöseri men också startade den trend som har hållit i sig till pandemins dagar med Just in Time (JiT) produktion där så få varor och arbete ska vara på lager eller stå stilla någonstans under produktionsprocessen.

Om jag skulle försöka mig på att sammanfatta något som det skrivits hela böcker om så blir det dessa principer:

• Värdefokus: Identifiera vad som skapar värde ur kundens perspektiv och fokusera alla processer på att leverera detta värde.

• Eliminering av slöseri: Lean strävar efter att eliminera allt slöseri i processerna, där slöseri definieras som allt som inte bidrar till kundvärdet. Detta inkluderar överproduktion, väntetid, onödig transport, överflödig bearbetning, onödigt lager, rörelser och defekter.

• Kontinuerlig förbättring (Kaizen): Lean betonar vikten av kontinuerlig, inkrementell förbättring av processer. Genom att ständigt sträva efter förbättringar i alla delar av en organisation kan man uppnå högre effektivitet och bättre kundvärde.

• Respekt för människor: Lean lägger stor vikt vid personalens engagemang och utveckling. Genom att respektera och lyssna på dem som är involverade i processerna, kan man dra nytta av deras kunskap och erfarenhet för att förbättra verksamheten.

• Jämna ut arbetsbelastningen (Heijunka): Detta innebär att arbeta i en jämn och balanserad takt för att undvika överbelastning och säkerställa en jämn produktionsflöde.

• Kvalitet vid källan: Säkerställa kvalitet genom att rätta till problem så snart de uppstår, för att förhindra att fel sprids vidare i produktionskedjan.

Jag tycker det är intressant att det finns ganska tydliga spår mellan Agile och Lean, speciellt i fokus på värde (fungerande programvara i samband med kundönskemål), respekt för människor (Individer och interaktioner) och kontinuerlig förbättring (inte bara följa en plan).

Scrum

Scrum är ursprungligen en rugbyterm där alla lagmedlemmar samlas tätt ihop för att få kontroll över bollen. Denna metod började användas redan på 1980-talet för att möjliggöra snabbare produktutveckling genom ett korsfunktionellt team. Detta team är involverat genom alla faser av produktskapande. Ursprungligen kallades detta för rugbymetoden, men det kom att bli känt som Scrum inom mjukvaruutveckling under 1990-talet.

Grunden i Scrum är ett korsfunktionellt team, alltså ett team som besitter alla kompetenser som krävs för att lansera en produkt. Teamet står i direkt kontakt med slutkunden och utvecklar produkten i korta cykler, kallade sprintar. Dessa sprintar, som vanligtvis varar 1-4 veckor, används för att ofta ha kontakt med slutkunden och kunna justera leveransen för att undvika onödigt arbete.

Roller i Scrum:

• Product Owner: Ansvarig för att definiera projektets mål och prioritera arbetsuppgifterna (backloggen).

• Scrum Master: Fungerar som en facilitator för teamet och ser till att Scrum-processen följs. Scrum Master hjälper teamet att lösa hinder och förbättra dess dynamik.

• Utvecklingsteam: Ett tvärfunktionellt team som utför arbetsuppgifterna. Teamet är självorganiserande och ansvarar för att leverera produktens inkrement.

Möten i Scrum:

• Sprintplanering: Ett möte där teamet enas om arbetsuppgifter för den kommande perioden.

• Dagliga Scrum-möten (Stand-ups): Korta dagliga möten för att synkronisera teamets arbete och planera för nästa 24 timmar.

• Sprint Review: Vid slutet av varje sprint hålls en genomgång där teamet presenterar det de har åstadkommit, vilket ger möjlighet för feedback och justeringar.

• Sprint Retrospective: Ett möte efter varje sprint för att diskutera vad som gick bra, vad som kan förbättras och hur teamet kan implementera dessa förbättringar i nästa sprint.

Scrum är djupt rotad i både Lean- och Agile-värderingar, men är här nedbrutet till en faktisk vardagligt applicerad process. En varning dock, bara för att du håller vissa möten och följer en process betyder det inte att din agila resa är klar.

Kanban

Kanban är en metodik med fokus på kontinuerlig förbättring och effektivitet i arbetsflöden. Ursprungligen utvecklade Toyota metoden efter att ha studerat livsmedelsaffärer, där kunder tar för sig av varor och affären fyller på efter behov. Man anpassade och införde speciella kanban kort för att förbättra tillverkningsprocesserna. Kanban har sedan anpassats till mjukvaruutveckling och andra arbetsområden.

Här är några nyckelaspekter av Kanban:

• Visualisering av Arbete: Ett centralt element i Kanban är användningen av en Kanban-tavla, vilken visuellt representerar arbetsflödet. En typisk Kanban-tavla är indelad i kolumner som representerar olika stadier i arbetsprocessen (till exempel "Att göra", "Pågående", "Klart").

• Begränsa Pågående Arbete (Work In Progress, WIP): Kanban lägger stor vikt vid att begränsa mängden arbete som är under bearbetning vid en given tidpunkt. Genom att sätta gränser för hur mycket arbete som får vara i varje stadium i processen, kan team effektivisera flödet och minska överbelastning.

• Flödeseffektivitet: Kanban strävar efter att uppnå ett jämnt och kontinuerligt arbetsflöde, där arbetsuppgifter flyttas smidigt från start till avslut. Detta bidrar till snabbare leveranstider och ökad produktivitet.

• Flexibilitet och Responsivitet: Kanban tillåter team att anpassa sig snabbt till förändringar. Istället för fasta tidsramar som i Scrum, kan arbetsuppgifter läggas till, omvärderas eller omorganiseras baserat på aktuella prioriteringar och resurser.

• Kontinuerlig Förbättring: Precis som andra agila metoder, uppmuntrar Kanban till ständig reflektion och förbättring av arbetsprocessen. Team utvärderar regelbundet sitt flöde och processer för att identifiera och åtgärda flaskhalsar.

Visualiseringselementet i Kanban har blivit nästan en defakto-standard inom agila arbetssätt och även icke agila. Det är bara att skaffa en tavla och börja visualisera sitt arbete. Återigen här, bara för att du visualiserar ditt arbete på en Kanban tavla så är du inte agil, du har bara visualiserat ditt arbete, det agila kommer med att du mäter och kontinuerligt förbättrar hur och vad du arbetar med.

SAFe

Scaled Agile Framework for enterprises, är ett ramverk för att skala upp agila arbetssätt från teamnivån upp till bolagsnivån. Inte för att Agila tankesätt är oskalbara från början, men min personliga åsikt är att många gillar tryggheten i tex Scrum och vill ha svart på vitt vilka möten man ska hålla och vilka processer som ska finnas. SAFe kombinerar element från Agile, Lean, Scrum och Kanban och ger dig ett färdigt agilt paket.

Här är några av de centrala komponenterna i SAFe:

• Agila team: På den lägsta nivån består SAFe av agila team som använder Scrum, Kanban, eller en blandning av dessa metoder för att organisera och utföra sitt arbete.

• Program Level: SAFe organiserar team i större enheter kallade Agile Release Trains (ARTs), som är långvariga grupperingar av agila team som planerar, utför och levererar tillsammans.

• Large Solution Level: För större och mer komplexa lösningar som kräver samarbete mellan flera ARTs, tillhandahåller SAFe riktlinjer och metoder för att hantera dessa större initiativ.

• Portfolio Level: SAFe inkluderar också principer och praxis för lean portföljhantering, vilket hjälper företag att anpassa strategi till utförande och att organisera och prioritera arbete på företagsnivå.

• Lean-Agile Leadership: SAFe betonar vikten av ledarskap i en lean-agil transformation och att ledare ska exemplifiera och främja agila principer och tankesätt.

SAFe ger din organisation en ritning att utgå ifrån, ger alla samma begrepp att förhålla sig till, det finns färdiga kurser och roller. Det gör det lättare att komma igång och känns bekvämt för många bolag, speciellt de som är vana att följa ramverk. Risken är dock att du bara byter ut alla processer mot nya processer, gamla roller mot nya men missar den kulturella aspekten. Med kulturen bygger du förmågan att kontinuerligt förbättra dina processer och arbetssätt efter vad som passar din organisation och vad som tillför värde för dina kunder.

DevOps

Jag skulle vilje benämna DevOps som när agil mjukvaruutveckling möter operations. Det vill säga, du har ett korsfunktionellt team som gör både mjukvaruutvecklingen (Dev) och långsiktigt förvaltar (Ops) den plattform som mjukvaran körs på. Som en uppmärksam läsare kanske du då undrar, men i scrum har man ju redan ett korsfunktionellt team? Vad är nu skillnaden. Scrum:s korsfunktionalitet tar egentligen bara hänsyn till produktutvecklingen, inte den fortsatta förvaltningen.

Andra nyckelkoncept i DevOps är:

• Automatisering och Continuous Integration/Continuous Delivery (CI/CD): DevOps implementerar ofta automatiserade processer för att testa och distribuera mjukvara, vilket minskar manuellt arbete och ökar effektiviteten.

  IaC: Infrastructure as Code, för att hela teamet ska kunna jobba med ett arbetsätt så blir även den infrastrukturen som tas fram kod, dvs kod som beskriver infrastrukturens uppsättande. Denna kod kan sedan hanteras precis som all annan kod. Den versionshanteras och installeras med så stor automation som möjligt.

  Shift-left: När allt arbete finns i fördefinierade automationsprocesser försöker ett devops team att tidigarelägga diverse uppgifter i kedjan, istället för att göra säkerhetstester på slutet, till höger i processen, flyttas dessa till vänster och görs i början och under tiden. Allt för att inte komma till plötsliga stopp och upprätthålla flödet.

Jag tycker shift-left-principen är en av nycklarna, att ständigt tänka hur kan du integrera fler steg som normalt sett händer efter produktutvecklingen att vara en integrerad del av den. Hur kan du bli så klar som möjligt, för kunder att konsumera din produkt eller tjänst, när utvecklaren trycker på knappen för produktionssättning. För att detta ska fungera effektivt behöver de andra delarna av DevOps vara på plats.

Jämförelse

Metoderna förhåller sig på lite olika nivå, där jag ser Lean och Agile som mer värderingar eller en kultur, Kanban och Scrum är metoder, eller vågar jag säga processer, som en väg för ett team att passa in i kulturen. Kanban lutar lite mer åt Lean, med ursprung i industrin. Scrum kanske något mer åt Agile eftersom båda kommer mer från mjukvaruutvecklingshållet.
SAFe säger egentligen inget om kultur(i sitt ramverk) men inkluderar både agila koncept och Scrum och kanban-metoderna.
DevOps blir egentligen bara en utökning av Scrum/Kanban teamets uppdrag och mycket av det som DevOps innehåller är lösningar på hur man kan optimera flöde och minska antalet stopp/pauser i sin produktionskedja.
Gemensamt för alla är dock:

1. Fokus på flexibilitet och att svara på förändring.

2. Kontinuerlig förbättring och effektivisering.

3. Att lyssna på kunden och prioritera värdeskapande.

4. Visualisering och hantering av arbete.
   

Agila metoder och molnet

Det finns egentligen inget som säger att du måste bli det minsta agil för att använda molntjänster. Det går bra att köpa infrastruktur och peka och klicka sig fram som tidigare. Men molnet är anpassat för att kunna vara mer agilt. Först och främst uppfyller du Lean-principer genom att inte ha ett varulager av serverkapacitet utan beställer bara det som behövs, när det behövs(JiT). Sedan är molnet skapat för DevOps-principer. Stödet för CI/CD och IaC är inbyggt och gör det lättare att bygga korsfunktionella team som sätter upp sin egen virtuella hårdvara (självklart automatiserat via självservice). Om du redan idag har utvecklare som kör Scrum eller Kanban är steget väldigt kort, rent tekniskt, att utöka deras ansvar till att bli DevOps-team. Dessa team kommer sedan behöva införliva vissa agila värderingar för att bli så effektiva som möjligt. Hur ska ett Scrum-team kunna införliva sitt löfte om att leverera värde till kunden om de aldrig fått prata med eller visa sin produkt för kunden själva? Hur ska de kunna tillämpa shift-left om du inte är flexibel nog att kunna omstrukturera processer och tidigarelägga steg som tidigare annars skedde efter att all kod har skrivits klart? Det här utgör den största delen av en agil omställning; att organisationen ska göra shift-left på sina processer och ansvarsområden för att passa ett korsfunktionellt DevOps-team.

Oavsett om du vill börja köra DevOps eller bara införliva fler agila värderingar, så tror jag att det sämsta du kan göra är att börja slänga ut alla befintliga processer. De agila ramverken och metoderna innehåller, som tidigare nämnt, både massor av nya processer men också metoder för att effektivisera befintliga. Använd din nya kultur och ta inspiration från de metoder som du tycker passar din organisation. Applicera metoderna på befintliga processer, förädla, förkorta, ta bort eller byt ut dem. Agilitet handlar inte om att ta bort alla processer, bara om att kontinuerligt förbättra de processer och delprocesser som tillför värde och ta bort de som inte gör det. Kanske det mest agila handlar om människor, så ibland istället för att mata in text i ett verktyg, ta en fika tillsammans med mottagaren och prata om det.