Вот нашел еще такую ссылочку:
http://bradapp.blogspot.com/2006/07/agile-cmmi-and-dancing-elephants.html

Что следующее?? Agile Waterfall?

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

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

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

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

Ох, по-моему такие аналогии очень редко хорошо работают. Между коммуной и Agile-командой есть большая разница - размер.

Построить "коммунизм" внутри группы из 6 человек возможно. Разница в том, что коммунизм в смысле "от каждого по возможностям, каждому по потребностям" возможен, когда обеспечивается полная прозрачность.

Давайте тогда аналогию с семьей проводить? :-)
Вы уже перешли на товарно-денежные отношения внутри семьи? Сколько вы платите жене за ее труд? Вы уже заключили с ребенком договор о долгосрочных инвестициях?

Ох, по-моему такие аналогии очень редко хорошо работают.

Аналогии могут быть многоаспектными, я ведь прямо указал на тот аспект деятельности (целеполагание и управление достижением цели) применительно к которым интересно было бы проследить сходство и различие проблем в сравниваемых областях. Т.е. если уж говорить о том, как аналогии должны "работать" то ИМХО представляет смысл рассматривать схожие проблемы в отдельных практиках, и смотреть какие решения применялись для этих проблем. Может быть и для проблемы аналогичной практики найдется решение. По аналогии .
А обосновывать преимущества капитализма и теории товарно-денежных отношений в качестве методологии управления проектами (и семейными отношениями ) в противопоставлении Agile я совсем не собирался. Более того, с большой симпатией и уважением отношусь к Вашей подвижнической деятельности на ниве Agile и желаю Вам всяческих успехов . Но тему границ возможности успешного применения Agile  полагаю важной для успешного применения практики Agile как таковой, а также для дальнейшего развития ИТ-методологий. В том числе путем создания разнообразных "гибридных" практик, что и было исходной темой данного обсуждения.

Небольшое замечание и информация... Один из "проповедников" Agile CMM (http://www.agilecmmi.com/) сейчас принимает участие в североамериканской SEPG - конференции по "совершенствованиям процессов" (информация о конференции на http://www.sei.cmu.edu/sepg/2008/ и чуть-чуть на http://russian-sla.livejournal.com/). И там он выступил с презентацией, в которой в конце есть простые выводы, которые и говорят о том, что и практики CMMI можно реализовать при помощи "агильных" подходов.
Я к тому, что частенько CMMI и Agile представляются настолько антогонистичными, что при это абсолютно утрачивается понимание и того и другого.

Где можно взять текст доклада или данную презентацию?

Посто помнится совместная презентация Асхата Уразбаева и Стаса Калканова на SECR и они сошлись на том, что     
Agile и CMMI не совместимы.

Посто помнится совместная презентация Асхата Уразбаева и Стаса Калканова на SECR и они сошлись на том, что     
Agile и CMMI не совместимы.

Скрестить можно хоть ежа с ужом. Только сделать с результатом ничего нельзя. Я просто не вижу ни одной нормальной причины смешивать это в кучу.

Практики CMMI могут работать на уровне организации, причем крупной. На уровень проекта (особенно небольшого!) их нельзя пускать, они деструктивны.

И кстати, вам любой апологет CMMI скажет, что это потому что никто не умеет CMMI готовить. Типа это трудно. Ну и начерта нужна вещь, которую трудно делать?

Попробую ответить всем сразу.

To bas: презентация Hill Glazer получаема по по ссылке http://www.agilecmmi.com/glazer_1061.pdf. Презентация Асхата и Стаса на SEC(R) - http://www.secr.ru/etc/2_day_10_20_-_kalkanov_s__urazbaev_a.pdf.

To Askhat:
Почему-то всегда упорно понимаются под CMMI самые тяжеловесные варианты внедрения этой модели! Тем более - они часто трактуются исходя из личного опыта работы в той или иной организации, где как раз внедрялся тяжелый вариант. При чем внедрялся для сертификата.

Реально - могут сосуществовать и CMMI (на уровне "что") и Agile-практики (на уровне "как"). Более того, ничто не отрицает возможности существования одной "реализации" CMMI (назовем ее "классической") для одного вида проектов и другой ("Agile-ориентированной") для других проектов.

По поводу "трудно"... Это только вопрос желания обучиться и понять. И такой подход относится не только к CMMI. Agile-методам тоже надо обучиться и их тоже надо понять (вот неожиданность-то, а!). Довелось насмотреться уже таких "агильных реализаций", когда тот же SCRUM представлялся чем-то вроде группы детского сада, оставленной воспитателем на день без присмотра. Что приводило к тому, что среди "детей" начиналась драка за "лучшую игрушку", за "лидерство" и т.п. И вот потом возвращался "воспитатель" и достаточно громко ужасался. И говорил: "да чтоб я еще вас оставил!".

Трудно делать то, что не нужно и не подходит. Трудно делать то, в чем имеешь поверхностное понимание. И это не зависит от того, какие буквы применять - CMMI, Agile и т.п.