История

Если посмотреть вглубь истории, (лет на 20-30) и понять условия появления процессного каркаса Scrum, то можно обнаружить, что проблемы с которыми сталкивались разработчики новых систем и новых изделий они такие же, как сейчас. А именно:

• Затягивание сроков принятия решений.
• Много обсуждений которых по мнению инженеров быть не должно.
• Слишком долгий цикл разработки нового продукта для рынка.

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

Scrum

Scrum - новые правила для решения задач по другому. А если мы хотим, чтобы новые правила хорошо экспортировались за пределы одной отрасли  или компании, то нужно, чтобы в правилах максимально отсутствовала отраслевая специфика. 

Джеффу Сазерленду и Кену Шваберу это удалось сделать. Поэтому Scrum - это каркас, и при применении нужно смотреть “А что из предлагаемых подходов, УЖЕ работаету нас в компании?”. К тому же, Scrum  - это правила для игры для одной команды. Правила для для одной команды - это самый простой способ унификации. Если мы помещаем эту команду в разные среды, то появится много правил взаимодействия, что усложнит понимание основной идеи.

Например: 
Запускаем Scrum в конструкторском бюро: появляется взаимодействие с производством, службой эксплуатации, обеспечением информационной безопасности. Или запустим  Scrum в компании производящую авиационное оборудование: появляется влияние отраслевых стандартом КТ178 и цикл выпуска продукции с повышенной отказоустойчивостью, что сразу добавляет новых правил работы.

Поэтому если мы создадим свои новые правила и очистим отраслевую специфику то у нас появится

1. Основные события обеспечивающий стандартный протокол работы. У вас в компании же есть еженедельные совещания по планированию, так? А каждый день вы наверное координируетесь с коллегами : “Что делать будем? Какой план на сегодня?” . Если в вашей компании этого нет, то на стройке и производстве координационная “летучка” - производственное совещание всегда есть.
2. Основные роли - чтобы были минимальные зоны ответственности, было понятно кто отвечает за постановку целей и приоритеты,  а кто за выполнение правил и регламентов, а кто за создание результата.
3. Основные артефакты планирования и результатов работы - кросс отраслевая штуковина объясняющая необходимость планирования и получаемый результат.

Так, в результате очистки, у нас получится совершенно стерильный бизнес-процесс который можно “подселить” в любую организацию. Этим и является Scrum. В отличии например от Unified Process, или Extreme Programming.

Особенности применения

Однако, когда мы начинаем “подселять” стерильный и бесцветный процесс  в организацию в которой уже работают свои бизнес процессы, то часто ситуация развивается по сценарию: 

Весь мир насилья мы разрушим
До основанья, а затем
Мы наш, мы новый мир построим, —
Кто был ничем, тот станет всем.
(с) Интернационал

То есть, отработанные  работающие техники и практики хоронятся, а вместо них вводятся новые, модные и такие привлекательные термины и практики из Sсrum. Которые, не закрывают всех потребностей бизнеса.  И только через какое время, эти техники и роли начинают окрашиваться в отраслевую специфику и начинают быть похожими на те, которые были, но с улучшениями. 

Как бы сделать, чтобы сразу правильно?

С точки зрения Теории Систем,  всякую организацию можно рассматривать, как систему состоящую из других систем. Поэтому  встраивая Scrum в организацию нужно понимать в какую систему мы встраиваем и как. Scrum как процессный фреймворк работает на уровне тактики и оперативного управления, и не затрагивает вопросы стратегического управления.

При внедрении Scrum нужно ответить на вопросы:

1. Как правила Scrum могут улучшить наши текущие регламенты и бизнес-процессы?
2. Что из текущих правил нужно изменить для соответствия правилам Scrum?
3. К каким последствиям приведут изменения?

Непременно следует учитывать отраслевую специфику и сложившуюся культуру, Например:

• Если это разработка программного обеспечения, то свод правил адаптивной разработки ПО - это дисциплина “Экстремальное программирование”. 
• Если мы встраиваем Scrum  в проектное управление, то роль Владельца продукта как человека определяющего приоритеты и работающего с заинтересованными лицами ляжет на Руководителя проекта , если иное не описано в Плане Управления проектом.
• Для небольших компаний в сегменте дистрибуции, работающих только по коротким целям и задачам, где 90% активностей это операционные задачи, от всей ценности Sсrum останутся только события типа планирования, координация дня  и ретроспектива. А роль Владельца процесса и Постановщика целей будет совмещена на собственнике.

Накладывая на отраслевую специфику следует учитывать, что интересы ролей Владелец процесса и Постановщик целей диаметрально противоположные:

• Интересы Владельца процесса: улучшать процесс для максимизации скорости реализации заявок, а 
• Интерес Постановщика целей: получить результат в максимально короткие сроки.

Поэтому при совмещении ролей на одном сотруднике будет или тоталитаризм: “Давай быстрей, пофиг  на качество”, или раздвоение личности. Во втором случае команда разработки не будет чувствовать себя в безопасности, а значит не будет открыто высказываться о проблемах, и обещанные Scrum улучшения не будут достигнуты.

Выводы

1. Не внедряйте Scrum насильственно вместо текущего бизнес-процесса. 
2. Не плодите сущностей сверх необходимого.
3. Обсудите и возьмите то, что улучшает ваш процесс.

Примечание

Да, описания ролей и событий заменены умышленно. Новое, это просто хорошо забытое старое. И скорее всего, что-то из этих техник вы уже у себя применяете.

• Постановщик целей - Владелец продукта
• Владелец процесса -  Scrum master