В шапке
Как стать Agile

Как стать Agile

Cтать Agile…Для чего  и как?

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

Да, в России бум Agile. Почему я в этом уверен? Посмотрите результаты опроса российских компаний, вышедшие в ноябре 2018 года: в опросе участвовало более 1200 человек, они представляли более десятка отраслей.

 

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

Ради чего компании начинают движение в сторону Agile?

Чаще всего, Agile начинают внедрять для сокращения сроков вывода новых продуктов на рынок. В качестве вдохновляющих примеров можно вспомнить компанию Zara, в которой с момента идеи до появления нового продукта на полках магазина проходит  2 недели (https://pandia.ru/text/77/475/3315.php). Как им это удается? За счет вот таких практик:

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

-ZARA заказывает часть текстиля у своих поставщиков без определенного цвета. Цвет определяется только тогда, когда ZARA получит реальные данные о предпочтениях покупателей.

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

(с) https://onagile.ru/industries/fashion/zara-2

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

А что в Беларуси происходит с  Agile? К сожалению, у нас никто не проводит аналогичных опросов и никто не знает ответа на вопрос: как много компаний внедряют Agile и какие результаты они получают.

На сайте hh.ru по запросу «Scrum master» в регионе Беларусь на 02.01.2019 есть только 9 вакансий, 6 из них связаны с поиском разработчика, и только 3 – направлены на поиск Scrum master, и все вакансии из ИТ-компаний.

За последние 3 года я помогал внедрять самый популярный Agile подход (Scrum) в семи командах.

Для того, чтобы обучить участников проекта работать по Scrum мы проводили следующие работы:

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

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

Обычно в первом же спринте вырисовывался ряд проблем, которые мешали команде перейти на новый подход:

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

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

А теперь подробнее о моей практике внедрения Scrum.

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

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

Чаще всего мы измеряли метрики, связанные с:

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

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

А теперь немного рефлексии: что помешало этим трем командам получить весомый результат от внедрения Scrum?

Этому были разные причины:

В одной из команд мы столкнулись:

1.       часть участников команды со стороны  владельца продукта говорили о том, что не видят никаких выгод от использования нового подхода

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

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

Во второй команде были другие причины скромных результатов:

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

2.      Отказ от детального проектирования будущей системы привел к пропуску некоторых требований и это привело к дополнительным доработкам

3.      Поздно начали работать с переносом данных и это привело к запоздалому выявлению проблем с производительностью работы системы

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

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

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

Попытаюсь обобщить тот опыт, который я получил:

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

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

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

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

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

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

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

Комментарии (0)
Войти как