Agile at Scale: izazovi primene agilnih metoda u velikim IT organizacijama

Ključne teze (Key Takeaways) – šta je najbitnije u ovom tekstu

Agile at Scale nije jednostavno „više Scrum timova“ – to je potpuno drugačiji organizacioni problem.

Jedan mali tim može relativno lako da uskladi prioritete, dogovori tehnički pristup, promeni pravac i brzo isporuči funkcionalnost. Kada isti proizvod razvija deset, dvadeset ili pedeset timova, pojavljuju se problemi koje ni najbolji Daily Scrum ne može rešiti:

zavisnosti između timova,
zajednička arhitektura,
konflikti prioriteta,
neusklađeni release ciklusi,
različiti standardi,
centralizovano finansiranje,
Security i Compliance zahtevi,
sporo donošenje odluka,
dugi lanci odobravanja.

Zato je najveća greška misliti da se agilnost skalira prostim množenjem: ako jedan Scrum tim radi dobro, 20 Scrum timova radiće 20 puta bolje. Neće.

Scrum.org kod Nexus frameworka upravo suprotno upozorava da povećavanje broja ljudi povećava kompleksnost, zavisnosti i broj komunikacionih puteva, pa skaliranje ponekad zahteva čak i smanjivanje broja ljudi koji rade na istom problemu (Scrum.org). LeSS polazi od slične ideje kroz princip More with Less – više vrednosti uz manje procesa, uloga i organizacionog overhead-a, uz jedan Product Backlog, jednog Product Ownera i fokus na ceo proizvod (LeSS).

Sa druge strane, SAFe pokušava da reši problem velike organizacije kroz širi sistem koji povezuje timove, Agile Release Trains, Product Management, Lean Portfolio Management i strateško finansiranje (Scaled Agile). Scrum@Scale koristi drugačiji pristup i svoju arhitekturu opisuje kao minimum viable bureaucracy, sa ciljem koordinacije više Scrum timova bez stvaranja nepotrebno teškog centralnog sistema (Scrum@Scale).

Framework-i se razlikuju, ali problem koji pokušavaju da reše uglavnom je isti: kako povećati broj ljudi i timova koji rade na jednom sistemu, a da komunikacioni trošak, zavisnosti i birokratija ne pojedu svu korist od dodatnog kapaciteta.

Agile odlično radi dok problem stane u jedan tim

Zamislimo tim od sedam ljudi: jedan Product Owner, jedan proizvod, jedan Backlog i jedan prioritet. Ljudi međusobno razgovaraju. Ako postoji problem, okrenu se kolegi. Ako se pojavi tehnička dilema, reše je za pola sata. Ako korisnici ne žele funkcionalnost, promene plan. To je okruženje u kojem Agile prirodno funkcioniše.

Sada dodajte još deset timova. Svaki od njih ima svoj Backlog, svog Product Ownera, svoj Sprint, svoj roadmap i svoje tehničke odluke, a svi menjaju isti proizvod. Odjednom pitanje više nije kako ovaj tim radi, nego kako rad deset timova postaje jedan koherentan proizvod. Tu počinje Agile at Scale.

Najveći problem nije veličina. To su zavisnosti

Ako tim A može samostalno da razvije, testira, deploy-uje, prati i održava svoju funkcionalnost, skaliranje je relativno jednostavno. Ali ako tim A ne može završiti ništa dok tim B ne promeni API, tim C ne pripremi bazu, tim D ne odobri Security model i tim E ne promeni infrastrukturu – imamo ozbiljan problem zavisnosti (Dependency Problem).

Scrum.org Nexus upravo međutimske zavisnosti (cross-team dependencies) navodi kao centralni problem skaliranja Scruma. Nexus je dizajniran tako da više timova radi iz jednog Product Backloga i isporučuje integrisani inkrement (Integrated Increment) najmanje jednom po Sprintu, uz stalno smanjivanje zavisnosti (Scrum.org). To je ključna formulacija: cilj nije bolje upravljati zavisnostima, već ih, gde god je to moguće, potpuno ukloniti.

Loš Agile at Scale često izgleda kao fabrika koordinacionih sastanaka

Jedan tim ima Daily Scrum. Deset timova imaju deset Daily Scrumova. Zatim nam trebaju:

Scrum of Scrums,
Product Owner Sync,
Architecture Sync,
Release Sync,
Dependency Meeting,
Security Review,
Portfolio Sync,
Quarterly Planning,
Program Planning,
Leadership Review.

Odjednom imamo organizaciju koja je navodno postala agilna, ali zaposleni pola radne nedelje provode usklađujući se oko toga kako će uopšte raditi. To je paradoks skaliranja: što više pokušavamo da koordiniramo kompleksnost, to pravimo još više kompleksnosti.

Zato se Agile at Scale ne može meriti brojem koordinacionih mehanizama. Ponekad je najbolji koordinacioni sastanak onaj koji više nije potreban zato što smo uklonili samu zavisnost.

Zavisnosti su često arhitektonski problem prerušen u procesni problem

Ovo je jedna od najvećih grešaka u velikim kompanijama. Menadžment često zaključi: „Timovi se loše koordiniraju.“ Pogledamo sistem i vidimo da svi rade na istom monolitu: pet timova menja istu bazu, jedna promena zahteva testiranje kompletnog sistema, deployment je centralizovan, a samo jedan Architecture Team sme da odobri promene.

Da li je problem koordinacija? Delimično jeste, ali mnogo veći problem je arhitektura. Ako 20 timova mora konstantno da razgovara zato što im je kod tehnički nerazdvojiv, nikakav dodatni broj sastanaka neće rešiti problem. To je razlog zašto arhitektura i topologija timova (Team Topology) moraju biti sastavni deo Agile at Scale strategije. Organizaciona struktura i tehnička arhitektura povezane su mnogo dublje nego što mnogi transformacioni programi žele da priznaju.

Conway’s Law nikada nije bio relevantniji

Konvejev zakon (Conway’s Law), u pojednostavljenom obliku, kaže da organizacije imaju tendenciju da dizajniraju sisteme koji doslovno odražavaju strukturu njihove interne komunikacije.

