Почему у одних получается, а у других — нет. Эксперт про опыт внедрения Agile

Сегодня многие хотят «стать Agile», чтобы повысить эффективность работы команд. Мы узнали, к чему нужно быть готовым при внедрении Agile. Почему у одних команд получается работать по принципам гибких методологий, а у других — нет. Рассказывает наш эксперт Максим Якубович, опираясь на исследования и собственный опыт.

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

---

Посмотрите результаты опроса российских компаний, вышедшие в ноябре 2018 года. В опросе приняли участие 1228 человек из более чем 80 городов. Москвичей больше всех – 53%, Санкт-Петербург – 17%, Новосибирск и Екатеринбург – по 3,5%. В топ-3 отраслей входят: разработка ПО – 34%, финансы – 20%, телеком – 7%. 

Нажмите, чтобы увеличить

Конечно, это далеко не все компании из России, что-то делающие для внедрения новой философии управления проектами. Их намного больше.

Для чего нужен Agile

Чаще всего Agile начинают внедрять для сокращения сроков вывода новых продуктов на рынок. В качестве вдохновляющих примеров можно вспомнить компанию Zara, в которой с момента идеи до появления нового продукта на полках магазина проходит 2 недели. Вот как им это удается. 

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

Это и есть один из принципов Agile. Остальные составляющие успеха — оптимизация производства, использование высоких технологий, грамотное взаимодействие с производителями и покупателями. Например, Zara заказывает часть текстиля у своих поставщиков без определенного цвета. Цвет определяется только тогда, когда Zara получит реальные данные о предпочтениях покупателей.

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

Как мы внедряем Agile

Исследование ScrumTrek показывает, что обычно от Agile бизнес ожидает скорости, точнее, ускорения поставок и выхода продуктов на рынок. Эта цель реализовалась у 66% участников исследования, сообщивших о том, что их организация уже внедрила Agile. Среди всех участников исследования таких компаний ровно половина: 10% сказали о «высоком уровне компетенции в Agile всей организации», а остальные 40% «внедрили Agile, но пока находятся на этапе становления». Большинство остальных организаций пока проводят локальные эксперименты с Agile, но в статистику этого раздела они также включены.

Нажмите, чтобы увеличить

При этом если лет десять назад считалось, что Agile нужен только для ИТ-компаний, то опрос 2018 года показал, что число Agile-команд, чьим результатом работы является материальный товар, за год выросло с 4,6% до 8%.

Что происходит с Agile в Беларуси?

К сожалению, у нас никто не проводит опросов, аналогичных российскому, и никто не знает ответа на вопрос, как много компаний внедряют Agile и какие результаты они получают. Поэтому тут я опираюсь на свой личный опыт. За последние 3 года я помогал внедрять самый популярный Agile-подход — Scrum — в семи командах. Для того чтобы обучить участников проекта работать по Scrum, мы провели следующие работы:

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

В первые 2−3 месяца я выступал в роли Scrum-мастера, параллельно помогая владельцу продукта наладить работу с журналом продукта. В первом же спринте вырисовался ряд проблем, которые мешают команде перейти на новый подход:

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

В исследовании компании ScrumTrek этот список проблем ранжирован, исходя из количества голосов респондентов:

Нажмите, чтобы увеличить

О практике внедрения Scrum

Одна из команд, о которых пойдет речь, представляет производителя сантехнической продукции, 2 команды — из банковского сектора, 2 — из софтверных компаний, 1 команда из стартапа и 1 — из бизнес-школы. Чтобы привить им навыки работы по Scrum, я два месяца выполнял роль Scrum-master в этих командах: помогал командам создать бэклог продукта, владельцу продукта — научиться управлять важностью элементов бэклога, модерировал все события Scrum, а потом около месяца наблюдал за работой другого человека, который сменил меня в этой роли.

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

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

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

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

В итоге через год эта компания все равно вернулась к идее внедрения Agile, только теперь она пробует сделать это не с одной, а с тремя командами.

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

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

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

В остальных четырех командах результатами мы остались довольны: проекты были реализованы в плановые сроки, руководители, затеявшие Agile-трансформацию своих команд, остались довольны, и сами команды отметили, что подход им понравился.

Обобщение опыта. Выводы

1. При внедрении Agile очень важна поддержка высшего руководства компании, а именно — личное участие одного из топ-менеджеров в проекте.

2. Если корпоративная культура компании разделяет ценности Agile-манифеста, то научить команду работать по новому подходу будет не сложно.

3. В первые три-четыре месяца очень важно, чтобы команду, которая впервые работает по Agile-фреймворку, тренировал опытный Scrum-master, а тот, кто его потом сменит, наблюдал за его поведением и учился.

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

5. Нужно создать атмосферу, в которой участники команды не боятся ошибаться, но при этом быстро учатся, берут на себя ответственность.

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

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

Обратная связь с экспертом возможна по электронной почте: max.yakubovich@gmail.com