Столкновение корпоративной культуры с Agile
Продолжаю серию статей «Менеджмент цифрового мира» (оглавление). В предыдущей статье «Изменение культуры в успешной Agile-трансформации» мы рассматривали основной сценарий успешной Agile-трансформации, изменяющий не только процессы, но и культуру компании. А в этой, 45 статье мы поговорим о том, какие угрозы возникают при реализации успешного сценария.
«Культура ест стратегию на завтрак», и эта фраза Питера Друкера в полной мере относится к проблемам Agile-трансформации. Для того, чтобы конструктивно работать с этими угрозами полезно рассмотреть восприятие ценностей Agile с точки зрения разных уровней Спиральной динамики, поскольку люди воспринимают рассказ о ценностях и культуре, интерпретируя его на основе собственного уровня развития.
Для начала напомним модель корпоративных культур из статьи «Культуры компаний в модели Спиральной динамики».
Культуры компаний в модели спиральной динамики. Из моих презентаций
Восприятие Agile в разных культурах
В фиолетовой культуре принадлежности и зеленой культуре согласия отзовется фокус на сотрудничестве и теплых отношениях, но будет не слишком воспринята процессная составляющая и ориентация на результат. В красной культуре силы лидеры воспримут Agile-методы как хороший способ организовать сотрудников, чтобы они пошли за вдохновенным лидером, пренебрегая ценностями самоорганизации и свободы сотрудников, заложенные в механизмы.
В синей культуре правил будут хорошо видны ритуалы, заложенные в процессы. Но в целом идея самоорганизации на основе ценностей входит в глубокое противоречие с культурой правил, в которой глубоко убеждение, что так работать могут лишь единицы, а всем остальным необходимы регламенты. Менеджеры оранжевой культуры успеха увидят в Agile-ценностях хороший мотиватор, и в процессах тоже увидят точки для интенсификации работы.
Кратко все это изображено на следующей схеме.
Восприятие Agile для разных уровней Спиральной динамики. Из моих презентаций
Такое восприятие крайне важно учитывать, когда вы собираетесь внедрить Agile в своей компании или команде и рассказываете о них. При этом, если десять лет назад люди узнавали про Agile впервые от того, кто предлагал изменения, то теперь многие знакомы с ним на основе публичных источников. А в этом случае интерпретация происходит дважды: сначала один человек, поверхностно познакомившийся с Agile, пишет статью или рассказывает о нем, делая свои акценты, а затем читатели воспринимают это на основе своего mindset. Поэтому необходимо представлять, какое представление об Agile-культуре и методах уже есть в компании, оценивать, как люди будут воспринимать ваш рассказ, и работать с их восприятием.
Модель спиральной динамики тут позволяет представить спектр возможного восприятия и помогает с этим работать, потому что восприятие Agile не изолировано, а является частью общей картины мировоззрения.
Недоверие к самоуправлению – часть культуры правил
Самоуправление в команде – конструкция новая и не привычная. Более того, синяя культура правил говорит о том, что самоуправление и инициатива встречаются довольно редко и их нельзя ожидать от всех сотрудников. То же самое говорит и оранжевая культура успеха, в которой организация разделена на две части: предпринимательскую, где инициатива приветствуется и исполнительскую, работающую по регламентам.
И, что важно, эти утверждения закреплены в mindset. Массовая школа нам прививает следование культуре правил, дисциплина учеников – одна из основных идей образования. Конечно, существуют и другие учебные системы, и сейчас некоторые из них получают широкое распространение, как ответ на вызовы современности, но основная масса сотрудников все-таки училась в традиционной школе. И это же продолжает институт, включая обучение современному менеджменту.
Каким же образом в этих культурных условиях Agile получил широкое распространение? Это произошло благодаря конструкции Scrum. Это жесткий фреймворк, учитывающий, что культура и привычки будут неосознанно толкать в сторону традиционного менеджмента, особенно на начальном этапе. Поэтому в процессы встроены предохранители против возврата к обычному процессу, а в руководстве и статьях про Scrum есть достаточно много предостережений. В их числе предостережения против неоправданной адаптации процесса, которые звучат примерно так: «Сначала вы должны понять устройство. Это возможно только через деятельность, а не по книге. Поэтому надо некоторое время работать, соблюдая процесс, и только потом – его изменять».
Заметим, что все это актуально даже для высокотехнологичных инженерных компаний. Например, при переходе к единой системе управления на основе Team Foundation Server в Лаборатории Касперского в 2011-2013 было принято решение, что основным шаблоном процесса будет Agile, а исключения необходимо специально обосновывать перед комитетом по изменениям. Заявок на исключения было много. Они разбирались и в большинстве были вскрыты, что проблема не в новом процессе, а в привычке к старому и нежелании изменений. И реальная необходимость была подтверждена только для двух подразделений из почти сотни.
И все это приводит к ряду негативных сценариев при Agile-трансформации
Феномен ScrumBut: культура и привычки ломают процесс
Типичная ошибка, которая возникает при внедрении – когда для сохранения существующей культуры из процесса вынимают предохранители, на предостережения не обращают внимания. И тогда daily scrum превращается в ежедневный отчет руководителю и получением заданий, оценку задач тоже делает руководитель или старший разработчик, а у исполнителя стоит задача просто в нее уложиться, задачи вбрасываются в середину спринта, потому что «срочно нужно» в произвольном количестве и так далее.
Целостность фреймворка разрушается, а идеи самоорганизации, которые и дают эффект – не реализуются. В лучшем случае получается, что почти ничего не изменилось, только названия поменялись, а в более плохих – еще и возрастают накладные расходы, потому что раньше, например, руководитель давал задание подчиненному 1:1, а теперь это слушает вся команда и 7 человек – то есть расходы времени возрастают в 3 раза. Да еще при этом разрушаются связи, построенные на личных взаимоотношениях и индивидуальном подходе.
В удачном случае внедрение прекращают, делая заключение, что «Scrum не для нас», или, чаще, «Scrum не работает, это лажа». Однако, признание ошибок неудачных изменений не свойственна ни синей культуре правил, ни оранжевой культуре успеха, поэтому официального прекращения внедрения Scrum не происходит, наоборот, официально это называются «Scrum, но с адаптацией», по-английски «Scrum, but …» – откуда, собственно, и пошло название ScrumBut. Как легко догадаться, из этого сделали и русский мем «СкрамНо»: «А как у вас? – А у нас как-то Скрамно ☺».
То же самое регулярно происходит и при внедрении других Agile-методов, просто Scrum появился раньше других, и его чаще пытались внедрять, поскольку есть фреймворк с готовыми правилами процесса. Но собирают не по инструкции, а как привыкли ☺. И это – не российская специфика, так происходит во всем мире.
Жесткое столкновение с синей культурой правил
Как уже говорили, в синей культуре правил идея самоуправления воспринимается скептически. Это распространено и в компаниях с квалифицированным персоналом: часто сотрудники верят, что только правильная научная организация труда, основанная на продуманном порядке способна дать высокие результаты. При этом это часто сочетается с высокой внутренней свободой и недоверием к любым инициативам сверху.
В результате сотрудники воспринимают Agile-трансформацию не как полезную вещь, изменяющую компанию к лучшему, а как очередной каприз руководства. Усиливающим фактором часто служит негативный опыт сотрудников, переживших неудачные попытки Agile-трансформации, например, видевших ScrumBut на предыдущих местах работы.
В результате реакцией на внедрение Scrum может быть попытка показать, что предлагаемый процесс не работает через жесткое следование процессу по сценарию итальянской забастовки: инициативные сотрудники изучают Scrum Guide и начинают требовать буквального исполнения, делая фокус на форме, а не на содержании.
Например, прекращать daily scrum или другую встречу по рекомендованному времени, несмотря на то, что ее цели не достигнуты. Проблема в том, что в этом случае цели встречи никогда не будут достигнуты, а процесс будет разваливаться из-за отсутствия необходимых элементов. Правильное поведение – другое: ретроспективно анализировать ход встречи и придумывать, каким образом его изменить, чтобы уложиться в рекомендованное время. Для этого есть выделенное время – ретро, однако никто не мешает поговорить об этом и внутри спринта, и попробовать какие-то идеи немедленно. Против этого, кстати, догматики тоже будут возражать: «Написано, что изменения на ретро – значит только на ретро».
В целом, это – достаточно конструктивная ситуация, открытые возражения – гораздо лучше скрытого саботажа и с ними можно работать. Как через рациональное убеждение, так и через постепенное внедрение отдельных практик, эволюционный путь вместо революционного. Накопленный опыт Agile-трансформаций показывает, что эволюция часто предпочтительнее революционного изменения, и встречаются доклады, в которых люди рассказывали, как столкнувшись на начальной презентации идеи с общим скепсисом сотрудников, они резко меняли курс, предлагая просто взять полезные практики, а не процесс целиком, и достигали успеха. Гораздо большего, чем в описанном ранее сценарии ScrumBut.
Agile не работает как средство оранжевой мотивации
Еще один негативный сценарий Agile-трансформации связан с восприятием ценностной составляющей Agile как средства мотивации и вовлечения персонала. Такое отношение в целом характерно для оранжевой культуры успеха. Конечно, ценности работают на вовлечение. Однако, необходимо, чтобы работа была осмыслена, ее цели вдохновляли. И это должна быть не декларация, а должно реально проявляться в повседневной деятельности. Если же это не так, то у сотрудников быстро наступает разочарование, и ожидаемый эффект не достигается.
Фишка в том, что Agile-процессы не просто предполагают прозрачность в отношениях с клиентами и сотрудниками, а практически ее реализуют. Ведь для ощущений не нужно формально открывать все показатели, достаточно мелочей и деталей, которые видны в повседневных взаимоотношениях с менеджерами и клиентами. А поскольку все это фиксируется в таск-трекерах, обсуждается на регулярных встречах команды, то это перестает быть делом частных коммуникаций и разовых случаев, любой может провести системный анализ. Аналогично в таск-трекерах видно, какой вклад вносит каждый из сотрудников в общее дело, он же обсуждается на встречах – и сотрудники могут соотнести его с уровнем вознаграждения, о котором неформальная информация обычно имеется.
Поэтому манипуляции сотрудниками, стремление за счет нематериальной мотивации повысить маржинальность проекта для фирмы и не делиться ею с сотрудниками. Аналогично сотрудники видят накрутки и манипуляции стоимостью проекта для клиента. И если руководство фирмы готово описывать это прозрачно «мы все просто ведем бизнес, вы участвуете на таких-то условиях», то проблем не возникает, за исключением отказа некоторых сотрудников участвовать в таком бизнесе. Но часто компания не готова к прозрачным взаимоотношениям. А в этом случае ценности начинают восприниматься сотрудниками, как пустые декларации, и вместо воодушевления и вовлечения идет отторжение и демотивация. Что опасно, часто переключение происходит скрыто, и становится явным, когда явление становится массовым и изменить отношение становится сложно или даже невозможно.
Опасения младших струн
Продолжая тему предыдущего раздела, отметим, что скептическое отношение к целям и ценностям, сомнение в них часто изначально присутствуют в компаниях. Как мы разбирали в статье «Культуры компаний в модели Спиральной динамики», в корпоративной культуре должны быть здоровые бежевая и фиолетовая струны, что означает хорошую социальную атмосферу, мы-восприятие всех сотрудников без противостояния исполнитель-менеджер или других вариантов свой-чужой, и уважение компании к сотрудникам и их базовым потребностям.
Однако, в традиционных компаниях часто дело обстоит не так, присутствует разделение сотрудников по уровням, сложные взаимоотношения между отделами, практика решения проблем компании или конкретных менеджеров за счет сотрудников. А в этом случае следует ожидать восприятия внедрения Agile-методов как способа заставить работать больше, платя меньше.
Более того, даже в компаниях со здоровой корпоративной культурой такое восприятие может быть со стороны сотрудников, которые работают недавно, и которые сталкивались с подобными попытками по опыту своих прошлых мест работы. Поэтому особым риском тут является большое количество сотрудников, пришедших недавно из компаний с токсичной атмосферой. А это что часто наблюдается в компаниях или отдельных отделах в период бурного роста.
Поэтому, проводя трансформацию, подобных возражений следует ожидать и конструктивно с ними работать. Основная проблема состоит в том, чтобы выявить такие возражения, потому что чаще всего они не высказываются явно, а обсуждаются в кулуарах. Однако, они могут проявляться завуалированно, в виде косвенных вопросов, к которым следует чутко относиться, выявляя смыслы и опасения, стоящие за ними.
Фокус на ценностях с потерей результативности
Зрелое руководство компании часто понимает опасности манипуляций и необходимость показать сотрудникам компании искреннее отношение к ценностям. Есть случаи, когда оно не только ожидает изменений от сотрудников, но и готово изменяться само для успеха Agile-трансформации, потому что видит в ней средство достижения компанией новых возможностей. И здесь возникает другая опасность – фокус на ценностной составляющей в ущерб результативности.
Дело в том, что в Scrum, и других Agile-процессах достаточно много вопросов, по которым команда должна договориться, выработать согласованное решение, как внутри, так и с руководством, заказчиками, смежными подразделениями. И если «договориться» трактуется как «учесть мнение каждого и прийти к консенсусу», то получается очень дорогой и медленный процесс. В результате все встречи – daily scrum, планирование, ретро, а также другие рабочие встречи, посвященные конкретным задачам, затягиваются на много часов и при этом не приводят к удовлетворительным результатам.
Продуктивность работы команды резко падает. Однако, команда не видит иных способов решения, кроме как вернуться к старым практикам управления. А это воспринимается как отказ от Agile. И возникает реальная проблема.
Отметим, реально в Agile-методы встроены механизмы, обеспечивающие прозрачность происходящего в команде для внешних стейкхолдеров и работу с целями. Если говорить о Scrum, то это доски, демо и целеполагание на спринт. И в целом это – не принципиально новые механизмы по сравнению с известными в менеджменте, это все – частные виды метрик, key performance indicator и управления по целям. Только понимаемые широко, а не примитивно как расчет бонуса сотрудника. Другое дело, что далеко не все менеджеры этим владеют. Подробнее я обсуждал все это в статьях «Kanban и Lean — эволюция вместо революции» и «OMG Essence и OKR – многофокусное ведение проектов и бизнеса в целом».
А развитие желтого уровня привело к выработке эффективных способов принятия решений, учитывающих мнение каждого, но без дорогого консенсуса. Это консент (consent), который я подробно разбирал в статье «Решение конфликтов в компаниях разной культуры», и его применение позволяет эффективно приходить к решениям в самоуправляемых командах.
Agile-курорт
Иногда развитие ситуации приводит к феномену, получившему название Agile-курорт. Это – относительно молодое явление, обязанное своему появлению массовому переходу на Agile IT-отделах обычных компаний. Руководство уже понимает, что это необходимо. Но не понимает, как управлять таким отделом. А люди внутри ограждают себя от излишнего напряжения. При этом апеллируют к тем частям процесса, в которых говорится о самостоятельном принятии командой обязательств, требуют от бизнес-подразделений квалифицированной постановки задач для начала работы, на демо – утверждают, что сделано то, что просили, отказываясь отвечать за применимость софта для решения проблемы, вызвавшей запрос.
Хотя явление распространено для IT-отделов, ситуация может возникать и в других подразделениях, например, пиара или HR или маркетинга, которые перестают работать на цели компании. Фактически, ценности во взаимоотношении с внешним окружением оказывается утерянными, хотя внутри создается теплая атмосфера локальной фиолетовой культуры принадлежности.
Как я отмечал статье «Культуры компаний в модели Спиральной динамики», в больших компаниях, и, особенно, в больших корпорациях часто есть островки подразделений с относительно сильной фиолетовой культурой принадлежности внутри, отгородившиеся или обороняющиеся от угроз внешнего мира. Для таких подразделений будет очень созвучна ценностная и социальная составляющая Agile-культуры кооперации и взаимодействия, и они ее воспримут. Но кооперация будет подразумеваться только внутри, а не с соседними подразделениями. А вот часть культуры и процессов, ориентированная на результативность и кооперацию снаружи, воспринята не будет.
Более того, будет решаться задача: каким образом использовать все ритуалы для уменьшения собственной работы и укрепления границ подразделения. И если подразделение успело достаточно жестко оформить свои границы, то изменение ситуации будет очень тяжелым, опасность лучше зафиксировать на начальном этапе.
У нас адаптация или ScrumBut?
Отдельная проблема состоит в том, что Scrum-процесс спроектирован для относительно узкого класса проектов и неявно предполагает много условий, в которых соблюдение процесса возможно. Например, наличие Product Owner, понимающего траекторию развития продукта и способного при планировании оперативно и ответственно принимать решения. Или присутствие на демо стейкхолдеров, способных воспринять демонстрацию и дать релевантную обратную связь. В конкретной команде или компании этот идеал достижим далеко не всегда, и необходима адаптация процесса с самого начала, а не после некоторого срока работы. За двадцать лет развития накоплен достаточный опыт таких адаптаций, однако люди опасаются их применять, не потеряв суть Scrum. Ведь в Scrum Guide написано, что сначала надо принять процесс, а лишь потом его изменять, то же говорят многие гуру.
При этом далеко не всегда в компании есть опытный agile-коуч или другой авторитетный сотрудник, хорошо разбирающийся во внутреннем устройстве Scrum или другого Agile-фреймворка и способный аргументированно показать, что предлагаемая адаптация не приводит к потере ценностей и сути Agile. Может показаться, что это – надуманная проблема, раз уж есть объективные обстоятельства – учти их и работай по-другому. Однако, достаточно активно общаясь в разных контекстах с теми, кто использует Agile-методы, я хочу заметить, что проблема – актуальна и серьезна.
В одних случаях адаптацию делают и люди работают по-другому. Но они постоянно сомневаются, настоящий ли у них Agile, или у них симуляция и показуха, ScrumBut или какой-то другой вариант фиктивно-демонстративного внедрения. И эти сомнения демотивируют и лишают энергии.
В других случаях люди следуют букве и реально сожалеют о потере продуктивности, которая была при старых методах управления. И от этого начинают сомневаться в собственных способностях, ведь у них не получилось применить Agile-метод, а столько вокруг это сделали. И это еще больше снижает энергию и продуктивность работы.
В подобных сценариях необходимо обращение к сообществу профессионалов, разбор с ними конкретного кейса компании или команды. Не на уровне общих слов, а в деталях. И надо услышать несколько разных мнений, сопоставить, построить свое. Конечно, опытные коучи и тренеры сильно заняты. Однако, большинство из них присутствуют в социальных сетях, проводят вебинары, в том числе бесплатные или дешевые и вполне доступны для небольших консультаций бесплатно или платно. Собственно, это же относится и ко всем негативным сценариям. Если вы чувствуете, что Agile-трансформация развивается не так, как ожидалось, полезно получить взгляд со стороны, и лучше – не один. Его стоимость обычно невелика по сравнению с потенциальными потерями.
Только помните, что это будет оценка ситуации и варианты действий, а не единственно правильный рецепт. Ответственность на выбор решения и его осуществление никто не возьмет. А если возьмет, то успеха Agile-трансформации ожидать просто глупо. Нельзя построить организацию на основе самоуправляемых команд, если принимать управленческие решения никто в компании не способен, а хочет отдать это сторонним экспертам.
Юрий Велигорский: Что такое Agile и с чем его едят?

