8 Антипаттернов в Agile и как с ними бороться

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

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

1. Водопад, разбитый на циклы

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

Почему это проблема?

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

Что можно сделать?

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

2. "Двойной стек" Agile

Я столкнулась с этим в одной японской компании, которая гордилась своим уникальным подходом. На самом деле, это распространённая практика в разных вариациях, и она всегда является плохой идеей.

Что это такое?

Идея заключается в том, что несколько команд работают над одним продуктом параллельно, следуя ритму спринтов. Например, одна команда занимается дизайном, другая — разработкой (или у вас могут быть команды фронтенда, бэкенда и QA). В спринте 5 команда дизайна разрабатывает новые макеты, фронтенд работает с макетами из спринта 4, бэкенд использует код фронтенда из спринта 4 (основанный на дизайнах спринта 3), а QA проверяет результаты спринта 4 (разработанные на основе дизайнов из спринта 2).

Почему это проблема?

Здесь всё не так. Как видно из примера, для завершения продукта требуется как минимум 4 спринта, поскольку каждая задача должна пройти через все команды (дизайн, фронтенд, бэкенд, QA). Здесь нет места для экспериментов, а ответственность за конечный продукт размазывается: дизайнеры могут сказать, что их макеты были неправильно поняты, а разработчики заявят, что их код идеален, но продукт не работает из-за плохого дизайна. Этот подход не имеет ничего общего с Agile.

Что можно сделать?

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

3. Слепое следование фреймворкам

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

Почему это проблема?

Иногда даже лучшие практики Agile не работают в определённых контекстах. Уникальный продукт, необычные проблемы команды, нестандартный стиль работы — возможных причин много. Если вы слепо следуете Scrum и отвергаете любые другие подходы, вы продолжаете поддерживать процесс, который не работает. Команда демотивируется, продуктивность падает, бизнес-результаты ухудшаются, и вся организация страдает.

Что можно сделать?

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

4. Kanban против канбан-доски

Я часто слышу: "Мы следуем фреймворку Kanban, потому что у нас есть канбан-доска". Нет, это не так. Вы следуете фреймворку Kanban, если у вас есть доска и вы ограничиваете количество одновременно выполняемых задач (WIP), измеряете время выполнения задач, используете pull-систему вместо push-системы и применяете лучшие практики непрерывного улучшения в своей ежедневной работе.

Почему это проблема?

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

Что можно сделать?

Изучите фреймворк Kanban и помните, что одной доски недостаточно.

5. Роль менеджера команды

Во многих организациях, особенно в период перехода на Agile, сохраняется роль "менеджера команды" или она совмещается с ролью Product Owner. Могут ли команды с менеджером быть Agile? Я видела несколько допустимых случаев, но чаще всего это приводит к катастрофе.

Почему это проблема?

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

Что можно сделать?

Это сложная задача, так как она требует организационных изменений, которые не всегда легко реализовать. Идеал, к которому нужно стремиться, — это кросс-функциональная команда без менеджеров (Product Owner не является менеджером!), которая самостоятельно определяет цели и работает вместе для их достижения. Если организационные изменения невозможны, может быть полезным обучить формальных менеджеров принципам лидерства-служения (servant leadership).

6. Оценки, основанные на времени

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

Почему это проблема?

Оценки на основе времени требуют заранее назначать задачи (что часто приводит к созданию "сильосов") и отнимают много времени, при этом вызывая больше проблем, чем принося пользы. Как оценить неопределённость? Добавить 3 лишних дня в расчёты и надеяться на лучшее? Как оценить задачу, которая требует 1 час работы в день на протяжении 15 дней? Это 15 часов или 15 дней? Если указать 15 часов, можно ошибиться с таймлайном, а если 15 дней, то переоценить ресурсы.

Что можно сделать?

Определите, действительно ли вам нужны какие-либо оценки работы. Часто в них вообще нет необходимости — если задачи в вашем бэклоге примерно одинакового размера, просто оценивайте скорость команды количеством завершённых задач в неделю и на основе этого планируйте будущее. Если же оценка необходима, попробуйте использовать методы "размер футболки" или story points; оценки на основе времени должны быть вашим последним вариантом.

7. Команды не ставят цели

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

Почему это проблема?

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

Что можно сделать?

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

8. Управление производительностью, основанное на выходе

Это моя больная тема и очень распространённая практика в Японии. Людей оценивают по тому, сколько они работают (часы работы, количество написанных строк кода, количество созданных слайдов PowerPoint и т.д.), а не по результатам. Во многих японских компаниях сложно получить повышение, если вы работаете только с 9 до 5 и не задерживаетесь.

Почему это проблема?

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

Что можно сделать?

Никогда не устанавливайте цели, основанные на выходе (например, запустить x кампаний, завершить x story points или написать x строк кода). Все цели должны быть ориентированы на результат (например, увеличить продажи на x %, достичь NPS x баллов или обеспечить SLA 99%).

Эти рекомендации помогут вам выявить и устранить неэффективные практики, делая вашу команду более продуктивной и Agile в самом лучшем смысле!