Переосмысление Agile: придерживаться классики или создать свой путь?

Ответ искали на панельной дискуссии на K-Tech Summit 2024. Предлагаем вашему вниманию мнения спикеров.

Екатерина Тен, руководитель отдела Agile-трансформации Beeline:

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

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

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

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

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

Майя Кайгородцева, CEO SOFT CREATION:

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

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

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

– Не стоит думать, что Agile отменяет документацию. Да, нам хочется побыстрее протестировать свою гипотезу, запустить проект, выполнить KPI’s, получить бонусы и пойти дальше. На самом деле, что происходит – если процесс не систематизирован, то сложно прийти к желаемому результату. Самообман команды может состоять в том, что она думает: «Документацию мы потом допишем». Поэтому дисциплина и точки контроля крайне важны.

Агиис Конкабаева, CEO red_mad_robot CA:

– Когда я еще работала в «Альфа-Банке», то отвечала за 15 Agile-команд – это 180 разработчиков. В 2022 году мы подошли к масштабированию, и вот тогда уже выбирали, куда идти дальше. Agile должен проникнуть в культуру всей компании, а не оставаться только фреймворком разработчиков. У меня был пример одного из банков, который собрал в одной комнате бухгалтера, юриста и разработчиков, сказав им: «С сегодняшнего дня вы работаете по методологии Agile». Понятно, что никакие процессы не улучшились.

– Сначала все начинается с того, что любую методологию нужно локализовать под текущие реалии и потребности бизнеса. Если говорить про опыт «Альфа-Банка», то за все IT-команды отвечал бизнес-блок. IT было инфраструктурным подразделением, которое, так сказать, подносило снаряды, обеспечивая функциональность всех систем. В бизнес-блоке были маркетологи, юристы – люди, которые находили решения, чтобы сделать разработку быстрее и качественнее.

– Мы много говорим про цифровую трансформацию, но все начинается с руководства компании. И дальше вокруг выстраивать удобный фреймворк, неважно, что это – Agile, канбан, скрам и т.д. Главное, понимать цель – для чего это нужно: чтобы привлечь новых клиентов, чтобы выводить на рынок новые продукты или чтобы увеличить прибыль?

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

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

– Люди заблуждаются, когда думают, что Agile ведет к хаосу. На самом деле, в методологии все четко прописано. Хаоса не будет, если вы его сами не устраиваете из-за неточного понимания Agile. Эта методология про ответственность, про скорость, про ценность для клиентов.

Максим Чернышев, CIO Freedom Mobile:

– Закон Лармана гласит, что люди, столкнувшиеся с изменениями, первым делом стараются сохранить статус-кво. На самом деле, успех любой методологии или фреймворка зависит не от того, что мы выбираем. Не от подхода – их очень много. Все начинается гораздо раньше – с правильно заданных вопросов: что мы внедряем, как и зачем? Вот если здесь мы определились, тогда шансов на успех гораздо больше.

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

– Вопрос в том, чьими глазами мы смотрим на методологию Agile – энтузиастов и агентов изменений или клиентов, а может методологов? Но есть всегда еще одна точка зрения – собственника бизнеса, который считает деньги. Без учета его мнения мы придем в никуда. Хотя, у меня вызывают уважение те предприниматели, которые на вопрос «Зачем вам Agile?» честно отвечают: «Нам это нужно для статуса». Они признаются, что просто хотят быть в тренде, выглядеть прогрессивными. Такой ответ экономит много времени, сил и средств.

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

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

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

Нигмет Абдрахманов, CPO Sergek Group:

– Мы попробовали разные методологии – и Agile, и скрам, и канбан. Главное во всем этом – чтобы была поддержка со стороны руководства. Оно должно понимать, что не стоит ожидать быстрого результата. При этом важно не заигрываться в Agile, держать фокус на боли клиента.

– Мы сейчас выходим на разные рынки, разрабатываем различные проекты. В итоге, делаем тюнинг команд под конкретные задачи.

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

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

Алмат Жапаров, генеральный директор One Technologies:

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

– В Agile важно быть готовым к изменениям, нежели следовать первоначальным планам. Это правило методологии должно оставаться неизменным.

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