Публикации SIBE (16-20)

Agile-команды и психологическая безопасность

За последние 20 лет движение agile набрало поразительные обороты - существует agile HR, agile управление проектами, agile обслуживание клиентов, agile продажи, agile операции, и так далее. Но примерно половина организаций, которые проводят agile-преобразования, терпят неудачу в своих попытках. Если вашей команде еще предстоит воспользоваться плодами agile, вам необходимо понять, что мешает внедрять и масштабировать agile- решения, которые вы задумали. Нередко причина повала именно в культуре взаимодействия команды. Предлагаем пять практических способов повышения психологической безопасности для создания успешной agile-команды.
Оценив несколько agile-команд и проведя серию интервью с ведущими экспертами в области agile, исследователи пришли к выводу, что основным фактором неудачных переходов на agile является пренебрежение первой ценностью Манифеста Agile: "Личности и взаимодействие важнее процессов и инструментов". Этот манифест был опубликован 23 год - "Манифест гибкой разработки программного обеспечения", более известный как "Манифест Agile". В ответ на бюрократическую водопадную модель разработки программного обеспечения с ее линейными этапами и объемной документацией инженеры выступили за более гибкий подход, способный адаптироваться и преуспеть в высокодинамичной среде.
Эта простая декларация ценностей и принципов с тех пор породила глобальное движение, которое вышло далеко за рамки разработки программного обеспечения, постепенно расширяясь и включая под свой зонтик широкий набор инструментов, процессов и функций.
Agile в корне изменил то, как мы создаем программное обеспечение. Тысячи организаций могут подтвердить, что их усилия в области agile окупились с точки зрения скорости, качества, ценности и долгосрочного роста. Но не все могут так сказать - на самом деле, примерно половина организаций, которые проводят agile-преобразования, терпят неудачу в своих попытках.
Если вашей команде еще предстоит воспользоваться плодами agile, вам необходимо понять, что мешает вам предоставлять быстрые, беспроблемные и масштабируемые решения, которые вы задумали.
Процессы и инструменты не заменят культуры взаимодействия людей
Процессы и инструменты Agile обеспечивают поддержку, но центральным несущим механизмом agile-подхода является не scrum или спринт. Успех в конечном итоге определяется взаимодействием команды - как используется интеллектуальное трение (т.е. конфликтующие идеи) для выполнения взаимозависимой работы; способны ли члены команды давать и брать, говорить и слушать, задавать вопросы и отвечать, действовать и реагировать, анализировать и решать? Или же они деавторизируют друг друга и в итоге оказываются в режиме самосохранения? По сути, основная технология agile не является технической или механической. Она культурная. Agile-команды в конечном итоге полагаются на психологическую безопасность - среду вознаграждаемой уязвимости - для совместного процесса взаимодействия.
Высокая психологическая безопасность приводит к ‘реакции на результат’, когда целью является инновация, в то время как низкая психологическая безопасность вызывает ‘реакцию страха’, когда целью является выживание. Когда члены команды перестают задавать вопросы, признавать ошибки, исследовать идеи и оспаривать статус-кво, они перестают быть гибкими. Как, например, команда разработчиков может быстро создавать прототипы, если она парализована страхом? Или как может команда HR сделать справедливый отбор кандидатов, если они не могут спокойно указать на предвзятость?
Когда откровенная обратная связь, изучение нестандартных идей и несогласие с мнением большинства становятся источниками наказуемой уязвимости, люди перестают это делать. Как вы наказываете уязвимость? Вы критикуете, смущаете, обескураживаете, заставляете молчать, стыдите, запугиваете и устрашаете. В этот момент процесс взаимодействия в команде нарушается и в конечном итоге может разрушиться.
5 практических способов повышения психологической безопасности для создания успешной agile-команды
1 - Представьте agile как культуру
Вскоре после внедрения agile многие организации возвращаются к стандартной ошибке и возводят в культ технические процессы и инструменты, потому что культурные аспекты кажутся абстрактными и трудно реализуемыми. Проще перейти к скраммингу, спринтингу, канбанингу и кайзенингу, чем строить культуру agile - эти процессы осязаемы и измеримы, есть показатели, которую создают иллюзию успеха и видимость масштабного внедрения и развития agile.
Начните преобразование agile с определения agile как культурной, а не технической или механической трансформации. При этом будьте осторожны и не подходите к культуре как к рабочему процесс. Процесс - это поэтапное выполнение задач, необходимых для завершения проекта. Когда мы рассматриваем культуру как рабочий процесс в контексте agile, мы классифицируем ее как нечто, что может быть завершено. Культура не может быть завершена.
Помните, что всегда существует риск того, что культура команды вернется к нормам, основанным на страхе, поэтому сосредоточьтесь на отдельных людях и их взаимодействии как на самом высоком приоритете. Небольшие и, казалось бы, незначительные проявления неуважения, грубости или безразличия могут подтолкнуть команду к отказу от работы и управлению личными рисками. Внедрите в работу базовые поведения психологической безопасности такие как "дать людям закончить свои мысли, не перебивая их", “руководитель говорит последним и создает пространство для вопросов”, и т.д. Стремитесь моделировать эти поведения и они станут нормами, которые команда будет поддерживать во время взаимодействия
2 - Разработайте, задокументируйте и покажите примеры поведения и безопасные реакций на них.
Проведите встречу с командой, чтобы выявить уязвимые модели поведения и ожидаемые реакции на них. Попросите команду привести примеры таких поведение - что им делать сложно и/или неприятно во время совместной работы. Члены команды, скорее всего, начнут с определения общих моделей поведения, таких как задавание вопросов, предоставление обратной связи или предложение различных точек зрения. Продолжайте, пока не составите более длинный и более глубокий список. Затем определите положительные модели реагирования для каждого поведения. Например, вы можете назвать уязвимым поведением указание на ошибку, а затем сказать: "Спасибо, что указали на нее. Как вы думаете, в чем причина?" - как положительную реакцию на это.
3 - Зафиксируйте пары поведение/реакция и сделайте их публичными
Например, повесьте ю в комнате для совещаний или разошлите по почте. Если вы проводите виртуальные собрания, опубликуйте их в чате. Считайте список живым документом и возвращайтесь к нему во время ретроспектив спринта. Создайте печатную версию списка, которую члены команды смогут носить с собой, а также цифровую версию, которая будет служить подсказкой и руководством на виртуальных встречах.
4 - Сосредоточьтесь на одном поведении во время каждого скрама и практикуйте культурное моделирование - делайте сами, следуйте правилам
Теперь, когда вы совместно составили список уязвимых пар "поведение/реакция", выберите одну из них для отработки во время каждого спринта. Когда команда фокусируется на конкретном поведении и модели реагирования, это обеспечивает управляемый объем практики и активизирует совместную культурную ответственность.
Если между уязвимыми парами поведения/реакции и собственной моделью поведения лидера возникает разрыв, этот диссонанс порождает цинизм и подрывает доверие. Но если лидер стремится моделировать поведение и публично признает ошибки на этом пути, команда добьется синергетического прогресса. Лидер должен четко дать понять, что члены команды несут ответственность за то, чтобы отчитываться друг перед другом за выполнение и поощрять уязвимые модели поведения.
5 - Оцените свой процесс во взаимодействие в ходе ретроспективы спринта
Выделите время во время ретроспективы спринта - встречи, которая проводится в конце каждого спринта для анализа того, что прошло хорошо и что можно улучшить - для официальной оценки качества диалогового процесса команды. Сделайте этот обзор стандартной частью повестки дня.
Обсудите качество взаимодействия команды и определите потенциальные угрозы открытости. Задайте такие вопросы, как:
  • Чувствовали ли вы себя включенным в процесс? Почему или почему нет?
  • Какое наиболее уязвимое поведение вы совершили во время этого спринта? Как команда отреагировала на это?
  • Было ли что-то, что вы не сказали или не сделали, потому что не чувствовали себя в безопасности?
  • Проявляет ли команда демократическую модель участия и влияния? Почему или почему нет?
