Мы не работаем по Scrum

И по Kanban тоже.

Хотя используем и то, и другое.

Чем дольше работаешь с командами, тем меньше хочется выбирать одну «правильную» методологию и пытаться натянуть её на всю компанию.

Scrum, Kanban, Waterfall, PMBOK, LeSS, SAFe — всё это полезно знать.

Но для меня это скорее ящик с инструментами, чем инструкция, которую нужно выполнить от первой страницы до последней.

Есть проблема — выбираем подходящий инструмент.

У команды постоянно 15 задач одновременно?

Берём из Kanban WIP-лимиты и ограничиваем количество работы в процессе.

Каждый день прилетает что-то «срочное»?

Берём классы обслуживания:

Expedite — упали платежи, разбираемся сейчас. Fixed Date — интеграция должна выйти к конкретной дате. Standard — обычный продуктовый поток. Intangible — архитектура, рефакторинг и техдолг, которые без отдельного внимания почему-то всегда становятся «не сейчас».

Нужно регулярно показывать результат и корректировать направление?

Берём из Scrum короткий цикл планирования, цель спринта, review и retrospective.

Большой проект с кучей зависимостей, бюджетом и несколькими стейкхолдерами?

Можно взять из PMBOK управление рисками, зависимостями и коммуникациями.

Есть работа, где этапы действительно должны идти последовательно?

Ничего страшного не произойдёт, если часть процесса будет похожа на Waterfall.

Стало десять команд и они начинают мешать друг другу?

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

В итоге процесс может выглядеть странно: Scrum + Kanban + кусок PMBOK + несколько собственных правил.

И это нормально.

Я бы даже сказал, что хуже другая ситуация.

Когда команда выполняет все церемонии Scrum, но сроки продолжают ехать.

Когда есть Kanban-доска, но одновременно в работе 40 задач.

Когда проводится ретро каждую вторую пятницу, но одна и та же проблема обсуждается уже полгода.

Формально методология есть. Управления нет.

Поэтому для меня порядок такой: Сначала проблема. Потом практика. Потом процесс.

А не наоборот.

Методологии стоит изучать не для того, чтобы однажды выбрать «правильную».

А чтобы в нужный момент понимать, какой инструмент достать из ящика.