Итак, мы определись с термином, а теперь самый главный вопрос: зачем вам Хозяин процесса (Скрам Мастер)? Для какой цели он нужен? В руководстве по Скраму (Scrum guide) явно указана Роль Скрам Мастера, но если есть роль, значит "очевидно" что нужен отдельный человек на эту роль. Но чем должен заниматься Скрам Мастер (Scrum Master)?

Вариантов ответов несколько:

1. Помогать команде принимать решения и проводить мероприятия. - Хм... хороший ответ. Но если нужно ПОМОГАТЬ команде, то вы хотите сказать, что ваши сотрудники НЕСАМОСТОЯТЕЛЬНЫЕ и непрофессиональны?

2. Модерировать и фасилитировать мероприятия. - Отличный ответ! Для этого точно нужен внешний хозяин процесса. Хотя если подумать... а участники сами договориться не могут?

3. Проводить ретроспективы спринтов. - Отличный ответ! Да, ретроспективу, как немного психологическое мероприятие, лучше чтобы проводил хороший наставник.

4. Помогать Владельцу продукта лучше формировать план работ. Я сказал "план работ"? Хорошо "лучше формировать упорядоченный список заказов". - Отличный ответ! Для того чтобы не лгать самому себе, а также для прояснения цели и приоритета каждой заявки лучше работать с коучем.

5. Повышать качество бизнес-процессов и принимаемых решений для того, чтобы заработать больше денег. - Этот ответ мне больше всего нравится.

Итак мы прошлись по ответам и все-таки пришли к идее, что Хозяин процесса Скрама (Скрам Мастер) необходим. Однако, как вы помните у нас все еще ситуация когда "Денег нет и не будет, поэтому применяем старую индейскую мудрость: когда нельзя но очень хочется, то... можно! Или переиначим коучинговый подход:

У любой организации УЖЕ есть все ресурсы, для того чтобы она могла обеспечить процесс непрерывного совершенствования чтобы зарабатывать больше денег СЕЙЧАС. (с) А.В.

Так, как такой вопрос поиска Scrum Master (SM) появляется в основном в ИТ-компаниях, то я покажу что для ИТ-компании НЕ нужен внешний Хозяин процесса Скрам (Скрам Мастер) и все ресурсы уже есть.

Для начала давайте посмотрим, а кто у нас есть в ИТ-компании, если у вас этой должности нет, то его функции кем-то выполняется:

1. Руководитель организации - задачи Руководителя организации делать продажи, или он может делегировать это.

2. Технический директор - определяет технологический вектор развития продуктов (он, же Архитектор).

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

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

5. Инженер обеспечения качества (QA) - обеспечивает качество на всех стадиях выполнения заказа (проекта):

• качество требований (заявок) - чтобы не пропустить нужное
• качество реализации - помочь Клиенту принять результат
• качество документации - дабы Пользователь Клиента не покинул его
• качество процессов создания Продукта - чтобы экономить не делая переделки.

Все эти роли есть почти в любой ИТ-компании, по вертикали "производство", я не указываю здесь обслуживающие подразделения: АХО, договорной отдел, бухгалтерия, юристы и т.д.

И если мы сопоставим действия, которые должен делать Скрам Мастер с сотрудниками - которые у нас УЖЕ есть то выяснится что:

1. Регламентные мероприятия Скрам (Scrum) - вполне может проводить любой участник команды или тимлид или Инженер обеспечения качества.

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

3. Помочь Владельцу продукта принимать правильные решения о планировании - Инженер обеспечения качества. В шапке тестировщика он может легко проверить заявку про критерию ценности. Также в зоне "правильного" Инженера обеспечения Качества находится ВСЕ вопросы качества, в том числе и "Качество гипотез".

4. Декомпозиция и PBR (Product Backlog refinement) - при заданных критериях проверки корректности разбивки и инструкции по тестированию логической связности это тоже может делать.... Инженер обеспечения качества, или лидер команды который ХОЧЕТ обучить своих коллег правильно думать.

Таким образом, большую часть сложных активностей закрывают:

• Инженер обеспечения качества
• Лидер команды разработки.

Даже если у вас нет иерархии, то у вас всё равно ЕСТЬ лидер команды, человек которому ЭТО НАДО, тот, кому доверяют. В любой стае есть вожак.

Но где же взять такого Инженера обеспечения качества? "Личинка" такого у вас уже есть, это Тестировщик. Попробуйте добавить ему полномочий, обучите навыкам тестирования высказываний. Руководитель проекта и бизнес-аналитик могут помочь с этим.

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

Что делать когда хочется что-то изменить, но изнутри не этого сделать?

Обращайтесь в нашу консалтинговую практику: /consulting