Agile-практики: как избежать ошибок, допущенных нашей маркетинговой командой

Секрет раскрыт. Гибкое управление проектами меняет правила игры, и разработчики и ИТ-специалисты больше не единственные, кто знает об этом.

Как маркетолог, вы наверняка слышали об Agile. Ваша команда может использовать некоторые методы Agile, такие как проектные спринты и стоячие встречи. Если так, то вы в меньшинстве. Команды маркетинга по-прежнему не осознают преимущества Agile. Согласно новому отчету Workfront и MarketingProfs, только 30% маркетинговых команд используют Agile-подход для управления своими процессами. Остальные 70%, вероятно, испытывают те же разочарования, которые испытывала моя команда до того, как мы взяли на себя решение внедрить Agile.

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

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

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

Прежде чем мы начнем, давайте рассмотрим несколько основ:

Что такое Agile-практики?

Практики Agile (часто называемые «Agile») делают упор на непрерывном выполнении небольших частей работы над проектами с более крупными взаимосвязанными задачами, которые могут занимать недели или месяцы (что традиционно называется управлением в стиле водопада).

Основы Agile включают:

• Скрам-команда: эта высокопрофессиональная команда, организованная под руководством скрам-мастера, решает сложные проблемы и предоставляет решения в итерациях фиксированной длины, называемых спринтами, которые могут длиться от одной недели до 30 дней. Например, скрам-команда, работающая над контентом, может начать двухнедельный спринт, взяв на себя обязательство создать новую инфографику или таблицу данных.
• Минимально жизнеспособный продукт (MVP): при планировании конечного результата принципы Agile делают упор на том, чтобы как можно быстрее реализовать проект, чтобы ваша команда могла быстро отреагировать на реальные проблемы. Чтобы создать модель непрерывной доставки, мастера схватки побуждают команды определять MVP и находить наиболее креативные способы довести продукт до конца в рамках спринта. Например, если вы начинаете двухнедельный спринт по созданию электронной книги в качестве вашего MVP, а ваш дизайнер заболевает, вы можете решить переопределить MVP этого спринта как серию сообщений в блоге и разработать электронную книгу в следующем спринт.
• Ежедневная стоячая встреча: члены команды стоят в кругу около 15 минут каждое утро, чтобы обсудить выполненные задачи, основные направления и препятствия, которые могут помешать им завершить назначенную им работу по спринту. В конце спринта Agile-команды предоставляют определенный набор проектов, которые затем оцениваются и улучшаются в следующем спринте. Некоторые команды Scrum также включают ретроспективные встречи, на которых обсуждают недостатки процесса, которые можно устранить в следующем спринте.

Почему маркетологам следует использовать Agile?

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

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

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

Каких ошибок следует избегать?

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

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

Ошибка 1. Мы назвали себя Agile, не сделав уроки.

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

Не приходите на работу в один из понедельников и объявляйте, что вы «переходите на Agile», как я. То, что вы выполняете работу в двухнедельных спринтах и ​​ежедневно устраиваете встречи, не означает, что вы являетесь Agile-командой. Прелесть Agile в том, что он дает вашей команде возможность совместно работать над проектами и определять качественный результат в установленные сроки. Если вы просто пытаетесь втиснуть как можно больше работы в две недели и жертвуете качеством, чтобы пересечь финишную черту, эта красота сводится на нет.

Прежде чем внедрять Agile-процессы в свою маркетинговую команду, сделайте домашнюю работу. Взломайте книгу или две. Я рекомендую начать со Scrum Джеффа Сазерленда (известного многим как один из отцов Agile) и Hacking Marketing Скотта Бринкера. Также прочтите несколько отличных статей CMI по гибкому маркетингу.

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

Ошибка 2. Нам не удалось указать владельцев проблемы.

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

Остальные, представьте себе это: вы на 98% выполнили крупный командный проект с четкими сроками, и неожиданная заинтересованная сторона вмешивается в последний час с десятками исправлений. Затем ваша команда будет вынуждена продлить проект еще на две недели, чтобы учесть эти изменения, потому что никто не может возразить, что эта заинтересованная сторона ошибается.

Все еще читаете? Я так думала.

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

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

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

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

Для нашей команды владение проблемами оказалось особенно успешным по нескольким причинам:

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

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

Ошибка 3. Мы сосредоточились на результатах, а не на проблемах.

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

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

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

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

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

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

Когда случается __________, я хочу ________, чтобы мы получили такой измеримый результат: ___________.

Вот пример такого типа постановки задачи (или пользовательской истории) из гипотетического проекта:

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

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

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

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

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

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

Ошибка 4: вместо того, чтобы расставить приоритеты (и притворились, что мы можем все это сделать), мы забились

Если вы пытаетесь втиснуть как можно больше в каждый спринт Agile-маркетинга, как это делали мы, вы делаете это неправильно.

Без общего чувства приоритета вы не знаете, на чем сосредоточить свое время. И без концентрации вы прибегаете ко всему, говоря «да». И когда вы говорите «да» всему и у вас нет проблемных владельцев для ваших проектов, вы оказываетесь в гуще напряженного квартала с множеством незавершенных результатов.

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

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

Мы попробовали два или три метода отслеживания скорости (в том числе планирование покера, распространенный способ оценки работы). Мы сосредоточились на использовании оценки как на способе доказать, что мы можем выполнить много работы, а не на способе стать более эффективной командой. ЭТО была наша ошибка.

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

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

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

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

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

Заключение

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

Какие ошибки допускали ваши команды при внедрении Agile-процессов? Как вы исправили эти ошибки? Дайте нам знать в комментарии.

Хотите улучшить свою структуру для повышения эффективности контент-маркетинга? Подпишитесь на нашу еженедельную рассылку Content Strategy for Marketers, в которой представлены эксклюзивные идеи Роберта Роуза, главного советника по содержанию. Если вы похожи на многих других маркетологов, с которыми мы встречаемся, вы будете с нетерпением ждать его мыслей каждую субботу.

Изображение на обложке: Джозеф Калиновски / Институт контент-маркетинга