Вечные вопросы scrum-мастеров

Всем привет!

Недавно я открыл для себя Linkedin-группу "Scrum Practitioners" и  благодаря этому стал свидетелем и участником интереснейших дискуссий! Две из них меня заинтересовали особенно:

1. Как заставить Product Owner не вставлять новые задачи в середине спринта?
2. Что делать с человеком, постоянно опаздывающим на дейли-стендапы?

Оба эти вопроса интересны тем, что они связаны фактически с менеджментом в процессе, где менеджера нет :) И оба эти вопроса направлены на сохранение scrum-процесса, где PO не лезет к команде во время спринта, а вся команда дружно собирается на дейли стендапы.
При этом значительная часть участников этих дискуссий грешат догматическими и безапелляционными суждениями, такими как "PO не должен...отказать..." или "штрафовать...заставить носить кроличьи ушки...". Увы, но то, что многие из нас получили свой CSM сертификат так и не сделало нас гибкими. Мы просто получили новую игрушку - новый процесс, и теперь старательно его охраняем от любых изменений.
Но ведь одна из главных вещей, которые мы должны понять - это то, что изменения случаются, что изменения - это данность и зачастую - просто необходимость. И касается это как требований к продукту, так и самого процесса разработки. Мы должны научиться спокойно встречать новые изменения или неожиданные события и в первую очередь задать себе и окружающим вопрос - "Почему?" и быть готовы принять и "обработать" ответ, быть готовы изменить что-то в продукте и в процессе после этого.

Например, product owner все время втыкает нам новые фичи в середине спринта. Казалось бы - предать его анафеме, а лучше выпороть за нарушение scrum-процесса. Но ведь он почему-то это делает? Причин может быть множество - от недоученности PO (ну не представляет он себе последствий этого действия) до реальных бизнес/технических причин (высокая изменчивость требований, например). И по-настоящему агильные люди в такой ситуации никогда не будут бросаться в бой с "врагами скрама" не выяснив причины подобного поведения, не задумавшись о том, насколько эта причина весома для PO, для бизнеса, для команды, не попытавшись взглянуть на свой процесс со стороны... ведь вполне может оказаться, что нам ничего не стоит сделать итерации короче - это только сделает нас еще гибче и позволит нам победить не таких гибких конкурентов (а они есть всегда - поверьте).
Кстати, часто в такой ситуации достаточно просто поставить такую задачу в product backlog на самую вершину - при достаточно коротких итерациях это и так приведет к тому, что мы ее сделаем достаточно скоро, что бы сделать PO счастливым.

Ситуация с опаздывающими на daily scrum на самом деле очень похожа. У нас опять есть человек, сознательно или несознательно нарушающий наш замечательный скрам-процесс. И вопрос - "почему так происходит?" должен быть задан в первую очередь - а вовсе не "что с этим козлом делать?". Вполне может оказаться, что время для дейли скрама выбрано неудачное, а опаздывающий коллега был слишком скромен, что бы сказать, что для него оно неудобно, а может у него сейчас есть какие-то сложности, с которыми ему можно помочь?

А теперь внимание - кому приходится решать обе эти проблемы? Кто должен разобраться с причинами, задуматься об их обоснованности и предложить команде изменение процесса, если это нужно? Тарарарам! Scrum-Master! Ой, а как же? Мы же все тут с красивыми сертификатами от Scrum Alliance! Почему при этом мы продолжаем нести такую ересь?

Получается, что Scrum Alliance научился выдавать CSM-сертификаты, так и не научившись обучать скрам-мастеров. И учимся мы, горемычные, друг у друга, у психологов, у менеджеров (спаси Господи), у коучей... и знаете, чем дальше, тем больше мне кажется, что Scrum-мастер, придуманные Scrum-альянсом не более чем вымышленный персонаж из романа-утопии. А мы почему-то продолжаем в него верить...

Может уже хватит?