Agile-трансформация
AgileSurvey
Beyond Budgeting
DevOps
HR
Kanban
LeSS
PMI
Project management
SAFe
Scrum
Scrum-мастер
Бюджетирование
Игра
Конфликты
Обучение
Фасилитация
Применить

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

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

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

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

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

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

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

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

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

1-2

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

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

Культура контроля

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

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

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

Культура компетенций

Еще одной распространенной культурой, особенно в академической среде, является культура компетенций.

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

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

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

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

Культура взаимодействия и развития

Ориентир на потребности настоящего и важность людей приводит компанию в культуру взаимодействия. Здесь люди достигают успеха, стараясь любую работу выполнять сообща, командой. Это основная область применения Agile. Грубо говоря, именно в таких культурах «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 раза!

2-1

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

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

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

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

Эту главу посвящаю всем HR, с которыми у меня всегда были теплые отношения.

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

Рефлексивность

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

Лев Николау, председатель совета директоров «Атринити», который рассказал мне эту модель развития людей, утверждает, что по статистике количество рефлексивных людей в мире около 10-15%. Представьте пирамиду, в вершине которой лидеры человечества: руководители компаний, гениальные ученые и все, кто оказывает влияние на развитие всего человечества. Количество рефлексивных относительно больше во главе пирамиды, чем в ее основании.

3

В чем ключевая проблема всех компаний, которые хотят лидировать? Непонятно, где найти достаточное количество рефлексивных сотрудников? Если по статистике таких всего один на десять человек. А как их удержать в компании? Компания должна научиться не только привлекать рефлексивных людей, но обеспечивать возможность их движения вверх по пирамиде.
Также огромная проблема компаний — не рефлексивные люди вверху пирамиды. Ведь зачастую это руководители высокого ранга.

Инфантилизм

В какой-то момент все люди перестают развиваться, то есть рефлексировать. Этот возраст остановки развития можно назвать инфантилизмом. У каждого это происходит в разном возрасте. Человек решил, что ему все уже понятно в этом мире: уже все знает, уже всему научился. Или, быть может, кто-то сказал ему, что он умный, а он этому поверил. А может быть, человек стал успешным настолько, что решил дальше только отдавать, что нет смысла больше учиться. Может быть много причин, почему человек решает, что ему дальше не нужно развитие.

Представьте пирамиду человечества по возрасту. С возрастом количество рефлексивных уменьшается. После рождения все активно развиваются. Рефлексируют все, но все-таки останавливаются в определенный момент. В 2 года все развиваются, а вот в 90 лет почти никто, точнее, таких чрезвычайно мало.

4

Итого, проблема: с возрастом процент рефлексивных падает. Обращаете ли вы внимание, как родитель, на развитие вашего ребенка хотя бы до 20 лет. А то, бывает, происходит останов и в 15 лет – и подросток на всю жизнь.

Маржинальные усилия

Улучшаться невозможно большими рывками. Только маржинально, иначе не будет результата. К примеру, на тренировке ты жмешь 10 раз штангу, а больше нет сил, но, сделав усилие, ты жмешь дополнительный раз — вот и улучшение! В следующий раз ты жмешь 11 раз, но пытаешься сделать еще один жим: если смог — новое улучшение! И так это работает везде: ведешь переговоры, готовишь презентацию — каждый раз ты начинаешь все с самого начала, поэтому нужны маржинальные усилия, резкие скачки обычно не срабатывают.

И что еще важно — темп. Можешь быстро реагировать на обратную связь, можешь быстро адаптироваться, значит, маржинальные усилия быстрые и ты активно развиваешься. Иными словами, недостаточно быть рефлексивным, грубо говоря, умным, недостаточно быть молодым. Если ты медленно адаптируешься, даже получив и осознав обратную связь, то нет никакого результата. Это называется ленью. Маржинальные усилия нужны для развития, их нужно делать постоянно и поддерживать частый темп.

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

Если вам интересны материалы по трансформации процессов в крупных компаниях, рекомендуем группу Enterprise Agile Russia в Facebook. Будем обсуждать подходы к масштабированию, такие как SAFe и LeSS.

17 мар 2017, Сергей Рогачев
Другие статьи
nor
11 дек 2017, Алексей Дерюшкин
Что такое Agile-подход и зачем он нужен бизнесу?

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

Исследование Agile в России
24 ноя 2017, Сергей Рогачев
Отчет об исследовании Agile в России 2017

Компания ScrumTrek провела первое масштабное исследование востребованности и особенностей внедрения гибких методологий управления в России.

lego1
22 ноя 2017, Сергей Рогачев
Совместное планирование #4

Перевод книги Хенрика Книберга и Тирстеда Брэндсгарда про масштабирование Agile в компании LEGO, часть 4