Någonstans runt år 2000
När jag började med mjukvaruutveckling, som exempelvis webbutvecklare, för många år sedan (innan 2000), så var det ganska kaotiskt dit jag kom. Inga synkmöten, inga morgonmöten, inga demos, inga UX-test (användningstest) eller konverteringstest. Inga automatiserade tester, eller ens några tester alls. Kör så det ryker var metoden på många webb-bolag.
Fördelen var att vi ofta satt tillsammans med marknadsavdelningen, affärsutvecklarna, kundtjänst, inköpare och säljare. Inga ledtider, allt beslutades direkt och tillsammans.
På andra platser, där jag hade vänner, var metoden “Skriv ner så många saker ni kan komma på som kan behövas i en jättelång spec i ett halvår. Lämna den sedan till ett utvecklingsteam och gå vidare till nästa projekt. Skäll på utvecklarna om de levererar fel saker eller om det tar för lång tid. Och häng projektledaren!”
Fördelarna var nog inte så många, utöver att det faktiskt fick ta lite tid att formulera sina tankar och lösningsidéer, grubbla, ta reda på en del bakgrundsinformation, modellera och tänka på olika möjligheter.
Någonstans runt 2005
Dessa metoder fungerade inte direkt klockrent i längden. Så kom Scrum
och XP (Extreme Programming), Lean Software Development och
Kanban-metoden.
Nu skulle vi jobba i något mer strukturerade team. Demos varannan vecka
för stakeholders. Kundrepresentanter i teamet som fick agera som en
slags prioriterings-tratt för alla olika viljor. Test började
automatiseras och definieras före koden. Användarupplevelsen började bli
viktig och istället för långa projekt så planerades små korta loopar av
utveckling och leverans. Regelbundna reflektioner över
utvecklingsprocessen och hur den kunde förbättras. Visualisering av
aktuellt arbete på en tavla för att se vad som var klart och inte.
Det här gillade jag som då hunnit bli projektledare och Scrummaster. Det
fanns en struktur och plötsligt några ramar att förhålla sig till.
Takten blev lite mer fokuserad, transparent och i mina ögon kontrollerad och vi fick ut något mer stabila och uppskattade leveranser med mindre kaos, stress och övertid.
Nackdelen var väl att med tiden blev dessa rutiner och roller ganska rigida. Rutinerna såsom morgonmöten, retrospektiv och demos i sig blev viktigare än själva leveransen och teamets välmående. “Hur agil är du?” var den ständiga frågan och måttstocken blev “Hur många morgonmöten har du?”

Någonstans runt 2020
Med tiden så ville många organisationer skala det “agila” arbetssättet till större avdelningar och större leveranser. Ramverk som SaFe dök upp för att synka många team eftersom de tekniska och affärsmässiga beroendena blivit så många. De tidiga supertighta små teamen lyckades och växte och behov av struktur uppstod. Ticket-system såsom Jira tog stora andelar av marknaden och kallade sig Kanban. Det agila arbetssättet blev likvärdigt med att ha ett stort Jira-system med massor av tickets och många och långa synk- och planeringsmöten. Allt för att försöka få ordning på torpet.
Samtidigt fanns fortfarande en vilja att jobba som lag och att utvecklingsteamen skulle få en chans till kompetensutveckling inom ramen för jobbet.
Mer och mer byråkrati började smyga sig in i teamarbetet och många utvecklare dränktes i Jira-administration och långa estimeringsprocesser där varje liten uppgift skulle få en estimeringspoäng.
Fördelen var nog att även ledningar för stora organisationer insåg värdet av team-organisationer och ett någorlunda iterativt arbetssätt.
Någonstans runt 2026
Sedan kom “AI”. Nu ska inte programmerare behövas längre. Skala ner och ersätt med “vibe coding” och låt erfarna utvecklare tröska igenom enorma mängder “AI”-genererade kodförslag och ägna sin tid åt buggrättningar. Strunta i att rekrytera nybakade programmerare; det är ju bara att prompta!
Fördelen är förstås att många komplicerade uppgifter faktiskt går snabbare att genomföra. Att det går att lära sig ett nytt programmeringsspråk eller ramverk betydligt snabbare än innan “AI”. Att en person kan få mer gjort på kortare tid och t.om kunna bli mer kreativ och ta ut svängarna när tid frigörs från syntax-koll.
Nackdelen… ja, det är bara att kika in på LinkedIn eller googla “resultat av vibe-kodning” eller “säkerhetsproblem med AI-genererad kod”.
Tillbaka till rötterna
Efter att ha varit med och jobbat i, sett och hört om alla dessa varianter plus några till, så ser jag ett behov av att titta tillbaka på och minnas vad som faktiskt leder till effektiv och värdeskapande programvaruutveckling.
Det finns delar från alla tider som är värdefulla att ta med sig in i framtiden.
Att använda “AI” som ett av flera verktyg för att faktiskt förbättra produkterna vi utvecklar. Att återgå till det nära samarbetet i verkliga tvärfunktionella team - där programmerare sitter bredvid stakeholders, marknadsförare och kundtjänst - dagligen! Att visa upp vad vi gör regelbundet. Att följa principen “test först”. Att stanna upp och tänka och ta reda på information innan vi gör. Att i stora organisationer kunna ha en gemensam agenda och mål och där insyn och regelefterlevnad är möjligt.
Välkommen till Agila Sverige 2026 och spåret “Tillbaka till rötterna - att arbeta nära med glädje”
Därför kommer jag och två nära kollegor och vänner i branschen (Anette Lovas, Ola Ellnestam) moderera spåret “Tillbaka till rötterna” på årets Agila Sverige-konferens den 28-29 maj.
Vi önskar att få se många gamla och nya vänner posta talarförslag och/eller delta på årets konferens!
Att utveckla programvara är nästan lika nytt som LLM:er (Large Language Models) dvs de modeller som genererar kod. Vi har just börjat.
Hur gör du bra, hållbara och nyttiga system? Spelar nära samarbete fortfarande en roll?
Välkommen att dela med dig i en eller annan form! Eller bara mingla och ta ett par dagar att reflektera över hur du skulle vilja göra dina system och produkter.