Ako imate poseban Frontend Department, Backend Department, Database Department, QA Department i Security Department, nemojte biti iznenađeni ako svaka funkcionalnost mora da prođe kroz pet organizacionih granica. Sa druge strane, ako imate multifunkcionalan (cross-functional) tim koji poseduje jednu jasnu poslovnu sposobnost od početka do produkcije, arhitektura ima znatno veće šanse da prati tu autonomiju. Naravno, nije dovoljno samo preimenovati timove – struktura timova i struktura sistema moraju biti suštinski usklađene da bi agilnost bila realna.

Skalirati Agile ne znači skalirati timove. Znači skalirati autonomiju

Ovo je možda najvažnija misao u celom tekstu. Velika organizacija ne postaje agilna kada formira 100 Agile timova; ona postaje agilnija kada dovoljno veliki broj odluka može biti donet blizu mesta na kojem postoji stvarna informacija.

Ako developer zna šta treba uraditi, ali čeka odobrenje Team Leada, Engineering Managera, arhitekte, direktora i Governance odbora, onda nema mnogo veze što on formalno radi u Sprintu. Tim je samo lokalno agilan unutar rigidnog, centralizovanog sistema. To je prepoznatljiv obrazac: decentralizujemo izvršenje, centralizujemo odluke, a onda se čudimo zašto je organizacija spora.

SAFe pokušava da reši upravo taj problem – ali po cenu dodatne strukture

SAFe je verovatno najpoznatiji Enterprise Agile framework. On ne pokušava da skalira samo Scrum tim, već nastoji da poveže:

strategiju,
portfolio,
finansiranje,
Product Management,
arhitekturu,
timove,
release mehanizme,
upravljanje (governance).

Centralni koncept jeste Agile Release Train (ART) – dugoročniji „tim timova“ koji radi na zajedničkom toku vrednosti (Value Stream) i isporučuje vrednost kroz planerske intervale (Planning Intervals). SAFe 6.0 dodatno naglašava ART odgovornosti, Flow, Product Management, tehničku agilnost timova i Lean Portfolio Management (Scaled Agile).

To ima smisla u velikim organizacijama, ali problem nastaje u implementaciji. Ako kompanija usvoji PI Planning, Release Train Engineera, ART i Portfolio Kanban, ali zadrži staru hijerarhiju, staro finansiranje, stara odobrenja i stare silose, onda dobija samo još jedan dodatni organizacioni sloj. SAFe nije automatski birokratija, ali to vrlo lako postaje ako ga organizacija koristi samo da formalizuje postojeću hijerarhiju umesto da je suštinski promeni.

PI Planning može biti moćan – ili ogromna predstava

Ideja iza ovog događaja je logična: veliki broj timova radi zajedno i neophodno je uskladiti ciljeve, zavisnosti i plan rada. Zato SAFe koristi Planning Interval i PI Planning kao centralni mehanizam zajedničkog usklađivanja, gde ART okuplja više timova oko zajedničke misije i PI ciljeva (Scaled Agile).

Ali tu leži opasnost. Ako se dvodnevni događaj pretvori u skup od 200 ljudi, ogromne table, stotine linija zavisnosti i precizno planiranje svakog zadatka za naredna tri meseca, moramo se zapitati: da li je ovo Agile planiranje ili samo Waterfall obojen Story Pointsima?

Planiranje unapred nije problem samo po sebi; problem nastaje kada plan postane kruto obećanje koje više ne sme da se promeni. Ako PI Planning služi da organizacija razume zavisnosti i postavi početnu hipotezu, to je u redu. Ali ako služi da se čitav kvartal unapred zamrzne svaki feature, onda smo upravo skalirali ono od čega je Agile pokušao da pobegne.

LeSS ide gotovo suprotnim putem

Large-Scale Scrum (LeSS) ima sasvim drugačiju filozofiju, a njegova osnovna poruka glasi: Large-Scale Scrum je prosto Scrum. On ne pokušava da izgradi mnoštvo novih slojeva, već naglašava:

jedan proizvod,
jedan Product Backlog,
jednog Product Ownera,
jedan Sprint,
jedan zajednički Increment,
prave feature timove.

Njegov princip More with Less polazi od ideje da gomilanje procesa i uloga često guši ownership i dramatično povećava operativni overhead (LeSS). To zvuči izuzetno elegantno, ali je organizaciono veoma zahtevno.

LeSS ne dozvoljava da postojeće silose sakrijemo iza novih modernih naziva. Ako imamo 15 komponentnih timova, LeSS će nas naterati da se zapitamo zašto oni uopšte postoje. Ako jedan Product Owner ne može da upravlja proizvodom, možda proizvod nije dobro definisan. Ako tim ne može end-to-end da isporuči funkcionalnost, možda je struktura loša. LeSS zato ume da bude neprijatan, ali upravo kroz to razotkriva suštinske probleme.

Nexus pokušava da skalira Scrum minimalno

Nexus je još jedan pristup sa filozofijom minimalnog proširenja. Tipično povezuje približno tri do devet Scrum timova koji rade na jednom proizvodu, koriste jedan Product Backlog i isporučuju jedan integrisani inkrement (Scrum.org).

Njegov centralni fokus nije izgradnja velike korporativne hijerarhije, već integracija, zavisnosti, transparentnost i koordinacija između timova. Zanimljivo je da Nexus eksplicitno upozorava da više ljudi ne znači nužno više vrednosti. Dodavanje ljudi povećava broj komunikacionih puteva, umnožava zavisnosti i pojačava potrebu za koordinacijom. Ponekad pravo pitanje nije kako skalirati na 20 timova, već zašto nam uopšte treba 20 timova.

Scrum@Scale: „minimum viable bureaucracy“

Scrum@Scale polazi od sličnog izazova, ali ga rešava kroz modularnu mrežu koordinacije Scrum timova. Zvanični vodič opisuje ovaj okvir kao arhitekturu bez fiksnih skala (scale-free architecture) sa ciljem uspostavljanja minimalne održive birokratije (minimum viable bureaucracy) (Scrum@Scale).

