Arkitekten som facilitator i ett lean-agilt kontext – del 2

24 oktober 2019

I denna artikelserie om tre delar reflekterar vi kring hur man med avstamp i nio principer, som är en del av SAFe-ramverket, kan arbeta med arkitektur.

I den första delen av denna artikelserie togs princip 1-3 upp. Denna del handlar om:

  • Princip #4 – Build incrementally with fast, integrated learning

  • Princip #5 – Base milestones on objective evaluation of working systems

  • Princip #6 – Visualize and limit WIP, reduce batch sizes, and manage queue lengths

Princip #4 – Build incrementally with fast, integrated learning

Ofta är produkter och IT-lösningar mycket komplicerade och verkar i ett komplext sammanhang. Inom agil produktutveckling lyfts det kontinuerliga lärandet fram i form av (PDCA-cykeln (Plan - Do - Check - Adjust). Att skapa en produkt genom att dess lösningsförmågor växer fram inkrementellt i lärandecykler innebär också att produkten behöver vara körbar kontinuerligt, testbar och integrerbar.

 

Att säkra olika förutsättningarna för att en fungerande återkoppling av en produkts funktionalitet blir därmed en kritisk framgångsfaktor för ett lyckat produktutvecklingsarbete. Genom att skapa förutsättningar för kontinuerlig integration och deploy säkras möjligheten till ett kontinuerligt lärande.

 

Arkitekten kan stötta genom att säkra att de tekniska förutsättningarna finns på plats genom att underlätta hanteringen av beroenden mellan funktioner i en backlog samt genom att identifiera och definiera kritiska integrationspunkter inom ramen för en eller flera utvecklingscykler.

 

Inom SAFe skiljs långsiktiga och plandrivna arkitekturbeslut (Intentional architecture) från mer kortsiktiga, ständigt pågående designbeslut (emergent design). I intentional architecture ingår t.ex. att sätta ramarna för utvecklingsarbetet och fastställa tekniska principer som alla utvecklingsteam bör följa för att lyckas takta. I emergent design tar man fasta på teamens förmåga att självständigt ta viktiga arkitekturbeslut kopplat till ett avgränsat system – i enlighet med devisen från det agila manifestot “The best architectures, requirements, and designs emerge from self- organizing teams”.

 

Praktiskt innebär det att arkitekten kan stödja verksamhetsledning och produktansvariga avseende produktutformning och avgränsning av en backlog samt säkra att en s.k. Feature som ingår i ett programinkrement är beskriven så att olika intressenter har förutsättningar att leverera. Arkitekten bör dessutom ha kontinuerliga avstämningar med utvecklings- teamen kring tekniska utmaningar som kan behöva lyftas från team till programnivå, t ex genom att aktivt delta på olika synkmöten.

 

Princip #5 – Base milestones on objective evaluation of working systems

Att leverera körbara versioner av en produkt tidigt är viktigt både för att ha kontroll mot marknaden men även för att stämma av en produkts tekniska förmåga. Detta bygger transparens och förtroende samt ger möjlighet att styra prioriteringar. Många traditionella projektstyrningsmodeller innehåller kontrollpunkter som baseras på icke värdeskapande faser. I det lean- agila förhållningssättet betonas istället vikten av att ha ett produktfokus framför ett projektfokus, där de naturliga utvecklingsstegen Istället representerar den kontinuerliga cykeln inom ramen för ett avgränsat programinkrement. Milstolpar bör baseras på ett explicit formulerat affärsvärde för just den leveransen som avses för ett avgränsat programinkrement. Här kan arkitekten facilitera genom att visualisera och stämma av att förväntningarna från verksamhetsledning, produktägare och utvecklingsteam är i balans.

 

För varje avgränsat programinkrement definieras ett antal prioriterade Features som ska realiseras för produkten. Dessutom formuleras också ett antal så kallade Enablers. De senare är mer implicita för användaren men helt avgörande för att produkten ska fungera tillfredställande. Det kan handla om att genomföra aktiviteter som bidrar till en produkts viktiga kvalitetsegenskaper som stabilitet, säkerhet, laglighet, tillgänglighet mm. Dessa nödvändiga Enablers bygger upp det som SAFe kallar The architectural runway med synsättet att arkitekturen evolverar och växer fram längs vägen.

 

Användbarhet är ofta en viktig kvalitetsegenskap, kring vilken arkitekten bör samverka med en UX-funktion på programnivå för att säkerställa känslan av en tillämpning trots att en mängd olika utvecklingsteam varit inblandade. Även i det här fallet handlar det om att se till att förväntningarna på leveranser formuleras och är i balans samt att alignment stäms av kontinuerligt – kopplingen mellan strategiska teman, epics, features, enablers och i slutändan utvecklingsteamens user stories. Verksamheten behöver ha hypoteser om nödvändiga strategiska förflyttningar (epics) och även någon slags roadmap som exekverar en del i denna. Arkitekten kan till exempel bidra genom att tydliggöra dessa epics och ta fram hypoteser om omfattning på kommande program- inkrement, vilket då representerar en slags roadmap för vad verksamheten vill åstadkomma, varför och i vilken ordning.

 

Princip #6 – Visualize and limit WIP, reduce batch sizes, and manage queue lengths

Ett grundläggande förhållningssätt i ett lean-agilt arbetssätt är som framkommit ovan att skapa förutsättningar för ett kontinuerligt flöde, vilket bäst görs genom att tydligt avgränsa utmaningen. Långsiktiga committments till en roadmap bör dock undvikas. Grundprincipen är att en roadmap inte ska blicka längre fram än tre program- inkrement, vilket omfattar en period på cirka 30 veckor. Committments görs dock enbart för ett programinkrementet i taget. Kommande programinkrement är enbart hypoteser om en fortsättning. Därmed minskar sannolikheten att onödiga väntetider uppstår. Allt som kan skapa köer där olika intressenter väntar på varandra bör undvikas. Att över- belasta sin verksamhet med alltför många förändringsinitiativ och sina utvecklingsteam med för många samtidiga arbetsuppgifter är ett vanligt förekommande problem i våra organisationer.

 

SAFe förespråkar därför en tydlig visualisering av det som är prioriterat och committat (WIP = Work in Process). Arkitekten bör kontinuerligt fungera som en facilitator av det arbetssättet. Arkitekturarbete bör handla om att stödja realisering av mål, uppnå resultat och skapa genomförandekraft. Arkitekten hjälper samtidigt till att tydliggöra och säkra rimliga avgränsningar som bidrar till att driva en produkt framåt.

 

Det är också viktigt att fråga sig vilka arkitekturbeslut som krävs och hur dessa ska tas. Allt som behöver eskaleras riskera att försena leveransen. Anti- mönstret är omständliga arkitekturgranskningar och inväntande av olika beslutsforum. Ytterligare ett sätt att säkra ett bra flöde i utvecklingsprocessen är genom investeringar i det som brukar benämnas DevOps, inklusive nödvändig automation och erforderlig infrastruktur som krävs för att säkra ett effektivt utvecklingsarbete. Arkitektens roll blir som ambassadör för värdet av att investera i DevOps.

 

Av: Johanna Värild, Forefront Consulting. I nästa vecka publiceras den tredje och sista delen som handlar om princip 7-9. 

Nästa nyhet

Detaljerad data i mängder – ett måste för bra beslutsstöd

8 oktober 2019