Время быть Agile — страница 18 из 33


Правильно понятые и признанные ценности Agile и быстрое внедрение методологии SCRUM дадут преимущества

…сотрудникам:

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

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

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

4. Работа в команде в атмосфере взаимного доверия и равенства создает драйв, вовлеченность и удовольствие.


…бизнесу, предприятию, организации:

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

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

AGILE НЕ ПРОСТО СТАЛ ПОПУЛЯРНЫМ СПОСОБОМ БЫСТРО И КАЧЕСТВЕННО ПОСТАВЛЯТЬ ЦЕННОСТЬ ЗАКАЗЧИКАМ И ПОТРЕБИТЕЛЯМ, ОН СТАЛ ФИЛОСОФИЕЙ НОВОГО ВРЕМЕНИ

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


Когда это становится понятно людям, принимающим решения в компании, тогда создание Agile-команд это уже дело техники. На самом деле происходит все так:

1. Первый импульс – уровень слухов.

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


2. Общение с первым лицом компании – уровень сомнений.

Из опыта, случившегося в компании G., стало очевидным, что консультантам недостаточно на входе общаться только с HR или с директором по развитию. Для успешности Agile и использования всех его преимуществ на благо компании необходимо непосредственное общение с первым лицом. В этой коммуникации проходят все стадии принятия: отрицание, недоверие, сомнение, согласие на эксперимент, желание переложить ответственность на консультантов. Пожалуй, за все наши четыре года активной работы по созданию Agile-команд в различных сферах деятельности ни разу не было такого, чтобы от первого лица не прозвучала фраза: «Мне все понятно, я уверяю вас, что мы уже давно Agile. У нас все это есть, правда, без этого вашего птичьего языка, без досок с карточками и ежедневного стояния перед ними. А все остальное такое же».


3. Обучение топ-менеджеров компании – уровень погружения в тему.

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

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

Во-вторых, в процессе такого первичного обучения руководители впервые понимают, что сотрудники выходят из-под их контроля и получают невиданную ранее свободу. На одном из таких «welcome to Agile» семинаров мы проводили бизнес-игру «Как провести конференцию по Agile». Казалось, что топ-менеджерам все было понятно, и сам метод им понравился, но тот, кто отвечал за эту конференцию перед акционером, постоянно спрашивал консультантов: «Я все понял, мне все нравится, но как же я их буду контролировать? Вдруг меня вызовут наверх и потребуют актуальную информацию, а я должен ждать, когда меня, как Заказчика, позовут на спринт? Я так не понимаю».

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

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

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


4. Общение с Заказчиком – уровень определения конфигурации будущего проекта.

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

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

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

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

Поэтому в Agile мы сразу движемся дальше. Параллельно.


5. Конфигурация команд – уровень старта проекта.

Мы вплотную подошли к очень важному моменту – формированию команд. Чтобы вспомнить, как это происходит, возвращаемся к пятой главе. Напомню только, что нам надо соблюсти принцип полноты компетенций для решения конкретной задачи и выпуска конкретного продукта. Поэтому, прежде чем объявить, что набор в команду идет на добровольных началах, надо определить, кто же нам все-таки нужен. В это же время с Заказчиком мы примериваемся к тому, кто сможет быть Владельцем продукта в каждой команде, если их несколько.


6. Популярно об Agile – уровень знакомства потенциальных участников с гибким менеджментом.

Всех, кого Заказчик наметил взять в команды по профессиональному признаку, мы посвящаем в «эйджалисты». Проводим обучение основам и принципам Agile, пока без получения навыков и распределения ролей в командах. До этого еще далеко. Когда на следующем этапе мы будем объявлять о добровольном участии в проекте, люди уже должны понимать, что их ожидает. И прийти в команду действительно по доброй воле.

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