Ideja je vrlo praktična: birokratija nije automatski zlo jer velika organizacija mora imati definisano upravljanje, koordinaciju, upravljanje rizikom, finansijsku kontrolu i compliance. Problem je nepotrebna birokratija. Minimalna struktura koja omogućava organizaciji da stabilno funkcioniše je korisna, ali svaki dodatni sloj mora biti opravdan jasnim pitanjem: koji problem ovaj sloj rešava? Ako je odgovor samo „zato što framework tako kaže“, imamo ozbiljan problem.

Najveća greška: izabrati framework pre nego što razumemo problem

Ovo se u praksi stalno dešava. Jedna kompanija kaže: „Uvodimo SAFe jer smo veliki.“ Druga tvrdi: „Mi ćemo LeSS jer želimo manje birokratije.“ Treća navodi: „Nexus nam deluje jednostavnije.“

Nijedno od toga nije dovoljan razlog. Koji tačno problem pokušavate da rešite?

Preveliki broj zavisnosti?
Sporo portfolio planiranje?
Nekoordinisane release cikluse?
Silosnu arhitekturu?
Previše Product Ownera?
Nejasnu strategiju?
Loš protok (Flow)?

Ako ne poznajemo tačan problem, framework postaje samo skupa organizaciona moda.

Nije pitanje koji framework je najbolji

SAFe, LeSS, Nexus, Scrum@Scale – svaki od njih ima svoju unutrašnju logiku i ne postoji univerzalni pobednik:

SAFe ima smisla u veoma velikoj organizaciji kojoj je potrebno eksplicitno povezivanje nivoa portfolija, finansiranja i velikog broja timova.
LeSS ima smisla tamo gde kompanija želi radikalno pojednostavljenje i fokus na ceo proizvod (Whole Product Focus).
Nexus je idealan kada nekoliko Scrum timova zajedno razvija isti proizvod, a najveći izazov predstavljaju integracija i zavisnosti.
Scrum@Scale odgovara organizacijama koje traže modularan model skaliranja uz minimalnu koordinacionu strukturu.

Framework nikada nije strategija – on je samo alat.

Agile at Scale često propada na finansiranju

Ovo se u praksi pominje znatno ređe od Scrum ceremonija. Tim je organizovan oko proizvoda, ali kompanija i dalje finansira izolovane projekte. Svake godine prolazi se kroz isti ciklus: napravimo Business Case, tražimo budžet, formiramo projekat, privremeno okupimo tim, isporučimo opseg posla (Scope) i na kraju rasformiramo tim. To je tradicionalno projektno finansiranje (Project Funding).

Agile Product Model zahteva stabilnije timove, dugoročnije vlasništvo nad proizvodom i finansiranje celog toka vrednosti ili proizvoda. SAFe kroz Lean Portfolio Management upravo pokušava da poveže strategiju, investiciono finansiranje i agilne portfolio operacije (Scaled Agile). Bez promene finansijskog modela praktično je nemoguće postići ozbiljnu organizacionu agilnost. Ne možete istovremeno imati stabilne produktne timove i svaka tri meseca preraspoređivati ljude na nove projekte.

Budžet može biti rigidniji od bilo kog Waterfall plana

Tim kaže: „Podaci sa tržišta pokazuju da ovaj feature više nema smisla.“
Odgovor glasi: „Ali za njega je već odobren budžet.“
Tim navodi: „Korisnici ga ne žele.“
Rukovodstvo odgovara: „Ali nalazi se u zvaničnom Business Case-u.“
Tim primećuje: „Konkurent je u međuvremenu promenio stanje na tržištu.“
Odgovor je: „Ali preuzeli smo obavezu (commit) za ovu fiskalnu godinu.“

Ovo više nije pitanje Scruma, već pitanje upravljanja organizacijom (Governance). Agile at Scale postaje ozbiljan poduhvat tek kada u proces uključi finansije, portfolio, strategiju, HR, nabavku i compliance. Ako je samo IT prešao na Agile, celokupna organizacija nije postala agilna.

Još jedan veliki problem: lokalna optimizacija

Tim A ima odličan Velocity, tim B takođe, a tim C podjednako briljira. Kompanija deluje zadovoljno, ali kada se pogleda ceo proces, feature putuje redom: Tim A -> Tim B -> Tim C -> Security -> Operations. Ukupan Lead Time iznosi 65 dana. Svaki tim pojedinačno izgleda maksimalno efikasno, ali sistem kao celina to uopšte nije. To je klasična zamka lokalne optimizacije.

Velike organizacije moraju prestati da mere isključivo timski učinak i moraju početi da mere protok kroz celokupan tok vrednosti (Value Stream):

Koliko vremena prolazi od sirove ideje do isporuke korisniku?
Koliko se na poslu stvarno aktivno radi, a koliko on provodi u čekanju?
Gde tačno nastaju zastoji i koliko ima primopredaja (handoffs)?
Koliko se zadataka vraća na doradu?

To su neuporedivo važnija pitanja od podatka koliki je trenutni Velocity tima broj 7.

Story Points na Enterprise nivou mogu postati apsurd

Ako tim A proceni određeni feature na 100 Story pointsa, a tim B na 40, da li je prvi tim automatski sporiji? Naravno da ne znamo. Story points predstavljaju isključivo relativnu procenu unutar jednog specifičnog tima.

Kada organizacija pokuša veštački da ih standardizuje na nivou od 100 timova, internu planersku tehniku pretvara u lažnu korporativnu metriku. Zatim slede poređenja tipa: „Ovaj ART isporučuje 12% više Story pointsa.“ To u praksi ne znači ništa, ili još gore: inženjeri brzo nauče kako da optimizuju bodove umesto rezultata. Dobićemo više fiktivnih bodova, ali ne nužno i više stvarne vrednosti.

Scale povećava cenu loše metrike

U malom timu loša metrika može proizvesti lokalno loše ponašanje. Ali u organizaciji od 5.000 ljudi, loša metrika menja kompletnu kulturu kompanije:

