Все статьи

Сергей Рогачев

Генеральный директор «Лидеры изменений», Agile-коуч, эксперт в Agile-трансформации крупных компаний.

Развивает SAFe® и OKR в России, продюсер исследования «Agile в России», конференций Enterprise Agile Russia и OKR Russia. Публичные кейсы: Монитор Электрик, РТЛабс, Газпром нефть, ХМАО, HeadHunter, Главстрой, Xsolla, Администрация города Саратов, Билайн, DSSL и Сбербанк.

Подробнее

Agile-трансформация и корпоративная культура

Дата: 17.03.2017

Влияние корпоративной культуры на успешность Agile-трансформации.

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

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

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

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

Модель культур Шнейдера

Все модели неправильные, но некоторые из них полезны.

Модель Шнейдера предлагает определение корпоративной культуры по 4 квадрантам. Квадранты расположены на пересечении 4 разнонаправленных фокусов: по горизонтали противоположно направлены фокус на важность компании или на сотрудников, а по вертикали – ориентация на настоящее, в котором нужно достигать результатов, или на будущие возможности (инвестиции). Таким образом, на модели Шнейдера представлены 4 ключевые типы корпоративной культуры: контроля, взаимодействия, компетенции и развития.

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

От культуры контроля к культуре развития

Приведу пример компании, в которой я когда-то работал.

На старте это компания с классической сильной матричной структурой. У каждого сотрудника есть функциональный руководитель, который должен отвечать за его развитие в компании, а также один или несколько менеджеров проектов, в которых он работает. С одной стороны, менеджеры проектов говорили, что функциональные руководители не занимаются развитием как экспертизы специалистов, так и функциональных практик (практики сбора требований, разработки и тестирования) в целом по компании. С другой стороны, начальники отделов ворчали на самоуправство менеджеров проектов: «думают только о том, как быстрее закрыть проект — после них хоть потоп». В итоге, при полном контроле: ответственность разграничена между руководителями и менеджерами и поддерживается материальной мотивацией – низкое качество продуктов и неразвитые процессы, немотивированные сотрудники.

В компании не было инструмента развития сотрудников. Мы начали с внедрения системы регулярной обратной связи каждому сотруднику компании. Теперь функциональный руководитель каждые полгода проводил опрос в стиле 360 градусов и предоставлял обратную связь каждому своему подчиненному. Идея в том, чтобы предоставить возможность каждому сотруднику самостоятельно развиваться, опираясь на советы руководителя, коллег, а то даже и своих подчиненных. Важным условием была открытость: результаты опроса не подразумевали анонимные отклики (наиболее ответственные руководители собирали отзывы в непосредственном устном общении). Таким образом, сотрудник мог уточнить обратную связь непосредственно у коллег  и понять, что конкретно нужно изменить в себе, чтобы стать более успешным. На выходе процесса сотрудники составляли план персонального развития. Мне казалось это избыточным, поэтому мы не стали вводить контроль руководителей за этим процессом. Через полгода очередной опрос покажет, принял ли сотрудник какие-то меры. С одной стороны, мы верили в то, что судьба самого человека в его собственных руках. А с другой стороны, понимали, что стагнирующие сотрудники не интересны компании и в большинстве случаев они ее покидают. Человеку некомфортно работать в условиях регулярной отрицательной обратной связи: он или изменяется, или уходит туда, где он нужен именно такой, как есть.

Полтора года работы системы показали результат.

Начинающий менеджер проекта за 1 год вырос в ведущего менеджера проектов, а затем стал руководителем выделенного подразделения в 50 сотрудников. Он понял и принял правила игры — любую обратную связь нужно воспринимать как задачу саморазвития.

Более того, компания провела реорганизацию от функциональных отделов (сильной матричной структуры) к продуктовым кросс-функциональным отделам. Бывшие функциональные руководители сотрудников стали отвечать за экспертизу, развитие сотрудников и функциональных процессов непосредственно перед руководителями продуктовых отделов. Это очень сильное изменение! К примеру, теперь ты не начальник .NET-разработчиков. Ты — тренер и лидер развития практик .NET-разработки в компании. Теперь ты не владеешь ресурсами, а менеджеры проектов не приходят к тебе на поклон. Ты получаешь обратную связь от них и руководителей продуктовых отделов о качестве экспертизы .NET-разработчиков и используемых ими процессов, так как это твоя непосредственная ответственность. Один из основных инструментов мы тебе дали — регулярная обратная связь сотрудникам. Создавай и развивай новые.

Только прошу вас, никогда не привязывайте систему регулярной персональной обратной связи сотрудникам к персональной материальной мотивации! Сотрудники снова быстро угадывают правила новой игры – и перестают помогать друг другу развиваться: вместо советов друг другу о развитии в 90% случаев будут давать отзывы в стиле оценки «хорошо», так как люди не хотят конфликтов на столь токсичной почве. Примечательно, что в культуре контроля возможны попытки максимально автоматизировать процесс сбора отзывов и предоставления обратной связи. Вместо сбора отзывов вживую обмен письмами, а вместо обратной связи в виде рекомендаций по развитию балльная оценка текущего уровня. Не идите на искушение полного контроля, иначе вы получите систему аттестации, а не развития сотрудников.

В культуре контроля Agile не работает

Agile обещает нам три основных результата: сокращение Time-to-Market (время от идеи до выхода продукта на рынок), рост Customer Experience (качество с точки зрения востребованности конечным пользователем) и увеличение Productivity (производительность как объем работы за единицу времени) – и несколько промежуточных: прозрачность, предсказуемость, мотивация и прочие.

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

Я задаю простую задачку группе сотрудников компании.

