Когда топ-менеджеры узнают про SCRUM (или думают в очередной раз о нем), то часто по сути отказываются от него, т.к. не готовы работать без менеджера: его в скраме нет, эта роль заменяется 2мя ролями: Product Owner и Scrum Master.

И вопрос звучит как-то так: к кому предъявлять претензии, если проект провалится?

Давайте попробуем на него ответить:

  1. SRUM про продукт, а не про проект. При использовании SCRUM для проектов эту специфику скрывает в себе Product Owner. По умолчанию он ответственен.
  2. Если делали не то, если много переделывали или долго ждали уточнений – к Product Owner.
  3. Если в команде проблемы – люди увольняются, демотивированы, нет инициативы, нет прозрачности что происходит (срываются daily, а тем более спринты) – это это к Scrum Master.
  4. Если выяснилось, что конкретный программист не тянет и нет его обучения – то это к руководителю отдела из которого взяли программиста для команды. Да, все еще матричная схема подчинения (руководитель отдела и проект/команда).
  5. Если ошибка в сроках, то это неизбежно. Шутка. Нужно анализировать, смотреть первоначальные оценки, сколько было запаса, куда он ушел (новые задачи, проблемы с кадрами (увольнения и найм), уровень ошибок и т.п.). Обычно команда оценивает задачи где-то на 1-2 спринта вперед. Поэтому сроки – опять же к Product Owner (и его команде – архитектору, аналитикам и т.п.).
  6. В самом Scrum нет ничего про качество. В частности, про проектирование и технические политики. По нему это часть DoD. По факту же это кто-то должен делать: на уровне компании, подразделения, и/или проекта. Если пустить на самотек, то чем дальше по ходу разработки, тем больше проблем будет (определение плохой архитектуры).

И самое главное:

Не нужно ждать провала проекта: нужно серьезно подходить к результатам каждого спринта (а спринт желательно не 2 недели и больше, а одну неделю). Скрам дает потрясающую прозрачность работы команды: сборка каждый спринт, история velocity, возможность дать отзыв на сборку, улучшения в работе команды и т.п. , но это все можно игнорировать и “проснуться” уже только в конце, когда уже нет пространства что-то исправлять. Не надо так.

Другими словами, если есть проект, то остается руководитель проекта. И с него спрос. Другое дело, что часто еще есть Технический Менеджер, который отвечает за технические аспекты. По сути что-то похожее на разделение Product Owner / Scrum Master: понятно, что разделение другое, но видно, что это не что-то, чего раньше не было.