Markkontakt och flöde

De agila värdena och principerna är en sak. De storskaliga ramverken gör så gott de kan. Men det finns ett par andra viktiga principer som många glömmer av när de ska implementera agila arbetssätt hos sig. Det gäller kanske framförallt när de ska införa agilt i de större sammanhangen, och det beror inte på vilket ramverk man väljer, utan hur man väljer att tillämpa det.

Det är principerna om markkontakt ("gemba") och flöde ("flow").

Vissa agila ramverk, t ex lean software development och SAFe, är tydliga med vad de lånat från Toyota. Men alla ramverken har lånat från Toyota, och i synnerhet dessa två principer.

Hela skälet till att vi investerar i att bli mer lättrörliga (agila) är för att vi vill uppnå ett bättre flöde även i en komplex och oplanerbar miljö. Vi vill bli bättre på att möta behov, även när vi inte riktigt vet hur. Då behöver vi investera i flödesskapande arbetssätt så att vi kan leverera mindre paket men göra det snabbare och bli duktigare på att snabbt fånga upp återkoppling.

Att optimera på flöde är att rensa bort allt onödigt arbete och all onödig väntan. Det är att först och främst se till att informationen flödar fritt och effektivt, för informationsflödet påverkar alla andra flöden. Det är att se till att ingen del i systemet (till exempel en människa) är överlastad. Optimerar man på flöde kan man inte optimera på ett högt resursutnyttjande, men genom att få ner varianser i arbetsbelastningen så kan man förbättra bägge.

Alla agila ramverk är flödesoptimerande i någon mån. Just förmågan att flödesoptimera blir testad när man vill bli agil i större organisationer och värdeflöden. Det är här som lättviktiga ramverk får problem om de inte kompletteras med verktyg för att hantera det större flödet. En hel del av verktygen i SAFe försöker lösa precis detta.

Men det man ofta misslyckas med när man försöker bli storskalig och agil är att behålla markkontakten. Principen om gemba, att vara verklighetsnära i allt man gör, är central för alla smidiga arbetsmetoder.

Det började i verkstadsföretaget Toyota som en idé att den som ska leda ett arbete själv måste veta vad arbetet innebär. Chefen måste ha jobbat på golvet. Det fortsatte med en tanke att beslut inte ska fattas på tyckande utan på fakta. När man gick mer mot massproduktion innebar detta att chefer inte skulle fatta beslut på aggregerade nyckeltal utan istället gå ut i fabriken för att på plats se hur det faktiskt fungerar. Detta ledde sedan fram till insikten att det är folket på golvet som själva bör få mandat och förmåga att också fatta beslut.

När det gäller att utveckla produkter och affärer har principen om markkontakt lett till insikten att gemban ("golvet") inte i första hand är fabriken eller utvecklingsavdelningen eller styrelserummet, utan är den verklighet där produkten används.

Jag har sett storskaliga agila ansatser inom mjukvaruutveckling som aktivt motverkat principen om markkontakt på alla nivåer. De som sätts att leda produktens utveckling på strategisk och taktisk nivå (till exempel i portföljstyrningen eller i programledningar) saknar erfarenhet av att utveckla system. Man fattar beslut baserade på planer och tyckande istället för på faktiska kapaciteter och relevanta mätetal. Ingen av de som styr tar sig någonsin dit där de kan observera det faktiska arbetet äga rum. Man hindrar folket på golvet att själva ta kontrollen över sina arbetsformer, istället standardiserar man i onödan runt praktiker som i det enskilda fallet minskar möjligheten att nå i mål. Och man undviker i det längsta att införa kravfångstmetoder som bygger på att observera verkliga användare och låta nya insikter om deras behov få påverka de redan fastslagna planerna.

Det behöver väl knappast nämnas att resultatet i alla dessa fall blir sämre än det var tidigare?

Jag är beredd att ge ramverken halva skulden för att det är på det här viset. SAFe-införande löper, förmodligen på grund av sitt språkbruk, en notoriskt hög risk att överstandardisera när ledande personer beslutar om att likrikta utan att riktigt förstå varför man vill likrikta eller vilka de skadliga konsekvenserna kan bli.

