Att skala agilt innebär inte bara att teamen ska bli fler. Att skala agilt framgångsrikt innebär att vi skalar upp eller ner i alla nivåer och behåller det som fungerar bra och undviker att skala dysfunktionella aktiviteter. Det finns ramverk för skalning som LESS och SAFe.
Genom att ta ett utvecklingsperspektiv när vi skalar agilt oavsett vad vi har för en organisatorisk roll blir det enklare att se vad vi behöver skala och vad vi ska göra annorlunda eller upphöra att göra.
När vi utvecklar, om det så är kod, verksamhet, upplevelse eller affär, är en framgångsfaktor att optimera för helhet och dra nytta av ett generellt tänk.
SAFe bygger sin metodik baserat på tre områden: Systemteori, Agil utveckling och Lean produktutveckling.
Systemteori säger oss bland annat att systemet måste manageras som en helhet. Komponenter och mönster bör byggas generellt med hela systemet i åtagande. När vi utvecklar, oavsett roll, behöver vi alltså utgå från samma mönster och komponenter för att inte ”skada” systemet med omotiverade speciallösningar.
Agila principer ger teamet en hög grad av självbestämmande. Men när vi utvecklar i en skalad miljö behöver vi förhålla oss till centraliserade beslut och artefakter tex frågor kring gemensamma komponenter och mönster, delade plattformar och utvecklingstekniker.
Lean produkt utveckling säger oss bland annat att för att uppnå maximalt värde med kortast möjliga ledtider behöver vi minimera överlämningar och aktiviteter som inte bidrar till att lösa primära behov. Flödeseffektivitet är viktigare än resursoptimering. Vi behöver både utveckla produkten/tjänsten men också utveckla hur vi arbetar.
Vi är alla utvecklar som både behöver utveckla effekt inom organisationen men också oss själva och teamet. När vi skalar behöver vi gemensamma principer, värderingar, komponenter och mönster att utveckla och utvecklas från. Annars riskerar vi att suboptimera hela kalaset.