Vad innebär egentligen teknisk agilitet?
Teknisk agilitet, synonymt med lättrörlig systemutveckling eller produktutveckling, handlar om att enkelt och riskfritt kunna anpassa sig och ändra riktning när hinder uppstår eller när ny information kräver en förändring. Agilitet adresserar i grund och botten det faktum att vi kommer göra misstag, vi kommer ha fel, och osäkerhet är en del av branschen vi agerar i. Även tech-giganter som Google, Microsoft och till och med den ikoniske Steve Jobs har ibland haft fel i sina förutsägelser – vi kommer också ha det. Teknisk agilitet ger oss förutsättningar att hantera fel och snabbt ändra riktning baserat på erfarenhet och feedback. Att vi lär oss av våra misstag är fundamentalt inom systemutveckling – det vi gör är per definition nyutveckling, vi kan inte utveckla nästa produkt på precis sätt som vi utvecklade den förra.
Fördelarna med teknisk agilitet
Ett tekniskt agilt arbetssätt underlättar genom att påskynda utvecklingscykeln och möjliggöra snabbare feedback från användare. Genom att följa korta utvecklingscykler, ofta kallade sprintar, skapas möjlighet att anpassa och förbättra produkten snabbt. Jämför det med den traditionella vattenfallsprocessen där arbete utförs i linjär ordning, vilket kan förlänga tiden till produktlansering. Feedback – riktig feedback från riktiga användare, kommer i slutet, när det är som svårast och dyrast att agera på den.
Från vattenfall till agilitet – ingen hybrid
I det traditionella vattenfallsarbetssättet utförs kravspecifikation, utveckling och tester sekventiellt. I kontrast till detta betonar det agila arbetssättet samarbete och iteration. Korta utvecklingscykler möjliggör ständig anpassning av krav och riktning, med fokus på att skapa värde i varje steg. Samarbete mellan olika kompetenser i teamet undviker flaskhalsar och förbättrar kommunikationen mellan kravställare, utvecklare och kvalitetssäkring.
Den vanligaste missuppfattningen är att en hybrid av arbetsätt fungerar. Mitt favorituttryck som svar är; ”Det går inte att köra lite högertrafik och lite vänstertrafik, och hoppas att man ska få fördelen utav båda.” Det kostar alltid mer än det smakar att arbete på det sättet. Det är bättre att bestämma sig för att arbeta på ett sätt och sen ta konsekvenserna: känner ni att ni måste köra “big design up front” och släppa produkten i stora sjok så kan ni åtminstone optimera för det, istället för att låtsas att ni ska vara lite agila vid sidan av. Att köra två metoder parallellt dubblar administrationen, och tar bort i princip alla fördelar.
Tips för en smidig agil start
- Börja med teknisk agilitet: Innan du strävar efter en omfattande agil transformation är det viktigt att säkerställa att din tekniska utvecklingskompetens är på plats. Kvalitet och snabbhet är grundläggande.
- Starta i liten skala: Inför förändringar gradvis och börja med att applicera agilitet på små projekt eller delar av ditt arbete. Det ger möjlighet att lära sig och justera under resans gång.
- Fokusera på värde: Identifikationen av högsta prioritet och mest värdeskapande arbete är avgörande. Rule of One – en vecka, en uppgift, ett team – kan hjälpa till att hålla fokus. Det är svårt – väldigt svårt, men det är just därför det kan ge dig en fördel mot konkurrenterna.
- Utmana beroenden: Bygg organisationer kring värdeflöden istället för teknik eller funktioner. Minska beroenden mellan team, och underlätta snabb feedback.
- Testa: När man börjar testa ser man vart det gör ont. Anledningen till att agil transformation misslyckas är ofta att man försöker lista ut och rulla ut – i stället för att testa. Testa produkten på faktiska användare, testa arbetssättet på faktiska medarbetare, och LYSSNA PÅ DERAS FEEDBACK. Om användaren hatar din idé är det en dålig idé.
- Lär av misstag: Agilitet omfamnar osäkerhet och fel. Lärdomarna från misslyckanden är en värdefull resurs för att guida dig i framtiden.
Standarder och ramverk för teknisk agilitet
Inom teknisk agilitet finns ganska få standarder och ramverk som fått stor spridning. Men här är några exempel:
- Extreme Programming (XP): En samling tekniska practices som främjar kvalitet och lättrörlighet i teknisk utveckling. XP inkluderar metoder som parprogrammering och testdriven utveckling för att säkerställa kvalitet och flexibilitet.
- Kanban: Ett visuellt verktyg som hjälper till att visualisera arbetsflödet och hantera arbetsuppgifter. Det underlättar att hantera prioriteringar och upptäcka flaskhalsar i utvecklingsprocessen.
- DevOps: En metodologi som kombinerar utveckling och drift för att skapa en sömlös process från kodning till driftsättning. Ju fortare du kan få ut din kod i en produktionslik miljö, desto fortare kan du få feedback.
- Scrum: Det mest spridda ramverket inom agil projektutveckling, med fokus på korta utvecklingscykler och kollaboration inom teamet.
En praktisk liknelse: Att skapa värde i utvecklingsprocessen
Låt oss illustrera vikten av att skapa värde genom att titta på en liknelse från vardagen. Tänk dig att några personer samarbetar för att laga middag tillsammans. En person är en mästare på att göra sås, men mitt i processen ser personen att köttet bränns i stekpannan. Sitter man fast i att fokusera på sin egen uppgift kunde man resonera: “Jag är inte bra på att steka kött, någon annan är säkert bättre på det, det här är deras problem” Men vad blir det för middag av det? Oavsett hur bra såsen är så kommer den inte kompensera för att köttet är bränt.
Denna liknelse är en spegling av agilitetens kärna. I utvecklingsprocessen handlar det inte bara om att vara specialist på en viss uppgift; det handlar om att vara medveten om hela processen och agera när det behövs. Att skapa värde är nyckeln. Om vi redan har tillräckligt med sås för middagen, är det ingen mening att laga mer. I stället ser vi vad vi kan göra för att bidra till slutleveransen: i det här fallet, vad krävs för att middagen ska bli så god som möjligt.
Det som gör detta till en utmaning är att både organisationen och användarna måste vara villiga att omfamna detta sätt att arbeta. Många organisationer har en inbyggd benägenhet att försöka kontrollera allt i förväg, och det ses som bättre att inte göra något alls (men ha väldigt bra tidrapportering på vad man inte har gjort!), än att göra något som kanske blir fel, men genererar lärdomar om vad som skulle kunna bli rätt i framtiden.
Det är här den tidigare mat-liknelsen blir så träffande. Precis som i matlagning, är det inte bara mängden som betyder något; det är kvaliteten på varje komponent och hur de samverkar som skapar det perfekta resultatet. Genom att följa ett bra recept, smaka av och ta emot feedback, kan vi fortsätta att förbättra och anpassa våra produkter för att tillfredsställa våra användares behov på bästa sätt.
Vill du lära dig mer om teknisk agilitet?
Vi erbjuder ett flertal kurser inom olika agila arbetssätt, bland annat inom ramverken SAFe® och Scrum. Kolla in Consids kurser inom agila arbetssätt. I avsnitt 47 av Consids podd Utveckla samtalar jag, Sam Storm, dessutom mer om teknisk agiltet med våra värdar Lily och Simon. Lyssna in avsnittet.
