Kärnan i välfungerande utvecklingsprocesser är regelbunden värdeleverans och återkoppling

I den här artikeln undersöker jag hur olika metoder för mjukvaruutveckling överlappar varandra för att belysa de gemensamma principerna.

För mer än tio år sedan studerade jagiterativa metoderoch använde ”Rational Unified Process – RUP” i mina uppgifter på fakulteten. Det var sista gången jag skrev otaliga dokument innan jag började med själva designen och kodningen. Jag ler när jag minns hur jag ritade dussintals detaljerade UML-diagram.

När jag började arbeta heltid var ett av mina första projekt att ta fram en uppsättningScrum-verktygför att underlätta ledningen av mjukvaruutvecklingsteam. Vi följde upp arbetsuppgifter, buggar, nedlagd tid, velocity och så vidare, med målet att skapa en bättre process. Scrum kändes alltid lite för mycket som en koreografi, och jag är inte säker på att de flesta någonsin förstod de underliggande principerna och värdet.

När jag gick över från projektinriktade företag till produktinriktade företag fick jag bekanta mig med metodernaKanban, Lean Startup,Design Thinking ochDesign Sprints. Det som imponerar mest med dessa metoder är framför allt de korta iterationerna och avsaknaden av strikta regler, vilket känns befriande. Dessa metoder fick mig att återigen fokusera på verkligheten genom konkreta mätvärden.

Nyligen upptäckte jagbegreppet ”kontinuerlig leverans”och det var en riktig aha-upplevelse. Jag insåg att det är den mest avancerade metoden för att regelbundet leverera värde och samtidigt automatisera repetitiva arbetsuppgifter.

I skärningspunkterna mellan olika metoder kan vi hitta liknande idéer:

• Snabba iterationer för värdeleverans (t.ex. daglig leverans inom Continuous Delivery, leverans var N:te vecka inom Agile, kortast möjliga leveransintervall inom Lean Startup, snabbast möjliga flöde inom Kanban)
• Kundfokuserat arbetssätt och kvalitativ feedback (t.ex. kundutveckling inom Lean Startup, användarberättelser inom Agile, användarundersökningar/observationer och tester inom Design Thinking och Design Sprints)
• Kortsiktiga planer (det finns inga detaljerade långsiktiga planer. Man lanserar och lär sig för att minska osäkerheten och anpassa planerna. Exempelvis release- och sprintplanering inom Agile, MVP inom Lean Startup, idégenerering och testning inom Design Sprints samt JIT-planering inom Kanban)
• Kvantitativ analys (t.ex. analytiska översiktspaneler inom Lean Startup, story points och velocity inom Scrum, cykeltid inom Kanban, releasefrekvens eller MTTR inom DevOps)
• Samskapande och effektiv kommunikation (t.ex. planering, stand-up-möten och retrospektiver i Scrum, uppstartsmöten i Kanban, parprogrammering i XP, idégenerering i designsprints)
• Optimering av teamets produktivitet (t.ex. optimering av pågående arbete (WiP) och minskning av slöseri inom Kanban, gruppering av aktiviteter inom Design Thinking, Design Sprints och CD, sekventiell LOFA-validering inom Lean Startup, automatisering av driftsättning, kontinuerlig integration och testning inom Continuous Delivery)

Det här är inte alla principer som är gemensamma för olika metoder, men de viktigaste.

Skulle du kunna ta fram en egen metod genom att kombinera principerna ovan på olika sätt?Ja.

Kärnan i bra utvecklingsprocesser ligger i kombinationen av grundläggande principer, vilket också är en anledning till att det agila manifestet är lika relevant idag som det var 2001.

Och slutligen: spelar det verkligen någon roll vilken metod du använder, så länge du levererar verkligt värde regelbundet?