Скрам-собрания должны быть быстрыми, ежедневными координационными совещаниями, на которых члены команды просматривают бэклог, выявляют препятствия и определяют приоритеты задач. Они часто проходят стоя, чтобы быть короткими. Хоть они и не предназначены для мозгового штурма, всегда можно выделить время и создать атмосферу - сделайте это частью нормы и культуры.
Например, если команда столкнулась с трудным препятствием, задайте вопрос об этой проблеме и попросите команду прийти на следующее скрам-собрание подготовленной к ее обсуждению. Такой подход дает членам команды больше времени для кристаллизации своих мыслей и поощряет их к дивергентному мышлению. Убедите команду, что вы хотите услышать как интуицию, так и варианты, подкрепленные данными.
. . .
Если вы внедрите инструменты и процессы agile в небезопасную культуру, где наказывается уязвимость, необходимая для agile, вы потерпите неудачу. Agile останется лишь техническим процессом.
Если команда испытывает трудности в процессе преобразования в agile, понаблюдайте за ней. Оцените ее процесс и культуру взаимодействия. Уважительны ли члены команды друг к другу? Могут ли они быть откровенны? Задают ли они вопросы друг другу и лидеру? Если ответы на эти вопросы отрицательные, а члены команды работают в изоляции и отстаивают свои территории, вам есть над чем работать - над созданием психологически безопасной среды