Men ett ramverk kan aldrig göras ansvarig. Ansvaret vilar på dem som fattar besluten. Om de fattar beslutet att följa ett halvbra ramverk till punkt och pricka på grund av att de själva saknar kunskap att hantera verktyget rätt, så bör de överväga att lämna över en del av beslutsmakten till de som har bättre insikt.

I synnerhet då insikter i principen om flöde och principen om markkontakt.

Det är skalan och inte ramverken

Kritik mot storskaliga agila ramverk bygger ibland på att de bryter mot några av de fyra agila värdena eller de tolv bakomliggande principerna. Och det stämmer i viss mån. Men jag vill ändå försvara de storskaliga ramverken med att brotten mot till exempel de fyra värdena snarare är en produkt av storskaligheten än en produkt av ramverken.

Individer och deras samspel framför processer och verktyg? Ja, men om vi ska synka samspelet mellan hundra individer behöver vi ha något strukturerat sätt att samspela på. Kanske är en tvådagars produktinkrementsplanering med alla i rummet ett bättre verktyg för detta än många alternativ?

Fungerande mjukvara ofta? Ja, men i vissa tekniska plattformar innebär "ofta" var tionde vecka istället för varannan. Trögheten behöver inte ha med processen att göra, utan med övriga strukturer (tekniska och organisationella).

Kundsamverkan framför avtal och friskrivningar? Ja, men där är ramverken, både lättviktiga (som Scrum) och tyngre som (SAFe), helt i händerna på säljprocesser och avtalsjuridik. Det bästa vi kan göra är att försöka övertyga kunder och säljare och ledning om behovet av andra angreppsätt, men då behöver vi presentera ekonomiska modeller och andra kringstrukturer. Lättviktighet som innebär att vi inte svarar på vissa frågor från omgivningen hjälper oss inte i den kampen.

Omplanering framför att följa planerna? Japp. Men på rätt nivå. Om vi använder de agila verktygen för löpande omplanering till att vimsa omkring så tar vi oss ingenstans.

Agilitet har inget egenvärde. Värdet ligger i om ökad agilitet gör oss bättre på att uppfylla människors behov. Vi kan använda vår agilitet för att kunna söka oss fram, men den övergripande riktningen behöver vara fastslagen så att vi vet vilka behov som är viktigare än andra. Särskilt om vi är många som ska springa mot samma mål.

Mer lättviktiga metodramverk som Scrum döljer den här problematiken.  Man antar att det finns en person, PO, som helt enkelt vet hur man värderar och prioriterar. Men den PO som läser Scrumguiden får liten eller ingen vägledning för sitt arbete. "Organisationen ska veta vad som är viktigt och ställa sig bakom PO:ns prioriteringar!" Men hur organisationen kommer fram till detta besvaras inte.

Man kan ha synpunkter på hur SAFe föreslår att en produkt- och portföljledningsstruktur ska se ut. Det finns fler bra sätt att lägga upp arbetet på än vad SAFe beskriver. Men man är farligt naiv om man påstår att en sådan struktur inte behöver finnas utan bara är ett sänke för agiliteten. Scrum implicerar att den finns där. På något sätt behöver PO:n ta reda på vad som är viktigt inför sprintplaneringen.

Däremot lider flera storskaliga agila implementationer av problem. Men dessa menar jag snarare uppstår när man frångår två viktiga leanprinciper: den om "gemba" och den om "flow". Man behöver markkontakt och flöde. Men det får bli ämnet för ett annat inlägg.

De storskaliga ramverkens grundantagande

De tre mest kända ramverken för storskalig agil utveckling: SAFe, Nexus och LeSS utgår från samma grundantagande: utmaningen för storskalig agil utveckling är hur man ska koordinera flera team runt en produkt.

SAFe kallar för ett "Agile Release Train". Nexus kallar det för ett "Nexus". LeSS kallar det inte för något särskilt, bara "det här är Scrum fast för flera team". Men det handlar om en samling av team som samplanerar sin utveckling av en och samma produkt från en och samma behovslista.

