Гибкое дело. Что за зверь agile и как его внедрить, не облажавшись

Немного теории

Процесс работы «по эджайлу» делится на итерации — короткие циклы по две-три недели. Каждый цикл решает серию задач. По итогам каждой итерации команда анализирует результаты и меняет приоритеты для следующего цикла. В итоге за каждый цикл создаётся мини-продукт или отдельная часть, готовая к самостоятельному запуску.

Как правило, в agile-командах менеджеры, разработчики, дизайнеры, тестировщики и другие участники равноценны в иерархии и работают в одном пространстве. Вся команда регулярно получает обратную связь от заинтересованных сторон — пользователей, заказчиков, спонсоров и т. д. В команде есть специально выделенная роль — product owner, который фокусируется на ценности продукта для клиентов, рынка и заказчиков, приоритизирует задачи и решает, какой функционал необходим в первую очередь.

Agile-подходы используют разработчики Google, Netflix, Spotify и других компаний. В России об «agile-трансформации» объявил «Сбер». В последнее время сфера использования agile расширилась и вышла за пределы IT.

Истории ошибок и правильный подход к пилоту

— «Этот ваш agile не работает», — слышу я иногда от руководителей разного уровня. Я всегда интересуюсь, почему они сделали такой вывод, и слышу самые разные истории. Давайте разберемся с некоторыми из них.

История первая — «грустная»

«Надо повышать скорость внедрения изменений», — громогласно разносится на конференциях и в выступлениях уважаемых руководителей. «Agile лучшее решение!» — звучит со всех сторон. Начнём с пилота, подумали руководители…

И вот уже первая восхищённая agile-команда пытается делать свой продукт в недрах организации, натыкаясь на бесконечные препоны внешнего мира. Они верят в успех agile и свой продукт и пытаются героически преодолевать препятствия, но тратят большую часть времени и энергии на решение проблем, связанных в первую очередь со средой, так как все обеспечивающие процессы компании не готовы работать так же гибко. Поиск сервера для регрессионного тестирования, попытки договориться с другим подразделением об интеграционном тестировании, согласование с маркетингом и информационной безопасностью посадочной страницы. Всё это и многое другое отнимает у команды массу времени.

«Эффективность команды низкая, у нас agile не работает», — заключает руководство — и пилот прекращается.

История вторая — «трагическая»

Начало может быть таким же, но послушав истории из первой компании, руководство решает поддержать молодые побеги agile в организации и обеспечивает «зелёный коридор» всем запросам от юной agile-команды в других подразделениях. Всходы в таких тепличных условиях, естественно, растут быстро.

«Успех! Agile работает», — думает руководство, глядя на скорость развития продукта, и расширяет agile-периметр до десятков или даже сотен команд. Конечно, уже без тепличных условий и «зелёных коридоров». Вот тут-то и начинают падать мотивация, скорость развития продукта и вера в работоспособность Agile-подходов в организации.

Вот только масштаб бедствия уже больше… Итог понятен — формируется мысль: «Этот ваш аgile подходит только для маленьких команд».

Историй, которые формируют установку «Agile не работает», множество, но давайте разберёмся, как переписать сценарий, чтоб повысить шансы на happy end.

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

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

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

• Определите бюджет и дайте руководителю подразделения полномочия управлять им без согласования на различных внешних комитетах. Agile-командам для эффективной работы необходимо проверять десятки гипотез, и некоторые из них могут требовать финансов. Может потребоваться дополнительное оборудование или привлечение сторонних специалистов. Когда каждое такое решение необходимо обосновывать и согласовывать с людьми, не находящимися в контексте работы, это снижает эффективность работы в целом.

