Корпоративная культура и Agile
Недавно 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® ).
Тренер по Agile
Ускорьте движение к Agile по маршруту, уникальному для вашей организации, и помогите командам выполнять важную работу.
Что такое методология Agile?
Методология Agile — это подход к управлению проектами, предполагающий разбивку проекта на этапы, а также непрерывное сотрудничество и совершенствование. В рамках этого подхода команды следуют циклу планирования, выполнения и оценки.
Темы, связанные с agile
Манифест agile
В Манифесте agile выделены 4 ценности и 12 принципов работы для команд, но актуален ли он сегодня, десятилетия спустя? Читайте далее
Scrum
В методологии Scrum поставка продукта осуществляется в рамках серии итераций с фиксированной длительностью. Такие итерации называются спринтами. Благодаря им agile-команды могут поставлять ПО на регулярной основе. Узнайте, как scrum-методология влияет на традиционное управление проектами.
Kanban
Kanban — это популярная agile-методология, которая предполагает обсуждение возможностей команды в режиме реального времени и полную прозрачность рабочих процессов. Узнайте о преимуществах методологии Kanban для вашей agile-команды разработчиков.
Управление проектами по гибкой методологии Agile
Управление проектами по методике agile — это итеративный подход к управлению разработкой ПО, ключевую роль в котором играют непрерывные релизы и обратная связь от клиентов. Начните преобразование своей организации по методике agile с прочтения этой статьи.
управление продуктами
Руководство по работе менеджера по продукту или владельца продукта в agile-команде. Узнайте, как составлять дорожные карты, определять приоритеты для функций, разрабатывать документы с требованиями к продукту и принимать решения на основе аналитических данных по продукту.
Agile-подход при любом масштабе
Узнайте, как масштабировать работу в стиле agile с помощью методологий Scrum of Scrums или SAFe® (Scaled Agile Framework). Обе методологии прекрасно подходят для того, чтобы начать применять agile-подход на разных уровнях вашей организации.
Разработка программного обеспечения
Вы разработчик? Узнайте, как agile повышает эффективность написания кода, улучшает корпоративную культуру и делает процесс разработки ПО более гибким.
Как взаимосвязаны agile и DevOps?
DevOps и agile — это культурные движения, которые вдохновляют организации на достижение более высоких результатов. Ознакомьтесь с этой статьей, чтобы узнать о взаимосвязи agile и DevOps.
Преимущество agile
Методология agile появилась более 15 лет назад, но ничуть не утратила своей актуальности. Компании, использующие agile, по-прежнему сохраняют лидерство.
Обучающие руководства
Kanban для начинающих
Пошаговое руководство по ведению Kanban-проекта в Jira Software
Scrum для начинающих
Пошаговые инструкции по реализации Scrum-проекта в Jira Software
Продвинутые методики Scrum
Пошаговое руководство по ведению продвинутой scrum-программы в Jira Software
[ПРОДОЛЖЕНИЕ]
При использовании традиционного каскадного подхода к разработке один специалист заканчивает работу над проектом и передает эстафету следующему, самоустраняясь от участия в дальнейшем процессе. В отличие от этой модели, agile предполагает активное взаимодействие между участниками многофункциональных команд. В основе agile лежат открытое общение, совместная работа, адаптация и доверительные отношения между участниками команды. Хотя обычно за расстановку приоритетов между поставляемыми функциями отвечает руководитель проекта или владелец продукта, то, как будет выполняться работа, решает команда. Она самостоятельно выбирает, какие части работы выполнить и как разделить обязанности между участниками.
Agile не сводится к ряду собраний и конкретных приемов разработки. Agile — это группа методологий, в каждой из которых прослеживается стремление к безостановочному выполнению циклов обратной связи и непрерывному совершенствованию.
В первой версии Манифеста agile не были закреплены двухнедельные итерации или оптимальный размер команды. В нем просто были перечислены основные ценности, в центре которых были люди. Вы сами решаете, насколько строго нужно придерживаться этих ценностей вам и вашей команде. Неважно, практикуете ли вы Scrum строго по инструкции или сочетаете в работе Kanban и XP.
В чем преимущества agile?
Команды переходят на agile, чтобы быстро реагировать на изменения на рынке или отзывы клиентов и не нарушать планы, составленные на год вперед. Команда, которая осуществляет планирование по принципу достаточности и поставляет продукт часто и небольшими «порциями», может получить отзывы об изменениях и учесть их при составлении будущих планов без лишних затрат.
Дело не только в показателях. Главное — это люди. Согласно Манифесту Agile, естественное человеческое отношение при взаимодействии важнее неукоснительного следования инструкциям. Сотрудничество с клиентами и коллегами важнее стандартных договоренностей. А решение проблемы клиента важнее проработанной до мелочей документации.
Agile-команда имеет общую цель и достигает ее наиболее эффективным, по ее мнению, способом. Каждая команда устанавливает свои критерии качества, удобства пользования и готовности работы. По ним можно оценить скорость выполнения работы команды. Поначалу руководителей компаний может пугать мысль о том, чтобы доверить agile-команде такую ответственность. Однако со временем они обнаруживают, что это доверие только усиливает чувство ответственности и команда прилагает все усилия, чтобы оправдать (или превзойти) ожидания руководства.
Agile вчера, сегодня и завтра
Методология agile появилась в 2001 году, когда был издан Манифест Agile. С тех пор появилось множество agile-платформ, таких как Scrum, Kanban, бережливое производство и экстремальное программирование (XP). В основе каждой из этих платформ лежат главные принципы методологии agile: работа частыми итерациями, непрерывное обучение и обеспечение высокого качества. Scrum и XP пользуются популярностью среди команд разработчиков, а Kanban предпочитают команды, ориентированные на оказание услуг, например ИТ-отделы или отделы кадров.
Сегодня многие команды, следующие принципам agile, сочетают приемы из различных платформ, дополняя их собственными практиками. Одни команды внедряют ритуалы agile (например, регулярные стендапы, ретроспективы, ведение бэклога и т. п.), другие, например маркетинговые agile-команды, следующие принципам Манифеста Agile для маркетинга, создают новые практики agile.
В будущем для agile-команд собственная эффективность будет цениться выше, чем верность догмам. Открытость, доверие и автономия постепенно становятся ценными культурными ресурсами для компаний, которые хотят привлечь лучшие кадры и задействовать их с максимальной пользой. Опыт таких компаний подтверждает, что команды могут использовать разные подходы к agile, если они следуют фундаментальным принципам этой методологии.
Agile в компании Atlassian
Применение agile на практике должно учитывать уникальные потребности и культуру команды. В компании Atlassian нет двух команд, которые применяли бы agile одинаково.
Хотя многие наши команды работают спринтами, оценивают сложность работы в очках за истории и расставляют приоритеты в бэклогах, нас нельзя назвать фанатичными адептами Scrum, Kanban или любой другой зарегистрированной методологии. Каждая наша команда сама выбирает практики, которые могут помочь ей добиться наилучших результатов. Рекомендуем предоставить такую же свободу выбора и вашим командам.
Например, если ваша команда обрабатывает запросы на обслуживание по мере поступления, как ИТ-отдел, Kanban будет для вас идеальным решением. Но вы можете дополнить эту платформу несколькими собраниями Scrum, например сеансами демонстрации результатов для заинтересованных лиц или регулярными ретроспективами.
Чтобы правильно применять agile, нужно настроиться на непрерывное совершенствование. Экспериментируйте, пробуйте различные практики и обсуждайте их в команде. Продолжайте использовать те подходы, которые оказались полезны, и отказывайтесь от неэффективных.
Принципы использования этого сайта
Мы считаем, что каждая команда должна сама определять, как внедрять agile в свою деятельность, поэтому на этом сайте вы не найдете готовых рецептов. Здесь приведено прагматичное руководство по итеративному подходу к работе, обеспечению ценности для клиентов и реализации концепции непрерывного совершенствования. Ознакомьтесь с этим руководством, обсудите его со своей командой и внесите в рабочий процесс изменения, которые покажутся вам целесообразными.
Кроме того, на сайте есть обучающие руководства по применению этих практик в сочетании с Jira Software — нашим инструментом управления проектами для agile-команд разработчиков. Хотите создать и настроить доску Kanban? Нужно получить аналитические данные по скорости работы команды? Всю необходимую информацию вы найдете в наших обучающих материалах.
Вы на правильном пути. Вперед, к вершинам!
Как сделать организацию Agile-ной
В Agile роль менеджера заключается в том, чтобы помочь исполнителям проявить свои таланты и способности и создать ценность для клиентов, а еще устранить препятствия, которые могут в этом помешать. Менеджер доверяет суждениям и мудрости тех, кто соприкасается с клиентами, в выборе необходимой работы. Менеджер также доверяет талантам и возможностям сотрудников, чтобы выяснить, как лучше это сделать. Agile не работает «сверху вниз» или «снизу вверх». Его направление — снаружи вовнутрь. Основной фокус — доставка ценности клиентам. Здесь босс — клиент, а не менеджер.
В традиционном управлении роль менеджера абсолютно противоположна. Его функция — понять задачу, объяснить ее сотруднику, а затем проверить, что сотрудник завершил работу согласно инструкций. Роль сотрудника — следовать указаниям, доверяя решениям и опыту менеджера, чтобы необходимая работа была сделана правильно. Основная цель — заработать деньги для компании. Менеджер — босс.
В организациях, где живет фундаментальная вера в эффективность подхода «сверху вниз», где «менеджер — босс», сложно будет внедрить Agile. Постоянно будут возникать разногласия между различными целями и подходами. В результате, если внедрение Agile происходит только на уровне команды, оно рискует быть неполным и дисфункциональным, что вряд ли улучшит организационные процессы в целом.
Почему частичные изменения не работают
Частичным решением разногласий между Agile и менеджментом может стать переопределение роли непосредственного руководителя Agile-команды так, чтобы соответствовать Agile-подходу. Для менеджера нужно описать новые должностные обязанности, которые согласуются с Agile-идеологией. Если повезет, их даже формально утвердит вышестоящий руководитель.
Такой подход предлагает лишь частичное временное решение по нескольким причинам.
Во-первых, насколько действенным будет это официальное одобрение в большой организации, где над вышестоящим руководителем может быть три и больше уровней управления? Другими словами, разногласия между Agile-командой и иерархией просто перемещаются на один уровень выше по иерархии. Вряд ли эти правила будут соблюдаться, если все уровни не примут новую цель и новые подходы.
Одна из причин, по которой верхние уровни находятся в разногласии с Agile, состоит в том, что цель крупных компаний, как правило, зарабатывание денег для акционеров и топ-менеджеров в виде ежеквартальной прибыли, представленной на фондовом рынке. Такой подход известен в управленческих кругах как «максимизация акционерной стоимости». Эта цель решительно осуждается даже Джеком Уэлчем как «самая тупая идея в мире», но она по-прежнему широко распространена в крупных организациях.
Зарабатывание денег для акционеров в качестве основной цели противоречит ценностям Agile, в котором главное внимание уделяется доставке ценности клиенту. В Agile зарабатывание денег — результат, а не цель. Когда различные части или уровни организации преследуют разные цели, возникают постоянные разногласия. Если их не решить, переход к Agile на уровне команды вряд ли состоится.
Почему высшее руководство не любит Agile?
Реально ли вовлечь верхние уровни менеджмента крупной организации в Agile и новые роли менеджеров, не договорившись о цели организации? Опыт подсказывает, что нет.
Одной из причин приверженности командно-административным подходам и управлению сверху вниз является то, что цель зарабатывания денег для акционеров и топ-менеджеров по своей сути является неинтересной для сотрудников. Зарабатывание денег для босса не придает им легкости и бодрости, когда они идут на работу.
Таким образом, высшее руководство не имеет другого выбора, кроме как использовать командно-административные методы, чтобы сосредоточиться на производстве высоких квартальных прибылей и повышении цены акций. Как результат — безбожный альянс между стоимостью акций и иерархической бюрократией. Этот альянс создает среду, которая враждебна Agile и демотивирует сотрудников. По сути, топ-менеджмент должен заставить сотрудников подчиняться. Вследствии этого в масштабах всей экономики только один из пяти сотрудников полностью включен в свою работу, и еще меньше людей действительно неравнодушны к ней.
Почему SAFe небезопасен?
Одновременно, некоторые усилия по «масштабированию Agile», такие как Scaled Agile Framework или SAFe, тоже непродуктивны. Их целью является разрешение напряженности между Agile и руководством под видом «согласования» команд с корпоративными целями. По сути, они стремятся втиснуть ориентированные на потребителя Agile-практики в иерархические цели и структуры, которые ориентированы на акционеров.
Очевидно, что такой подход будет популярен у традиционных менеджеров, поскольку он избавляет их от необходимости вносить какие-либо изменения. Босс может продолжать быть боссом. Этот подход сохраняет и поддерживает существующую идеологию управления сверху вниз, ориентированную на акционера, а также предоставляет интересные бонусы топ-менеджменту для ее поддержания.
Но в процессе «стыковки» Agile-команд с корпоративными целями по квартальной прибыли и подъему цены акций, SAFe разрушает саму суть Agile. Наподобии неудавшихся причуд управления 20-го века, он уничтожает и подрывает аутентичное и полезное в Agile. От Agile остаются лишь пустые фразы и ярлыки.
Другой способ: креативная экономика
Некоторые организации, например Apple, Google и Zara, работают по-другому. Эти компании создали то, что называется Креативной Экономикой. Они сместили цели своих организаций с максимизации акционерной стоимости на удовлетворение клиентов. Эти организации на всех уровнях управления применяют клиент-ориентированную философию. Это отличная среда для Agile культуры. В таких компаниях использование Agile на уровне команды становится очевидным. Зарабатывание денег становится результатом, а не целью. Парадоксально, но как показывают примеры Apple и Google, такой подход может быть чрезвычайно прибыльным.
Урегулирования разногласий между Agile и традиционным управлением обычно невозможно достигнуть чисто рациональными средствами. Отчасти это связано с тем, что традиционная роль менеджмента часто имеет глубокие эмоциональные привязанности, отношения, ценности и взгляды на то, как работает мир, которые в совокупности составляют корпоративную культуру и идеологию. Некоторым менеджерам нравится быть «боссом». Даже те, на кого культура не воздействует, ведут себя так, будто они — ее часть.
Опыт показывает, что изменения корпоративной культуры или идеологии невозможно достигнуть путем внедрения методологий, описанием должностных обязанностей и решений, или предоставлением руководству жестких финансовых фактов, что радовать клиента — это действительно выгодно.
Вместо этого, чтобы убедить менеджеров перестать действовать как босс и поддержать Agile, необходимо привлечь их на более глубоком эмоциональном уровне через опыт и рассказы о лидерстве, которые позволят менеджерам принять другой набор симпатий, взглядов, ценностей и понимания того, как работает все вокруг. Менеджер фактически должен влюбиться в клиента.
Достижение такого взгляда — сложная лидерская задача. Это связано с тем, что роль менеджера в качестве босса встроена в культуру организации, которая содержит взаимосвязанный набор целей, ролей, процессов, ценностей, методов общения, отношений и допущений. Даже если менеджер лично хотел бы прекратить выступать в роли босса и начать любить клиента, культура затрудняет это изменение.
Элементы культуры взаимодополняют друг друга и объединяются в систему, чтобы предотвратить любые попытки ее изменения. Одиночные изменения на уровне команды, возможно, покажут некоторый прогресс, но в итоге взаимосвязанные элементы организационной культуры берут верх, и это изменение неумолимо исчезает в существующей организационной культуре.
Это не похоже на ремонт автомобиля, где, если вы поменяли шину, то она работает. Вместо этого организация действует как гениальный вирус, который непрерывно приспосабливается и, в конечном счете, побеждает, нивелируя изменения и возвращая все в начальную точку, иногда даже более опасную, чем раньше.
Переход к Agile включает пять основных изменений:
- Вместо того, чтобы делать деньги для организации, цель организации — радовать клиента.
- Вместо того, чтобы сотрудники отчитывались боссам поодиночке, работа выполняется в самоорганизующейся команде: роль руководства заключается не в том, чтобы проверить, сделали ли сотрудники нужную работу, а чтобы позволить тем, кто делает работу, вкладывать все, что они могут, и устранить любые препятствия, которые могут им помешать.
- Вместо работы, управляемой бюрократией с правилами, планами и отчетами, работа регулируется Agile-методами с итеративными рабочими циклами и прямой обратной связью от клиентов или их доверенных лиц.
- Вместо фокуса на эффективности и предсказуемости главными ценностями становятся прозрачность и непрерывное улучшение.
- Вместо директивных и односторонних, коммуникации становятся горизонтальными, партнерскими.
Принципы — это не случайный набор улучшений. Вместе они образуют взаимно усиливающую последовательность.
Как изменить организационную культуру
Завершение этих пяти изменений для внедрения Agile во всей организации обычно сводится к изменению корпоративной культуры. Конечно это сложное и масштабное мероприятие. В конце концов, все организационные инструменты изменения мышления приходят в действие. Но порядок их развертывания оказывает решающее влияние на возможность успеха.
В целом стратегия наиболее плодотворных успехов заключается в том, чтобы начать с инструментов лидерства, включая видение или рассказы о будущем, закрепить изменения с помощью инструментов управления, например определения ролей, систем измерения и контроля, а также использования инструментов власти, таких как принуждение и наказание в качестве крайней меры, когда все остальное терпит неудачу.
Потребность в историях от лидеров
Вдохновляющие аспекты лидерства, которые необходимы для изменения корпоративной культуры, во многом зависят от историй, рассказанных лидерами. Как я объясняю в своей книге «Руководство по сторителлингу для лидеров», рассказывание историй — это ключевой метод руководства, потому что он быстрый, мощный, свободный, естественный, бодрящий, дающий энергию, партнерский, убедительный, целостный, развлекающий, подвижный, запоминающийся и аутентичный. Истории помогают людям почувствовать глубокие изменения.
Лидерский сторителлинг — это больше, чем инструмент для достижения цели: это способ для лидеров — где бы они не находились — воплощать изменения, к которым они стремятся. Вместо того, чтобы просто пропагандировать изменения, подсовывая аргументы, которые обычно ведут к еще большему числу аргументов, лидеры могут вызвать доверие и самобытность, рассказывая истории, которые они действительно проживают. Когда лидеры сами глубоко в них верят, их истории резонируют, создавая творчество, взаимодействие и трансформацию.
Лидерский сторителлинг по своей сути хорошо адаптирован к решению сложной задачи изменения корпоративной культуры. Сторителлинг переводит сухие и абстрактные цифры в убедительные картины будущего. Несмотря на то, что хорошие бизнес-кейсы разрабатываются на основе цифр, они, как правило, утверждаются на основе истории, то есть повествования, которое соединяет множество событий в связанную последовательность.
Сторителлинг — ключевой инструмент для изменения культуры, потому что часто больше ничего не работает. Графики оставляют слушателей озадаченными. Проза остается непрочитанной. Диалоги слишком трудоемкие и медленные. Когда перед вами стоит задача убедить группу менеджеров или ключевых сотрудников крупной организации принять серьезные изменения, то сторителлинг — единственное, что работает.
Это происходит, потому что люди мыслят историями, а не абстракциями. Сторителлинг — инструмент непрерывного творчества, сила, которая неумолимо продвигает нас вперед в будущее, создавая новые миры и новых нас. Сторителлинг является частью творческой борьбы за создание нового будущего, в отличие от обычных коммуникационных подходов, которые ищут виртуальные якоря в призрачной безопасности прошлого.
Повествование опирается на активное, живое участие людей. Оно живет в опыте людей, которые действуют, думают, разговаривают, обсуждают, беседуют, шутят, жалуются, мечтают, мучаются и торжествуют вместе. Из них и состоит организация. Напротив, традиционная коммуникация занимается безжизненными элементами — формулировкой миссии, формальными стратегиями, программами, процедурами, процессами, системами, бюджетами, активами — инертными артефактами организации.
Сторителлинг — это больше, чем инструмент. Мы слышим историю, которая глубоко затрагивает нас, и тогда наши жизни наполняются смыслом. Как слушатели, мы получаем то, что значимо. Момент, в котором возникает эта связь и чувство удивления, может длиться недолго, и мы неизбежно возвращаемся в туман повседневной жизни. Но разница в том, что мы можем вернуться уже совсем другими.
История — то, что приходит извне. Смысл — то, что появляется изнутри. История с глубоким смыслом достигает наших сердец, захватывает нас. Как только это происходит, можно отпустить ее, ведь самое важное уже осталось с нами. Мы не устаем от такого опыта. Только мы услышали одну историю, тут же ждем другой. Мы хотим большего, если оно снова может передать магию связанности между нами и вселенной.
Через повествование мы можем отпустить желание контролировать и страх, который с ним связан, узнав, что мир способен самоорганизовываться, и признать, что управление включает в себя стимуляцию этой способности.
Результаты изменения культуры на Agile
Компании, которые перешли на Agile и ориентируются в работе на клиента, показывают постоянное улучшение результатов для своих клиентов благодаря инновациям и обеспечению значимой работы для своих сотрудников. Стартапы, которые следуют этим принципам, могут расти без потери гибкости.
Лидерам необходимо увидеть вызов, связанный с переходом от традиционного управления к Agile. Они должны увидеть, что мелкие изменения на более низких уровнях вряд ли будут устойчивыми до тех пор, пока проблемы не будут рассмотрены в целом. Они должны освоить новые методы управления и пути их передачи другим.
Основные принципы Agile быстро схватываются, но их реализация может занять целую жизнь. Задача лидеров — начать это путешествие длинною в жизнь.
Рекомендованные мероприятия
Agile — это фанатичное стремление к качеству
Антон Бевзюк присоединился к Райффайзенбанку в феврале 2020-го, через три года после начала перехода компании к гибким методологиям в создании цифровых продуктов, платформ и сервисов. 10-летний опыт Антона в преподавании гибких методологий в сочетании с 20-летним бэкграундом разработчика — отличная отправная точка для разговора о стадии зрелости банка в развитии Agile, , том, везде ли нужен Scrum и как обеспечить командам уровень IT-сервисов, как в Amazon
Вадим Ференец
Антон Бевзюк
Руководителя отдела развития гибких практик Райффайзенбанка
— Антон, свой путь в Agile Райффайзенбанк начинал вместе с консультантами из Unusual Concept и AgiliX. Зачем понадобилась внешняя экспертиза?
— Когда нужен прорыв, быстрые качественные изменения, проще нанять консультанта, который обладает богатым опытом, поработал с разными компаниями на рынке, может предостеречь от типичных ошибок, направить в нужную сторону. Unusual Concept и AgiliX, на мой взгляд, — самые опытные тренеры на рынке, это хороший выбор.
— Было ли на начальном этапе движения понимание, что Agile — это скорее философия, культура? Как это тогда и сейчас сочетается с консервативным имиджем банкира?
— Я не знаю, как все происходило на начальном этапе, но мне кажется, что Райффайзенбанк инициировал эти изменения осознанно. Имидж консервативного банкира устарел: банки точно так же, как другие компании, находятся в очень неопределенной среде с жесткой конкуренцией, в условиях падающего рынка, кризиса. Здесь выживает тот, кто хорошо приспособлен к изменениям, может быстрее реагировать, эффективнее и быстрее предоставляет лучший сервис за счет адаптивности и гибкости.
Agile давно проник в банковскую сферу. Огромный вклад в это внес Герман Оскарович. Кажется, он сделал для Agile-культуры в России больше, чем все бизнес-консультанты вместе взятые. Но «Райффайзен» — не тот банк, который посмотрел на Сбербанк и тоже захотел. Наш выбор был сделан осознанно, по нашим внутренним соображениям.
— В чем преимущество и отличие Scrum, LeSS и других фреймворков, которые банк использует в продуктовой разработке?
— Чем Scrum хорош? Тем, что он простой. В этом фреймворке мало лишних элементов. Чем хорош LeSS? Тем, что LeSS — это Scrum. Выбор в пользу LeSS был сделан неслучайно: люди, которые принимали решение, сравнивали разные фреймворки между собой, смотрели на Nexus, на SAFe, на LeSS и выбрали LeSS по причине логичности, простоты и элегантности. LeSS прост, логичен и понятен. По сравнению со Scrum в него добавлен всего лишь один элемент, и это позволяет организовывать работу до восьми команд над одним продуктом. В этом его главное преимущество и отличие от других фреймворков. В нем нет ничего лишнего.
Но это не значит, что в LeSS совсем все просто. В этих фреймворках есть глубина и определенные вещи, без которых они не работают: ценности, принципы, инженерные практики и так далее. Еще одно неочевидное свойство LeSS — он не просто выстраивает процессы, а изменяет структуру организации. Без этого никакие процессы не заработают. Если вы их будете «натягивать» на старую структуру, которая под них не приспособлена, ничего не изменится. Внедрение LeSS начинается с того, что мы изменяем структуру и потом уже в ней запускаем новый процесс. К сожалению, к таким масштабным изменениям не все готовы.
— Использование фреймворков предполагает изменение ролей. Появляются product owner или скрам-мастера, исчезают проектные менеджеры. Как воспринимает изменения существующий штат и готовят ли вузы кадры со соответствующим менталитетом?
— Роли меняются, и тут важно сделать плавный переход — люди, которые ранее работали, не должны чувствовать обреченность, ненужность и невостребованность. Они являются ценными носителями знаний, источниками экспертизы, у них есть опыт, отстроенные связи внутри организации. Если эти люди готовы к изменениям, готовы принимать ценности Agile, работать в другой роли и помогать организации двигаться вперед, то, скажем, из проектного менеджера может получиться прекрасный product owner или scrum master. Почему бы и нет? Ведь scrum master — это лидерская роль, и в ней важен управленческий опыт.
Те, кто не готов к изменениям, уходят. Это нормально. При изменениях всегда происходит отток. Те, кто готовы меняться, остаются и реализуют себя в новых ролях. Они воспринимают это как вызов, интересный опыт, новый эксперимент. Новые роли, такие как скрам-мастер, востребованы на рынке. Люди повышают свою ценность — это тоже хорошо.
Готовят ли вузы кадры с соответствующим менталитетом? Насколько я знаю — нет, и это большая проблема. У нас вузы до сих пор готовят даже разработчиков по моделям прошлого века, то есть их учат программировать, но не учат практикам совместной, командной работы. В некоторых вузах начинают появляться такие программы, но нельзя сказать, что они стали мейнстримом. У нас пока еще довольно консервативное образование. Я не видел институтов продакт-оунеров или скрам-мастеров. К счастью, выпускники — довольно открытые, подвижные люди, они готовы учиться.
— Культура Agile. Есть ли «религиозные» течения внутри, кого легко принимает коллектив, от кого старается избавиться?
— Из чего состоит культура, на самом деле, исчерпывающе описывает манифест. Во-первых, это опора на командные решения. Мы доверяем команде в том, что она готова на самоорганизацию и принятие лучших решений, чем каждый отдельный участник команды или менеджер. Мы думаем о том, какую пользу приносит в целом команда, а не каждый отдельный человек. Команда работает для того, чтобы приносить максимальную пользу клиентам и бизнесу. Это значит, что она не идет на поводу у каких-то формальных договоренностей, а воспринимает клиента как своего партнера и старается действовать в его интересах. Ну и конечно, это постоянная готовность к изменениям, потому что ради этого Agile и был придуман — выживать в неопределенной среде, когда ситуация все время меняется и нужно на нее реагировать. Это не исключение, а правило. Ты должен строить свой процесс из предпосылки, что в окружающем мире нет ничего постоянного. Именно поэтому культура Agile стоит на двенадцати принципах, среди которых доверие и качество. Мы доверяем команде, мы доверяем нашим продакт-оунерам, клиентам. Про качество, кстати, часто забывают. Очень часто Agile почему-то воспринимают как хаос и безответственность. На самом деле Agile базируется на фанатичном стремлении к качеству и на очень высокой требовательности друг к другу. При этом мы делаем ставку не на то, что кто-то придет и проверит, а на то, что команда сама будет отвечать за результат, постоянно меняться и постоянно учиться. Качество и доверие — это неотъемлемая часть Agile-культуры.
Есть ли «религиозные» течения? Провокационный вопрос. Наверное, есть. На этой культуре пытаются заработать все, кому не лень, возникают разные течения, школы, каждая из которых пытается создавать какой-то свой бренд и его монетизировать. Но тут важно не увлекаться каким-то конкретным течением, а помнить о ценностях и жить в соответствии с ними. В Agile-методах работы команда — это важнейшая сущность, на которую опирается весь процесс, поэтому важно не только то, насколько человек профессионален, но и то, насколько он способен работать в команде. Выполнять договоренности, адаптироваться, приспосабливаться к мнению других, объяснять спокойно свою позицию, выслушивать другую позицию, принимать совместные решения, соблюдать договоренности, которые приняла команда, постоянно обучаться.
Обучение — это еще одна важнейшая вещь в Agile. Люди, готовые учиться, нормально вписываются. Людей, которые паразитируют на других, команда сразу видит и быстро от них избавляется. Как и от людей, которые ценят себя выше команды, от токсичных персон, от тех, у кого «звезда во лбу», таких, знаете, ковбоев: «Вот я приду, сам все сделаю, всех спасу, ночь не посплю…». Командная работа — другая, она не полагается на ярких одиночек. Это не значит, что в команде все равны . Это значит, что команда антихрупкая. Если любой человек однажды не сможет выйти на работу, то команда все равно выживет, сделает работу с тем же качеством и в тот же срок. Это ее не убьет. А если не выйдет ковбой «со звездой во лбу», то все обречены.
— Как с такими особенностями Райффайзенбанк сосуществует с коллегами по группе RBI? Нет ли трений между географически распределенными командами из России?
— Agile-сообщество существует не только в России, мы с нашими венскими коллегами общаемся, делимся опытом и помогаем друг другу. Я бы даже сказал без ложной скромности, что российское отделение Райффайзенбанка по развитию Agile-культуры намного сильнее европейских коллег, и это скорее мы им помогаем и делимся нашим опытом. Мы уже выстроили роли, прошли определенные этапы трансформации, описали, чем занимается scrum master и другие роли в ADORE, описали грейды, и у нас есть понятная линейка развития. Мы создали программу подготовки ключевых ролей. Мы прошли долгий путь признания скрам-мастера — от полного непонимания, что это за роль, до текущей ситуации, когда команда скрам-мастеров подчиняется напрямую Сергею Монину. Такого нет нигде, не только в RBI, но и на российском рынке.
Нет ли трений между географически распределенными командами из России? В этом смысле удаленная работа сыграла нам на руку. Если раньше коллеги из Омска могли находиться в каком-то неравноправном положении (например, мы здесь собираемся в «переговорке», а они подключаются удаленно), то сейчас, когда все в равных условиях, это как раз помогло распределенным командам работать более эффективно.
— До какой степени зрелости Agile банк дошел сегодня? Нет ли на горизонте новых целей? Вообще, где предел совершенства в рамках этой философии?
— Зрелость в Agile неравномерная. Есть команды, которые приобрели очень большой опыт — они работают по Agile, Scrum и LeSS уже два-три года и прошли большой путь. Если хотите посмотреть, как работает настоящий Scrum (многие не верят, что он есть вообще), приходите к нам. Покажем, расскажем. Но такие команды, естественно, не все в банке. Есть другие, менее опытные команды, которые находятся только в начале этого пути. Те, кто только стартовали, сталкиваются со сложностями и проходят естественные этапы взросления, с которыми сталкивается любая Agile-команда.
Agile — это бесконечное развитие. Нельзя сказать в один прекрасный день: «Всё! Мы Agile-трансформацию закончили». Она не заканчивается никогда. В Agile заложен механизм постоянных изменений процессов, это никогда не прекращается.
Кроме этого, в зрелой Agile-организации люди понимают, где им нужен Scrum а где не нужен, и делают этот выбор осознанно. Scrum — очень дорогой фреймворк, который оправдан только в условиях высокой неопределенности. Его тоже нужно применять к месту. Компания, которая умеет это делать — собирать подходящие инструменты под подходящий контекст и отказываться от них вовремя, когда ситуация изменилась, — вот это и есть Agile-организация. В этом смысле многим организациям есть чему учиться, и нам в том числе.
Недавно мы провели опрос внутри банка, знакомились с командами, узнавали, в каком фреймворке они работают, куда хотят двигаться. Этот опрос дал нам очень много информации и почвы для размышлений о том, что будет дальше. Оказалось, например, что у нас 72 команды — больше половины — выбирают Scrum или LeSS. Это не только продуктовые команды, есть и сервисные команды, каналы, стримы и платформы. Эти команды находятся в разной степени зрелости, но у нас наработана очень сильная экспертиза, и мы готовы ее расширять. У нас есть опыт, сильное сообщество профессиональных скрам-мастеров, к нам приходят с рынка профессионалы, которые тянутся к этому сильному сообществу, хотят в нем жить и развиваться. То есть мы создали критическую массу, которая притягивает профессионалов. Это наша сильная сторона, и мы будем и дальше ее развивать.
У значительной части из этих 72 команд, которые хотят работать в Scrumе, нет скрам-мастера. Это значит, что мы им должны помочь. Возможно, некоторые из них не видят ценности в этой роли, не понимают ее до конца. И мы готовы предоставить сервис, то есть помочь запустить команду, обучить, рассказать про эту роль, продемонстрировать в деле, как она работает, помочь обучить участников команды, которые готовы взять эту роль на себя.
Оказывается, у нас есть довольно большое количество команд — целых 25, которые выбирают для себя Kanban, и этой экспертизы у нас в банке пока нет. Мы ее развиваем. Прямо сейчас мы создаем роль канбан-коуча, и человек в этой роли будет помогать становлению процесса Kanban.
Кроме того, в самой идее LeSS заложено развитие организационной структуры команды, которая работает над продуктом. Где-то границы продукта проведены неправильно, и их нужно пересмотреть, где-то они слишком узкие — команда выросла и нужно их раздвигать, где-то нужно их менять — эти вещи нужно делать постоянно. Равно как и усиливать автономность команд за счет более тесной работы между собой, обучения, упрощения технических и инженерных решений, автоматизации.
Agile опирается на техническое совершенство, это один из принципов. У нас много успехов — мы используем современные технологии, переходим на Kubernetes, наши команды IT-платформы ставят себе цель обеспечить такой же сервис для команд, как в «Амазоне», чтобы команды могли легко поднимать микросервисы за минимальное время, а затем самостоятельно их развертывать и обслуживать. Нам еще многое предстоит сделать вместе.