9 вещей, которые необходимо правильно настроить, если вы хотите, чтобы ваша компания стала Agile

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

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

1. Agile-лидерство

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

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

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

2. Обученные Product Owners

Для того чтобы организация стала Agile, обучение должно пройти каждый сотрудник. Но наиболее критичной ролью в этом процессе являются Product Owners. Они должны научиться правильно формулировать цели команды, создавать и приоритизировать бэклоги, работать с заинтересованными сторонами и мотивировать команду.

Product Owner должен быть целеустремлённым, независимым, амбициозным, хорошо знать продукт и обладать отличными навыками общения.

Очень важно организовать внутренний буткемп или академию для Product Owners перед началом трансформации, чтобы они могли освоить и попрактиковать новые навыки, а также наладить связи друг с другом, что впоследствии будет способствовать сотрудничеству между Agile-командами.

3. Команды, сформированные вокруг продуктов

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

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

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

4. Психологическая безопасность

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

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

5. Процессы для выравнивания между командами

Мы можем узнать из Scrum или других фреймворков, как организовать процессы внутри одной команды. Но эта команда не существует в вакууме — в рамках Agile-трансформации нужно продумать, как организовать координацию и взаимодействие между командами.

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

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

6. Управление эффективностью

Во многих традиционных организациях люди устанавливают личные цели или KPI и периодически проходят оценку со стороны своих менеджеров (или коллег и менеджеров). В мире Agile это может создать проблемы, особенно если личные цели членов команды не согласуются (а они, вероятно, не будут согласовываться).

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

При этом важно поддерживать рост каждого человека и помогать им развивать профессиональные навыки, поэтому система управления эффективностью должна учитывать и этот аспект.

7. Вовлечение подрядчиков

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

Основная проблема аутсорсинга в том, что он часто приводит к мини-«водопадам» и создаёт «чёрный ящик». Обычно команда формулирует требования, отправляет их подрядчику, ждёт какое-то время («чёрный ящик»), а затем получает итоговый результат, который не обязательно соответствует их ожиданиям.

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

Сложность заключается в контракте (не всегда возможно интегрировать подрядчиков в команду) и дополнительном обучении Agile, которое, возможно, потребуется организовать для подрядчиков.

8. Процесс постановки целей

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

Для этого требуется процесс постановки целей между командами. Чаще всего он реализуется в форме OKR (Objectives and Key Results) на ежеквартальной основе. OKR позволяют командам формулировать цели, которые соответствуют целям компании (или департамента), при этом сохраняя гибкость в определении того, что и как они хотят достичь.

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

9. Распределение бюджета

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

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

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