Юрий Велигорский – Agile-коуч и Scrum-тренер, приглашённый преподаватель Advance Business School по направлению Agile/Scrum. Помогает создавать Agile-культуру и выстраивать гибкие процессы как в IT , так и не IT-компаниях. Помогает командам становиться эффективнее, постоянно улучшать продукт и повышать эффективность бизнеса.
Про Agile
Agile — это философия с определенными взглядами и ценностями, которой должны руководствоваться команды для эффективной работы. Она не содержит конкретных инструкций. В ее основе 12 принципов и 4 ценности, которые описаны в «Манифесте гибкой разработки ПО».
В Agile вся работа держится на четырех основных ценностях:
- Люди и взаимодействие важнее, чем процессы и инструменты.
- Сотрудничество с заказчиком важнее переговоров по контрактам.
- Рабочий продукт важнее исчерпывающей документации или презентации.
- Реакция на изменения важнее, чем следование изначальному плану.
В мире, где все быстро меняется, каждая компания хочет идти в ногу со временем и успевать за трендами. Для этого нужно срок от идеи до выхода продукта на рынок делать максимально коротким.
Когда вы маленькая компания, стартап — это может быть не сложно. У больших компаний есть два варианта. Добиваться результатов жестко-директивно и долго. Или сделать так, чтобы ваши сотрудники были счастливы, могли влиять на процессы, давать обратную связь и у всех был четкий ориентир куда и как им идти. Если коротко — это и есть Agile.
Стоит помнить, что Agile не должен быть целью. В первую очередь нужно стремиться к изменениям организационной культуры, открытости и прозрачности.
Scrum и другие умные слова…
Scrum, Kanban, LeSS, SAFe и другие умные слова — это способы организовать работу в духе Agile.
Часто говорят, что Scrum — методология. Но это не так, Scrum — фреймворк, шаблон процесса или скелет процесса. Это рамочное описание того, как вам стоит работать, чтобы достигнуть своей цели. При этом, используя данный фреймворк, можно добавлять что-то свое, что не противоречит структуре и ценностям Scrum.
Зачем нужен Agile-коуч?
Люди часто спрашивают: «Кто такой Agile-коуч?». Термин состоит из двух слов. Agile мы уже разъяснили. Коуч — это проводник. Человек, который помогает идти к своей цели, содействовать позитивным изменениям. Сначала может показаться, что это «традиционный консультант», но есть принципиальное отличие. Консультант говорит как надо делать, а коуч помогает, чтобы клиент сам пришел куда стремился. Можно сказать, что Agile-коуч — это тренер, учитель и наставник, фасилитатор, ментор, и эксперт в Agile в одном лице. Он работает как на уровне команды, так и на уровне организации.
Работа Agile-коуча — это не просто работа с командой, а глубинные организационные изменения всей компании.
Agile только для IT ?
Да, есть мнение, что Agile подходит только для IT-отраслей. Оно скорее основано на том, что Agile движение было создано группой разработчиков. Но сегодня этими принципами руководствуются самые разные компании во всем мире. А успешный опыт в банковской, страховой, медицинской и во многих других сферах показывает, что Agile можно применять где угодно, независимо от компании, страны и сферы деятельности.
Ведь Agile — это культура, а культура не знает границ!
Какие проблемы решает Agile?
Многие руководители хотят, чтобы люди работали быстро и эффективно, были готовы к неопределенностям в работе, а процессы были понятны. При этом чтобы взаимодействие было открыто и прозрачно. Красиво звучит, верно?
Вот с этим всем и работает Agile. Ведь Agile это не конечное состояние, а образ мышления и жизни.
С чего начать “ гибкие изменения”?
Важно понимать, что Agile, как и любое культурное изменение, не запускается по движению волшебной палочки. Agile-трансформация — это полноценный проект и довольно длительный по времени. Чем меньше компания и меньше подразделение, тем легче и быстрее будет проходить процесс трансформации. В крупных компаниях трансформация может длиться 3 – 5 лет. К сожалению, нельзя просто запланировать, что мы станем Agile, и через полгода это само собой произойдет.
Начать этот процесс необходимо с понимания того, где сейчас находится компания и где она хочет оказаться после трансформации. Между этими 2 точками нужно построить путь, чтобы понять план конкретных действий.
Про инструменты визуализации
Доска — это всего лишь инструмент, который помогает все максимально визуализировать.

