Недавно Agile коуч (coach) Michael Sahota провел исследование влияния корпоративной культуры на Agile преобразования. Мы встретились с Майклом (Michael) и попросили его ответить на несколько вопросов.
InfoQ: Что вы думаете о корпоративной культуре и о ее влиянии на Agile?
Michael Sahota: Я стараюсь осмыслить и понять разные вещи, пытаюсь разобраться в моей вселенной. А это также означает – осмысление того, что я вижу в сообществе. Осмысление происходящего и попытка понять, что работает хорошо и что не работает. Активно я подключился, когда заметил, что некоторые вещи происходят неправильно. Люди переживают неудачу. С Agile-ом были серьезные неудачи, и мы не обсудили их.
InfoQ: Что вы называете неудачей для Agile?
Michael Sahota: Есть несколько вариантов. Вы можете поставить вопрос более тонко, если попросите каждого определить лично. Голосуем пальцами одной руки от нуля до пяти. Проголосуйте, насколько серьезной была ваша неудача при переводе компаний и команд на Agile. На Play4Agile в Германии я в основном получил оценки два и три. Когда я задал тот же вопрос на митинге XP Toronto, результат был более благоприятным, в среднем ближе к трем, двоек также было много, но зато и четверок больше. Но случаев полного успеха было не много.
Так что же с этими неудачами? Это из-за того, что люди не знают Agile? Из-за того, что они не знают, как внедрить Agile в компаниях? Или это из-за неправильного окружения, и мы просто пытаемся протолкнуть изменения, которые не подходят для данной ситуации? Вот где мне стало действительно очень-очень интересно, в чем же дело. Мне нужно было раскопать проблему и найти объяснение для нее. Я уже некоторое время знал о Модели культур Шнайдера (Schneider Culture Model). Michael Spayd представил ее мне во время серии семинаров, которые проводились для группы коучей (я был в этой группе).
Когда я прочитал книгу, я понял эту модель. Я стал использовать эту модель для объяснения некоторых неудач, которые возникали при переходе на Agile.
InfoQ: Вы ссылаетесь на модель Шнайдера. Расскажите немного о ней.
Michael Sahota: Хорошо, перед тем, как перейти к модели Шнайдера, я хочу сказать, что существует предостережение: все модели неправильные, но некоторые из них полезны.
В связи с этим, я считаю, что модель Шнайдера – это очень полезная модель для объяснения корпоративной культуры . Я не думаю, что это идеальная модель. Есть другие модели, которые более полезны для более глубокого (второго) взгляда на корпоративную культуру, и для того, чтобы изменить ее в более глобальной перспективе. Но для первоначального понимания культуры и для понимания разницы между Kanban, Software Craftsmanship и Agile, это очень хорошая начальная точка.
Модель Шнайдера очень проста. Она говорит о том, что есть четыре ключевых типа культуры. С точки зрения Agile, наиболее распространенной является культура взаимодействия (collaboration culture), когда мы добиваемся успеха работая вместе. Это о людях, работающих вместе, как о источнике успеха. О таких вещах как командная работа, взаимодействие, о вещах, которые имеют место для такого типа культуры.
Другая часть Agile культуры связана с ростом и развитием. Это о обучении, личном росте, о нахождении базиса, когда люди хорошо работают, зная, что им нужно делать, чтобы быть успешными, и когда у них есть представление о и цель работы, для того, чтобы двигаться в направлении успеха.
Наиболее распространенная культура в корпоративном мире – это культура контроля. Где есть стандарты, процессы, иерархия, и где компании достигают успеха за счет получения и поддержки контроля.
И последний тип – это культура компетенции. Это о том, чтобы быть лучшим. И это модель мастерства программирования (Software Craftsmanship). Это о разработке понятий совершенства, талант и способности. Итак, внутри модели Шнайдера есть четыре ключевые модели. Согласно модели, обычно в компании есть основная культура и вторичная, поддерживающая, культура.
Компании не единообразны. Может быть даже так, что своя культура есть даже у подразделения. И даже разные культуры внутри подразделения. Например, для разработчиков могут быть более характерны взаимодействие и творчество, а для системных администраторов может быть более характерна культура контроля, поскольку они должны поддерживать системы в рабочем состоянии. Вы можете наблюдать, как эту культурные различия выплескиваются, и создают проблемы между различными функциональными группами внутри компании. Чтобы решить проблемы такого типа и появились, например, девопы (DevOps). Возникает серьезная озабоченность тем, как добиться успеха в разработке, а также в администрировании.
InfoQ: В своем блоге Вы также упомянули о том, как расположены квадранты, и какие из них находятся в противоречии друг с другом. Объясните, как компетенция и взаимодействие противостоят друг другу в модели.
Michael Sahota: Хорошо. Это интересно. Модель взаимодействия – это о том, как люди добиваются успеха работая вместе. Модель компетенции, которая ей противостоит, – это о том, что успеха добиваются лучшие, те у которых есть мастерство и класс. Таким образом, понятие “лучший” – это как личная цель. Это звучит как: “Я хочу быть мастером по разработке ПО”. Я хочу быть высококлассным разработчиком или высококлассным специалистом, который создает user story или требования или сотрудником, который действительно компетентен в тестировании, или исследовательском тестировании, или автоматизированном тестировании или еще в каком-нибудь виде работы. Это об обучении и личностном росте и о том, чтобы быть лучшим. Т.е. это совершенно противоречит культуре взаимодействия.
В Scrum-е на самом деле нет понятия компетенции, в отличие от Extreme Programming-а. В XP большое значение имеют такие понятия, как мастер по разработке ПО (software craftsman), лучший по unit тестированию, разработке управляемой тестированием, по рефакторингу. XP породил понятие мастерство программирования, потому что все Agile движение было извращено Scrum-овским взглядом на мир, где основные модели культур – это взаимодействие и развитие.
Хотя, справедливости ради, надо сказать, что дело здесь не только в популярности Scrum и в его недостатках. Если мы посмотрим на манифест Agile, посмотрим на ценности и принципы, и впишем их в квадранты Шнайдера, мы увидим, что в принципах манифеста есть очень сильный перекос в сторону взаимодействия и развития, и только формальный кивок в сторону культуры компетентности.
И поэтому, я так думаю в 2009 году, Bob Martin огласил еще одну, пятую, ценность для манифеста: Мастерство против Чепухи, не так ли? Это было сделано в ответ на существующий дисбаланс в Agile сообществе: хотя Agile – это о создании и поставке качественного ПО, порой мы слышим, как люди говорят и говорят часами, даже не упоминая ПО. Т.е. это своего рода индикатор дисбаланса.
InfoQ: Есть ли проблема сосуществования противостоящих друг другу культур? Могут ли взаимодействие и компетенция быть одновременно?
Michael Sahota: Да. На самом деле это необходимо. Это звучит примерно так: “Нам нужны компетентные люди мирового уровня. Но этого не достаточно. Мы достигаем успеха, только когда работаем вместе, поэтому здесь нет места тем, кто не в команде. На самом деле, взаимодействие, наставничество и обучение – это путь для подготовки высококлассных сотрудников.” Фактически, это означает связь с культурой развития. Итак, это возможно, но наверное только для команд и компаний выстроенных снизу вверх, где это заложено в ядре, в основании. Вы не можете взять уже существующую организацию и сделать так, чтоб это вдруг заработало.
InfoQ: Может организация изменить свою культуру?
Michael Sahota: Консультантам по управлению я говорю, что в крупной организации для изменения культуры может потребоваться 10 лет. Я искал примеры среди компаний успешно использующих Agile. И я думал, что нашел такой пример в salesforce.com. Прекрасно. Однако, если посмотреть более детально, основатели компании считают переход на Agile возвращением к основным ценностям, от которых они отошли. Т.е. это не подходит в качестве примера того, как можно использовать Agile для преобразования компаний. Я думаю, есть люди, которые поддерживают мысль о том, что это возможно, но я еще не встречал людей, которые смогли бы объяснить это компетентно.
На концептуальном уровне я вижу, как это сделать, первоначальные и последующие шаги. Я верю и знаю, что вокруг команды или группы разработчиков можно создать что-то вроде защитного кокона, внутри которого вы можете вырастить другую культуру. Т.е. общая организационная культура контролируется компанией, но у вас есть руководитель, который говорит: “Хорошо, я собираюсь поддерживать мою группу. Я буду защищать их и помогу команде создать барьер, через который не может пройти остальная часть организации и воздействовать на команду.”. Внутри этого кокона команда основывает культуру развития, взаимодействия и компетенции и может делать все те замечательные вещи, которые поддерживает Agile, и может добиться отличных результатов. Это можно сделать, создав барьер вокруг команды, причем остальная часть организации не должна отвергать это, как чужеродный организм.
Т.е. я думаю, можно преобразовать части организации. Общая трансформация займет примерно лет 10. Это очень сложно для большой организации. И действительно, что вам нужно? OK, вам нужно ощущение срочности, когда все в компании говорят: “Нам нужно изменить то, что мы делаем или мы проиграем. Мы можем выйти из бизнеса. Поэтому нам необходимы изменения.”
InfoQ: Стоит ли попытаться и изменить свою культуру? Стоит ли это того?
Michael Sahota: Альтернативы нет. Я думаю, практики Agile приводят к изменению культуры и это вызывает негативную реакцию на Agile преобразования. Люди говорят: “Это глупые правила. Мы не хотим подчиняться им.”. А организация говорит: “Нет, вы будете”. И потом возникает дым, шум и взрывы. Вот что вызывает проблемы при переходе на Agile. То, что людей побуждают к изменению культуры, и не ставят в известность о том, что они действительно делают это.
Я называю это частью модели бессознательной некомпетентности. Это когда люди не осознают то, что они увидят во время преобразований, или когда они внедряют практики, и у них нет реального понимания, что собой представляет культура организации. На мой взгляд, общее понятие культуры, модель Шнайдера, действительно необходима людям, чтобы понять, где они сейчас и что они действительно пытаются сделать, и как сделать это безопасно, чтобы не вызвать негативную реакцию против Agile, или очень плохие случаи Scrumbut-ов, когда люди оказываются в еще худшей ситуации, из-за слишком хорошего понимания Scrum-а.
InfoQ: Какую роль играет Agile коуч в каждом типе культур?
Michael Sahota: Роль коуча (coach) или человека, занимающегося изменениями (change agent) заключается в том, чтобы помочь компаниям сделать изменения, которые помогут им попасть туда, куда они хотят прийти.А также помочь им улучшить их практики, с помощью применения некоторых Agile практик, причем это должно быть безопасно внутри их культуры, помочь компаниям принять изменения так, чтобы сохранить гармонию. В случае преобразований мы должны быть уверены, что компании знают, на что они подписались, должны убедиться в поддержке со стороны менеджмента, должны убедится, что есть ощущение необходимости перемен.
Отчасти это может быть что-то вроде выполнения модели Коттера (прим. переводчиков: http://en.wikipedia.org/wiki/John_Kotter). Я знаком с одним коучем, у которого есть набор карточек историй (story cards), которые можно использовать для каждой из восьми фаз модели Коттера. Там говорится, что нужно сделать в каждой фазе, и какие вещи должны произойти, чтобы можно было сделать это. Это один из подходов для поддержки преобразований. Я думаю, что Agile коучи получают высокую зарплату, не так ли? Им требуется много знаний, чтобы понять, как работает Agile, а преобразование организации – это совершенно другая область, да? Итак, есть модель Коттера, есть и другие модели, такие как сложные системы адаптации, и другие пути проведения изменений в организации. Коуч должен знать Agile, обладать навыками консультирования и содействия. Для проведения изменений в организации нужен другой набор знаний. Его необходимо получить тем коучам, которые хотят помогать компаниям в этой области.
InfoQ: Допустим, вы Agile коуч, вы оказались в некоторой организации, вы знаете модель Шнайдера, и внезапно вы поняли, что вы в организации с культурой развития. В чем отличие вашего подхода в этом случае, если сравнивать, например, с организацией с культурой взаимодействия?
Michael Sahota: Если ваша организация фокусируется на развитии, это означает несколько хороших вещей. Это означает. что вам нужно убедится, в том что у всех членов команды есть представление о концепции и цели. Это вроде первой ступени в Agile проектах. Убедитесь, что у команды есть концепция и миссия. Это действительно прекрасное место, на котором стоит сфокусироваться. Это мощный рычаг для управления. Можно сказать, что если мы хотим добраться до нашей цели, нам нужно сделать несколько других вещей, например, поддержать совместную работу, обратить внимание на технические практики, и т.п.
Для поддержки основной культуры, подтянутся другие культуры, которые не являются частью основной. Например, для поддержки нашего роста и обучения, необходима, совместная работа. Работа парами, скажем, может помочь людям расти быстрее.
InfoQ: Давайте посмотрим с другой стороны. Например, тот же коуч просыпается на следующее утро и оказывается в организации с культурой контроля.
Michael Sahota: Если мы находимся в культуре контроля, основной вопрос – это: “В какую игру мы играем?”. Это игра, в которой мы просто собираемся внедрить несколько небольших практик, чтобы сделать текущую систему менее болезненной? Мы собираемся создать защитный зонт над некоторой областью и создавать организацию с другой культурой внутри этой области? И тогда нам нужно сфокусироваться на том, что нужно для создания барьера вокруг команды или группы для эффективного функционирования.
Т.е. в зависимости от ответа на вопрос, изменяется природа наших активностей. Потому что если мы делаем что-то существенно отличающееся от остальной организации, мы должны быть уверены, что мы синхронизированы с ними, чтобы не потерять их, правильно? Я был в таких ситуациях, когда имел дело с PMO. Может быть, для команды лучше всего создавать диаграмму Ганта в этом случае. С точки зрения команды это пустая трата времени. Кто-то должен терять 5 часов в неделю на создание и поддержку этого. Но с другой стороны, эти 5 часов дают команде пространство, которое ним необходимо чтобы быть действительно продуктивными, работать вместе и получить высокую производительность. Это действительно стоит того. Лучше думать об этом так, чем “Это пустая трата времени, мы собираемся бороться с этим до последнего”. Более прагматично сказать: “Посмотрите, мы внутри более крупной культуры, и мы должны приспосабливаться, и это наша плата. И цена того, что мы делаем, стоит тех преимуществ, которые мы получаем.”
InfoQ: У вас скоро выйдет электронная книга. О чем она?
Michael Sahota: Мне всегда нравилось InfoQ , и то, что они публикуют электронные книги.Больше всего мне запомнилась первая книга Henrik-а Kniberg-а, Scrum and XP from the Trenches. Это было очень памятно для меня. Она понравилась мне, потому что она очень привязана к реальной жизни и очень актуальна, легко читалась, не слишком длинная, очень конкретная и целенаправленная. Таким образом у меня появилась идея о создании книги,но я не знал точно, что это будет за книга. Это могла быть просто большая вырезка из моего блога, вот так смутно я себе это представлял следующие несколько лет.
Затем у меня была возможность сделать эту работу по культуре, и это действительно хороший цельный материал для книги. Я действительно хотел бы иметь возможность охватить больше людей и создать цельную историю, которую можно было бы прочитать и использовать для Agile в реальном мире. Так что это руководство по выживанию для людей, внедряющих Agile и тех, кто использует Agile , так чтобы Agile использовался во благо, а не во зло. Мы можем приносить пользу, внедряя практики или делая преобразования, и при этом не наносить вред компаниям. Я видел много вреда и хочу остановить это.
О интервьюируемом
Michael Sahota работает тренером и сертифицированным Scrum коучем в Agilitrix в Торонто, чтобы помочь предприятиям быть успешными. Это включает внедрение современных технологий разработки ПО, таких как Scrum или Kanban. Он помогает менеджерам продуктов (Product Manager) взаимодействовать с заинтересованными сторонами (stakeholders) и заказчиками, чтобы определить инновационные и значимые продукты с помощью Innovation Games®. Майкл является признанным авторитетом по Agile, регулярно участвует в конференциях и был выбран ведущим Agile блоггером. Майклу нравится ничем не сдерживаемое творчество и достижение революционных результатов через Игру. Кроме разнообразных игр и моделей, он играет в StrategicPlay® ( Lego® SERIOUS PLAY® ).