Ako nagrađujemo samo Velocity, timovi će veštački naduvavati procene.
Ako nagrađujemo broj isporučenih funkcionalnosti, dobićemo gomilu površnih dodataka.
Ako nagrađujemo stopostotnu zauzetost (utilization), svako će biti zatrpan poslom, a ukupan protok će kolabirati.

Na velikom nivou to više nije samo problem metrika, već pitanje dizajna podsticaja (Incentive Design).

Organizacija sa 100% iskorišćenosti je često spora organizacija

Ovo zvuči kontraintuitivno. Menadžment po pravilu voli ideju da svi zaposleni moraju biti potpuno uposleni u svakom trenutku. Međutim, sistemi koji rade na 100% iskorišćenosti nemaju nikakav manevarski prostor za:

nepredviđene zadatke,
rešavanje incidenata,
pomoć drugim timovima,
eksperimentisanje,
saniranje tehničkog duga,
učenje i usavršavanje.

Sve staje u red čekanja (Queue), a nagomilani redovi direktno produžavaju Lead Time. Rezultat je organizacija u kojoj su svi konstantno preopterećeni, a ništa se zapravo ne završava brzo. To je jedna od ključnih Lean lekcija koju Agile at Scale prečesto zaboravlja.

Sastanci nisu problem. Previše zavisnosti jeste

Lako je podsmevati se masovnim PI Planning sesijama ili Scrum of Scrums sastancima, ali sami sastanci nisu uzrok problema – oni su samo vidljiv simptom. Ako 150 ljudi mora dva puna dana da mapira 300 međusobnih zavisnosti, problem nije sam sastanak, već činjenica da uopšte imamo 300 zavisnosti. Uklonite polovinu tih zavisnosti i priroda sastanka se istog trenutka menja.

To je suština sistemskog razmišljanja (Systems Thinking): ne treba optimizovati sastanak, već optimizovati sistem koji je taj sastanak uopšte učinio neophodnim.

Platform Engineering može biti jedan od najvažnijih alata za skaliranje

Agile at Scale nikada nije samo organizacioni okvir; neophodna mu je tehnička infrastruktura koja velikom broju timova pruža stvarnu autonomiju u radu. Tu Platform Engineering preuzima centralnu ulogu.

Ako svaki pojedinačni tim mora samostalno da postavlja CI/CD, brine o upravljanju tajnama (Secrets), konfiguriše opservabilnost, podiže cloud resurse i piše alate za deployment, organizacija završava u ogromnom dupliranju posla. Sa druge strane, kvalitetna interna platforma daje timovima standardizovan i utaban put (paved road): bezbedan deploy, monitoring, automatizovane testove i skaliranje. Time se dramatično smanjuju zavisnosti prema centralnim operativnim timovima.

DORA istraživanja sve snažnije povezuju kvalitet interne platforme sa sposobnošću timova da efikasno usvoje moderne tehnologije, uključujući i AI alate (DORA). Tehnička platforma zato nije samo tema za DevOps, već primarni organizacioni pokretač agilnosti.

Standardizacija nije neprijatelj agilnosti

Postoji česta zabluda sažeta u stavu: „Naši timovi su autonomni, neka svako bira alate po želji.“ Rezultat takvog pristupa jeste 15 različitih logging alata, 12 modela za deployment, sedam načina autentifikacije i šest CI sistema. Autonomija nikada nije značila anarhiju.

Uspešna velika organizacija jasno razlikuje šta mora biti standardizovano, a gde tim ima punu kreativnu slobodu. Na primer, bezbednosne osnove, pravila usklađenosti i interfejsi za opservabilnost moraju biti uniformni standard. Sa druge strane, koje specifične interne obrasce tim primenjuje unutar sopstvene komponente može biti stvar njegove autonomije. Dobar model Enterprise arhitekture postavlja jasne zaštitne ograde (guardrails), a ne mikromenadžerska uputstva.

Centralni Architecture Board može uništiti Flow

Druga krajnost je podjednako opasna: svaka iole ozbiljnija tehnička odluka mora ići na centralni odbor. Odbor se sastaje jednom nedeljno, tim čeka u redu, traže se dodatna pojašnjenja, zakazuje se novi sastanak i odluka stiže tek tri nedelje kasnije.

Takav mehanizam možda čuva tehničku konzistentnost, ali stvara nepodnošljivo kašnjenje. Znatno bolji pristup jeste centralizovati principe, a decentralizovati odluke: jasno definišite arhitektonska načela, dozvoljene tehnologije, bezbednosne zahteve i pravila o podacima, a timovima prepustite da unutar tih zadatih granica donose brze i samostalne odluke.

Veliki Agile sistem može biti sporiji od malog Waterfall projekta

Ovo je neprijatna istina: agilna etiketa ne garantuje apsolutno ništa. Ako imate deset organizacionih slojeva, 30 koordinacionih sastanaka, stotine zavisnosti, tri nivoa Backloga, četiri kapije za odobrenje i preobiman PI plan, dobićete sistem koji je znatno teži i sporiji od klasičnog projektnog menadžmenta.

Na ITNetwork-u smo već pisali o tome da Agile nije automatski brži niti jeftiniji od tradicionalnih metoda. Pravo pitanje uvek glasi: koliki nivo neizvesnosti, zavisnosti, rizika i promena vaš sistem mora realno da apsorbuje? Agile nije dekorativna oznaka na vratima, već stvarna sposobnost sistema da brzo i bezbedno reaguje na promene.

Najgori Agile at Scale je Waterfall sa iteracijama

Ovaj scenario se u praksi dešava izuzetno često:

Prvi kvartal (Q1): biznis detaljno definiše sve zahteve.
Drugi kvartal (Q2): arhitekte do detalja dizajniraju celokupan sistem.
Treći kvartal (Q3): razvojni timovi implementiraju rešenje kroz sprintove.
Četvrti kvartal (Q4): sledi finalno testiranje i release.

Unutar same faze programiranja formalno se koristi Scrum, ali na nivou celokupne kompanije imamo čist sekvencijalni, tradicionalni proces. Takav hibridni model može imati smisla ako je svesno odabran, ali ga ne treba lažno predstavljati kao Enterprise agilnost. Timovi možda jesu agilni, ali organizacija to svakako nije.