Она может быть на флипчарте, стене или в электронном виде. Каждая команда выбирает ту доску, которая ей подходит больше всего. Но самое важное то, чтобы она улучшала взаимодействие между членами компании или команды.
Выбор доски зависит от команды, бюджета, ситуации, количества участников. Если говорить про электронные доски, то из бесплатных или условно бесплатных можно выделить Trello и Redmine, каждая со своими особенностями. Из известных компаний VersionOne или Jira. Из украинских компаний выделю Worksection, которая недавно выпустила доску задач. Очень надеюсь, что у данного продукта появятся киллер-фичи, которых нет у большинства досок. Например, ограничения по количеству задач в столбике или на человека. Или срочная полоса задач (когда владельцу данной задачи необходимо, чтобы ее выполнили раньше других), но во многих инструментах этой функциональности нет.
Про внедрение
Частый вопрос: «Что нужно, чтобы Scrum заработал?» Открываю секрет — серебряной пули не существует. Культурные изменения всегда происходят сложнее и дольше всего. Можно прийти на работу и сказать: «Сегодня у нас тренинг по Scrum и через три дня мы начинаем работать по Scrum». Нет, это так не работает. Agile – это не переключатель, который можно нажать у себя в компании и сказать: «Мы стали Agile».
Эта история скорее о том, как современные лидеры могут создавать среду, которая вовлекает команды в создание качественных продуктов для ваших клиентов.
С помощью Agile подходов современные руководители создают такую атмосферу в организации, чтобы людям хотелось достигать целей, чтобы эти цели их вдохновляли. Сотрудники не боятся предлагать свои решения, создавать что-то новое, они знают, что их никто не будет порицать за ошибку.
Agile — это не: «Коуч, сделай что-то с моими людьми». Это скорее: «Коуч, помоги мне стать лучшим лидером, чтобы я создал вовлекающую среду, научился слышать своих людей, и сделал из них классную команду».
Книги, которые советую прочесть:
- Джефф Сазерленд «Scrum: Революционный метод управления проектами»;
- Патрик Ленсиони « 5 пороков команды»;
- Книберг Хенрик «Scrum и XP : заметки с передовой».
1. Введение в гибкие подходы
Данный раздел коротко отвечает на вопрос: «Что представляет собой Agile?» — и раскрывает его основные термины. Дается общее представление о подходах для тех, кто уже слышал такие слова, как Agile, Scrum и спринт, но не имел возможности детально изучить тему
Данный раздел коротко отвечает на вопрос: «Что представляет собой Agile?» — и раскрывает его основные термины. Дается общее представление о подходах для тех, кто уже слышал такие слова, как Agile, Scrum и спринт, но не имел возможности детально изучить тему
Время чтения: 8 мин.
Согласно современному пониманию, Agile (agile software development, от англ. agile — быстрый, проворный) — это набор принципов и подходов, направляющих ресурсы организации на быстрое создание продуктов, нужных клиентам. C 2001 года Agile применялся для создания программного обеспечения и рассматривался как семейство гибких подходов к управлению разработкой.
- фокусируется на нуждах и целях клиентов;
- упрощает оргструктуру и процессы;
- выполняет работу короткими циклами;
- максимально быстро создает ценный и необходимый для клиента результат, чтобы получить обратную связь;
- активно использует обратную связь;
- принимает полномочия и ответственность и демонстрирует высокий уровень самоорганизации;
- берет за основу гуманистический подход.
Время чтения: 8 мин.
Согласно современному пониманию, Agile (agile software development, от англ. agile — быстрый, проворный) — это набор принципов и подходов, направляющих ресурсы организации на быстрое создание продуктов, нужных клиентам. C 2001 года Agile применялся для создания программного обеспечения и рассматривался как семейство гибких подходов к управлению разработкой.
- фокусируется на нуждах и целях клиентов;
- упрощает оргструктуру и процессы;
- выполняет работу короткими циклами;
- максимально быстро создает ценный и необходимый для клиента результат, чтобы получить обратную связь;
- активно использует обратную связь;
- принимает полномочия и ответственность и демонстрирует высокий уровень самоорганизации;
- берет за основу гуманистический подход.
Подходы Agile являются не конечным состоянием, а, скорее, образом мышления (mindset) и жизни. Гибкие проекты реализуются в итеративноинкрементальном ключе. Это означает, что реализация проекта (создание продукта) ведется итерациями — небольшими этапами длительностью от 1 до 4 недель.
В конце каждой итерации (как правило, она называется спринтом) достигается конечный результат — создается версия продукта, набор функций и т. д. (см. раздел 3). Готовый результат (инкремент) полагается представить заинтересованным сторонам, возможно, конечным пользователям для получения обратной связи и принятия решения о выпуске или определения направлений улучшения/доработки.
Каждый инкремент должен иметь ценность в первую очередь для пользователей продукта, заказчиков и — в идеальном случае — для всех иных заинтересованных сторон (стейкхолдеров). Более того, каждый последующий инкремент привносит добавленную ценность по сравнению с предыдущим. Инкрементальная разработка помогает максимально быстро создать минимально жизнеспособный продукт (от англ. Minimum Viable Product, MVP) (см. раздел 3.2.6). С его помощью проверяются гипотезы и предположения о требуемых результатах проекта, организуется работа с обратной связью.
Разработчики манифеста: Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas, Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith.
Agile Manifesto был разработан и принят в 2001 году на лыжном курорте The Lodge at Snowbird в горах Юты (США). В разработке этого основополагающего документа Agile-подхода принимали участие 17 экспертов в области разработки ПО.
- Люди и взаимодействие важнее процессов и инструментов.
- Работающий продукт важнее исчерпывающей документации.
- Сотрудничество с заказчиком важнее согласования условий контракта.
- Готовность к изменениям важнее следования первоначальному плану.
12 основополагающих принципов Agile-манифеста:
1. Наивысшим приоритетом для нас является удовлетворение потребностей заказчика благодаря регулярной и ранней поставке ценного программного обеспечения.
2. Изменение требований приветствуется даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.
3. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
4. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
5. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
6. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.
7. Работающий продукт — основной показатель прогресса.
8. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки.
9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
10. Простота — искусство минимизации лишней работы — крайне необходима.
11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
12. Команда должна систематически анализировать возможные способы улучшения эффективности и, соответственно, корректировать стиль своей работы.
Данные 12 принципов являются своеобразным чек-листом, который позволяет понять, насколько вы соответствуете Agile или даже что делать в сложном случае.
Взаимосвязь ценностей, принципов и конкретных инструментов Agile, которые группируются в тех или иных фреймворках (наборах инструментов и практик по применению гибких подходов), проиллюстрирована на рисунке 1.
Рисунок 1. Взаимосвязь ценностей, принципов и инструментов Agile
Сходство и различие между понятиями «методология» и «фреймворк» рассмотрены в статье: Wood M. Why You’re Confusing Frameworks with Methodologies // Project Management. URL: https://www.projectmanagement.com/articles/278600/Why-Youre-Confusing-Frameworks-with-Methodologies.
Зыкова С. Agile, scrum, kanban: в чем разница и для чего использовать? // Rusbase. URL: https://rb.ru/story/agile-scrum-kanban/.
Зыкова С. Agile, scrum, kanban: в чем разница и для чего использовать? // Rusbase. URL: https://rb.ru/story/agile-scrum-kanban/.
Разные гибкие подходы к управлению развиваются под общим названием Agile-подходов, что иногда вызывает определенную путаницу в понимании (см. также раздел 3.1). На иллюстрации выше описана связь всех компонентов Agile, включая наиболее распространенные фреймворки (наборы инструментов и практик по применению гибких подходов) в частности Scrum и Kanban (см. раздел 1.4).
Важно также понять, что подразумевается под продуктом в данном документе, для чего приведем несколько определений.
Продукт проекта (в понимании большинства классических подходов) — финальный результат проекта, который должен быть объективным, проверяемым и документированным.
Продукт (в контексте гибких подходов) — материальный или нематериальный объект, услуга или сервис, который предоставляется для удовлетворения потребностей клиента и который можно вывести на рынок. Также предполагается, что продукт должен иметь измеримую ценность для клиента. При сравнении двух определений видно, что продуктом проекта может быть любой «артефакт», то есть результат целенаправленной деятельности человека. В гибком контексте это определение продукта более узкое, фактически содержит дополнительные требования. Далеко не у каждого «артефакта» есть свой клиент, потребности которого «артефакт» удовлетворяет и для которого имеет измеримую ценность, и при этом есть возможность представить его на рынке. Agile равно эффективен в рамках как проектного, так и продуктового подхода, соответственно, в данном документе большинство рекомендаций можно применять и в реализации проекта, и в создании продукта иным, «непроектным» способом. В случае если есть отличия в реализации разных подходов, это будет явно отмечено в тексте.
Признаки и характеристики корпоративной культуры Agile

