Ещё одна интересная статья поднимающая важные вопросы из области агильного программирования: "Bad attitudes of Agile".

Во первых это всеобщая уверенность в всесильность самоорганизации которая ведёт нас часто к убеждению что менеджеры нас абсолютно больше не нужны. Безусловно, самоорганизация является неотъемлимой частью практики и условием для её применения, но это не даёт нам право говорить о том, что менеджер является абсолютно не нужным балластом в организации  который получает бонусы от работы нас, несчастных практиков, разработчиков програмного обеспечения. Пусть даже в агильном проекте у нас будет кто-то без официального названия менеджер, все равно следующие роли просто необходимо выполнять:
1. Роль лидера проекта. Кто то должен прочетить в общих чертах проект, что мы делаем, как мы делаем, помогать приходить к общему знаменателю в споре и поддерживать команду в трудные времена.
2. Административная роль. Все мы хотим буть самоорганизующимися, но через мгновения мы говорим, "Эй, я программист, и именно этим я хочу заниматься. Почему я должен заказывать воду, организовывать собрания или делать заметки в течении собрания?" или "Бюджет? Да за кого вы меня принимаете? Что, доходность.... ?"

Во вторых. Итеративный принцип разработки программного беспечения часто ведёт к убеждённости, что в проекте нет сроков выпуска - "Ну, мы сдадим проект сразу же после того как всё допишем. Когда? Ну откуда мы знаем как вы будете устанавливать приоритеты или какая обратная связь будет приходить. Сорри - no comments". Всё это мы делаем не смотря на то, что очевидно проект имеет определённый бюджет, определённых клиентов которые заинтересованы узнать предпологаемую функциональность, а так же сроки сдачи проекта, чтобы составить свои планы и так далее. Тот факт, что начальные итерации как правило являются не готовыми к выпуску легко позволяют нам забыть, что общее правило по прежнему гласить, что в конце каждой итерации мы должны иметь продукт готовый к выпуску, и мы говорим "сроков нет" вместо того, что бы сказать "срок примерно такой то, но содержание может варьироваться в опеределённых рамках"

И наконец лозунги "все равны в проекте" и "никаких документов" на сегодняшний момент явно переоценены. В силу особенностей разработки, мы не можем получить готовое описание продукта в начале работы, так как мы не знаем как будут меняться приоритеты в ходе работы и каковы будут отзывы от руководства и клиентов которые принудят нас что-то менять в планах. Но это совсем не значит, что мы не должны фиксировать наши решения сделанные в процессе планирование каждой итерации и разработки. В противном случае ни тестеры, ни мы сами через определённое время не будем знать - как работают те или иные функции и, главное, почему именно так (кто и в силу чего решил). Не говоря уже о клиентах которых многие оставляют просто один на один с продуктом без описания функциональности.

Что касается всеобщной равности в проекте - это уже было и называется социализмом или ... На практике всё это трансформируется в лозунг "все равны, но некоторые равнее". А именно есть более и менее востребованные ресурсы. В нашем плане умения разработчика проекта как правило встречается на порядок реже нежели тестера, а поэтому такие ресурсы просто не рационально иногда использовать не по назначению, хотя безусловно и как тестеры они тоже приобретают полезный опыт. Всё таки нам нужна группа людей, которая будет заниматься тестированием как текущей итерации, так и уже выпущенных с целью гарантирования качества конечного продукта.