Применение и особенности внедрения Scrum
Намного проще делать сложные вещи, чем простые. Scrum - простой для понимания и тяжелый для внедрения. Разбираемся почему так, и как сделать так чтобы он хорошо лег на бизнес-процессы компании.
История
Если посмотреть вглубь истории, (лет на 20-30) и понять условия появления процессного каркаса Scrum, то можно обнаружить, что проблемы с которыми сталкивались разработчики новых систем и новых изделий они такие же, как сейчас. А именно:
- Затягивание сроков принятия решений.
- Много обсуждений которых по мнению инженеров быть не должно.
- Слишком долгий цикл разработки нового продукта для рынка.
В целом это достаточно типичная проблема для компаний “кубиклов” (кабинетов), и компаний с длинной историей. В таких компаниях есть отлаженные процессы управления изменениями и они достаточно хорошо справляются с ротацией кадров, выращивая новых специалистов. Однако если требуется сделать рывок или усилия нескольких департаментов, то нужны другие правила игры, другие схемы взаимодействия.
Scrum
Scrum - новые правила для решения задач по другому. А если мы хотим, чтобы новые правила хорошо экспортировались за пределы одной отрасли или компании, то нужно, чтобы в правилах максимально отсутствовала отраслевая специфика.
Джеффу Сазерленду и Кену Шваберу это удалось сделать. Поэтому Scrum - это каркас, и при применении нужно смотреть “А что из предлагаемых подходов, УЖЕ работаету нас в компании?”. К тому же, Scrum - это правила для игры для одной команды. Правила для для одной команды - это самый простой способ унификации. Если мы помещаем эту команду в разные среды, то появится много правил взаимодействия, что усложнит понимание основной идеи.
Например:
Запускаем Scrum в конструкторском бюро: появляется взаимодействие с производством, службой эксплуатации, обеспечением информационной безопасности. Или запустим Scrum в компании производящую авиационное оборудование: появляется влияние отраслевых стандартом КТ178 и цикл выпуска продукции с повышенной отказоустойчивостью, что сразу добавляет новых правил работы.
Поэтому если мы создадим свои новые правила и очистим отраслевую специфику то у нас появится
- Основные события обеспечивающий стандартный протокол работы. У вас в компании же есть еженедельные совещания по планированию, так? А каждый день вы наверное координируетесь с коллегами : “Что делать будем? Какой план на сегодня?” . Если в вашей компании этого нет, то на стройке и производстве координационная “летучка” - производственное совещание всегда есть.
- Основные роли - чтобы были минимальные зоны ответственности, было понятно кто отвечает за постановку целей и приоритеты, а кто за выполнение правил и регламентов, а кто за создание результата.
- Основные артефакты планирования и результатов работы - кросс отраслевая штуковина объясняющая необходимость планирования и получаемый результат.
Так, в результате очистки, у нас получится совершенно стерильный бизнес-процесс который можно “подселить” в любую организацию. Этим и является Scrum. В отличии например от Unified Process, или Extreme Programming.
Особенности применения
Однако, когда мы начинаем “подселять” стерильный и бесцветный процесс в организацию в которой уже работают свои бизнес процессы, то часто ситуация развивается по сценарию:
Весь мир насилья мы разрушим
До основанья, а затем
Мы наш, мы новый мир построим, —
Кто был ничем, тот станет всем.
(с) Интернационал
То есть, отработанные работающие техники и практики хоронятся, а вместо них вводятся новые, модные и такие привлекательные термины и практики из Sсrum. Которые, не закрывают всех потребностей бизнеса. И только через какое время, эти техники и роли начинают окрашиваться в отраслевую специфику и начинают быть похожими на те, которые были, но с улучшениями.
Как бы сделать, чтобы сразу правильно?
С точки зрения Теории Систем, всякую организацию можно рассматривать, как систему состоящую из других систем. Поэтому встраивая Scrum в организацию нужно понимать в какую систему мы встраиваем и как. Scrum как процессный фреймворк работает на уровне тактики и оперативного управления, и не затрагивает вопросы стратегического управления.
При внедрении Scrum нужно ответить на вопросы:
- Как правила Scrum могут улучшить наши текущие регламенты и бизнес-процессы?
- Что из текущих правил нужно изменить для соответствия правилам Scrum?
- К каким последствиям приведут изменения?
Непременно следует учитывать отраслевую специфику и сложившуюся культуру, Например:
- Если это разработка программного обеспечения, то свод правил адаптивной разработки ПО - это дисциплина “Экстремальное программирование”.
- Если мы встраиваем Scrum в проектное управление, то роль Владельца продукта как человека определяющего приоритеты и работающего с заинтересованными лицами ляжет на Руководителя проекта , если иное не описано в Плане Управления проектом.
- Для небольших компаний в сегменте дистрибуции, работающих только по коротким целям и задачам, где 90% активностей это операционные задачи, от всей ценности Sсrum останутся только события типа планирования, координация дня и ретроспектива. А роль Владельца процесса и Постановщика целей будет совмещена на собственнике.
Накладывая на отраслевую специфику следует учитывать, что интересы ролей Владелец процесса и Постановщик целей диаметрально противоположные:
- Интересы Владельца процесса: улучшать процесс для максимизации скорости реализации заявок, а
- Интерес Постановщика целей: получить результат в максимально короткие сроки.
Поэтому при совмещении ролей на одном сотруднике будет или тоталитаризм: “Давай быстрей, пофиг на качество”, или раздвоение личности. Во втором случае команда разработки не будет чувствовать себя в безопасности, а значит не будет открыто высказываться о проблемах, и обещанные Scrum улучшения не будут достигнуты.
Выводы
- Не внедряйте Scrum насильственно вместо текущего бизнес-процесса.
- Не плодите сущностей сверх необходимого.
- Обсудите и возьмите то, что улучшает ваш процесс.
Примечание
Да, описания ролей и событий заменены умышленно. Новое, это просто хорошо забытое старое. И скорее всего, что-то из этих техник вы уже у себя применяете.
- Постановщик целей - Владелец продукта
- Владелец процесса - Scrum master
Agile
eXtreme Programming
Scrum
Методологии
Управление проектами