В последние годы все больше компаний внедряют в практику своей работу инструменты и техники методологии Agile. Эффективная работа по модели Agile требует соответствующей рабочей атмосферы, характеризующейся инициативностью, командной работой и терпимостью к рискам.
В статье рассматриваются признаки и характеристики организационной культуры Agile, а также принципы гибкого корпоративного лидерства. Рассмотрены три уровня признаков Agile-культуры, матрица конкурирующих ценностей, благоприятные и неблагоприятные факторы для внедрения методологии Agile.
Динамичность и гибкое функционирование бизнеса обусловлены внедрением в корпоративную среду и развитием ценностей, поведенческих моделей и компетенций, которые повышают адаптивность, творческие возможности и устойчивость подразделений компании и в целом организации. В условиях быстро меняющейся бизнес-среды с высоким уровнем неопределенности гибкость компании может иметь решающее значение в конкурентной борьбе и в достижении стратегических целей. Превращение компании в «гибкую организацию», или Agile-трансформация, требует изменения традиционных управленческих моделей, затрагивая модели лидерства, корпоративные ценности и нормы поведения. Корпоративная культура Agile-организаций имеет ряд характерных особенностей, которые некоторые эксперты называют «ДНК Agile-культуры» [1]:
Понятные цели и значимые результаты: четко сформулированные вдохновляющие цели с фокусом на результатах, которые важны для всех стейкхолдеров.
Модель гибкого лидерства: поддерживающий стиль руководства, при котором лидер поддерживает и помогает своим подчиненным в их работе, участвует в процессе принятия решений, в то время как решения принимаются в большей степени подчиненными.
Благополучие и самореализация: удовлетворение от профессиональной деятельности, позитивный настрой вместо страха наказания, стрессов, апатии и профессионального выгорания; стремление к положительным эмоциям от персональных профессиональных достижений.
Коллаборативные сообщества и распределенные полномочия: сеть сотрудничающих рабочих команд с большой автономией для принятия решений.
Доверие и открытость: лояльность, добросовестность, приверженность открытости и честности в ежедневной работе.
Адаптируемость к изменениям: способность, обеспечивающая стабильность при переменах внутри и за пределами компании.
Инновации, обучение и личный профессионализм: психологическая безопасность, продуманное экспериментирование, обучение и рефлексивная практика, способствующие росту личных профессиональных качеств и мастерства.
Организация, корпоративная культура которой содержит значительную часть перечисленных выше элементов ДНК, может рассчитывать на успех в применении Agile подхода во всех аспектах своего бизнеса. ДНК Agile-культуры «живет» в большей степени в каждом из сотрудников компании, нежели в корпоративных структуре, процессах и системах.
Корпоративная культура представляет собой глубинные установки, ценности и убеждения, которые распространены в организации, охватывая все ее функции. Культура оказывает влияние на действия сотрудников и рабочих групп и наоборот. Для описания Agile-культуры удобно использовать трехуровневую модель Шейна [2], представленную в Таблице 1.
Таблица 1. Три уровня признаков Agile-культуры.
- Наблюдаемые элементы ДНК Agile-культуры
- Публично заявленные ценности, методы, инструкции и наставления
- Используемые методы и практики Agile
- Видимые артефакты Agile – диаграммы, графики и др.
- Наблюдаемые ритуалы и церемонии Agile
- Наблюдаемое поведение руководителей в стиле поддерживающего лидерства
- Наблюдаемое поведение сотрудников и рабочих групп, соответствующее принципам Agile
- Управленческие практики по методологии Agile
- Agile команды
- Корпоративный язык (устный и письменный), используемый в повседневной жизни
- Заявленные организационные ценности, философия и характеристики
- Заявленные ценности Agile
- 9 принципов лидерства в стиле Agile
- Недокументированные ценности и убеждения Agile, которые проявляются в действиях сотрудников и рабочих групп
- Неявные, принимаемые как должные установки, определяющие поведение, восприятие информации, образ мыслей и самоощущение
- Базовые установки не сформулированы, но могут быть обнаружены и исследованы на практике
Согласно модели Шейна, идеальный эффект наблюдается, когда существует полная согласованность всех трех уровней. Однако на практике часто встречается ситуация, когда многие модели поведения сотрудников представляются необъяснимыми. Различные бессознательные установки становятся необсуждаемыми и формируют устойчивые модели поведения, которые трудно изменить. Кроме того, Agile-культура сильно зависит от национальных контекстов, связанных с принятыми в обществе моделями поведения, устоявшимися рабочими практиками и культурными традициями.
При описании характеристик Agile-культуры приходится сталкиваться с так называемым «парадоксом конкурирующих ценностей» [3]. Ценности, связанные с ориентацией на потребителя, могут вступать в противоречие с ориентацией на внутренние процессы, а стремление к стабильности может противоречить гибкости в принятии решений (Таблица 2).
Таблица 2. Конкурирующие ценности.
| Ценности | Описание |
|---|---|
| Ориентация на внутренние процессы | Фокус на разработку, сотрудничество, интеграцию действий, координацию |
| Ориентация на потребителя | Фокус на потребности и ожидания потребителей, конкуренцию, диверсификацию деятельности |
| Стабильность | Устойчивая организационная структура, планирование, бюджетирование, надежность |
| Гибкость | Гибкая организационная структура, способная быстро приспосабливаться к изменившимся обстоятельствам |
Матрица четырех конкурирующих ценностей показывает ключевые характеристики, на основании которых можно сформировать портрет корпоративной культуры в четырех размерностях: созидание, контроль, сотрудничество, конкуренция (Таблица 3). Ни одна из размерностей не является более важной, чем остальные. Большинство организаций имеют какую-либо преобладающую культурную размерность, при этом характеристики других размерностей могут присутствовать в той или иной пропорции. Кроме того, различные подразделения одной компании могут иметь неодинаковые характеристики по четырем размерностям.
Таблица 3. Матрица конкурирующих ценностей.
- Формирование рабочих команд, совместное выполнение задач
- Ответственное отношение, расширение полномочий, сплоченность, вовлеченность в процесс
- Личностный рост и развитие
- Коллективный разум, долгосрочное партнерство
- Совершенствование профессиональных навыков
- Создание новых решений, визионерство
- Управление изменениями и рисками
- Свобода мыслей и действий, выход за пределы стандартов
- Продуманное экспериментирование, обучение на ошибках
- Фокус на потребителя
- Организационное обучение
- Предотвращение ошибок
- Повышение согласованности и надежности
- Повышение эффективности процессов
- Внимание к деталям, тщательно подготовленные решения, точный анализ
- Консерватизм, осторожность, логика
- Координация и интеграция
- Соревновательность, быстрые действия, игра на победу
- Отслеживание состояния рынка и сигналов от потребителей
- Создание ценности для стейкхолдеров
- Скорость: любые промежуточные результаты должны иметь ценность для потребителя
- Выполнение задач, достижение целей
- Видение, движение в стратегическом направлении
Для того чтобы формировать корпоративную культуру в желаемых пропорциях, необходимы усилия лидеров и управленцев компании. Постоянные перемены при полном отсутствии стабильности, инновации без экономического эффекта не имеют смысла, поэтому Agile-культура характеризуется балансом всех четырех размерностей. Степень доминирования и преобладающей значимости размерностей может меняться в зависимости от географических и социокультурных факторов, однако важнейшими размерностями в Agile-культуре неизменно остаются созидание и сотрудничество [4]. Согласно исследованиям McKinsey, Agile организации научились быть одновременно стабильными (устойчивыми, надежными и эффективными) и динамичными (быстрыми в принятии решений, гибкими и адаптивными) в координатах Персонал, Процессы, Структура [5].
С точки зрения корпоративной культуры, стабильность включает в себя следующие характеристики:
- устойчивые разделяемые ценности, акцент на ответственности и сотрудничестве;
- согласованное поведение лидеров.
Динамичность организации проявляется в следующих особенностях:
- поддержка сотрудников в постановке личных профессиональных целей, поощрение энтузиазма;
- ориентация на инновационные идеи каждый день.
Методология Agile встраивается не в каждую организацию. Существует ряд благоприятных и неблагоприятных факторов, которые влияют на успешность и эффективность применения Agile методов [6]. В то время как корпоративная культура может быть открыта ценностям Agile, внедрение Agile практик в бизнес-процессы зависит от пяти групп факторов, касающихся Конъюнктуры рынка, Вовлеченности потребителей, Модульности бизнес-процессов, а также Влияния отдельных неудач и провалов (Таблица 4).
Таблица 4. Благоприятные и неблагоприятные факторы для внедрения методологии Agile.
- Предпочтения заказчика и варианты решения проблемы часто меняются
- Сотрудничество с заказчиком и быстрая обратная связь от него достижимы
- По мере развития процесса разработки заказчик лучше понимает, чего он хочет
- Условия, на которых работает заказчик, стабильны и предсказуемы
- Требования заказчика ясно сформулированы на начальных этапах разработки и остаются неизменными
- Заказчик недоступен для сотрудничества
- Задачи разработки сложны, решения неизвестны, масштаб проекта четко не определен
- Характеристики разрабатываемого продукта могут меняться
- Творческие прорывы и время выхода на рынок имеют существенное значение
- Кросс-функциональное взаимодействие крайне необходимо
- Похожие проекты выполнялись раньше, проектные решения очевидны
- Детальные спецификации и проектные планы прогнозируемы с высокой долей уверенности
- Задачи проектирования могут решаться последовательно в функциональных подразделениях
- Поэтапные разработки имеют ценность, и заказчик может их использовать
- Проектная работа может быть разбита на этапы и проводиться быстрыми итерационными циклами
- Изменения технического задания на поздних этапах разработки управляемы
- Заказчик не может начать тестирование частей разрабатываемого продукта пока разработка не будет полностью завершена
- Изменения технического задания на поздних этапах разработки крайне затратны или невозможны
- Неудачи и провалы рассматриваются как поставщики ценного опыта
- Неудачи и провалы могут иметь катастрофические последствия
Одна из основных ролей корпоративного лидера – создание, внедрение и развитие организационной культуры [2]. Действия лидера определяют тип корпоративной культуры, которая устанавливается в компании. Лидеры создают новые кросс-функциональные рабочие группы, команды и подразделения, тем самым создавая новую корпоративную культуру. Как только новая культура будет создана, она определит, какого рода лидерство будет цениться и быть допустимым.
По мере роста и развития организации ролью лидера становится поддержание и укрепление сложившейся корпоративной культуры, а также выбор руководителей, соответствующих ценностям и моделям поведения, принятым в организации. По мере дальнейшего развития организации существующая культура может в какой-то степени утратить свою функциональность, тогда задача эволюционирования культуры всецело ложится на корпоративного лидера.
Девять принципов так называемого «гибкого лидерства» лежат в основе желаемого поведения руководителей, задающих тон для Agile культуры.
- Дела говорят сами за себя.
- Улучшение качества мышления приводит к улучшению результатов.
- Организации совершенствуются за счет эффективной обратной связи.
- Людям нужны смысл и цель, чтобы работа приносила удовлетворение.
- Эмоции — это основа для развития креативности и инноваций.
- Лидерство проникает повсюду в организации.
- Лидеры делегируют соответствующие полномочия.
- Сообщества достигают большего, чем отдельные люди.
- Великие идеи могут прийти из любой точки организации.
Организационные изменения в целом представляют собой совокупность различных элементов, таких как технологии, процессы, организационная структура, персонал, культура и рабочие практики. Изменение организационной культуры — это трудный процесс, требующий от руководства большой целеустремленности и самоотдачи. Культура — это очень мощный корпоративный каркас, и любое изменение, которое находится в прямом противоречии с основополагающими ценностями и убеждениями, не будет работать. Agile культура постоянно развивается и эволюционирует, поэтому конечное ее состояние никогда не может быть достигнуто. Ценности Agile и ДНК Agile-культуры дают прочную основу для построения организации, способной адаптироваться к новым условиям рынка, гибко реагировать на изменения и неопределенность.
Библиография
- Bains, G. (2015), “Cultural DNA – The Psychology of Globalisation”, John Wiley & Sons, New Jersey, USA.
- Schein, E. H., (2016), “Organizational Culture and Leadership”, The Jossey-Bass (John Wiley & sons), 6th Edition, London.
- Schneider, W. E. (1994), “The Reengineering Alternative”, McGraw Hill, USA.
- Maximini, D. (2018), “The Scrum Culture: Introducing Agile Methods in Organizations”, Second Edition, Springer, Germany.
- Aghina, W., De Smet, A. and Weerda, K. (2015), “Agility: It rhymes with stability”, McKinsey Quarterly.
- Rigby, D. K., Sutherland, J. and Takeuchi, H. (2016), “Embracing Agile”, Harvard Business Review.
Источник: Журнал «Управление развитием персонала», №2, 2020.