Фреймворк скрам не работает потому, что люди не выполняют его правила.

Частая проблема? Думаю что каждый раз, когда кто-то пробует применить скрам, это происходит. Скрам-но, даже термин такой есть. Дискуссии как правило ведутся вокруг причин и советов что делать, чтобы заставить людей исполнять правила. Я и сам пару лет этим страдал. Все это усугубляется тем, что любые правила можно обойти, формально их выполняя. То есть команда или PO сохраняют статус кво, доказывая скрам-мастеру, что это не противоречит скраму.

Например, в команде из 5 человек есть бизнес-аналитик, который до запуска скрам-команды писал BRD. Теперь он продолжает весь спринт собирать со стейкхолдеров требования и писать BRD для будущих спринтов, а за приоритетами по ним он бегает к PO. На это у него уходит ровно половина его времени. Ещё половина уходит на беготню между PO и командой по требованиям из бэклога текущего спринта.

Формально правила скрама нарушаются лишь косвенно в части командной ответственности и "no titles". Серьезные нарушения происходят по ценностям и принципам аджайл. А именно:

Извечные два вопроса, первый из которых - кто виноват? Конечно, неправильные пчелы (PO и команда разработчиков, включая бизнес-аналитика), которые делают неправильный мед. И поэтому ответ на второй вопрос: хитрые приемы фасилитации, неоспоримые аргументы, деловые игры, покажи им зеркало, и даже грубая сила в виде каких-либо санкций - все для того, чтобы убедить людей делать то, что они делать не хотят. Результат грустный - скрам-мастера увольняют либо сразу за скрам-фашизм, либо позже за то, что желаемой бизнес-эффективности от скрама нет и не было.

Давайте ещё раз попробуем ответить на извечных два вопроса. Существующая система управления в организации не даёт людям выполнять правила. И совершенно глупо надеяться, что вся компания сразу же встанет на сторону скрам-мастера, и будет менять ее. По закону нормального распределения таких новаторов будет от силы 10-15%. Столько же будет ярых противников. И оставшиеся 70-80% будут молчаливыми наблюдателями, потому что им плюс-минус норм.

Люди месяцами и даже годами работали под руководством функциональных менеджеров, kpi которых замыкает их ответственность на отдельную функцию. Владельцу продукта в лучшем случае спустили ответственность за управленческий учёт по продукту, вдобавок к уже давно существующим kpi в эксплуатации бизнеса. На последнее я бы даже не надеялся))

Предлагаю вам сейчас это тихонько осознать. Что вы, как скрам-мастер, сражаетесь не с командой в 6 человек, а громадной махиной, которая не хочет инноваций. Ей хочется просто быть, сохраниться как вид. Для организации в лице каждого ее сотрудника выжить - значит сохранить себя со всеми потрохами. Они так инстинктивно действуют. Раз бизнес есть, значит когда то успешно была найдена практика зарабатывания денег в конкретном сегменте рынка. Уверен, что компании это далось совсем непросто. Кризис, присущий старту любого бизнеса, выжег на организации систему управления как клеймо залога успеха.

И вам предстоит ЭТО менять. Сверху-донизу. И чтобы добиться в этом нелёгком деле хоть какой-то эффективности, надо превратиться из полицейского в садовника. В этом случае, скрам-мастер тоже подмечает и использует нарушения правил. Но не как плетку, а как индикатор эффективности своей работы. Команда перестанет нарушать правила, когда исчезнет причина (rigid в организации).

Сначала посадка растений. Это ответ на вопрос "зачем?". Предстоит сходить на самый верх, и найти того, кому действительно нужны инновации, которые делают скрам-команды. И здесь же первая отсечка - если потребность в инновациях не найдена, то не надо впаривать скрам. Идем работать в другое место.

Затем активная поливка и защита. Помним, что не все проклюнутся из земли, но большинство, потому что они сами этого хотят. У каждой команды есть overall goal в виде запроса на инновации в конкретном продукте в организации. И они хотят быть успешными. Им лишь нужна помощь, ведь разработчики навряд ли вообще занимались менеджерской работой, а тут общая цель и надо как-то до нее добежать.

Организация, как система, ведет себя как грунт земли - плотная, вязкая, а ещё не дай бог камни. Нужно обеспечить PO ответственность и свободу принятия решений, а это значит, PL + бюджет. Команде нужно дать full-time занятость по работе над продуктом, и защитить их от линейного менеджмента. Наконец, PO будет совсем не просто соблюсти баланс между пользователями (рынком) и командой. Он постоянно будет сильно сваливаться либо в микроменеджмент в команде разработчиков, либо в бизнес.

И вот когда уже растения уверенно растут и сами (!) тянутся к солнцу, и обещают плоды, остается их подрезать, пропалывать и продолжать поливать. И терпеливо ждать! Плоды для бизнеса будут, но не надо ждать быстрых результатов. За две недели чертополох дает "плоды". Фруктам, овощам и ягодам нужно гораздо больше времени.))