Гъвкавата разработка е подход към изграждането на софтуер, който предоставя работа в кратки итерации, включва непрекъсната обратна връзка и адаптира плановете с подобряването на разбирането. Той е формулиран в Agile манифеста през 2001 г., който посочва четири ценностни предпочитания: индивиди и взаимодействия пред процеси и инструменти, работещ софтуер пред изчерпателна документация, сътрудничество с клиенти пред договаряне на договори и реагиране на промени пред следване на план.
Формулировката на манифеста често се цитира погрешно по важен начин. Всяко твърдение изразява предпочитание между две неща, като и двете имат стойност, а не отхвърляне на второто. Документът изрично казва, че макар елементите отдясно да имат стойност, елементите отляво се ценят повече. Приложенията, които тълкуват манифеста като забраняващ документирането, планирането или договорите, са отхвърлили половината от това, което се казва в него, и обикновено водят до безпорядъка, който критиците приписват на самия подход.
Основната обосновка е свързана с несигурността. Последователното разработване предполага, че изискванията могат да бъдат точно определени предварително, което е валидно за добре разбрани проблеми и не е валидно за продукти, чиято стойност зависи от това как хората реагират на тях. Итеративната доставка намалява цената на грешките, като скъсява интервала между решението и доказателствата за него, което е ценно пропорционално на това колко несигурен е проблемът.
Най-често срещаният неуспех на практика е приемането на церемониите без принципите. Организациите въвеждат ежедневни срещи, граници на итерациите и практики за оценка, като същевременно запазват фиксиран обхват, фиксирани срокове, годишно планиране и липса на механизъм за действие въз основа на обратна връзка. Резултатът е последователно развитие, провеждано в двуседмични сегменти с допълнителни срещи, което е по-бавно от правилното прилагане на двата подхода и води до широко разпространен скептицизъм относно методологията.
Елементът за сътрудничество с клиентите е този, който организациите намират за най-труден и най-често пропускат. Адаптирането към обратната връзка изисква действително получаване на обратна връзка, което означава реални потребители да взаимодействат редовно с работещ софтуер. Екипите, работещи на базата на заместител, независимо дали е вътрешен заинтересован участник или писмена спецификация, имат честота на итерациите без входа, който им придава цел, и те итерират уверено в посока, която никой не е валидирал.
Мащабирането въвежда истинска трудност, която първоначалната формулировка не е адресирала, тъй като манифестът е написан с мисъл за малки, съвместно разположени екипи. Координирането на много екипи по един продукт изисква механизми за съгласуване, управление на зависимостите и архитектурна съгласуваност, а различните рамки за мащабиране, които се справят с това, често са критикувани за повторното въвеждане на теглото на процеса, което подходът е целял да намали. Напрежението е реално, а не е неразбиране.
Оценката трябва да се фокусира върху резултатите, а не върху придържането. Подходящите въпроси са дали времето от идеята до валидираното обучение се е съкратило, дали екипът може да промени посоката, когато доказателствата го налагат, дали качеството се поддържа, а не се губи поради крайни срокове, и дали продуктът е измеримо по-добър за потребителите. Екипите, изпълняващи всяка предписана практика, като същевременно ежегодно доставят продукти по фиксирана спецификация, са възприели речника, но не и ползата.
Тъй като подходът зависи както от организационните условия, така и от екипната практика, приемането му често изисква промени в управлението, финансирането и планирането, които са извън екипа за изпълнение. На практика това се решава в рамките на... разработване на продукти наред със самия процес на доставка, като обратната връзка се поддържа от потребителски изследванияи организациите, които изграждат капацитета вътрешно, обикновено го установяват в рамките на продуктов отдел където планирането и отчетността за изпълнението са съчетани.