Компания переходит от предиктивного подхода к гибкому. В последних двух обзорах спринта владелец продукта заявил, что инкременты не соответствуют критериям приемки, в то время как команда разработчиков заявила, что элементы бэклога не могут быть доставлены в согласованные двухнедельные спринты. Как руководитель-слуга, как менеджер проекта должен решить эту проблему?

Правильный ответ — поощрять всю команду быть уполномоченной и ответственной за решения, принимаемые в соответствии с их ролями. В гибкой среде, особенно при переходе, важно развивать самоорганизацию и кросс-функциональность. Менеджер проекта как лидер-слуга должен способствовать сотрудничеству и разрешению проблем внутри команды, а не диктовать решения. Команда и владелец продукта должны совместно определить корень проблемы (реалистичность оценки, ясность требований, объем работы) и найти решение, соответствующее принципам гибкой разработки. Продление спринтов до 3 недель может временно решить проблему, но не устраняет ее причину и противоречит принципам коротких итераций. Использование следующего спринта для устранения технической задолженности важно, но это лишь один из возможных шагов, а не комплексное решение проблемы расхождения ожиданий и возможностей. Проверка OPA менее актуальна в гибкой среде, где акцент делается на адаптивность и текущее решение проблем командой.