I grund och botten är ramverken väldigt lika. Nexus och Less beskriver inte behovslistan på något annat sätt än Scrum (det finns färdignedbrutna saker och ofärdiga) förutsätter värdeskapande varje sprint och tillför få (Nexus) eller inga (LeSS) nya roller. SAFe går lite längre och tar höjd för att varje värdeskapande kan ta några sprintar (ett sk "produktinkrement") och arbetar därför med en tredelad behovslista med vissa specifika artefakter i samt några nya roller för att koordinera detta.

Men inget av ramverken tar höjd för den situation där ett utvecklingsteam behöver stötta flera parallella utvecklingsansatser (projekt eller produkter). Inget av ramverken kan rakt av lösa frågan om hur man koordinerar värdeskapande som sker kors och tvärs och inte sällan i konflikt med varandra. SAFe har åtminstone i och med beskrivningen av värdeströms- och portföljnivån ett förslag på hur det ska lösas, men om ingen finns som kan prioritera på portföljnivå så fungerar det inte.

Problemet är vanligt, det kan lösas och det är inte jättesvårt att lösa även om det ofta inbegriper att man behöver se över beslutsmandat, projektfinansieringsmodeller och uppföljingsmodeller. Men det måste bli mer känt att inget av de existerande ramverken i sig löser den situationen.

Skalningsramverken försöker lösa koordineringsproblemet när flera team ska samsas om en backlogg. Det är en sorts skalproblem. Organisationer vill istället alldeles för ofta använda dem för att få ett eller flera team att samsas om flera skilda backloggar. Det går inte. Det är en helt annan sorts skalproblem.

Det spelar då ingen roll att ramverket har förmågan att hantera flera team. Det man behöver är ett sätt att hantera flera olika beställare med vitt skilda prioriteringar.

(...och apropå storskalighet, som vanligt säger Jurgen Appelo som det är!)

Vad måste synkas då?

Vad måste göras lika då, i en stor organisation som försöker utveckla agilt? Måste man inte likrikta?

Det är inte organisationen som styr det utan värdeflödet. Om ett team självständigt kan leverera värde behöver det inte synka med någon annan. Om ett team måste leverera värde tillsammans med ett annat team är det dessa två team som behöver synkronisera med varandra. Om det finns ett projekt eller liknande som håller samman utvecklingen måste alla teamen vara synkroniserade med projektets planeringsrytm.

Det betyder inte att teamet inte kan ha sin egen takt. Det betyder bara att den takten behöver vara synkroniserad med omgivningens behov av planering, beställning, och leverans. Inga dikterade sprintrytmer alltså, däremot att man uttrycker sina behov för varandra och går varandra till mötes.

Backloggstrukturen som rör de gemensamma delarna. Ofta behöver enskilda funktioner utvecklas gemensamt av olika team. Då behöver beskrivningen av funktionerna vara överenskomna, och beskrivningen av de enskilda paketen. Men de olika teamen behöver inte bryta ner funktionerna på likartat sätt till likadana sorters skivor. Projekt och program ska ändå inte följa upp på den delnivån, det sköter teamet så bra självt. Inget detaljreglerande av teamets egen del av backloggen alltså, nöj er med att skapa en gemensam förståelse av de delar som är gemensamma.

Prognoser i timmar och datum. För att kunna synkronisera och ha kontroll över kostnaderna behöver man ha någon sorts aning om när i tiden saker blir färdiga och hur mycket de kostar (oftas i persontimmar). Det finns inget skäl att kräva att team ska använda estimering för att skapa sina prognoser, inget skäl att kräva att estimeringen ska bygga på storlekspoäng, och det finns inget skäl att försöka ensa storlekspoängen med varandra. Diskutera i datum och persontimmar istället, med konfidensintervall. Det är ju det som storlekspoängsestimering ger oss när den fungerar. Men andra tekniker kan ge antingen ännu bättre precision i prognosen, eller lika dålig precision som estimering fast utan estimeringskostnaden. Kräv inte estimering, kräv prognoser!

Ständig förbättring. Detta är det viktigaste: att varje team och varje gruppering av team som samarbetar med varandra har regelbundna förbättringsmöten för att arbeta bort sina strukturella hinder för agilitet. Förbättring innebär förändring, därför måste allt vara öppet för ifrågasättande, utom just förbättringsarbetet i sig självt. Det är en ständigt pågående aktivitet. Det får ni inte tumma på! Och om teamet inte kan ständig förbättring så får deras närmaste chef visa dem hur man gör. Eller ta in en agil/lean-coach om chefen inte vet hur man lär ut ständig förbättring..

