Agilne metode - Prava stvar ili svinjarija

Problem kod agilnih metoda je što u većini slučajeva (barem kod nas) se to forsira da se bude "cool", a uvede se daily standup koji se odradi tako da nikome ne služi.

Agilne tehnike ti neće pomoći da napraviš bolji proizvod i vrlo vjerojatno, osim ako ne radiš nešto 100% in-house ili u potpunosti vlastiti proizvod, nećeš ih moći u potpunosti implementirati već ćeš morati se prilagođavati klijentu (pr. scrum under waterfall). Također, kao i sve dobre (moderne) prakse softverskog inžinjeringa (pr. code coverge, static analysis, code review, pair programming, DDD, DevOps, 3C,...) iziskuje vrijeme, trening i volju da ga se kako spada uvede (čitaj: novac).

To rečeno, Agilne metode donose i te kako benefite ako ništa drugo jer alternativa je najčešće ad-hoc managiranje tima. Krenimo samo od toga da je to više-manje industrijski standard (uz DevOps i vertikalne/full-stack timove) u razvoju softvera kada gledamo organizaciju i ustroj timova. 
Agilne metode neće ocijediti radnika kao limun, već će smanjiti stres i neizvjesnost na projektu (radnika ćeš cijediti ti bio na agilnim tehnikama ili ne - to je čisto do project managementa i jel se resursi na projektu alociraju realno ili "šampionski").
S druge pak strane, agilne metode uvode neke aspekte koje primoraju ljude da kontinuirano daju feedback i tu se stvara najveći otpor prema uvođenju agilnih metoda (čim ja moram reći što sam napravio u zadnja 24 sata, to kod nekih već stvara pressing).

No da skratim

Daily meeting je super stvar da svi znamo gdje tim stoji i da što ranije riješimo probleme ukoliko ih imamo.

Sprint je super stvar jer možemo daleko precizniji biti kod planninga manjih vremenskih intervala, a treba se gledati da je sprint logički organiziran (taj "brže se vide rezultati").

Retrospektiva je super jer kontinuirano se poboljšava tim i postaje sve efikasniji i efikasniji.
Definiranje Epica - Storyjica - Taskova - Subtaskova - PBI ili kako se već organiziramo je odlično za uklanjanje bilo kakvih nejasnoća i efektivno možeš dati bilo kojem developeru (pod ovo mislim junior - senior) da bilo što odradi.

Swimlineovi i board daju u svakom trenutku overview gdje smo i da li smo u vremenskom okviru ili možda negdje "curi".
Scrum master / Product owner, ukoliko se te uloge daju ljudima koji ih znaju kako spada raditi, nevjerojatno olakšavaju rad developeru.

Isto tako, što po mojem mišljenju jako puno ljudi totalno promaši koji prakticiraju agile, - to je framework, ne biblija uklesana u kamen i kao takav se treba prilagoditi timu / odjelu / firmi u koji se uvodi. Jako puno puta sam čuo da se probao uvesti ali se odustalo zbog rigidnog slijeđenja nekog artifakta ili ceremonije koji je stvarno bio za njih "šaka u glavu".
Primjerice, ako se mene pita ja iz svog iskustva smatram da Scrum Master treba biti osoba koja u tradicionalnijim timovima nosi ulogu Team Leada. Hard core pure scrumovci bi me udavili zbog ove izjave. Treba se shvatiti da u nekim timovima to tako najbolje funkcionira, dok kod drugih mora se radtiti separacija između "jednakijeg među jednakima" i Scrum Mastera.