Distribuirani timovi dodatno pojačavaju problem

Velike IT kompanije po pravilu posluju na globalnom nivou, obuhvatajući više država, vremenskih zona, jezika i kultura. Zavisnost koja se u istoj kancelariji rešava neformalnim razgovorom od pet minuta lako prerasta u celodnevno čekanje ukoliko se drugi tim nalazi u zoni koja kasni devet sati.

Zato skaliranje zahteva besprekornu kulturu asinhrone komunikacije: detaljnu i ažurnu dokumentaciju, transparentne odluke, vidljive zavisnosti i evidentirane arhitektonske odluke kroz Architecture Decision Records (ADR). Što je organizacija veća i geografski rasutija, to implicitno znanje koje živi samo u glavama pojedinaca postaje skuplje i opasnije.

Remote rad nije glavni problem. Nejasan Ownership jeste

Često se čuje opravdanje da je poslovanje otežano zato što timovi rade na daljinu. Međutim, ako je vlasništvo nad proizvodom i servisima kristalno jasno, rad na daljinu funkcioniše bez ikakvih zastoja.

Mnogo veći problem nastaje kada niko u sistemu ne zna:

ko donosi konačnu odluku,
ko je stvarni vlasnik servisa,
u čijoj je nadležnosti konkretan API,
ko zapravo sme da promeni prioritet zadatka.

Kada vlasništvo nije precizno definisano, čak i kancelarija prepuna ljudi na jednom mestu postaje izuzetno spora i neefikasna.

Product Owner na velikom nivou lako postane administrativni sloj

U teoriji, Product Owner je osoba koja maksimizuje isporučenu vrednost. U praksi velikih preduzeća često imamo čitavu armiju posrednika: Team PO, Area PO, Chief PO, Product Manager, Program Manager, Portfolio Manager i Business Owner – gde svi navodno „upravljaju prioritetima“.

Rezultat je opšta konfuzija u kojoj se gubi odgovor na pitanje ko zaista odlučuje. Ako svaki od ovih nivoa služi samo tome da prepisuje i prenosi zahteve sa višeg na niži nivo, nismo dobili kvalitetniji produktni menadžment, već samo glomazan lanac administrativnih posrednika.

Jedan Backlog ima veliku organizacionu moć

LeSS i Nexus iz tog razloga beskompromisno insistiraju na jednom jedinstvenom Product Backlogu za jedan proizvod (LeSS, Scrum.org). Zašto je to toliko važno? Zato što jedan zajednički Backlog primorava celu organizaciju na stvarnu prioritizaciju.

Ako svaki tim raspolaže sopstvenim izolovanim Backlogom, svako može tvrditi da radi na prioritetu broj jedan. Ali kada imamo samo jedan Backlog, to više nije moguće – organizacija je prisiljena da napravi stvaran kompromis (trade-off). To jeste politički bolan proces, ali je organizaciono izuzetno koristan.

Agile at Scale zahteva brutalno jasnu definiciju proizvoda

Ukoliko nemamo jasnu definiciju onoga šta zapravo predstavlja naš proizvod, nemoguće je oko njega smisleno organizovati timove. Korporacije po inerciji organizuju ljude prema tehničkim komponentama, pa tako imamo Database Team, Middleware Team, Frontend Team, Mobile Team i Integration Team.

To je menadžerski pregledno na šemama, ali korisnička vrednost nikada ne nastaje u granicama jedne komponente. Korisnik jednostavno želi da uspešno plati račun, i potpuno mu je nebitno koje odeljenje je napravilo API, a koje bazu. Zato pravo produktno razmišljanje zahteva reorganizaciju timova prema tokovima vrednosti, a to je znatno teži poduhvat od instalacije novog agilnog okvira.

Ljudi ne vole reorganizacije jer menjaju moć

Agile at Scale nikada nije neutralna tehnička operacija. Reorganizacija prema tokovima vrednosti po pravilu znači da:

pojedini menadžeri gube svoje timove,
drugi dobijaju potpuno drugačija ovlašćenja,
neke centralne funkcije postaju samo uslužne platforme,
pojedine uloge potpuno nestaju,
donošenje odluka više nije centralizovano.

Tu počinje stvarna politika svake transformacije. Upravo iz tog razloga mnoge Agile at Scale inicijative završe samo na usvajanju novih ceremonija: ceremonije su lake i bezopasne, dok je promena raspodele stvarne moći izuzetno teška.

Agile at Scale bez promene leadership-a je uglavnom predstava

Menadžment često deklariše da su timovi potpuno autonomni, a potom od njih zahteva detaljan tromesečni plan sa preciznim rokovima, svakom pojedinačnom funkcionalnošću i procentima realizacije.

Time se zaposlenima šalje nedvosmislena poruka: ne verujemo vam dovoljno da samostalno vodite sistem. Želimo privid agilnosti, ali pod uslovom da sve ostane stopostotno predvidivo kao pre. To je temeljna kontradikcija. Liderstvo u velikim agilnim sistemima mora preći sa kontrole pojedinačnih zadataka na dizajniranje sistema, stratešku jasnoću, postavljanje granica i upravljanje ishodima (outcome management).

Šta menadžer radi ako više ne raspoređuje zadatke?

Odgovor je: bavi se znatno ozbiljnijim poslom. On dizajnira zdravo okruženje u kojem timovi mogu nesmetano da stvaraju, uklanja međutimske zavisnosti, unapređuje protok vrednosti, razvija kompetencije zaposlenih, rešava duboke organizacione blokade i gradi mostove između strategije i operativnog rada. To je neuporedivo vredniji doprinos od pukog ispitivanja da li je tiket broj 432 pomeren u kolonu „Done“.

AI će Agile at Scale učiniti još težim – i još potrebnijim

Na ITNetwork-u smo već detaljno analizirali kako veštačka inteligencija transformiše Scrum i Kanban. AI višestruko uvećava lokalni inženjerski kapacitet: inženjeri brže pišu kod, automatski generišu testove, analiziraju dokumentaciju i automatizuju rutinski rad.

