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.
Inga kommentarer:
Skicka en kommentar