Есть 2 Скрам-команды. Каждая команда работает 2-недельными спринтами. Команде 2 нужен компонент, который может сделать только команда 1. Поэтому команда 1 в спринте 1 делает свою работу, соответственно, к спринту 2 отгружает компонент в команду 2. Команда 2 пытается интегрировать его в свою систему, чтобы реализовать бизнес-функцию, но сталкивается с проблемой: поведение компонента не соответствует API или соответствует, но, оказывается, в API забыли предусмотреть необходимое – команда 2 не может реализовать функционал для своего бизнеса. И здесь я спрашиваю: вы Скрам-мастер команды 2, каковы ваши дальнейшие действия?

Ответ людей культуры контроля стандартный: мы заведем дефект, поставим задачу в JIRA и любые иные варианты, при которых команде 1 передается информация о том, что им нужно исправить работу. Тогда я прошу спрогнозировать развитие дальнейших событий: что ответит вам команда 1 во время спринта 2, когда вы столкнулись с проблемой интеграции их компонента. И этот ответ чрезвычайно предсказуем: мы понимаем, что у команды 1 план спринта 2 уже забит, поэтому в лучшем случае они обещают сделать нам все в спринте 3. Я предупреждаю, что мы идем по позитивному сценарию: грубо говоря, мы все друг друга любим — упражнение на корпоративную культуру не про это.

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

Теперь я предлагаю посчитать T2M – 4 спринта по 2 недели, то есть 2 месяца. Обратите внимание, это был еще и позитивный сценарий!

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

Если совсем туго, то предлагаю свой вариант. Команда 1 планирует в спринт работу не только по созданию компонента, чтобы весело его перекинуть команде 2 на интеграцию в конце спринта, но и работу по совместной с командой 2 интеграции компонента прямо во время этого же спринта – исправление дефектов, которые найдет команда 2. Аналогично, команда 2 на тот же спринт планирует работу как по совместной интеграции компонента, так и реализации бизнес-функции на его основе. Когда это будет возможно? Когда обе команды совместно спланируют работу. Работы каждой команды в отдельности никому не нужны, это всего лишь пуговицы и карманы. Соответственно, команды приходят к понимаю, что и они в рамках этой работы не отдельные команды (это не чужие люди), это одна большая виртуальная команда. Соответственно, чтобы выполнить работу за спринт, нужно ее совместно планировать, совместно демонстрировать, а то и проводить совместную ретроспективу после.

И что получается? T2M в 2 недели при взаимодействии и сотрудничестве команд и T2M в 8 недель при контроле работ в стиле: сейчас проблема не на нашей стороне – разница в 4 раза!

Что дает это упражнение людям в культуре контроля? Расскажу наиболее яркий случай. После провокационного вопроса вся аудитория, это были 30 опытных менеджеров очень крупного банка, набросились на меня, наперебой доказывая, что это невозможно, что я теоретик (конечно, консультант же!) и т.п. После того, как я предложил готовый вариант решения, я вновь увидел стеклянные глаза большинства и бегающие глаза у основных троллей на сессии, которые судорожно искали варианты, как мне возразить. Но тут случилась неожиданность. Один парень, который явно долго собирался с духом, вдруг сказал: это возможно, более того, мы уже так пробовали, это работает. В один миг сверлящие меня стеклянные глаза участников сессии устремились на этого парня: что, в нашем стаде волков завелась «паршивая овца»?! Мне полегчало, но парню явно было непросто в этот момент. Но это отличный результат! Изменить культуру таким упражнением невозможно, конечно. Но удается посеять зерно сомнения в том, что их картина мира является единственно верной. Остальное остается за самими людьми. Собственно, в этом и заключается работа коуча.

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

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

Культура развития и Agile

Корпоративная культура компании является совокупностью культуры ее сотрудников. Поэтому трансформация культуры — это изменение людей. Компании нужны люди, готовые к изменениям, получению обратной связи и ориентированные на результат. Умение находить и удерживать таких людей является ключевой задачей компании, которая ожидает обещанных результатов Agile (напомню: быструю поставку, высокое качество и производительность). Как это реализовать?

В чем сила мощных компаний? Там люди постоянно, все время получают обратную связь. И это базис корпоративной культуры. Обратная связь там развивает и воспринимается сотрудниками как помощь в развитии, а вовсе не как наезд, она не демотивирует людей. Отсюда и самая сложная задача, которую необходимо решать компаниям: как обеспечить правильную коммуникацию обратной связи. Но если обеспечить постоянный цикл получения развивающей обратной связи и реакции на нее, то сотрудники и, как следствие, вся компания в целом развивается. Развитие сотрудников – это задача менеджмента, но также это и персональная задача каждого человека. Представьте, что человек воспринимает работу как тренировку, а сам мечтает стать чемпионом. По описанным выше моделям он хочет оказаться наверху пирамиды всего человечества, но до конца жизни! Не остановится в 45 лет, а даже и в 90 лет продолжать развитие. И вы знаете таких людей: ученые, писатели – нобелевские лауреаты. Осознайте, какой заряд энергии у такого человека: развиваться, быть в 10% меньшинстве, но постоянно бороться, чтобы делать это всю жизнь, каждый день заниматься этим, а также следить за скоростью своего улучшения. Что если так будет работать вся организация! Представьте мощь такой организации! И такие компании есть — это уникальные машины по воспроизводству талантов на основе циклов обратной связи.

Масштабирование Agile по SAFe®
Тренинг Leading SAFe® призван помочь крупным компаниям и быстро растущим командам справиться с проблемами синхронизации, возникающими вследствие сложной структуры, большого числа проектов и продуктов. По окончании тренинга и сдачи выходного экзамена участники получают международный сертификат Certified SAFe® Agilist (SA).

Автор:

Поделиться

VK
Telegram