Ključne teze (Key Takeaways) – šta je najbitnije u ovom tekstu
Veštačka inteligencija sve dublje ulazi u agilno IT poslovanje, ali najveća promena nije automatsko pisanje korisničkih priča (User Stories), sažimanje sastanaka ili generisanje izveštaja. AI počinje da menja način na koji timovi planiraju, procenjuju rizik, uređuju Product Backlog, prate tok rada (Flow), predviđaju kašnjenja i donose odluke.
Scrum zbog toga ne nestaje. Kanban takođe ne postaje suvišan. Naprotiv, njihovi osnovni principi – transparentnost, inspekcija (Inspection), prilagođavanje (Adaptation), ograničavanje rada u toku (Work in Progress – WIP) i optimizacija toka rada (Flow) – mogu postati još važniji. Zvanični Scrum Guide i dalje počiva upravo na empirizmu, transparentnosti, inspekciji i adaptaciji. AI može ubrzati prikupljanje i analizu podataka, ali ne može automatski odlučiti šta predstavlja vrednost za korisnika.
Podaci istovremeno ruše jednu opasnu pretpostavku: brži pojedinac ne znači automatski brži tim. DORA opisuje AI kao pojačivač (Amplifier) postojećeg organizacionog sistema – dobre procese može dodatno ubrzati, a loše učiniti još problematičnijim. Atlassian je u istraživanju među 3.500 developera i menadžera pronašao sličan paradoks: timovi prijavljuju veću uštedu vremena zahvaljujući AI-ju, ali istovremeno i rast organizacionih neefikasnosti.
Zato glavno pitanje više nije: „Kako ubaciti AI u Scrum?“
Mnogo važnije je: „Kako organizovati rad kada AI može da proizvede, analizira i obradi posao brže nego što ljudi mogu da ga pregledaju, razumeju i pretvore u poslovnu vrednost?“
Tu počinje prava transformacija agilnog poslovanja.
Agile je nastao zbog promena. AI sada dramatično povećava njihovu brzinu
Postoji određena ironija u načinu na koji danas govorimo o Agile-u.
Metodologije i principi nastali su kao odgovor na previše krute procese razvoja softvera. Umesto višemesečnog planiranja, ogromnih specifikacija i razvoja proizvoda koji korisnik vidi tek kada je gotovo sve završeno, ideja je bila jednostavnija: radi u manjim koracima, često proveravaj rezultat, slušaj korisnika i menjaj pravac kada dobiješ nove informacije.
Onda su kompanije uradile ono što kompanije često rade.
Od Agile-a su napravile proces.
Dobili smo Jira table, Story Points, Daily Scrum, Sprint Planning, Retrospective, grafikone brzine (velocity), Agile Coach-eve, Scrum Master-e, sertifikate i čitavu industriju oko agilnog poslovanja.
A ponekad smo usput zaboravili zašto sve to postoji.
AI sada brutalno vraća razgovor na početak.
Jer ako mašina može za nekoliko minuta da analizira stotine korisničkih tiketa, pronađe obrasce u zahtevima, napravi nacrt Product Backlog-a, sažme prethodnih šest sprintova i identifikuje zadatke koji se konstantno zaglavljuju – da li nam zaista treba trosatni sastanak da bismo ručno prepisivali informacije iz jednog sistema u drugi?
Verovatno ne.
Ali to ne znači da nam više nije potreban Product Owner.
Znači da njegov posao mora da postane ozbiljniji.
Scrum nije skup sastanaka
Da bismo razumeli šta AI zapravo menja, prvo moramo razjasniti čestu zabludu.
Scrum nije Daily Scrum + Sprint Planning + Sprint Review + Retrospective.
Prema zvaničnom Scrum Guide-u, Scrum je lagani okvir (framework) za stvaranje vrednosti kroz adaptivna rešenja kompleksnih problema. Njegova logika počiva na empirizmu i Lean razmišljanju, a transparentnost, inspekcija i adaptacija predstavljaju njegove ključne stubove. Scrum tim (Scrum Team) je samoupravljajući (self-managing), dok Product Owner, Scrum Master i Developers (developeri) imaju različite odgovornosti.
AI nijedan od tih principa ne čini zastarelim.
Naprotiv.
Ako AI omogući deset puta više informacija i nekoliko puta veću brzinu izvršavanja, potreba da znamo šta se zaista događa u sistemu postaje veća.
AI zato može promeniti mehaniku Scrum-a, a da njegova osnovna logika ostane iznenađujuće stabilna.
Šta se događa sa Product Backlog-om kada AI pročita sve što čovek ne može?
Zamislimo SaaS kompaniju sa 50.000 korisnika.
Tokom meseca dobije:
-
nekoliko hiljada support poruka,
-
stotine komentara na društvenim mrežama,
-
desetine zahteva velikih klijenata,
-
podatke iz aplikacione analitike,
-
rezultate A/B testova,
-
prijave grešaka (bug reports),
-
razgovore prodajnog tima sa potencijalnim kupcima.
Product Owner tradicionalno vidi samo deo toga.
AI sistem može da analizira praktično sve.
Može da grupiše zahteve prema temi, pronađe probleme koji se ponavljaju, poveže ih sa odlivom korisnika (churn), proceni koje funkcionalnosti najčešće traže korisnici određenog segmenta i napravi inicijalni predlog prioriteta.
To je ogromna promena.
Ali AI i dalje ne zna nužno šta kompanija želi da postane.
Ako 2.000 korisnika traži funkcionalnost A, a strateški pravac kompanije zahteva razvoj funkcionalnosti B koju trenutno traži samo 100 najvećih enterprise klijenata, statistički najpopularniji zahtev možda nije najbolja poslovna odluka.
AI može dati podatke.
Product Owner mora razumeti vrednost.
Zato bi njegova buduća uloga mogla biti manje „administrator backlog-a“, a mnogo više strateg proizvoda (Product Strategist).
AI može napisati User Story. To je najmanje zanimljiva stvar koju može da uradi
Danas je veoma lako demonstrirati: „Napiši User Story za resetovanje lozinke.“
AI će za nekoliko sekundi generisati nešto nalik:As a registered user, I want to reset my forgotten password so that I can regain access to my account.
Dodaće kriterijume prihvatanja (Acceptance Criteria), granične slučajeve (Edge Cases), možda i test scenarije.
Korisno.
Ali relativno trivijalno.
Mnogo zanimljiviji scenario nastaje kada AI ima pristup prethodnim incidentima, analitici proizvoda, dokumentaciji, dizajnu, tehničkoj arhitekturi i postojećem backlog-u.
Tada može upozoriti: „Ova User Story utiče na autentifikacioni servis, mobilnu aplikaciju i GDPR proces brisanja naloga. Slična promena u Sprintu 42 izazvala je regresiju. Pre implementacije proveriti X, Y i Z.“
To više nije generator teksta.
To je inteligentni sloj upravljanja projektom (Project Intelligence Layer).
I upravo u tom pravcu ide ozbiljnija primena veštačke inteligencije.
Sprint Planning će postati manje ritual, a više simulacija
Sprint Planning danas često uključuje dosta ljudskog nagađanja. Koliko možemo da završimo? Da li je zadatak prevelik? Ko ima kapacitet? Šta nas može blokirati? Koliko Story Points (poena) vredi ovo?
AI sistem koji ima istoriju prethodnih sprintova može da posmatra stvarne podatke: vreme ciklusa (Cycle Time), prethodne zavisnosti, odsustva članova tima, istoriju sličnih zadataka, broj vraćenih pull request-ova, učestalost regresija i raspoloživi kapacitet.
Umesto: „Mislim da možemo 42 poena.“ Možemo dobiti: „Na osnovu poslednjih 14 sprintova, trenutnog rada u toku (WIP), planiranih odsustava i tri zavisnosti od Platformskog tima, verovatnoća završavanja kompletnog predloženog obima posla (scope) je niska. Najveći rizik predstavljaju zadaci A i C.“
To ne znači da AI treba da odluči o sadržaju sprinta.
Znači da planiranje može postati informisano podacima (data-informed) umesto ritualnog pogađanja.
I tu dolazimo do potencijalno bolne teme.
Ako AI iz istorijskih podataka može bolje da predvidi Cycle Time nego Planning Poker, možda neke naše omiljene Agile ceremonije nisu svete.
Da li Story Points imaju budućnost?
Oko Story Points-a se već godinama vode rasprave.
AI ih čini još zanimljivijim.
Story Point pokušava da predstavi relativnu kompleksnost, neizvesnost i količinu rada. Problem nastaje kada menadžment počne da ga tretira kao jedinicu produktivnosti.
„Tim A završava 80 poena, tim B samo 50.“
To je metodološki problematično čak i bez AI-ja.
Sa AI-jem postaje još gore.
Ako AI dramatično ubrza određene vrste zadataka, istorijski Story Points gube deo prediktivne vrednosti. Zadatak koji je prošle godine bio „8 poena“ možda danas postaje rutinska intervencija od sat vremena.
Kanban pristup tu može dobiti dodatnu prednost jer je prirodno orijentisan ka empirijskim metrikama toka (Flow Metrics): broju završenih stavki (Throughput), vremenu ciklusa (Cycle Time), vremenu od zahteva do isporuke (Lead Time) i količini paralelnog rada (WIP).
Litlov zakon (Little’s Law) povezuje prosečan Throughput, WIP i Cycle Time u stabilnom sistemu, što omogućava predviđanje (forecasting) zasnovano na stvarnom toku rada, umesto isključivo na subjektivnim procenama.
AI tu može analizirati istoriju hiljada stavki i graditi probabilističke prognoze.
Pitanje više nije: „Koliko poena mislimo da ovo vredi?“ Nego: „Kolika je verovatnoća da će ova klasa posla biti završena u narednih sedam dana?“
To je ozbiljna promena.
Kanban i AI su možda prirodniji partneri nego što izgleda
Scrum organizuje rad kroz Sprintove.
Kanban naglasak stavlja na Flow.
AI je izuzetno dobar u prepoznavanju obrazaca u velikim količinama podataka.
Zbog toga Kanban tabla budućnosti neće biti samo digitalna tabla sa kolonama To Do – In Progress – Done.
Može postati sistem koji upozorava:
-
„Code Review kolona raste 37% brže nego prethodnih nedelja.“
-
„Backend zadaci čekaju prosečno 2,4 puta duže od frontend zadataka.“
-
„Ako dodate još tri zadatka u razvoj, Cycle Time će verovatno porasti.“
-
„Ovaj tiket pokazuje obrazac sličan zadacima koji su prethodno završavali kao blokirani (Blocked).“
-
„Najveće usko grlo više nije razvoj već testiranje (QA).“
Tu AI ne zamenjuje Kanban. On ga čini analitički moćnijim.
Kanban tabla prestaje da bude fotografija sadašnjeg stanja i postaje nešto bliže real-time sistemu za rano upozoravanje.
Daily Scrum bez čitanja tiketa naglas
„Juče sam radio X. Danas ću raditi Y. Nemam blokere.“
Ako vaš Daily Scrum izgleda ovako, AI zaista može da zameni veliki deo sastanka.
I možda bi trebalo.
Status se može automatski prikupiti iz Jira-e, GitHub-a, CI/CD sistema, Slack-a i drugih izvora.
AI može pre sastanka napraviti sažetak: „Cilj sprinta (Sprint Goal) je ugrožen zbog dve blokirane stavke. Pull Request 184 čeka recenziju 19 sati. Payment API ima neuspešan integracioni test. Tri člana tima rade na zadacima koji nisu direktno povezani sa ciljem sprinta.“
Sada 15 minuta ne trošimo na petnaest statusnih izjava.
Razgovaramo o problemima.
Scrum.org je tokom 2026. upravo ovu promenu počeo otvoreno da razmatra u kontekstu Scrum timova unapređenih AI-jem (AI-augmented): Daily Scrum treba da ostane fokusiran na inspekciju napretka ka cilju sprinta i adaptaciju plana, a ne na mehaničko izveštavanje o tiketima.
To zapravo nije rušenje Scrum-a. To je povratak njegovoj originalnoj svrsi.
Scrum Master neće nestati zbog AI-ja. Loš Scrum Master možda hoće
Ako je posao Scrum Master-a:
-
zakazivanje sastanaka,
-
pravljenje zapisnika,
-
prepisivanje statusa,
-
ažuriranje tabela,
-
podsećanje ljudi na tikete,
-
generisanje izveštaja,
onda postoji problem.
Veliki deo tog posla AI može automatizovati.
Ali Scrum Guide ni ne definiše Scrum Master-a kao administrativnog sekretara tima. On je odgovoran za uspostavljanje Scrum-a i povećavanje efektivnosti tima.
To podrazumeva treniranje (coaching), uklanjanje sistemskih prepreka, facilitaciju, razvoj samoupravljanja (self-management), rad sa organizacijom i pomoć timu da bolje stvara vrednost.
To je znatno teže automatizovati.
Zanimljivo je da je i sam Scrum.org već formalno uveo Professional Scrum Master – AI Essentials, program namenjen korišćenju AI-ja u radu Scrum Master-a, Agile Coach-a, timova i organizacija. To je dobar indikator pravca u kome se profesija kreće: ne „AI umesto Scrum Master-a“, već Scrum Master koji mora da razume kako AI menja sistem rada.
Najugroženiji zato nisu dobri Scrum Master-i. Najugroženiji su ljudi čiji je posao godinama bio glumljenje agilnosti kroz administraciju Agile alata.
Product Owner dobija mnogo više informacija – i mnogo veću odgovornost
Slično važi za Product Owner-a.
AI može pomoći u: analizi feedback-a, segmentaciji zahteva, pripremi backlog stavki, identifikovanju duplikata, proceni zavisnosti, analiziranju konkurencije, generisanju kriterijuma prihvatanja, pripremi Sprint Review-a i sažimanju razgovora sa interesnim stranama (stakeholders).
Ali postoji opasna zamka.
Što AI proizvodi više analiza, lakše je stvoriti iluziju objektivnosti.
Model može reći: „Funkcionalnost A treba imati prioritet 87/100.“
Odakle 87? Koje pretpostavke stoje iza toga? Koji podaci nedostaju? Da li je istorija na kojoj je analiza zasnovana relevantna za tržište koje tek pokušavamo da osvojimo?
Preporuka generisana AI-jem nije poslovna činjenica.
Product Owner zato postaje odgovorniji za kvalitet procene (quality of judgment), a manje za fizičku proizvodnju dokumentacije.
Najveća greška: povećati brzinu (velocity) i proglasiti AI transformaciju uspešnom
Pretpostavimo da AI developerima omogući da završe 30% više implementacionog rada. Menadžment je oduševljen. Brzina (Velocity) raste.
Ali QA tim sada dobija 30% više promena.Code Review proces dobija 30% više koda.Security tim dobija više posla.Product Owner mora brže pripremati kvalitetan posao. Proces isporuke (Deployment pipeline) mora da obradi više puštanja u produkciju (releases). Korisnička podrška (Customer Support) dobija više novih funkcionalnosti koje treba da nauči.
Ako ostatak sistema nema dodatni kapacitet, nismo ubrzali organizaciju.
Samo smo premestili usko grlo.
Upravo smo ovaj fenomen detaljno analizirali na ITNetwork-u u tekstu Veštačka inteligencija je ubrzala programere, ali zašto vaš ceo tim i dalje stagnira. Individualna produktivnost i propusnost sistema (System Throughput) nisu ista stvar.
Microsoft Research dodatno pokazuje koliko kontekst utiče na rezultat. U tri terenska eksperimenta u kompanijama Microsoft, Accenture i jednoj Fortune 100 organizaciji, na ukupno 4.867 developera, pristup AI asistentu bio je povezan sa 26,08% većim brojem završenih zadataka, pri čemu su manje iskusni developeri pokazali veće dobitke.
Ali Agile optimizacija nikada nije trebalo da bude optimizacija jednog radnika. Mi optimizujemo sistem.
DORA: AI je pojačivač, a ne lek
Ovo je možda najvažnija poruka za menadžment.
Istraživanje organizacije DORA o razvoju softvera potpomognutom veštačkom inteligencijom (State of AI-assisted Software Development) opisuje AI prvenstveno kao pojačivač (Amplifier).
Drugim rečima, AI pojačava ono što već imate.
Ako imate: jasne procese, kvalitetnu dokumentaciju, dobre testove, modularnu arhitekturu, brz feedback, zdravu kulturu i sposobne timove – AI može dramatično povećati njihove mogućnosti.
Ako imate: nejasne zahteve, lošu dokumentaciju, ogromne primopredaje (handoffs), političke prioritete, neodrživ tehnički dug i kulturu u kojoj niko ne sme da prizna problem – AI neće izlečiti organizaciju.
Samo će joj omogućiti da proizvodi haos većom brzinom.
To je suština agilnog IT poslovanja u eri veštačke inteligencije.
Paradoks: AI može učiniti neagilnu kompaniju još manje agilnom
Zamislimo kompaniju u kojoj svaku veću odluku mora da odobri pet nivoa menadžmenta. Razvojni tim uz AI sada završava posao za dva dana umesto četiri.
Ali odobrenje (Approval) i dalje traje dve nedelje.
Šta smo dobili? Skoro ništa.
Ili kompaniju u kojoj AI generiše odličnu analizu feedback-a za sat vremena. Ali budžet se zaključava jednom godišnje i nema mogućnosti promene prioriteta.
Opet ništa.
Agilnost nije brzina kucanja. Agilnost je sposobnost organizacije da brzo uči i bezbedno promeni pravac na osnovu novih informacija.
AI može dramatično ubrzati učenje.
Ali ako organizacija ne može da reaguje na naučeno, tehnološka brzina nema veliki poslovni značaj.
AI menja i retrospektive – ali tu treba biti veoma oprezan
AI može analizirati prethodne sprintove i pronaći obrasce koje ljudi ne primećuju. Na primer:
-
„U šest od poslednjih osam sprintova zadaci koji zavise od infrastrukturnog tima kasnili su više od dva dana.“
-
„Pull Requestovi veći od 700 promenjenih linija imaju dvostruko duže vreme provere.“
-
„Zadaci dodati nakon trećeg dana sprinta imaju znatno veću verovatnoću da ostanu nedovršeni.“
To je korisno. Ali Retrospective nije samo analitika podataka.
Tim možda ima problem sa poverenjem. Senior možda guši inicijativu juniora. Product Owner možda ne sluša developere. Dvoje ljudi možda imaju konflikt koji se nigde ne pojavljuje u Jira-i.
AI vidi ono za šta ima podatke. Ljudski odnosi često postoje upravo u prostoru između podataka.
Zbog toga princip čoveka u petlji (Human-in-the-Loop) nije privremeni kompromis dok AI ne postane dovoljno pametan. U određenim delovima agilnog rada on predstavlja samu prirodu posla.
Project Manager neće nestati, ali projekat kojim upravlja više neće izgledati isto
Klasični projektni menadžment dugo se oslanjao na prikupljanje statusa. Ko je završio šta? Šta kasni? Koliki je budžet? Koji su rizici?
AI može automatizovati ogroman deo te informacione logistike.
Project Manager budućnosti neće biti čovek koji zna gde se nalazi svaki tiket. AI to zna bolje.
Njegova vrednost biće u donošenju odluka u uslovima neizvesnosti, pregovaranju između interesa, upravljanju interesnim stranama, razumevanju poslovnog konteksta, riziku, budžetu i posledicama odluka.
Drugim rečima: manje statusni administrator, više arhitekta odlučivanja (decision architect).
Od dešborda ka sistemu koji predviđa problem
Današnji kontrolni panel (Project Dashboard) uglavnom govori šta se već dogodilo.
Sutra može govoriti šta će se verovatno dogoditi.
To je prelazak sa deskriptivne analitike na prediktivnu analitiku.
AI može procenjivati:
-
verovatnoću probijanja roka,
-
rizik pojedinačnih zavisnosti,
-
budući WIP (rad u toku),
-
očekivani Cycle Time,
-
mogućnost preopterećenja pojedinih članova tima,
-
verovatnoću regresije,
-
potencijalno kašnjenje puštanja verzije u rad (release).
Ali ovde postoji važna granica. Predviđanje (forecast) nije činjenica. Ako sistem kaže da postoji 72% verovatnoće kašnjenja, to nije proročanstvo. To je model zasnovan na dostupnim podacima i pretpostavkama.
Loši podaci proizvode precizno formatirane loše prognoze.
Sledeća faza: AI agent ulazi u Agile tim
Do sada smo uglavnom govorili o AI-ju kao asistentu.
Ali industrija prelazi ka agentskim (Agentic) AI sistemima. Takav agent ne mora samo da predloži šta treba uraditi. Može dobiti cilj, napraviti plan, koristiti alate, izvršiti zadatak, proveriti rezultat i pokušati ponovo.
Na ITNetwork-u smo taj prelazak detaljnije analizirali u tekstu Sledeća granica razvoja softvera: Kako postati „agentic AI“ developer.
To otvara neobično pitanje: šta se događa kada tim ima pet ljudi i deset AI agenata?
Ko je član Scrum tima? Da li AI agent ima zadatak? Da li se računa u kapacitet tima (capacity)? Šta znači WIP ako agent može paralelno izvršavati deset zadataka? Ko je odgovoran kada autonomni agent donese pogrešnu odluku?
Scrum.org već otvoreno diskutuje o scenarijima u kojima deo rada obavljaju AI agenti, ali osnovni princip ostaje važan: ljudski tim zadržava odgovornost za vrednost, kvalitet, inspekciju i adaptaciju.
I to je verovatno ispravan pravac. AI može izvršavati posao. Odgovornost (Accountability) ne bi trebalo automatski delegirati algoritmu.
Jira budućnosti možda više neće biti tabla koju ljudi gledaju
Postoji još dublja promena.
Današnji agilni alati napravljeni su za ljude. Tiket ima naslov, opis, osobu zaduženu za rad (assignee), status, oznaku (label), prioritet.
Zašto? Zato što čoveku treba vizuelna reprezentacija rada.
AI agentu to možda ne treba.
Scrum.org je 2026. objavio zanimljivu analizu upravo o mogućem prelasku od Jira-e kao klasičnog alata ka arhitekturi znanja pogodnoj za AI agente. Argument je da sistemi organizovani oko „kutija“, statusa i ručnog pregledanja table nisu nužno optimalan oblik organizacije znanja za agente koji mogu analizirati obrasce kroz ogroman broj iteracija.
To može imati ogromne posledice.
Alat za upravljanje projektima budućnosti možda uopšte neće biti tabla. Biće to graf znanja (Knowledge Graph) + tok događaja (Event Stream) + sloj za AI rezonovanje (AI Reasoning Layer) iz kojeg ljudi dobijaju vizuelizaciju samo onda kada im je potrebna.
Drugim rečima, Jira tabla mogla bi postati samo korisnički interfejs nad mnogo inteligentnijim sistemom.
Razvoj specifičan za AI (AI-native) traži i AI-native Agile
Na ITNetwork-u smo već pisali o prelasku sa „piši kod“ na „opiši nameru“ i nastanku AI-native razvojnih platformi. Suština te promene jeste da čovek sve manje definiše svaki korak implementacije, a sve više definiše željeni ishod, ograničenja i kriterijume uspeha.
Ako se menja osnovna jedinica programiranja, mora se promeniti i način upravljanja radom.
Možda ćemo umesto agilnog modela usmerenog na zadatke (task-centric Agile) sve više dobijati model usmeren na nameru (intent-centric Agile).
Tim neće pitati: „Ko će implementirati ova četiri zadatka?“ Nego: „Koji ishod pokušavamo da postignemo, koje granice AI agenti imaju i kojim dokazima ćemo potvrditi da je cilj ostvaren?“
To je mnogo ozbiljnija transformacija od pukog dodavanja ChatGPT-a u Jira-u.
Kako bi mogao izgledati Scrum tim potpomognut AI-jem (AI-augmented)
Zamislimo planiranje sprinta (Sprint Planning) 2028. godine.
Pre sastanka AI analizira cilj proizvoda (Product Goal), istoriju prethodnih sprintova, povratne informacije korisnika, tehnički dug, produkcione incidente, dostupnost tima i zavisnosti.
Predlaže tri scenarija.
-
Scenario A: najveća poslovna vrednost, ali visok rizik zavisnosti (dependency risk).
-
Scenario B: nešto manja očekivana vrednost, ali 91% procenjene verovatnoće završavanja.
-
Scenario C: fokus na smanjenje tehničkog duga i stabilnost sistema.
Product Owner i tim biraju. Tokom sprinta agenti rade deo implementacije, testiranja, dokumentovanja i analize. Daily Scrum ne počinje sa „šta sam radio juče“, već sa tri anomalije koje je sistem pronašao. Sprint Review kombinuje funkcionalni inkrement (Increment) sa podacima o ponašanju korisnika. Retrospective dobija analizu obrazaca, ali ljudi diskutuju o njihovim uzrocima.
AI je svuda. Ali ključne odluke i dalje donose ljudi.
To je verovatno realističniji scenario od ideje o „AI Scrum Master-u koji vodi sve“.
Šta kompanije mogu da urade danas
Prvi korak nije kupovina deset licenci za veštačku inteligenciju. Prvo izmerite sistem.
Koliki vam je Cycle Time? Koliki je Lead Time? Gde se gomila rad u toku (WIP)? Koliko traje Code Review? Koliko zadataka se vraća na popravku? Koliko često Sprint Goal nije ostvaren? Koliko vremena ljudi troše na administraciju?
Tek onda uvedite AI tamo gde postoji jasno definisan problem.
Automatizujte zapisnike ako su zapisnici problem. Koristite AI za pročišćavanje backlog-a (Backlog Refinement) ako tim gubi sate na obradu velike količine informacija. Koristite prediktivnu analitiku ako imate dovoljno istorijskih podataka.
Ali nemojte koristiti AI da automatizujete proces koji nikada nije ni trebalo da postoji.
To je možda najvažnije pravilo: automatizovana birokratija je i dalje birokratija. Samo je brža.
Najveći rizik nije da AI uništi Agile. Već da ga pretvorimo u algoritamski mikromenadžment
AI može analizirati gotovo sve: broj commit-ova, broj završenih zadataka, vreme odgovora, pull request-ove, poruke, sastanke, vreme ciklusa svakog pojedinca.
Na prvi pogled to izgleda kao raj za menadžment.
U stvarnosti to lako može postati digitalni tejlorizam – pokušaj da se svaki aspekt intelektualnog rada kvantifikuje, nadzire i optimizuje. To bi bilo direktno suprotno duhu agilnog poslovanja.
Scrum eksplicitno insistira na samoupravljajućim (self-managing) timovima.
Ako AI koristimo da bismo ljudima rekli kada rade dovoljno brzo, koliko vremena „gube“ ili zašto developer A ima manje zadataka od developera B, nismo napravili AI-powered Agile. Napravili smo sofisticiran sistem nadzora.
A ljudi koji znaju da ih algoritam konstantno ocenjuje počinju da optimizuju tu metriku. Ne nužno i sam proizvod.
AI ne smanjuje značaj poverenja. Povećava ga
Microsoft Research je u studiji sa više od 500 developera utvrdio da se efekti AI-ja razlikuju prema kompleksnosti zadataka, obrascima korišćenja i načinu usvajanja na nivou tima. Organizaciona podrška i kolegijalno učenje (peer learning) pokazali su se ključnim za izvlačenje stvarne vrednosti iz tehnologije.
To je važna lekcija.
AI transformacija nije samo tehnološka implementacija. To je promena načina rada.
Tim mora znati: kada koristiti AI, kada mu ne verovati, šta se sme slati modelu, ko proverava rezultat, ko snosi odgovornost i šta radimo kada se AI i iskusan član tima ne slažu.
Bez toga dobijamo Shadow AI (korišćenje alata „ispod radara“), različite standarde, nekontrolisano deljenje podataka i rezultate koje niko ne može pouzdano da objasni.
Agilno IT poslovanje posle AI-ja neće biti manje ljudsko
Na prvi pogled deluje paradoksalno: što više posla automatizujemo, to važnije postaju ljudske sposobnosti koje je teško automatizovati.
Procena. Pregovaranje. Empatija. Kreativnost. Strategija. Razumevanje konteksta. Preuzimanje odgovornosti.
I sposobnost da kažemo: „Podaci govore jedno, ali postoji razlog zbog kojeg ovog puta ne treba da ih poslušamo.“
AI može pronaći obrazac. Čovek mora razumeti da li taj obrazac nešto znači.
Šta nas verovatno čeka do 2030.
Ako se sadašnji pravac razvoja nastavi, granica između softvera za vođenje projekata, razvojne platforme i AI sistema postaće sve manje jasna.
-
Backlog neće biti samo lista – biće dinamički model prioriteta.
-
Kanban tabla neće samo prikazivati Flow – predviđaće njegovo buduće stanje.
-
Sprint Planning neće biti samo procena – biće simulacija mogućih scenarija.
-
Retrospektive neće počinjati praznom tablom – AI će unapred izdvojiti anomalije i obrasce.
-
Project Manager neće juriti ljude za status – sistem će znati status pre njega.
-
Scrum Master neće trošiti vreme na administraciju ceremonija – baviće se efektivnošću sistema i ljudi.
-
Product Owner neće ručno pretvarati stotine zahteva u backlog – baviće se pitanjem koje nijedan LLM ne može rešiti: Šta zaista treba napraviti i zašto?
Developeri će sve manje vremena provoditi kao neposredni izvršioci svakog tehničkog koraka, a sve više kao arhitekte, evaluatori i orkestratori inteligentnih sistema.
To ne znači kraj agilnog pristupa. Možda upravo suprotno.
AI će konačno pokazati ko je zaista agilan
Godinama je bilo moguće izgledati agilno: imati Scrum Master-a, imati Jira-u, raditi sprintove, meriti Velocity, organizovati retrospektive – i istovremeno čekati tri nedelje na odluku direktora.
AI tu kontradikciju čini sve očiglednijom. Kada tehničko izvršavanje postane mnogo brže, organizaciona sporost postaje vidljivija.
Ako AI napravi prototip za jedan dan, a kompaniji trebaju četiri nedelje da odluči da li želi da ga testira, problem nije AI.
