Key Takeaways – šta je najbitnije u ovom tekstu
Scrum nije mrtav. Agile nije prevaziđen. Ali AI-native kompanija sve teže može da se organizuje kao tradicionalni softverski tim iz prethodne decenije kome smo samo dodali Copilot, ChatGPT ili nekoliko autonomnih agenata.
Problem se promenio. Godinama smo pokušavali da ubrzamo delivery – isporuku softvera. Danas AI coding agents (AI agenti za programiranje) sve češće mogu da analiziraju repozitorijum, napišu kod, generišu testove, pokrenu ih, isprave greške i pripreme Pull Request dok čovek radi nešto drugo. Istraživanje Microsoft Research-a iz 2026. analiziralo je produkcijske GitHub Copilot tragove 3,2 miliona korisnika i 13 miliona agentic coding sesija – više nije reč o eksperimentu nekoliko entuzijasta, već o novoj razvojnoj infrastrukturi.
Istovremeno, Atlassian navodi da 94% engineering lidera kaže da njihovi timovi već koriste AI, dok samo 6% smatra da ima sisteme potrebne za njegovo skaliranje i governance (upravljanje).
Tu počinje priča o Post-Agile organizaciji. Ne kao formalnoj metodologiji koja sutra treba da zameni Scrum. Ne kao još jednom konsultantskom akronimu. Već kao mogućem sledećem organizacionom modelu u kojem Agile principi ostaju relevantni, ali se struktura rada menja jer više nije racionalno organizovati inteligentne ljude i digitalne agente oko istih ograničenja koja su postojala 2001, 2010. ili čak 2023. godine.
Najkraće rečeno: Agile je rešavao problem sporog razvoja. AI-native organizacija mora da reši problem prebrzog izvršenja. A to su dve veoma različite stvari.
Agile nije nastao zbog Daily Scrum-a
Da bismo razumeli šta se menja, treba se vratiti osnovama. Agile nije nastao zato što je softverskoj industriji nedostajao jutarnji sastanak od petnaest minuta. Nije nastao zbog Jira table. Nije nastao zbog Story Points-a. Niti zato što je neko smatrao da je dvonedeljni Sprint prirodni zakon razvoja softvera.
Agile je nastao kao reakcija na veliki problem tadašnjeg softverskog razvoja: organizacije su mesecima ili godinama izrađivale planove, a zatim isporučivale softver koji više nije odgovarao potrebama korisnika.
Agile je promenio osnovnu logiku: Napravi nešto manje. Isporuči. Proveri. Nauči. Prilagodi se. Ponovi.
Scrum je tu logiku operacionalizovao kroz Product Backlog, Sprint, Increment, Product Owner-a, Scrum Master-a i Developere. To i dalje ima smisla. Ali tehnologija ispod procesa počinje radikalno da se menja.
Šta ako kod više nije glavno usko grlo?
Decenijama je izrada softvera bila skupa zato što je zahtevala mnogo kvalifikovanog ljudskog rada za analizu, dizajn, implementaciju, testiranje, dokumentaciju, code review i deployment. AI sve više ulazi u svaki od tih koraka.
DORA istraživanje među gotovo 5.000 tehnoloških profesionalaca pokazalo je da je već tokom 2025. oko 90% ispitanika koristilo AI u razvoju softvera. Tokom 2026. priča je otišla dalje: JetBrains je utvrdio da je tokom leta iste godine čak 90% profesionalnih programera koristilo AI coding agents najmanje jednom nedeljno, dok ih je 68% koristilo svakodnevno.
To menja ekonomiju razvoja. Ako developer više ne mora dva dana da piše boilerplate kod, Sprint nije automatski kraći. Zašto? Jer neko i dalje mora da odluči šta treba napraviti, da li rešava pravi problem, da li je arhitektura prihvatljiva i da li su rezultati bezbedni. Drugim rečima: bottleneck (usko grlo) prelazi sa proizvodnje na rasuđivanje.
Scrum je dizajniran za drugačiju ekonomiju rada
Klasičan Scrum pretpostavlja ograničen kapacitet tima. Zato ograničavamo koliko rada ulazi u Sprint. Ali zamislimo tim 2028. godine: 1 Product Manager, 2 senior developera, 1 Product Designer, 1 Platform Engineer i 20 specijalizovanih AI agenata.
Jedan agent analizira customer feedback, drugi pravi prototip, treći piše backend, četvrti frontend, peti generiše testove, šesti radi Code Review… Kapacitet izvršenja tog tima više nije jednostavno broj ljudi × broj radnih sati. To je kombinacija ljudskog vremena, agentskog compute kapaciteta, paralelizacije i broja potrebnih ljudskih provera. Tu klasično planiranje kapaciteta počinje da puca po šavovima.
Kapacitet za proveru važniji od kapaciteta za rad
Ovo može postati jedan od najvećih paradoksa AI-native razvoja. Zamislite da pet agenata preko noći pripremi pet Pull Request-ova sa po 1.500 linija promena. Testovi prolaze, CI je zelen. Ali ujutro neko mora da razume šta je napravljeno.
Ako ljudski tim može kvalitetno da pregleda dva Pull Request-a dnevno, a agenti mogu da generišu deset, nije ubrzan ceo sistem – queue (red čekanja) se samo preselio. Generisanje koda postaje lakše, dok se bottleneck premešta na review, security, governance i deployment. Zato Sprint Planning više ne pita samo „Koliko možemo da napravimo?“, već „Koliko možemo odgovorno da proverimo i pustimo u produkciju?“
Post-Agile ne znači „posle agilnosti“
Post-Agile ne znači povratak na Waterfall. Naprotiv, najvažniji Agile principi možda postaju još važniji: kratke feedback petlje, česta isporuka, mali paketi promena, prilagođavanje na osnovu rezultata.
Post-Agile organizacija bi zato mogla da bude: Agile principles without Agile bureaucracy – agilni principi bez ceremonijalne birokratije koja se tokom godina nakupila oko njih.
Da li nam je zaista potreban Daily Scrum ako sistem sve vidi?
Tradicionalni Daily Scrum služi za usklađivanje ka Sprint Goal-u. Ali šta ako AI platforma već zna koji Pull Request kasni, koji testovi padaju i koja promena povećava rizik?
AI pre sastanka može napraviti sažetak. Šta onda ljudi rade na Daily Scrum-u? Da li ponavljaju podatke koje sistem već zna? Ne. Sastanak tada ima smisla samo za ono u čemu su ljudi bolji: odluku, pregovor, prioritet, konflikt i procenu rizika. Ako nema takvog problema, možda sastanak tog dana nije potreban. To nije anti-Scrum, to je dosledna primena ideje da proces treba da služi timu, a ne obrnuto.
Sprint od dve nedelje možda postaje čudna jedinica
Dvonedeljni Sprint je popularan jer daje brz feedback i omogućava da se nešto završi. Ali šta ako produkcijska promena može biti napravljena i deployovana istog dana?
Ovde postoji zamka. Izvršenje možda traje dva sata, ali učenje ne. Korisniku trebaju dani da koristi novu funkciju, a A/B testu statistički značajan broj interakcija. Zato AI-native organizacija verovatno neće imati jednu ritmičku jedinicu, već najmanje dve:
-
Execution Loop: Veoma brz ciklus (ideja → implementacija → test → deployment), možda meren satima.
-
Learning Loop: Sporiji ciklus (ponašanje korisnika → poslovni efekat → odluka), možda meren danima ili nedeljama.
Product Backlog menja funkciju
Kada proizvodnja softvera postane jeftinija, veoma lako možemo završiti u apsurdnoj situaciji: AI implementira backlog brže nego što organizacija može smisleno da ga uređuje.
Zato budući backlog verovatno neće biti skladište zahteva, već portfolio hipoteza. Ne: „Napravi filter X“, već: „Verujemo da korisnici napuštaju checkout jer ne nalaze dostavu. Koji je najjeftiniji eksperiment da to proverimo?“
Od task-centric ka intent-centric organizaciji
Ovo znači prelazak sa upravljanja zadacima na upravljanje namerom. Umesto zadatka „Napravi endpoint za eksport računa“, AI-native zahtev bi glasio: „Omogući računovodstvu da bez developera izvuče podatke za usklađivanje, uz poštovanje postojećih pravila pristupa.“
Agent sam pronalazi arhitekturu, predlaže rešenje i pravi API. Ali čovek mora preciznije definisati namenu, ograničenja i neprihvatljiv rizik. Što je AI sposobniji, specifikacija namere postaje važnija od specifikacije implementacije.
Senior developer postaje orkestrator sistema
AI neće „ukinuti programere“, ali će promeniti ulogu senior inženjera. Manje vremena za repetitivni kod, više vremena za arhitekturu, razlaganje cilja, upravljanje agentima i razumevanje biznisa. Senior developer će upravljati većom količinom izvršenja, ali mora da prepozna probleme u kodu koji nije on napisao. Što je pisanje koda lakše, to razumevanje celokupnog sistema postaje vrednije.
Scrum Master i Product Owner u Post-Agile eri
Scrum Master koji samo administrira proces i čuva Jira tablu postaće ranjiva uloga, jer AI već može da sažme sastanak i prepozna blokade. Scrum Master koji razume organizacioni dizajn, psihološku sigurnost i systems thinking postaje još važniji.
Product Owner dobija najteži posao. Ako AI može da napravi gotovo sve, pitanje „šta treba napraviti?“ postaje brutalno važno. McKinsey je 2026. utvrdio da je čak 32% organizacija već odustalo od kupovine softvera jer procenjuju da ga mogu interno napraviti agentima. Build vs. buy odluka se potpuno menja. AI spušta cenu implementacije, ali ne spušta cenu pogrešne odluke.
Flow iznad zauzetosti i važnost WIP limita
Pokušaj da svaki čovek bude 100% zauzet u AI-native razvoju samo povećava queue (red čekanja). Zato Flow postaje važniji od utilization-a (zauzetosti). Važnija pitanja su: Koliko posao čeka? Gde se gomila WIP?
AI uklanja prirodno ograničenje proizvodnje koje je stvarao ljudski kapacitet. Zato Kanban princip WIP limita (Work in Progress) postaje još važniji – moramo svesno ograničiti sistem da ne apsorbuje više promena nego što je to bezbedno.
Comprehension Debt: dug koji još ne merimo
Svi znamo za Technical Debt (tehnički dug). Ali šta je Comprehension Debt (dug razumevanja)?
AI može napraviti hiljade linija korektnog koda veoma brzo. Ako ljudsko razumevanje raste sporije nego codebase, kompanija poseduje softver koji više niko u potpunosti ne razume. To je veoma opasno kada se dogodi incident u 3 ujutro.
Engineering governance i „Chaos at machine speed“
Što više autonomije damo agentima, potrebnija su jasnija pravila: Koje repozitorijume agent sme da menja? Ko odobrava deployment? Agilnost i disciplina nisu suprotnosti – u AI-native okruženju jedna bez druge neće opstati. Zato su Policy as Code i automatizovani guardrails neophodni.
U suprotnom, dobijamo Chaos at machine speed. DORA odlično primećuje: AI pojačava postojeći sistem. AI nije lek za lošu organizaciju, već ubrzivač organizacije koju već imate.
Kapacitet više nije headcount
Dve kompanije sa po 100 developera danas mogu imati radikalno različit kapacitet. CFO i CTO će morati da nauče novu matematiku koja ne meri samo cost per engineer, već cost per validated outcome, agent utilization i human review capacity.
Za Srbiju i region ovo znači da „Imamo dobre programere po nižoj ceni“ više nije dovoljno. Nova konkurentska prednost biće: „Imamo mali tim koji, uz AI-native workflow, može da isporuči ono za šta konkurentu treba organizacija tri puta veća.“
Zaključak: Scrum nije mrtav – ali svet za koji je napravljen nestaje
Sve više izvršenja postaje jeftino: kodiranje, testiranje, analiza, dokumentacija. I upravo zato postaju skupe stvari koje ne možemo lako automatizovati: odluka, razumevanje, odgovornost, strategija, poverenje, ukus.
Post-Agile organizacija neće biti organizacija bez Agile-a, već organizacija koja više ne poistovećuje Agile sa ceremonijama. Neće pitati „Da li imamo Daily?“, već „Da li informacija dovoljno brzo dolazi do osobe koja može doneti odluku?“
AI-native organizacija nema problem sa nedostatkom proizvodne snage, već sa viškom mogućnosti. A upravljanje viškom mogućnosti zahteva ono što nijedan framework ne može da pruži: dobar sud.
FAQ
Šta znači Post-Agile organizacija? Post-Agile organizacija nije zvanična metodologija niti standardizovan framework. Termin opisuje organizacioni model u kojem se Agile principi zadržavaju, ali se tradicionalni rituali i strukture prilagođavaju svetu AI agenata, continuous delivery-ja i mnogo bržeg izvršenja.
Da li AI znači kraj Scrum-a? Ne. Scrumovi osnovni principi empirizma, transparentnosti, inspekcije i adaptacije ostaju relevantni. Međutim, određene ceremonije, načini procenjivanja i dvonedeljni ritam mogu postati manje korisni u AI-native timovima.
Šta je AI-native organizacija? AI-native organizacija nije samo kompanija koja koristi ChatGPT ili coding assistants. AI je ugrađen u način planiranja, razvoja, odlučivanja, automatizacije, analize i upravljanja radom, dok ljudi ostaju odgovorni za smer, procenu i konačne odluke.
Šta je najveće usko grlo AI-native razvoja? Sve češće nije generisanje koda, već review, verifikacija, security, governance, integracija i odluka šta uopšte vredi razvijati.
Da li će Sprintovi postati kraći? Moguće je, ali ne nužno. Execution Loop može postati veoma kratak, dok Learning Loop zavisi od korisnika, tržišta i prikupljanja dovoljno kvalitetnih podataka. Zbog toga AI-native timovi mogu koristiti različite ritmove za delivery i učenje.
Hoće li AI zameniti Scrum Master-a? Administrativni deo uloge može biti snažno automatizovan. Scrum Master koji se bavi coaching-om, sistemskim problemima, Flow-om, timskom dinamikom i organizacionim dizajnom verovatno ostaje relevantan.
Da li će Product Owner postati važniji? Verovatno da. Kada implementacija postane jeftinija, sposobnost da se izabere pravi problem i definiše vredan ishod postaje još značajnija.
Šta je Comprehension Debt? Comprehension Debt ili dug razumevanja nastaje kada količina i brzina AI-generisanog koda rastu brže od ljudskog razumevanja sistema. Softver može raditi, ali tim sve slabije razume njegovu strukturu i odluke ugrađene u njega.
Da li će AI-native timovi imati manje ljudi? Neki verovatno hoće. Međutim, veći produktivni kapacitet može takođe omogućiti kompanijama da razvijaju više proizvoda i eksperimenata sa istim brojem zaposlenih.
Zašto je Kanban i dalje relevantan? Zato što AI povećava mogućnost paralelnog rada. WIP limiti, upravljanje Flow-om i kontrola redova čekanja mogu postati još važniji kada agenti mogu proizvesti više rada nego što ljudski tim može proveriti.
Kako kompanija treba da počne tranziciju? Ne ukidanjem Scrum-a, već analizom bottleneck-a. Treba utvrditi gde AI već menja tok rada, šta se može automatizovati, gde je potrebna ljudska provera i koje postojeće ceremonije zaista stvaraju vrednost.
Da li je Post-Agile samo novi naziv za AI-Augmented Agile? Ne sasvim. AI-Augmented Agile opisuje način na koji AI povećava kapacitet postojećeg agilnog sistema. Post-Agile ide korak dalje i pita da li je potrebno redizajnirati samu strukturu organizacije kada AI postane trajni deo njenog proizvodnog kapaciteta.
