Когда я рассказал эту историю на встрече скрам-мастеров в Милане в июне 2003 года, Мел Пуллен отметил, что считает практику скрама скрамов противоречащей принципам самоорганизации и самоуправления скрама. Иерархические структуры навязаны руководством, утверждал Мел, а не теми, кто фактически выполняет работу. Почему бы не дать каждой команде выяснить, с какими другими командами нужно сотрудничать и координировать работу и где команды зависимы? Либо скрам-мастер сможет указать на зависимость от другой команды, либо команда разработки сама столкнется с зависимостью в процессе работы. Наткнувшись на зависимость, команда может отправить участника в качестве «цыпленка» на ежедневный скрам другой команды, работающей над зависимостью. Если никто не работает над этой зависимостью, команда может попросить владельца продукта создать соответствующий элемент бэклога продукта с высоким приоритетом. Скрам-мастер может либо позволить первой команде самостоятельно решить проблему зависимости, либо помочь сформировать другую команду для этого.

Это интересное замечание. Скрам основывается на самоорганизации, простых правилах и рекомендациях. Какой вариант больше подходит для координации и масштабирования проектов – примененный Джеком скрам скрамов или предложенное Мелом самостоятельное устранение зависимостей командой? Я пробовал оба и пришел к выводу, что правильное решение зависит от комплексности ситуации. Когда комплексность велика настолько, что самоорганизация не происходит достаточно быстро, простые правила помогают организации достичь своевременного решения. Но если самоорганизация происходит своевременно, я предпочитаю полагаться на нее, потому что руководство вряд ли сможет предлагать адаптации так же часто и хорошо, как это может делать команда. Иногда скрам-мастер может помочь самоорганизации, предложив несколько простых правил, однако в этом случае скрам-мастеру полезнее недоделать, чем переусердствовать.