Sund kultur och coachande ledarskap! Vi standardiserar runt följande beteenden: uppmuntran, experiment, kvalitet, transparens, tydlighet, självstyre, tillmötesgående, tillåtande. Från alla. Respektera människan.

Alla måste inte göra lika

En missuppfattning om sk "storskalig agilitet":

"När en stor organisation inför agila arbetssätt måste dessa likriktas!"

Nej. Nejnejnej. Eller: nja, jo, lite, ibland. Men akta er!

Agila metoder bygger på metodutveckling på teamnivå. Scrum, SAFe och andra ramverk är startpunktsmetoder. De erbjuder ett enkelt paket av några tekniker man kan använda för att lösa vissa problem (och har man inte just de problemen ska man inte ge sig på att använda just de verktygen).

Men vad metoderna gör är att de framförallt avslöjar strukturella hinder för agilitet, och genom den strukturerade ständiga förbättringen (i form av retrospektiv och liknande) erbjuder möjlighet att ta bort hindren. Det kräver frihet att experimentera med arbetsformerna.

Den organisation som tar bort möjligheten för ett team att experimentera med arbetsformerna kan inte vara agil. Och likriktning omöjliggör experiment.

Vissa organisationer har dåliga erfarenheter av experiment. Men lösningen är inte att likrikta, utan att bli bättre på att experimentera. Gör man det rätt blir det både säkert, effektivt, och produktivt.

Det är ett stort problem att det mest kända ramverket för agilt arbetssätt i stora organisationer, SAFe, på många ställen uttrycker sig som om likriktning är av nöden. I tidigare versioner av SAFe har man krävt att alla team ska arbeta med tvåveckorssprintar, att alla team ska använda estimering som prognosverktyg, att estimering måste ske med storlekspoäng, och att alla storlekspoäng i hela organisationen ska kalibreras utifrån samma skala där 1 poäng motsvarar 1 effektiv persondag.

Ingen av dessa olika tekniker är i sig fel. Men det finns mängder av exempel på situationer där teknikerna absolut inte ska användas. Om en ledning i onödan har beslutat om att standardisera runt dessa tekniker blir resultatet att det blir svårt att öka agiliteten i organisationen.

För att få agilt att fungera i ett helt värdeflöde krävs synkronisering. Dvs att teknikerna som används i organisationen fungerar tillsammans i harmoni. Från en position uppe i det blå kan det se ut som om likriktning är ett enkelt sätt att garantera harmoni. Men om tekniken du påtvingat en grupp inte harmonierar med deras situation så har du skapat kaos.

Det enda sättet att få arbetssätten smidiga är om de personer som utför arbetet också har friheten att utforma dem, och att de själva bär ansvaret för att arbetssätten harmonierar på ett smidigt sätt. Det sker när ledningen lär dem hur de ska arbeta med ständig förbättring. Ramverken ger vägledning, men de består av tekniker som kan vara mer eller mindre tillämpliga i den aktuella situationen. Man måste välja och vidareutveckla och anpassa, och man måste göra det på ett bra sätt.

SAFe 4.0, den senaste inkarnationen av SAFe, är betydligt mer liberal. Borta är tanken på att alla måste arbeta i samma takt, så länge som de kan samplanera varannan vecka. Fortfarande säger ramverket tyvärr att prognoser ska sättas med hjälp av estimering, att estimering ska ske med storlekspoäng och att storlekspoängen ska vara en gemensam valuta i hela organisationen, men när man går SAFe:s handledarutbildningar så får man höra att även detta är förhandlingsbart.

Viljan att likrikta tror jag kommer ur rädsla. Man vet egentligen inte vad de här teknikerna innebär, så därför saknar man förmåga att välja och anpassa. Men istället för att erkänna sin okunskap och använda lean och agila införandemetoder som bygger på experiment och utforskande, så väljer man att hålla fast vid vad någon någon gång sagt på ett tydligt sätt.

Och det är ju så frestande att tro på tanken att likriktning innebär trygghet.

Smärta? Det är så kulturförändring känns!

Nästa vanliga missuppfattning om agilitet:

