1. у нас не было инструмента
2. это надо запланировать
3. у задачи был низкий приоритет
4. не было команды это делать
5. сделано ровно то, о чём просили
6. если скажут сделать, то сделаем
7. мы работаем
8. мы всегда так делали
9. ничего не знаю. письма не было

надеюсь, не надо пояснять, что в нашей организации такое не приветствуется. но замечать — замечаем.

ps. картинка «кликабельна»

1. Планирование не имеет никакого смысла, т.к. реальная жизнь все-равно расходится с любыми планами.
2. Максимально длинные итерации. Нет абсолютно никакого смысла пичкать пользователя частыми релизами с незначительными изменениями. Так пользователь не будет видеть никакого движения вперед. Если и выпускать релиз, то ого-го какой, чтобы все видели что функционал растет! Поэтому не скупитесь на время подготовки релиза, добавляйте туда новые фичи пока они не кончатся.
3. Ограничение общения с пользователями. Посудите сами, откуда обычной домохозяйке (ну или инженеру) знать как должен работать ваш продукт. Пользователи окончательно запутают вас своими глупыми и бессмысленными просьбами, отнимая ваше драгоценное время. Разработчик лучше всех знает, каким должен получиться продукт.
4. Не стоит ограничивать рабочее время разработчика. Работать нужно в экстремальном режиме, до тех пор пока есть физические силы. Так будет написан больший объем кода и пользователи увидят, что качество продукта и его функционал растет. Идеальный вариант — это семидневная рабочая неделя. Отпуски крайне не приветствуются, так как разработчик забывает различные детали реализации и ему потребуется время, чтобы входить в курс дела заново.
5. Каждый разработчик должен работать исключительно со своей задачей, не забивая себе голову чужими проблемами. Это правило не допустит рассредоточения внимания и позволит выполнить работу в намеченные сроки. Золотое правило: одна задача — один разработчик. Это правило поможет выполнить максимальное число задач, равное числу разработчиков.
6. Недопустимо использование subversion. Каждый разработчик должен сам заботиться  о своих исходниках, хранить их у себя и никому не показывать, т.к. обязательно кто-нибудь испортит ваш драгоценный код.
7. Новый функционал превыше всего. Багам не стоит уделять особого внимания, т.к. их мало кто замечает. А новую фичу заметят все!

С помощью таких вот нехитрых правил вы сможете повысить продуктивность и качество продукта на порядок. Удачи, друзья =))