Agile — только для IT? Точно нет. Команда Kaiten поговорила с экспертами из разных сфер и выяснила, как принципы Agile работают за пределами разработки: какой эффект они приносят и какие сложности вызывают.

Рассказываем истории других команд, которые помогут пересмотреть подходы в своем отделе и сделать процессы эффективнее.

Эксперты статьи:

• Владислав Кальмуцкий — практикующий юрист, ex-партнер адвокатского бюро «Солларс», автор телеграм-канала «10 правил юриста».

• Евгения Чертаринская — бизнес-тренер, EX-директор по стратегии в Mint Solutions by Kokoc Group, Agile&OKRкоуч, автор телеграм-канала «Чертаринская про маркетинг и коммуникации».

• Елена Ленсу — организациционный консультант и тренер по Soft skills, ex-HR-директор юридической экосистемы Pravo Tech.

Agile-философия вне IT: почему это работает

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

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

Рассмотрим на примере некоторых принципов манифеста:

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

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

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

• HR проводят ретроспективы после адаптации новичков и находят узкие места и делает онбординг проще для всех. 

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

• Юристы автоматизируют рутину и освобождают время для сложных задач.

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

Далее мы рассмотрим подробнее эффект от внедрения Agile в каждом отделе.

Agile в юриспруденции: работа с операционкой и стратегией

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

Так происходит и в адвокатском бюро Sollars, где сотрудники используют гибкие методологии в отдельных проектах:

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

Задачи состояли из двух категорий. Первая — потоковые задачи, которых было около 100 в месяц: от достаточно простых до очень сложных и нетиповых. Вторая — стратегические задачи по типу анализа бизнес-процессов и регламентации деятельности, которые мы расписывали на год», — Владислав Кальмуцкий, практикующий юрист, ex-партнер адвокатского бюро «Солларс».

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

В зависимости от проекта подход к работе меняется. Например, какая-то команда работает по Scrum или канбану в полном соответствии с гайдами и рекомендациями, а другая использует только некоторые инструменты. По словам Владислава, самыми полезными оказались:

• спринты;

• канбан-доски с карточками;

• ретроспективы.

Чтобы совместить между собой Scrum и Kanban, в команде делили рабочий день пополам: полдня занимались потоковыми задачами, оставшееся время —стратегическими.

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

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

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

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

Какие результаты принес переход: За счет более интенсивной работы по спринтам команда стала работать эффективнее. Результат принес и канбан-метод, которые применяли на проекты с высокой текучкой:

«Например, если в первую неделю с момента внедрения канбана мы успели отработать вовремя только 15% текущих задач, включая согласование с заинтересованными службами, то через полгода эта цифра достигла уже 60%», — Владислав Кальмуцкий.

Agile в маркетинге: связь с другими командами

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

«Встречаю это повсеместно: у бизнеса свои цели, у продукта свои, у маркетинга — свои. А клиент в итоге не чувствует единого опыта. Agile перестраивает систему работы так, чтобы маркетинг был не сервисным, обслуживающим отделом, а полноправным участником создания ценности — рука об руку с продажами, продуктом, клиентским сервисом», — Евгения Чертаринская, бизнес-тренер, Agile&OKR коуч.

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

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

В одном проекте мы все изменили: внедрили канбан, недельное планирование и WIP-лимиты. Но главное — наладили кросс-функциональное взаимодействие. Маркетинг, врачи, юристы и IT начали договариваться "на берегу". Agile сработал не как набор практик, а как способ перестать тушить пожары», — Евгения Чертаринская.

Еще один пример — digital-агентство Darvin Studio. Команда агентства перенесла ключевые процессы в канбан-доски Kaiten и внедрила ежедневные митинги. Это позволило закрыть часть задолженностей уже к концу первой недели.

→ Кейс: как Darvin Studio внедрили Канбан в диджитал-агентстве

Другое дело, когда речь идет о крупных проектах. В отличие от публикации контента, разработка сайтов, бренд-платформ, смена позиционирования и digital-кампании часто связаны с неопределенностью, изменениями и кросс-функциональным взаимодействием. Чтобы не утонуть в хаосе, Евгения рекомендует попробовать работу по Scrum.

