Можно сказать, что на данный момент самый распространенный подход в гибкой адаптивной разработке продуктов - Scrum. Одна из ролей в Scrum - собственно Scrum-мастер. Роль, в зоне ответственности которой лежит обучение команды, правильная настройка процессов в команде, выявление и устранение препятствий в работе.
Если руководство и команда не обладают опытом в работе по Scrum, можно ли понять вообще, чем на практике должен заниматься Scrum-мастер, эффективно ли он выполняет свою работу?

Руководители проектов часто игнорируют правильное завершение проекта, считая этот процесс не слишком важным. Или не видя, чем он может быть полезен в дальнейшей работе.

В PMBoK этому процессу уделено всего пару абзацев текста, и в данной группе процессов есть собственно только один процесс - закрытие проекта или фазы.

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

Фрейморк Scrum в представлении не нуждается, и его преимущества многократно описаны. Однако о недостатках подхода говорят реже, и успешно применять его получается далеко не у всех. Зачастую после первых неудач команда разочаровывается в подходе и начинает считать его полностью бесполезной пустышкой. Но может быть дело не в самом Скраме, а в том, где и как его применили?

Попробуем рассмотреть, какие есть ограничения и допущения в применимости этого подхода, какие риски и предварительные условия нужно учесть.

Стоит ли команде тратить время на постановку цели спринта при работе по Scrum, и какой в этом вообще смысл?

Перевод статьи Лукаса Ф. Косты "Why your daily stand-ups don't work and how to fix them" с некоторыми размышлениями переводчика (выделены курсивом).

Ежедневные стендапы — классический пример выученной беспомощности. Мы все знаем, что они отстой. Тем не менее, мы ничего с этим не делаем. В наши дни мы проводим стендапы потому что нам так говорят, а не потому что они решают какие-то конкретные проблемы.