Качество процесса напрямую зависит от качества используемых в процессе артефактов.

У вас может быть прекрасная диаграмма, показывающая как цели текут в продуктовые требования, которые в свою очередь текут в разработку для создания архитектуры, а два раза в месяц у вас красивое демо, отчет для стейкхолдеров и команда с картинки в интернете, раздающая друг другу "пять" под восторженные крики пользователей.

На деле нам нужны:

• Цели, основанные на анализе, с однозначной формулировкой и понятным definition of done.
• Продуктовые требования, идеально рассказывающие зачем мы делаем то, что делаем, кому это нужно, сколько они готовы платить, user stories, CUJs (Critical User Journey), описывающие все функциональные и нефункциональные требования, а также подкрепляющие всё вышесказанное данными в приложениях.
• Архитектура, которая рассматривает различные варианты решения проблемы, в том числе неочевидные. Которая говорит "вы нас попросили вот так, но если мы сделаем по-другому, то будет ещё лучше".
• Культура планирования инкрементов, коммита на результат и ритм спринтов, совпадающий с ритмом отчетности руководству.

Вот. Если бы не вот это вот всё, можно было бы любой процесс насадить на любую команду.

Но процесс – это не про ромбики и стрелочки в диаграме.

Это про задротство по качеству артефактов и под-процессов на уровень глубже квадратиков в диаграмме.

Это про обратную связь и тюнинг процесса.

Это про организационные ритмы.

Это в том числе про отношения между людьми, хотя плохой процесс 100% сделает отношения еще хуже, а хороший процесс наладит отношения даже между Монтекки и Капулетти.

Короче, не так всё просто, как учат в буткемпах и книжках по проектному управлению.