"Vi kan inte få agilt att fungera om vi inte först lyckas ändra kulturen!"

Intressant, hur menar du?

"Vi provade det. Vi provade att ha dagliga möten men folk ville inte komma och berätta om vad de hade gjort sedan igår. Vi bad organisationen att prioritera vad de ville att vi skulle ägna oss åt först, men de ville inte bestämma sig. De ville ha allt! Vi slutade leda teamen men de blev inte självorganiserade och produktiva.

Vi gjorde precis som i boken men det hände inte. Vi har inte rätt kultur för agilt. Vi måste först få den att ändra sig!"

Men förklarade ni varför ni skulle ha dagliga möten? Synliggjorde ni problemen som uppstår när man undviker att prioritera? Ledde ni gruppen i konkreta vägar till att bli självorganiserande och produktiva? Stödde ni förändringen med beslut? Tog ni bort gamla beteenden?

Kultur på en arbetsplats är det beteende som vi förväntar oss av oss själva och andra i vissa situationer. Den är alltid vad vi alltid har gjort. Det enda sättet att förändra den är att börja göra på ett nytt sätt, och sedan fortsätta på det nya sättet tills det nya sättet blir det sätt vi alltid har gjort på.

Det gör ont att gå emot det etablerade sättet. Det känns konstigt, det finns inget riktigt stöd för det nya, och egentligen förväntar sig folk att vi ska falla tillbaks till det gamla. Vi behöver påminna oss om varför vi gör på det nya sättet. Vi behöver lyssna på skeptikerna och om det går ta hänsyn till deras invändningar, utan att falla tillbaks. Men framförallt behöver vi fortsätta.

"Men det känns ju så fel! Är du säker på att vi inte ska ändra vår kultur först?"

Det är ju det ni gör. Att det känns fel är ett bevis på just det. Det skaver, och det är precis så en kulturförändring känns!

SAFe "Feature" och Jira

I den lilla världen kan ett ensamt team leverera färdiga funktioner med bara några veckors (en sprints) mellanrum. Eftersom en funktion kan beskrivas i en sk "User Story" har man kallat de saker som ett team levererar under en sprint för just en "user story". Flera funktioner som hör ihop brukar kallas för en "epic".

Backloggverktyget Jira låter därför scrumteam hantera krav i ärenden av typen "Jira User Story", och flera sådana hanteras av den samlande ärendetypen "Jira Epic". I ärendetypen "Jira Epic" kan man följa upp hur varje ingående "Jira User Story" färdigställs.

Men om man måste skala upp det här? Om man inte kan leverera en funktion under en sprint utan behöver flera sprintar? Om det är mer än ett team som ska jobba med samma funktion? Alltså om arbetet med samma funktion måste delas upp mellan flera team och/eller delas upp över tid?

I Dean Leffingwells fyrdelade modell för en systemutvecklingsbacklogg (från Agile Software Requirements 2008, som senare blev ramverket SAFe) inför han därför en ärendetyp mellan user story och epic: en sk "feature". Tanken är att man på en övergripande nivå kommer fram till vilka funktioner man vill leverera, fångar var och en i en feature, och sedan bryts varje feature upp i mindre skivor av ett eller flera team och hamnar på deras respektive team-backloggar. På så sätt kan teamen följa upp hur de levererar en hel funktion även om de måste dela upp arbetet i delmål.

De sprintbara delmålen som hamnar på varje utvecklingsteams backlogg heter även i Leffingwells modell "user story". Så förhållandet i Leffingwells modell mellan "SAFe User Story" och "SAFe Feature" är precis densamma som i Jiras modell mellan "Jira User Story" och "Jira Epic". En "Jira Epic" delas upp i flera "Jira User Stories" på samma sätt som en "SAFe Feature" delas upp i flera "SAFe User Stories".

Samtidigt innehåller som sagt Leffingwells modell fortfarande begreppet "epic" ("SAFe Business Epic" samt "SAFe Architectural Epic"), och detta skapar förvirring när folk vill använda Jira för att hantera SAFe:s modell av backloggen. En "epic" i Leffingwells modell består av flera "SAFe Features" som i sin tyr består av flera "SAFe User Stories". En "epic" i Jiras värld består av flera "Jira User Stories" och det är allt.