• Обдумайте и подготовьте ответы на вопросы по HR-циклу: «Как нас будут оценивать?», «Кто подпишет мне отпуск?», «А как я могу пойти на обучение?» и т. д. Сотрудники будут их задавать, и ответы на них должны быть понятны и желательно, чтобы они подходили для agile-структуры. Особенно важен процесс оценки результатов сотрудников. Если в вашей организации, например, есть премирование за результат, то для успешной работы agile-команд результат должен оцениваться не у отдельно взятого сотрудника, а у команды в целом, и сотрудники должны об этом знать.

• Заранее договоритесь о взаимодействии со смежными подразделениями (юристы, закупки и т. д.). Должна быть возможность подключать коллег из этих подразделений на ранних этапах, а не просто обеспечивать ускоренную обработку запросов. Например, сотрудников информационной безопасности стоит подключать к встречам, где команды только начинают обсуждать идеи, чтобы не начинать реализовывать функционал с заведомо известной уязвимостью.

Лучшее решение, если у вас есть сомнения по поводу организации всего данного комплексного процесса: найдите тех, кто уже сумел успешно пройти путь от пилота к масштабированию, и спросите дельного совета.

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

5 типичных ошибок при внедрении agile

Внедрение Agile на уровне организации требует подготовки и дисциплины, без которых можно столкнуться с серьёзными ошибками и разочароваться в подходе. Компании разного масштаба и из разных отраслей будут иметь и специфические сложности, но 5 самых частых ошибок из нашего списка — общие для всех.

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

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

• Сохранение старой оргструктуры. На старте внедрения большинство компаний имеют традиционную функциональную структуру. В ней бизнес-инициатива в процессе реализации передаётся из отдела в отдел. Это серьёзное препятствие на пути к скорости и принятию лучших бизнес-решений: нередко каждый отдел оптимизирует работу через призму своей экспертизы, теряя фокус на конечном клиенте и приоритетах компании.

Как надо: организовать производство вокруг небольших команд, в которых есть экспертиза для достижения конкретного результата. Со временем такая команда накапливает знание о технологических особенностях производства и бизнес-контекста. Например, одна FMCG-компания из числа наших клиентов для выпуска нового продукта — чипсов для молодой аудитории — формировала команды из маркетологов, рыночных аналитиков, технологов и IT-специалистов.

• Отсутствие аудита. Часто решение о внедрении принимается на основе успешных историй конкурентов. При этом упускают отличия во внутреннем устройстве референсной компании — от состояния IT и производственной инфраструктуры до объёма контрактных обязательств и наличия внутренней экспертизы в различных областях. Например, значимое использование проприетарных технологий в ИТ инфраструктуре, таких как SAP или Siebel, может обязывать работать с внешними разработчиками и ограничивать скорость и гибкость доработки.

Как надо: аудит позволяет определить ключевые сдерживающие факторы и продумать оптимальный план внедрения. На этом этапе подбирают подходящую методологию (Agile@Scale, SAFe, Spotify-model и т. д) и определяют необходимость её адаптации под конкретную организацию.

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

Как надо: во время пилота внедрить изменения на ограниченном периметре компании и определить неочевидные на первый взгляд ограничения. Это поможет и снизить тревогу, и преодолеть непонимание сотрудников — им тоже важно увидеть и понять, что и как меняется в компании.

• Завышенные ожидания по поводу скорости изменений. Яркие истории успеха, которые становятся публичными, часто создают излишне оптимистичный взгляд на внедрение agile. Они не рассказывают о длительности и болезненности изменений. Неадекватная оценка рисков и неготовность компании к трудностям на первых этапах часто приводят к досрочной приостановке внедрения.

Как надо: быть готовым, что для компании в несколько сотен человек изменение оргструктуры, целеполагания и оптимизация производства требуют не менее 6–9 месяцев активной работы — как топ-менеджмента, так и команд. Это приводит к неизбежному замедлению работы в первые месяцы. Для более сложных корпораций и тысяч сотрудников переход будет занимать годы и требовать продуманного плана масштабирования и поддержки.

Фото: Unsplash, [Unsplash License] (https://unsplash.com/license)