Ali šta se događa kada timovi postanu dvostruko brži, a provera arhitekture i odobrenja i dalje traju po dve nedelje? Usko grlo celog sistema postaje još očiglednije i bolnije. Veštačka inteligencija neće magično rešiti problem korporativnih zavisnosti – naprotiv, ona će ga dodatno ogoliti.

Agentic AI može proizvesti novi nivo koordinacione kompleksnosti

Sledeći korak u evoluciji jeste Agentic AI. Kada svaki inženjerski tim počne da koristi specijalizovane agente za programiranje, testiranje, bezbednost i proizvod, organizacija više ne koordinira samo timove sačinjene od ljudi, već upravlja čitavom mrežom digitalnih izvršilaca.

To donosi ogroman skok u obimu posla, ali istovremeno proizvodi znatno više Pull Requestova, veću učestalost promena, veći pritisak na reviziju koda i više potencijalnih konflikata. Zbog toga skaliranje prestaje da bude pitanje pukog broja programera i postaje pitanje: koliki obim promena naš sistem uopšte može bezbedno da apsorbuje?

Budućnost Agile at Scale-a možda je manje „Scale“, a više „Decouple“

Najbolja koordinacija jeste ona koja zapravo uopšte nije potrebna. Kada tim može potpuno nezavisno da isporuči rezultat, drastično se smanjuje potreba za sastancima, zavisnostima, čekanjima i eskalacijama.

Zato se suština buduće skalabilnosti krije u:

modularnoj arhitekturi,
jasnim i stabilnim API interfejsima,
internim platformama,
autonomnim produktnim timovima,
besprekornom vlasništvu nad servisima.

Ne postižemo stabilno skaliranje tako što ćemo povezati svakoga sa svakim, već tako što radikalno smanjujemo broj elemenata koji uopšte moraju biti međusobno koordinisani.

To je možda najveća greška u samom izrazu „Agile at Scale“

Reč „scale“ implicitno sugeriše ideju: uzmite ono što dobro radi na malom uzorku i jednostavno ga višestruko uvećajte. Ali kompleksne organizacije ne funkcionišu kao dečije Lego kocke. Deset timova nisu jedan tim pomnožen sa deset; to je potpuno novi organizacioni sistem sa sopstvenim obrascima ponašanja.

Možda bi znatno tačniji naziv bio: Agility under Complexity (agilnost pod pritiskom kompleksnosti). Mi ne pokušavamo veštački da uvećamo Scrum, već nastojimo da sačuvamo sposobnost brzog prilagođavanja dok kompleksnost oko nas neminovno raste. To je suštinski izazov.

Kako prepoznati da je Agile at Scale otišao u pogrešnom smeru?

Postoji nekoliko vrlo pouzdanih signala:

Imate više agilnih uloga nego ikada pre, ali se odluke donose sporije nego ranije.
Broj koordinacionih sastanaka stalno raste, dok međusobne zavisnosti ostaju netaknute.
Svi timovi su maksimalno zauzeti, ali se Lead Time konstantno produžava.
PI Planning proizvodi glomazne planove u koje niko ne sme da dirne.
Velocity na grafikonima izgleda sjajno, ali se isporuke u produkciju stalno odlažu.
Svaki tim ima svog Product Ownera, ali niko nema stvarni autoritet da kaže „ne“.
Odbor za arhitekturu predstavlja glavno usko grlo celog sistema.
Svi timovi rade Scrum, a krajnji korisnik čeka na funkcionalnost šest meseci.

Ako prepoznajete ove simptome u sopstvenoj organizaciji, rešenje se ne krije u uvođenju još jednog novog agilnog okvira, već u preispitivanju samog sistema rada.

Kako izgleda zdraviji pristup?

Jasno definišite šta je stvarni proizvod i mapirajte tok vrednosti (Value Stream).
Detaljno identifikujte i mapirajte sve postojeće zavisnosti.
Pre nego što se zapitate kako bolje da ih koordinirate, postavite pitanje kako da ih trajno uklonite.
Organizujte timove oko isporuke vrednosti, a ne oko tehničkih komponenti sistema.
Dajte timovima stvarna, nedvosmislena ovlašćenja za odlučivanje.
Izgradite internu platformu koja smanjuje zavisnost od centralizovanih operativnih timova.
Pratite i merite ukupan protok vrednosti (Flow).
Prilagodite finansijski model tako da podržava stabilne produktne timove umesto kratkoročnih projekata.
Standardizujte isključivo one elemente koji moraju biti uniformni.
Nikada nemojte skalirati loš i nefunkcionalan proces.

Ne skalirajte pre nego što jedan tim zaista funkcioniše

Ovo zvuči kao zdravorazumski savet, ali se u praksi retko poštuje. Kompanija još uvek nije rešila osnovna pitanja: Product Ownership, stabilan CI/CD, nagomilani tehnički dug, kvalitetno testiranje i istraživanje potreba korisnika – a već uveliko planira agilnu transformaciju celog preduzeća.

Šta dobijamo takvim pristupom? Dobijamo loš, nefunkcionalan proces repliciran na 50 različitih mesta. To nije agilnost na nivou preduzeća, već skaliranje problema (Problem at Scale).

Velike organizacije imaju još jednu opciju: ne skalirati sve

Ponekad uopšte nije potrebno da 30 timova istovremeno radi na jednom te istom proizvodu. Proizvod se često može logički podeliti na nekoliko relativno autonomnih celina, a kvalitetna platforma može manjim timovima obezbediti potpunu samostalnost. Neretko je koren problema nastao zato što je kompanija godinama stihijski gomilala nove ljude umesto da sistemski smanjuje kompleksnost.

Scrum.org Nexus vrlo direktno ističe da smanjenje obima (scaling down) ponekad može proizvesti znatno veću vrednost (Scrum.org). To jeste nepopularna ideja u korporativnom svetu gde menadžment jednačinu posmatra linearno: više ljudi jednako je više rezultata. Međutim, kompleksni sistemi odgovaraju drugačijom dinamikom: više ljudi po pravilu znači neuporedivo više koordinacije.