Hur gör man? Tänker man uppifrån och ner så är det frestande att att beskriva "SAFe Business Epic" och "SAFe Architectural Epic" med hjälp av "Jira Epic". Det blir då på samma sätt frestande att använda en "Jira User Story" för att beskriva en "SAFe Feature". Men då orsakar man en massa svårigheter för alla andra i samarbetet.

En "SAFe Feature" ska inte ligga på ett enskilt utvecklingsteams backlogg utan på en sk "Program Backlog" för att hanteras på en överordnad nivå. En "Jira User Story" ska däremot handhas av ett team.

En "SAFe Feature" ska inte vara bunden till en viss sprint. I Jiras sprintplaneringsverktyg ska "Jira User Stories" bindas till en viss sprint.

En "SAFe Feature" ska kunna delas in (av teamen) i flera "SAFe User Stories", och varje "SAFe User Story" ska kunna estimeras och planeras och utvecklas av ett team för sig. Men om vi använt "Jira User Story" för att beskriva en "SAFe Feature", vad ska teamen använda för att kunna hantera sina "SAFe User Stories"? Hur ska de kunna göra sitt jobb om vi tagit verktyget från dem och använt det till annat?

Dessutom är det så att Jiras styrka är möjligheten att bringa ordning i en mängd arbetspaket och hur de förhåller sig till varandra. Det finns altid många fler "SAFe User Stories" än "SAFe Features", och många fler "SAFe Features" än "SAFe Epics". Det verkar vara dumt att slösa ärendetyper i Jira på att hantera ett fåtal saker som dessutom sällan förändras. Effektmålen och förutsättningarna för varje epic tenderar att vara stabila, det är informationen om hur epicen ska implementeras (vilket fångas i features och user stories) som förändras ofta och kräver verktygsstöd.

Så det rimliga är såvitt jag har sett att använda "Jira User Story" för att fånga en "SAFe User Story", och använda "Jira Epic" för att fånga en "SAFe Feature". Jag har sett konsekvenserna både av att använda Jira Epic för epic och för feature, och det blir oerhört trassligt för teamen att kunna koordinera sitt arbete om de inte får använda Jira User Stories för sina teambackloggar.

Vad ska man använda för att fånga sina "SAFe Epics" då? Man kan använda "Jira Epics" och länka till andra "Jira Epics" som fångar features. Man kan använda ett annat verktyg. Jag har goda erfarenheter av antingen en mapp i ett filarkiv (under versionskontroll), eller en wikisida per epic (kanske i Confluence, Jiras syskon som är en wiki). Låt sedan de "SAFe Features" som tillhör denna epic peka ut länken eller sökvägen dit. Sätt en "label" på din "Jira Epic" (="SAFe Feature") som beskriver vilken epic det rör sig om. Ha ett prefix i namnet på varje "SAFe Feature" som pekar ut vilken epic det rör sig om.

Det enda argumentet som jag tycker håller emot tanken att använda "Jira Epic" för att hantera en "SAFe Feature" är att man tyvärr inte kan ordna sina "Jira Epics" i en sträng ordning. Man kan alltså inte prioritera sina "SAFe Features", sin "Program Backlog", på samma sätt som andra backloggar. Men i praktiken har jag sett att det inte är något problem. På epicnivå handlar det inte så mycket om att prioritera "SAFe Features" löpande, utan om att bestämma vilka som ingår i en viss epic och vilka som inte gör det. Behovet av att dra-och-släpp-sortera sin programbacklogg är långt mindre än behovet av att dra-och-släpp-sortera teambackloggarna. Det är teamen som har det största behovet av "Jira User Stories", så låt dem använda dem till sina "SAFe User Stories".

När man skapar ett smidigt lean/agilt flöde börjar man från flaskhalsarna och arbetar sig bakåt. Eftersom utvecklingsteamen är den trånga sektorn behöver vi uppfylla deras behov av smidigt verktygsstöd först. Fungerar inte golvet smidigt kommer ingenting att fungera smidigt.

Kniberg om storskalighet

Henrik Kniberg gav ett föredrag om storskalig agil utveckling nyligen, och av döma av sammanfattningen på InfoQ (se länken) så var det ett bra föredrag med observationer som är helt i samklang med mina.

