Agile невозможен без психологической безопасности

Двадцать один год назад 17 инженеров-программистов опубликовали Манифест Agile-разработки программного обеспечения, более известный как Agile-манифест. В ответ на бюрократическую каскадную модель разработки программного обеспечения (ПО) с ее линейными фазами и объемной документацией эти инженеры выступили за более гибкий подход, способный адаптироваться и добиваться успеха в высокодинамичной среде.

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

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

Тысячи организаций могут засвидетельствовать, что их Agile-усилия окупились с точки зрения скорости, качества, ценности и долгосрочного роста. Но не все могут так сказать – на самом деле примерно половина организаций, которые проводят Agile-трансформации, терпят неудачу.

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

Процессы и инструменты – это строительные леса

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

Высокий уровень психологической безопасности вызывает реакцию повышения продуктивности с инновацией в качестве цели, в то время как низкий уровень психологической безопасности вызывает реакцию страха с выживанием в качестве цели. Когда члены команды перестают задавать вопросы, признавать ошибки, исследовать идеи и оспаривать статус-кво, они перестают работать в Agile. Разве команда разработчиков может выполнить быстрое прототипирование, если она плавает в страхе? Или как команда HR может сделать справедливый выбор кандидатов, если они не могут безопасно указать на действия, которые могут быть вызваны предубеждением? Если позаимствовать фразу Уильяма Батлера Йейтса, без психологической безопасности «все разваливается, центр не может удержаться».

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

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

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

1. Рассматривайте Agile как внедрение культуры

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

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

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

2. Разрабатывайте, документируйте и отображайте уязвимые пары поведение/реакция

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

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

3. Сфокусируйтесь на одном поведении во время каждого скрама и практикуйте культурную ответственность

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

Если между уязвимой парой поведение/реакция и собственной моделью поведения руководителя группы возникает разрыв, этот диссонанс породит цинизм и подорвет доверие. Но если лидер стремится изменить поведение и публично признает ошибки на этом пути, команда добьется кумулятивного прогресса. Лидер должен ясно дать понять, что члены команды несут ответственность за выполнение и поощрение уязвимого поведения.

4. Формально оценивайте свой процесс диалога на ретроспективе спринта

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

Обсудите качество взаимодействия команды и определите потенциальные угрозы открытости. Задайте такие вопросы: Чувствовали ли вы себя вовлеченным в процесс? Почему да или почему нет? Какое поведение было наиболее уязвимым во время этого спринта? Как отреагировала на это команда? Было ли что-то, чего вы не сказали или не сделали, потому что не чувствовали себя в безопасности? Демонстрирует ли команда демократическую модель участия и влияния? Почему да или почему нет?

5. Завершите скрам «вопросом/размышлением»

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

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

Если вы внедрите Agile-инструменты и процессы в унаследованную культуру, которая наказывает те самые акты уязвимости, которые необходимы для обеспечения Agile, вы потерпите неудачу. Среда наказуемой уязвимости – т.е. низкая психологическая безопасность – приводит к тому, что Agile используется в организации только на словах, как в той талантливой команде разработчиков, которая потерпела неудачу.

Если команда пытается провести Agile-трансформацию, последите за ней. Оцените ее процесс диалога. Уважают ли друг друга члены команды? Принимают ли они откровенность? Вознаграждают ли они уязвимое поведение? Если ответы на эти вопросы отрицательные, а участники обидчивы, темпераментны или защищают «свою территорию», вам есть над чем работать. Вы можете быть благословлены ресурсами, опытом и владеть техническими процессами и инструментами, но в конечном итоге Agile невозможен без важнейшего фактора – психологической безопасности.

Автор: Тимоти Р. Кларк
Источник

Книга в подарок

Опубликована наша книга «Прорыв. Единственный путь развития бизнеса». Это бизнес-роман о производственном предприятии, столкнувшимся с «потолком» в своем развитии. Для прорыва в развитии руководству и персоналу приходится преодолеть собственные, выстраданные на опыте, но устаревшие убеждения. Читателю предлагается пройти через этот прорыв вместе с героями. Вы увидите трудности такой трансформации, осознаете природу сопротивления изменениям и реальный путь к таким изменениям.
Подпишитесь на наш Telegram-канал и получите книгу в подарок!

Получить подарок

---

Лучшие статьи каждую среду в нашей рассылке. Присоединяйтесь к TOCpeople!

Подписаться

Нажимая на кнопку «Подписаться», я принимаю условия Политики конфиденциальности.