«Agile убирает подход “запланировали — и ждем результата”. Вместо этого команда начинает мыслить итерациями: следит за изменениями, слушает рынок и быстро корректирует курс. Это критично в маркетинге, где все меняется еженедельно: повестка, конкуренты, продукт. Вместо слепого следования плану появляется гибкость и движение к цели оптимальным путем», — Евгения Чертаринская.

Еще одно применение — discovery-задачи. Это исследования и эксперименты для поиска новых идей, аудиторий или каналов продвижения. Выполнение таких задачам означает работу в условиях максимальной неопределенности — запланировать все наперед сложно, но зато легко перейти в хаос.

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

Вместо плана на год — интервью, тесты гипотез, пробный лендинг. Agile здесь про способность быстро учиться и вовремя менять курс, если рынок показывает, что это необходимо», — Евгения Чертаринская.

В подобном формате работает маркетинговая команда «Кнопки» — аутсорс-бухгалтерии. Сотрудники перевели процессы в Kaiten и стали работать по Scrum: определяют фокус-цели, а затем делят их на части и добавляют в бэклог спринта.

→ Кейс: Как команда «Кнопки» работает по Scrum в Kaiten и делает процессы прозрачными

Какие результаты приносит переход: Со слов Евгении, маркетинговые команды, которые перешли на Agile, получают такие результаты:

• скорость запуска кампаний и проектов растет на 20–60%;

• производительность контент-команд увеличивается в 3–4 раза;

• приоритизация становится четкой и управляемой — «горящих» задач меньше;

• обратная связь и регулярные review помогают точнее попадать в ожидания клиента;

• вовлеченность и устойчивость команды растут — а вместе с ними и качество работы.

«Главное — не просто цифры, а изменения в команде. Люди перестают просто "проживать день«». У них появляется энергия и понимание ценности своей работы. На ретро часто говорят: "Работы столько же, но теперь я контролирую процесс, а не он меня". Именно так бизнес получает прозрачность и начинает понимать четкую связь между действиями и результатом», — Евгения Чертаринская.

Такой результат отражает один из принципов манифеста: «Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь сотрудникам.

Agile в HR: проектный взгляд на всю деятельность

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

«Когда наша команда разрослась, а многие сотрудники перешли на удаленку, стало понятно, что нам не хватает предсказуемости и четко поставленных целей. Из-за этого задачи могли превращаться в бесконечный процесс. Чтобы упростить работу, в компании нашли решение в виде работы по Scrum», — Елена Ленсу, ex-HR-директор Pravo Tech.

Scrum внедряли постепенно во все отделы компании. Сначала изменения коснулись IT-команды и отдела маркетинга, а уже затем HR. В дальнейшем по Agile начали работать все остальные команды. HR-cотрудники организовали свою работу так:

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

«Мы разбили работу по вакансиям на этапы: подготовка, ресерч, общие и технические собеседования и оффер. У каждого этапа была своя оценка по времени, поэтому когда мы начинали спринт, брали в работу только те части задачи, которые сможем сделать за 2 недели. Сначала оценки были примерными, но со временем стали точнее, поэтому работа стала предсказуемее», — Елена Ленсу.

По такому же принципу организовали работу с проектами по обучению, которые, со слов Елены, ничем не отличаются от проектов в других отделах. У них тоже есть предсказуемая оценка и понятная структура. С подобными задачами тоже работают по Scrum.

Регулярно используют только некоторые инструменты. Фреймворк внедряли не на 100%, как в The Scrum Guide, а точечно по потребностям команды. Взяли конкретные инструменты:

• двухнедельные спринты — так проще планировать и предсказывать результат;

• ежедневные стендапы — чтобы все понимали, кто чем занят;

• ретроспективы — разбирали, что пошло не так, и улучшали процессы;

• оценка задач в сторипоинтах — так было легче распределять нагрузку.

Главный результат, который принес переход на Scrum — процессы стали значительно прозрачнее:

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

Типичные барьеры при внедрении Agile в нетехнических отделах и как их преодолеть

Серьезные изменения в компании часто сталкиваются с сопротивлением. Переход на Agile — не исключение. Какие сложности возникают у компаний:

Отсутствие поддержки руководства. Часто причина кроется в недоверии. Руководители привыкли контролировать каждый шаг сотрудников, считая, что в противном случае задачи будут простаивать. И здесь проблема уже не в методологиях, а в убеждениях руководителей, с которыми нужно работать:

«Иногда вместо гибкого подхода получается странная смесь: вроде команда автономна, но все приходится согласовывать с руководителем, вплоть до мелочей.

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

Нужно, чтобы топ-менеджеры сами были инициаторами и лидерами изменений, иначе команда не воспримет всерьез. Большую роль играет и тот, кто будет мотивировать команду не отступать:

«Хорошо, если рядом есть кто-то, кто держит фокус. Это помогает команде не сбиться, напомнит про смыслы, держит безопасное пространство. Это может быть team lead, project, внешний коуч — не важно. Главное не остаться в этом процессе в одиночку», — Евгения Чертаринская.

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

Непонимание приводит к страхам команды:

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

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

«Перегруженная команда видит в нововведениях угрозу: “Мы и так не справляемся, а теперь еще и это?”. Поэтому сначала нужно помочь разгрузиться: показать, что вообще происходит, ввести лимиты на объем задач, вернуть людям чувства контроля над процессом. Лишь потом можно говорить про серьезные изменения», — Евгения Чертаринская.

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

Еще несколько советов по внедрению

Собрали рекомендации от экспертов, которые помогут упростить переход на гибкие методологии и помогут им прижиться в компании:

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

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

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

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

«Суть Agile все-таки не столько в работе по какой-то методологии, сколько в философии подхода. Поэтому мы сначала просто понемногу объясняли команде, как можно более гибко воспринимать процессы. А когда при внедрении Scrum мы столкнулись с сопротивлением, то собирали и прорабатывали возражения, а затем выбрали точечный подход и запускали Agile по отделам с наименьшими сложностями», — Елена Ленсу, ex-HR-директор юридической экосистемы Pravo Tech.

Адаптировать процессы так, чтобы было удобно вам. Необязательно строго следовать требованиям к методологиям, если они не работают. Когда понятно, что какой-то из инструментов только тратит время, можно отказаться от него или внедрять не в полном объеме.

«Например, раньше мы проводили ретроспективу каждые две недели. Тогда требовалось много изменений и улучшений в процессах. Но со временем мы отладили работу, и необходимость в таких встречах отпала, поэтому мы стали проводить их максимум раз в квартал. То же относится к оценке трудоемкости по Scrum. Слишком много времени уходило на оценку задач, но эффекта от этого не было», — Владислав Кальмуцкий.

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

«Agile не приносит пользы “сам по себе”. Но он дает потрясающие возможности, если внедряется не как система, а как способ осмысленной, честной, живой работы — между людьми, а не только между задачами.

Я вижу, как команды, которые раньше “просто сдавали задачи”, начинают проживать прогресс, гордиться собой, восстанавливать самооценку. А это уже про психологическую устойчивость, а не про KPI», — Евгения Чертаринская, бизнес-тренер, Agile&OKR коуч.

Готовьтесь к тому, что на переход потребуется много времени. Переход на Agile часто связывают с мгновенным результатом. Но так не работает, особенно если команда впервые работает в таком формате.

«Гибкая система требует много внимания. То есть, пока она не перейдет в режим привычки, а это больше полугода, вся гибкость может быстро разрушиться. И даже после успешного внедрения гибких методологий, не всегда все будет идеально. Например, внешние факторы вроде внезапных запросов основателей или системных сбоев все равно будут влиять на работу», — Елена Ленсу.

Важно использовать подходящий инструмент

Речь идет о таск-трекерах или крупных систем для управления. Раньше востребованной была Jira, сейчас чаще выбирают отечественные продукты. 

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

Среди инструментов Kaiten — готовые шаблоны Scrum-досок и возможность планировать бэклог на несколько спринтов вперед

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

От гибкости может быть и больно

В сети и на том же Хабре не раз встречались комментарии о том, что Agile, в частности Scrum, лишь доставляет проблемы из-за неправильной организации процессов. Встречались ли вы с подобным за пределами команд разработки? 

Расскажите о своем опыте — мы свяжемся с авторами самых интересных комментариев и напишем об этом отдельную статью.