Jag gillar särskilt att han trycker på att man måste förstå varför man skalar. Storskalig agil utveckling är inget eftersträvansvärt. Om en liten grupp människor oberoende av omgivningen kontinuerligt kan leverera nyttigheter som möter människors behov så är det att föredra. De storskaliga teknikerna tar vi till när vi måste koordinera fler än en handfull personers arbete och/eller nyttigheterna tar lång tid att leverera.

Det kluriga är alltså hur teamen kan hålla sig i synk med varandra och hålla ordning på beroendena mellan dem. Henrik pratade om tre grundläggande frågeställningar man behöver ha svaren på:

1. Hur man bryter ner det arbete man ska göra ("slicing the elephant").
2. Hur man bör organisera arbetslagen (ta reda på vilka människor som bör göra vad).
3. Vilka återkopplingar ("feedback loops") som behöver finnas för att koordinera arbetet.

Det är en konkret lista som matchar observationen att man först behöver ta reda på vad man ska göra innan man börjar fundera på organisationsformer och samarbetsmetoder (se Jim Womacks 3P).

Kruxet när man hanterar skalning är att det hela tiden är fråga om avvägningar, något som Henrik också trycker på. Om vi organiserar arbetslagen på ett sätt kommer behovet av återkopplingarna bli ett. Om vi organiserar arbetslagen på ett annat sätt kommer behovet av återkoppling bli ett annat.

Henrik påmminer om att det alltså därför inte kan finnas något rätt eller fel, utan varje organisation måste hitta sina avvägningar utifrån sina behov. Man kan inte hitta ritningar som automatiskt passar flera.

Det jag stannar upp inför är den svåra frågan om hur man fördelar ansvar mellan team. Man kan organisera sig utifrån lösningens bakomliggande komponentstruktur, men det betyder att varje levererad nytta (som ju sker i ett samspel mellan lösningens komponenter) kräver stor koordination mellan komponentteamen. Det är min och hela branschens observation att om det är möjligt ska man istället skapa team som inom sig själva kan leverera hela nyttor (sk "feature teams").

Men i organisationer som har en tillräckligt komplex miljö går det inte att sätta samman team som klarar av att leverera hela nyttor. I de enkla fallen, som i Henriks exempel med en trelagersarkitektur (klient, server, databas) är det förstås möjligt. Men om plattformen är krångligare än så? Teamen blir då antingen för stora, eller så blir de inte stabila utan behöver göras om inför varje ny nytta.

Vi kan sikta på att hålla nere antalet team som krävs per nytta, men det kommer ändå att uppstå ett behov av att för varje sak man gör koordinera mellan åtminstone två team, dvs situationen blir precis som den som Henrik varnar för (se bilden med det ledsna ansiktet vid "Coupled teams"). Det är trögt att få till agilitet i den situationen.

Men det går! Man kan använda smidiga synkroniseringstekniker som gör ansiktena betydligt mindre ledsna, och i de organisationer där jag har ramlat på den här situation har vi använt dem med någorlunda framgång. På samma sätt som smidiga tekniker får individer att jobba bra ihop i team kan smidiga tekniker få team att jobba bra ihop i olika och växlande konstellationer.

En del av de teknikerna utgår från det som Henrik visar i bilden om hur team kan synka med varandra. Organiserar man sig utifrån mönstret "Team of small teams" man man skapa stabila samverkansformer mellan teamen som tar bort en del av synkroniseringssmärtorna. Min erfarenhet är att samma tekniker med framgång kan användas om man organiserar sig i "Team of team of small teams" eller "Web of team of small teams". Det som krävs är en synkronisering på övergripande nivå där organisationen kan ge klara besked om syfte och prioriteringar, så att alla teamen vet vad de ska sträva efter.

Skalningsdimensioner och vektorer

Jag kom hem ifrån konferensen Agila Sverige med en hejdundrande förkylning (vilket troligen förklarade min trötthet och förvirring under själva konferensen) samt med en massa oavslutade samtal runt storskalighet. En del av samtalen har fortsatt på twitter och i epost, och en del av dem har rört det jag ofta återkommer till: skalningsdimensioner.