Koliko ljudi je previše?

Ne postoji univerzalan matematički broj, ali postoji vrlo jasan indikator: ukoliko veći deo radnog vremena vaših inženjera ne odlazi na stvarno stvaranje vrednosti, već na sastanke, čekanje na druge, integraciju koda i rešavanje eskalacija – prešli ste granicu zdravog i efikasnog skaliranja.

U tom trenutku pravo pitanje više ne glasi kako da dodamo još timova, već kako da radikalno smanjimo nepotrebne interakcije u sistemu.

Agile at Scale nije Agile framework problem. To je Organizational Design problem

Ovde dolazimo do same suštine teme. Bilo koji framework može vam ponuditi rečnik, uloge, ceremonije, artefakte i radni ritam, ali on ne može umesto vas:

redizajnirati softversku arhitekturu,
reformisati način finansiranja i budžetiranja,
srušiti ukorenjene korporativne silose,
delegirati stvarna ovlašćenja ljudima na terenu,
izgraditi kulturu poverenja,
sanirati nagomilani tehnički dug,
definisati jasnu poslovnu strategiju.

To je fundamentalni posao samog rukovodstva. Upravo zato se mnoge transformacije na velikom nivou završe na pukoj formi: okvir je formalno implementiran, ali se unutrašnja dinamika sistema nije promenila ni za milimetar.

Agile at Scale u budućnosti će verovatno biti manje opsednut framework-ima

SAFe, LeSS, Nexus i Scrum@Scale će nastaviti da postoje, ali savremeni tehnološki trendovi neumoljivo pomeraju fokus organizacija ka drugom pitanju: koliko brzo vrednost zaista može da prođe kroz naš sistem?

Platform Engineering, veštačka inteligencija, autonomni agenti, Continuous Delivery, sveobuhvatna opservabilnost i automatizovano upravljanje – sve ove tehnologije drastično smanjuju potrebu da se koordinacija rešava beskonačnim sastancima. Organizacija budućnosti može biti velika, a da istovremeno njeni timovi funkcionišu visoko autonomno. To je daleko zdraviji oblik skaliranja od izgradnje masivnih, centralizovano kontrolisanih sistema.

Agile at Scale možda najbolje radi kada ga najmanje primećujemo

Zrela organizacija ne troši energiju na svakodnevne rasprave o metodologijama, baš kao što iskusan vozač tokom vožnje ne razmišlja o teoriji upravljanja vozilom.

Timovi rade stabilno, vrednost neprekidno teče ka produkciji, međutimske zavisnosti su svedene na minimum, odluke se donose brzo na licu mesta, platforma pruža pouzdanu podršku, strategija je direktno uvezana sa izvršenjem, a povratne informacije od korisnika stižu u realnom vremenu. Kada su ovi preduslovi ispunjeni, postaje potpuno nevažno koji akronim stoji na prezentaciji. Framework je isključivo sredstvo, a ne identitet kompanije.

Najopasnija stvar kod Agile at Scale-a je mogućnost da birokratiju učinimo modernijom, a da je ne smanjimo

Pre uvođenja agilnih metoda organizacije su imale projektne odbore, upravne komitete, statusne sastanke i Gantt grafikone. Nakon transformacije dobile su Agile Release Trains, PI Planning, Scrum of Scrums, Portfolio Kanban i Agile savete.

Ako smo samo zamenili etikete, nismo postigli ništa. Birokratija prepisana u Jiru ostaje podjednako rigidna birokratija; kašnjenje izraženo kroz Story points i dalje je kašnjenje; a centralizovana kontrola upakovana u agilnu terminologiju ostaje puka centralizovana kontrola. Pravi test zrelosti ne glasi koliko naših timova koristi Scrum, već koliko lako naša organizacija može da promeni smer kada dobije novu informaciju sa tržišta.

Velika organizacija ne mora da bude spora. Ali mora da plati cenu svoje kompleksnosti

Ta cena se u praksi uvek plaća na jedan od dva načina:

Prvi način: plaćanjem kroz beskonačne sastanke, rigoroznu kontrolu, komplikovanu koordinaciju i birokratiju.
Drugi način: ulaganjem u kvalitetnu arhitekturu, kristalno jasno vlasništvo, autonomne timove, interne platforme, transparentnost i jasna pravila igre.

Prvi put je znatno lakše započeti jer zahteva samo dodavanje novih procedura. Drugi put je neuporedivo teže izgraditi, ali on čini funkcionisanje velikog sistema dugoročno održivim.

Nije cilj da 100 timova radi Agile. Cilj je da 100 timova ne mora stalno da pita jedni druge za dozvolu

U tome leži suštinska razlika. Ako svaki tim za svaku tehničku ili poslovnu promenu mora da traži odobrenje drugog tima, čeka odluku odbora, zakazuje sastanke za usklađivanje i pokreće eskalacije, onda broj timova ne predstavlja razvojni kapacitet – on predstavlja ogroman trošak koordinacije.

Agile at Scale uspeva tek onda kada rast organizacije ne prati proporcionalni rast međusobnih zavisnosti. To zahteva promišljen inženjerski dizajn, pažljivo organizaciono strukturiranje, zrelo liderstvo, odgovarajuće finansiranje i veliku disciplinu, a ne samo novi procesni priručnik.

Možda je pravo pitanje: koliko Agile-a uopšte treba skalirati?

Temeljni principi agilnog razvoja su zapravo jednostavni: kratke petlje povratnih informacija, rad u malim paketima, brza reakcija na promenu, neposredna blizina korisniku, transparentnost i decentralizovano donošenje odluka. Za primenu ovih vrednosti nije nužan komplikovan metodološki aparat.

Ponekad je najveći dokaz organizacione zrelosti sposobnost da se kompleksnost svesno smanji, umesto da se njome neprekidno upravlja. Najbolji okvir za skaliranje jeste onaj koji vam omogući da sam okvir koristite što je manje moguće. Krajnji cilj nikada nije bilo puko skaliranje Agile metoda, već skaliranje sposobnosti da se kontinuirano stvara stvarna vrednost – bez toga da veličina organizacije postane njena najveća prepreka.

