Стратегии и методы убеждения команды внедрить Agile методологии. Как создать подходящую среду и культуру, способствующую успеху продукта.

Если вы уже понимаете, что такое Agile–фреймворк, который вы хотели «продать», и как по нему работать, но команда уже пришла к вам, то все круто. Вы обговариваете детали, нанимаете коуча, который устранит вопросы и отшлифует командное понимание процессов, устанавливаете нужные инструменты работы, и опытным путем идёте по обоюдной инициативе итеративно–инкрементально работать.

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

В статье мы не будем говорить конкретно о командах, создающих IT–продукты.

Agile применяется и полезен во многих сферах: от строительства до медицины и рекрутинга. Люди, которые так или иначе руководят командами, где–то узнали о пользе Agile, почитали кейсы, прошли тренинг, приходят к команде и говорят: «С понедельника мы работаем по Scrum/Kanban/XP/и т.д. То–то то–то мы будем делать так–то и так–то».

Такой подход неверен. Если члены команды не проникнутся вашим Agile–фреймворком, не поймут его ценности лично для себя, то ваши инициативы будут восприниматься как очередные «авторитарные» указания, что противоречит пресловутым демократическим принципам Agile–фреймворков.

Для вас очень важно получить то доверие команды, которое переведёт, вас, как менеджера, из разряда босса–директивного начальника в разряд члена команды, ее партнёра.

В первую очередь важно определить конкретные проблемы в вашей команде.

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

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

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

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

Допустим после того, как вы провели встречу, вы узнали, что:

«Да что–то работы много», «Не пойми, что требуют», «Делаем кучу ненужной работы», «Не успеваем».

Отлично, вы услышали классические проблемы, на которых эффективны Agile–подходы. И ваша команда с радостью воспримет ваше желание исправить эти проблемы, потому что это ИХ проблемы, а не очередная ваша менеджерская прихоть.

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

Возьмём наш пример:

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

«Делаем кучу ненужной работы». Команда, к примеру, говорит, что они много раз все переделывают, делают ненужные задачи. Окей, вы вводите Just in Time, даете команде возможность приоритезации, возможность видеть и оценивать продукт со своей стороны, вводите совместное планирование и так далее.

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

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

Отлично, вы решаете проблемы, которые нашла ваша команда. Некоторое время вы работаете по–новому и шлифуете процесс, тестируете практики и даёте команде вникнуть в них.

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

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

Итак, после определенного времени вы вместе определили и решили с помощью инструментов Agile все то, что не устраивало сотрудников.

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

Настала ваша очередь. Вы видите то, что до сих пор делает teamwork менее эффективной, однако ваши сотрудники этого не замечают. Им нужно донести это.

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

Наконец, вы можете прийти к команде и сказать о своей изначальной идее изменений, сказать «А давайте сделаем это, поработаем так пару спринтов, это точно сработает». Команда поверит вам, и вы сможете продать это Agile–изменение без сопротивлений с её стороны.

Учтите то, что во время имплементирования Agile продуктивность может временно снизиться, пока ваша команда изучает новые техники и подходы. При всем вашем позитиве принимайте решения осторожно. Agile работает хорошо при обдуманных решениях и изменениях.

Важно заметить, что в Agile центральную роль играет принцип Барри Боэма: «нанимайте меньше людей, но лучших». Из проекта или продукта уходят неважные активности, поэтому у членов команды остается время развиваться.

Различия продуктивности не так заметны на проектах/продуктах, где члены команды выполняют много нерелевантных действий. Но когда они полностью включаются в Agile, они должны двигаться быстро. Медленная работа одного будет тормозить всех.

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

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

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

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

Вы должны сами проникнуться всеми ценностями Agile, которым вы обучаете команду, и только вместе с вами команда проникнется ими. Тогда ваша Agile–трансформация будет полноценна.

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

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

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

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

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

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

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