Att det finns många personer i organisationen är inte i sig ett kriterium på att man har behov av skalbarhetstekniker. Om de många personerna är organiserade i små självorganiserade arbetslag som oberoende av varandra kan leverera nytta och värde minst var fjärde vecka, så behövs inga andra agila tekniker än dem man använder sig av i en liten organisation.

Däremot finns det andra dimensioner som driver behov av ytterligare tekniker än de som t ex Scrum pratar om. Jag brukar tänka på dessa tre dimensioner:

Tid. Ibland (för att inte säga ofta) är det svårt eller omöjligt att leverera kundnyttor på kort varsel. Tiden för att skapa en nytta beror av trögheter i informationsflödet i organisationen. Är trögheten stor kommer det att ta tid, oavsett hur hårt alla arbetar. Arbetar man med mjukvara finns det dessutom alltid en underliggande komplexitet i plattformen som gör det trögt. Nytta på kort varsel är i mjukvarusammanhang svårt.

Konceptet med sprintar (som i Scrum) är en skalningsteknik för att hantera detta. Vi vet från lean att det mest värdefulla sättet att leverera nyttor på är ett kontinuerligt utflöde av en välbehövlig nytta åt gången. Men mjukvara behöver oftast modifieras batchvis, på grund av alla interna beroenden. Därför har man sprintar där ett tvärfunktionellt arbetslag levererar en handfull nyttor efter en två-till-fyraveckorsperiod.

När tiden mellan nyttorna på grund av underliggande trögheter måste utsträckas utöver det, då kan man använda Leffingwells uppdelning i hela nyttor och delnyttor ("features" och "stories" i SAFe), och man kan använda story mapping (Patterson) och olika slicing-tekniker (Cockburn) för att maximera värdet av varje delnytta.

Komplexitet. Det tvärfunktionella arbetslaget ska helst kunna skapa fullständiga nyttor genom att genomföra förändringar på alla nivåer i plattformen. Inom systemutveckling pratar man om "full stack development" där samma team tar sig an databasen, logiklager, och gränssnitt. Men om plattformen är för komplex går det inte att skapa sådana team. Särskilt inte om de olika delarna av plattformen har olika stort förändringstryck på sig, måste uppdateras i helt olika cykler, eller helt enkelt är tekniskt mycket olika. Då behöver man använda knep för att koordinera nyttoskapande mellan team, utan att teamen bryter den övergripande arkitekturella enigheten.

Bredd. Det finns situationer då man behöver leverera mycket nytta. Om man arbetat strukturellt för att få ner ledtiderna och komplexiteten (det som driver de andra dimensionerna), så kan man skala upp genom att låta flera parallella konstellationer arbeta samtidigt i bredd. Men man måste förstå att även den bandbredden kan begränsas av andra saker än antalet konstellationer. Arbetet måste koordineras, och det är inte säkert att plattformen håller för förändringstrycket. Då kan det krävas en uppsättning skalningstekniker för att jämna ut flöden och koordinera leveranser, till exempel olika kanbansystem.

Så varför menar jag att medvetenheten om dessa skalningsdimensioner är viktig då?

När du ser på din egen verksamhet så kan du få en bättre förståelse för utmaningarna. Tänk dig att dimensionerna bildar ett rum, och att er situation kan beskrivas som en uppsättning vektorer i detta rum. Vilka skalningsvektorer måste ni angripa? Vilka tekniker kan ni behöva ta till?

Jag ser ofta människor som inför en skalningsutmaning föreslår att man blint ska tillämpa en färdigpaketerad uppsättning skalningstekniker, exempelvis SAFe eller LeSS. Men det är som att svinga en stor träklubba i ett mörkt rum och hoppas att man inte slår sönder något värdefullt utan bara dödar den där myggan man är irriterad på. Skalningsteknikerna är dyra! De finns för att vi ska kunna skademinimera närvaron av strukturella hinder. Men inför vi dem där vi inte har dessa strukturella hinder så skapar vi istället hinder.

Så genom att se på vilka skalningsvektorer vi faktiskt har, så kan vi lite bättre välja precis den uppsättning skalningstekniker vi faktiskt behöver, och inte dra på oss dyr overhead genom att tillämpa tekniker i onödan.