FAQ – Agile at Scale

Šta znači Agile at Scale?

Agile at Scale označava primenu agilnih principa i metoda u okruženju u kojem veći broj timova radi na istom proizvodu, toku vrednosti ili kompleksnom sistemu, pri čemu moraju koordinirati prioritete, arhitekturu, integraciju i isporuku rešenja.

Zašto je skaliranje Agile-a teško?

Rastom broja timova eksponencijalno rastu međusobne zavisnosti, broj komunikacionih kanala, koordinacioni troškovi, tehnička kompleksnost arhitekture i nivoi odlučivanja u kompaniji.

Da li Scrum može da se koristi u velikim organizacijama?

Može, ali model jednog izolovanog Scrum tima nije dovoljan za usklađivanje desetina timova. Za veće sisteme primenjuju se specijalizovani okviri kao što su Nexus, LeSS, Scrum@Scale i SAFe.

Šta je SAFe?

Scaled Agile Framework (SAFe) je sveobuhvatan okvir za agilno poslovanje na nivou velikih preduzeća koji povezuje razvojne timove, Agile Release Trains, produktni menadžment, upravljanje portfoliom, finansiranje, arhitekturu i korporativnu strategiju.

Šta je Agile Release Train?

Agile Release Train (ART) je dugoročni „tim timova“ koji okuplja više agilnih timova oko zajedničkog toka vrednosti ili tehnološkog rešenja, predstavljajući centralnu jedinicu koordinacije i isporuke u SAFe okviru.

Šta je LeSS?

Large-Scale Scrum (LeSS) je okvir za skaliranje Scruma koji se oslanja na jednostavnost: zagovara jedan proizvod, jedan zajednički Product Backlog, jednog Product Ownera i minimalnu dodatnu organizacionu strukturu.

Šta je Nexus?

Nexus je okvir koji je razvio Scrum.org za grupe od tri do devet Scrum timova koji rade na istom proizvodu. Njegov primarni fokus je uklanjanje međutimskih zavisnosti i redovna isporuka zajedničkog integrisanog inkrementa.

Šta je Scrum@Scale?

Scrum@Scale je modularni okvir koji skalira Scrum kroz mrežu timova i koordinacionih tela, vođen filozofijom minimalne održive birokratije (minimum viable bureaucracy).

Koji Agile at Scale framework je najbolji?

Ne postoji univerzalno najbolje rešenje. Izbor zavisi od specifičnosti organizacije, prirode proizvoda, broja timova, zakonske regulative, stanja arhitekture, nivoa zavisnosti i modela finansiranja.

Da li SAFe stvara previše birokratije?

SAFe ima znatno više formalnih uloga, nivoa i događaja od okvira kao što su LeSS ili Nexus. U kompleksnim korporacijama može doneti red, ali nespretna implementacija lako pretvara njegove mehanizme u novi birokratski teret.

Šta je najveći problem skaliranja Agile-a?

U praksi su to međutimske zavisnosti. Veliki broj zavisnosti dovodi do dugotrajnih čekanja, otežane koordinacije, integracionih rizika i drastičnog produženja ukupnog vremena isporuke (Lead Time).

Kako arhitektura utiče na Agile at Scale?

Izuzetno snažno. Čvrsto povezani (tightly coupled) sistemi primoravaju timove na stalna usklađivanja, dok modularna arhitektura, nezavisni servisi i jasni interfejsi omogućavaju istinsku timsku autonomiju.

Da li veliki broj timova znači veću produktivnost?

Ne automatski. Dodavanje novih ljudi povećava teoretski kapacitet, ali dramatično uvećava kompleksnost komunikacije. Često manji broj dobro organizovanih timova može isporučiti više stvarne vrednosti.

Da li svi timovi treba da imaju svoj Product Backlog?

Okviri poput LeSS-a i Nexusa striktno insistiraju na jednom Backlogu za jedan proizvod, jer to primorava organizaciju na postavljanje jedinstvenih prioriteta i očuvanje fokusa na celokupan proizvod.

Kako treba meriti Agile at Scale?

Pored lokalnih parametara, fokus mora biti na sistemskim metrikama: Lead Time, Cycle Time, ukupan protok (Throughput), frekvencija deploymenta, stopa neuspešnih promena, vreme provedeno u čekanju i stvarni poslovni ishodi.

Da li Velocity treba porediti između timova?

Nikako. Procene u Story pointsima i brzina tima (Velocity) imaju isključivo lokalni kontekst unutar jednog tima, pa je njihovo poređenje na nivou organizacije metodološki pogrešno i kontraproduktivno.

Kakvu ulogu ima Platform Engineering?

Platform Engineering oslobađa razvojne timove zavisnosti od centralnih operativnih timova, pružajući im standardizovanu, samouslužnu infrastrukturu za razvoj, automatizovano testiranje, deployment i praćenje rada sistema.

Da li AI menja Agile at Scale?

Da. Veštačka inteligencija drastično ubrzava pisanje koda i lokalni rad inženjera, ali time postojeća organizaciona uska grla – u reviziji koda, bezbednosti, arhitekturi i donošenju odluka – čini još uočljivijim.

Da li velika organizacija mora da koristi Agile at Scale framework?

Ne mora. Nijedan okvir nije zakonska obaveza. Kompanija može uspešno kombinovati Scrum, Kanban, produktni menadžment, DevOps, Platform Engineering i sopstvene koordinacione modele prilagođene svojoj situaciji.

Kako znamo da je Agile at Scale uspešan?

Ne po broju održanih ceremonija ili sertifikata, već po tome da li organizacija brže donosi kvalitetne odluke, uspešno eliminiše zavisnosti, ubrzava protok vrednosti i može lako da promeni poslovni pravac bez velikih potresa.

Koja je najveća greška u Agile at Scale transformaciji?

Skaliranje procesa pre nego što su rešeni osnovni tehnički i organizacioni problemi. Kada skalirate loš i nefunkcionalan proces, dobijate samo haos na znatno većem nivou.