Получилось, что нагрузка у всех была неравномерная. Кто-то делал больше, потому что лучше проникся новыми идеями менеджмента, а кто-то остался в старой парадигме подчиненных отношений. Несмотря на то, что все вошли в команду добровольно. Кроме одного парня, который был назначен руководством. И от него было больше всего проблем, конечно.
– А что дал лично тебе этот проект? Как ты изменилась?
– Я испытала разочарование от того, что мы не сделали так, как это должно было быть в идеале. Еще я поняла, что никогда не надо делать работу за других, им это вредит. Это мой личный урок для всей моей деятельности.
Но самое важное открытие для меня в том, что Agile надо осознать, принять, прожить и следовать в жизни. Правила – это одно, ими можно пренебрегать, а осознание – это другое, это так глубоко проникает в тебя, что ты уже не можешь свернуть с этого пути.
В Agile нельзя заставить работать людей, с ним надо подружиться.
Уроки проекта Agile в компании G
1. Смещение ролей в команде. С первого же вводного семинара по основам Agile стало понятно, что команда находится на этапе формирования и еще недостаточно развита, чтобы быть эффективной. Неусвоенные принципы Agile приводили к тому, что участники посчитали роль SCRUM-мастера ответственной за все результаты работы команды. Поэтому ребята просто «сдавали» свою работу SCRUM-мастеру и ожидали вердикта. Члены команды загрузили эту роль массой файлов и презентаций, пока консультанты не вмешались в этот искаженный процесс. В команде долгое время сохранялись отношения «из прошлой жизни»: я свою работу сдал SCRUM-мастеру, почему я должен еще что-то делать, пока не прошла проверка.
Изменение такого отношения проходило болезненно и по живому, в процессе работы над проектом корректировались роли и выстраивались взаимоотношения, основанные на доверии и взаимопомощи.
2. Высокая должность Владельца продукта. Эта роль была искажена тем, что ее выполнял топ-менеджер высшего звена и по привычке управлял работой команды в авторитарном стиле. С другой стороны, и сами ребята не воспринимали топ-менеджера как члена своей команды, а исключительно как руководителя, которому надо подчиняться. О доверии в таких условиях речи уже не было. Это привело к тому, что команда тяжело обретала самостоятельность и самоуправляемость с постоянной оглядкой на руководство.
3. Совмещение с основной работой. Руководители, в подразделениях которых трудились участники команды, не прониклись значимостью проекта CRM по многим причинам, часть из которых описана в интервью. Более того, не осознавая важность конечного продукта Agile-команды, руководители считали, что это только отвлекает их сотрудников от основных задач, поэтому увеличивали их загрузку. Это означало, что над проектом нередко приходилось работать в свободное время и в выходные дни, что быстро свело первоначальный энтузиазм на нет. Появилась усталость от проекта и желание быстрее его завершить.
4. Некорректно составлен бэклог продукта. Команда начала работать в таких условиях, когда конечный продукт не был востребован большинством руководителей компании G. А они-то как раз и были будущими потребителями и заказчиками. И именно в силу этого они не могли сформулировать четкую цель для команды, не могли создать образ конечного продукта. Его попросту не было. Команда с подачи одного топ-менеджера взяла в работу задачу адаптировать CRM к различным подразделениям, наполнить данными и научить всех работать в этой системе. Но не ожидала, что проект начнет разрастаться в геометрической прогрессии. После каждого спринта добавлялись все новые и новые вызовы, работы становилось все больше, а конечный результат никак не вырисовывался.
Способность Agile-команд модифицировать задачу в процессе работы в данном случае сыграла плохую роль в этом проекте. Команда не ощутила радости победы, когда наступило окончание срока и проект закрыли, несмотря на то что было много сделано и CRM действительно вошел в жизнь компании, в настоящее время его активно используют все подразделения. Но усовершенствования продолжаются и сегодня.
5. Руководство компании не поддержало Agile-трансформацию. Позиция высшего руководства заключалась в том, чтобы только не препятствовать эксперименту. По идее, выступая в роли Заказчика, руководитель ни разу не пришел на спринты, несмотря на многочисленные приглашения от команды. Практически руководитель был в стороне от проекта, считал его игрушкой для молодежи. Такое равнодушие и непризнание заслуг сильно демотивировало команду. Несмотря на то, что для участников проекта это был хороший опыт и были достигнуты определенные результаты, Agile не раскрыл в этой компании своих преимуществ во всей своей полноте. Что оставило у ребят неприятный осадок. А для высшего руководства этот эксперимент стал лишним подтверждением тому, что гибкий менеджмент – это чуждый для данной компании элемент.
6. Отсутствие материальной мотивации. Я уже говорила о том, что от участников Agile-команды требовалось выполнять свою обычную работу в отделах со своими начальниками плюс при этом работать над проектом, по существу, в свое личное время. Понятно, что быстро случилось выгорание и усталость. Особенно в тех условиях, когда такая двойная нагрузка никоим образом не поддерживается материальной мотивацией. Работать за идею все-таки у нас получилось, но не очень долго.
Несмотря на все сложности создания продукта новым для компании способом, на все невыученные вовремя уроки внедрения гибкого менеджмента в компанию старого образца управления, эксперимент удался. Результат был достигнут – CRM работает, совершенствуется по ходу дела, дополняется новыми данными.
На самих ребят участие в Agile-команде подействовало очень серьезно. Одна из особенностей Agile заключается в том, что его трудно забыть. Один раз вкусив прелести свободы, участники проекта не забывают это ощущение и стремятся повторить это еще раз или уходят из компании, которая пока еще не соответствует их представлению о том, каким должен быть менеджмент. Именно поэтому мы с Владельцем продукта и SCRUM-мастером до сих пор разбираем ошибки и оплошности этого эксперимента, а ребята все еще называют себя «Чип и Дейл». Agile не проходит бесследно.
Анализируя сегодня результаты этого первого для нас, как для консультантов, проекта Agile вне IT, можно сказать, что мы не учли того, что все, кого мы обучали, имеют разный уровень осознанности и готовности быть гибкими, самостоятельными и ответственными. В таком случае, как в компании G., необходим дополнительный период личного Agile-коучинга с каждым членом команды.
Я так подробно разбираю этот опыт, поскольку для нас он был первым. Мы тоже учились преодолевать сопротивление среды вместе с пионерами Agile в крупной производственной структуре в России. Это был 2016 год.
Намного позже мы поняли, что невозможно привить Agile в организации, где высшее руководство понятия не имеет, как это работает, для чего это нужно и какие выгоды получает от этого все предприятие и люди, которые на нем работают. Из этого опыта родилась последовательность действий для встраивания гибкого менеджмента в структуры старого образца, о чем я расскажу в следующей главе. Этот опыт будет служить практически пошаговой инструкцией для тех, кто захочет быть Agile несмотря на то, что окружающая среда еще не готова к переменам.
Выводы:
1. Agile не случается по приказу, а лишь по интересу и доброй воле всех участников процесса.
2. Компания, в которой создаются Agile-команды, должна быть заинтересована в конечном продукте и оказывать поддержку в его производстве.
3. Agile оставляет след в душе участников процесса, положительно сказывается на их дальнейшей карьере и создает все больше приверженцев гибкого менеджмента в бизнесе.
Глава 7Внедрение Agile в устоявшиеся структуры
Встраивание Agile в структуры старого иерархического образца. Последовательность действий внешних консультантов и руководства компании.
Многие собственники и топ-менеджеры бизнесов оказались в 2020 году один на один с проблемой управления удаленными командами, с невозможностью контролировать все действия проектных команд, неспособностью людей самостоятельно решать задачи в турбулентное время. И тогда понадобилось четкое и понятное описание опыта того, как применить Agile без опасения ошибиться или потерять драгоценное время.
Во время моих интервью для этой книги многие собеседники говорили о том, что им хотелось бы видеть мою книгу полезной для повсеместного распространения Agile в нетехнологических компаниях и подразделениях. Чтобы люди могли прочитать книгу и понять, что им надо делать для получения быстрых результатов, а попутно удовлетворения от этих результатов и радость от совместного труда в небольшой кросс-функциональной самоуправляемой команде.
К тому же, во многих случаях, когда у самого амбициозного в команде руководителя возникает мысль об Agile, вся организация может находиться еще на синем уровне Правил по спиральной динамике и только-только примериваться к оранжевому уровню Успеха. Это означает, что в компании процветает крепкая непоколебимая иерархия. Чтобы встроить в это пространство гибкий менеджмент и не потерять результаты деятельности Agile-команд в рутине корпоративной бюрократии, я предлагаю пройти путь, который описываю ниже. Этот путь сложился из опыта нашей с Марией Куршиной работы в самых различных по уровню развития корпоративной культуры организациях.
Было бы преувеличением сказать, что залог успеха Agile в любой компании – это лишь последовательное соблюдение описанных мной уровней. Для успеха нужно гораздо больше слагаемых, чем автоматическое повторение чужого опыта. У каждого проекта свой секрет и свой список падений и возвышений. Но выполнение поэтапного плана встраивания Agile в структуры старого иерархического образца дает гораздо больше возможностей для достижения целей.