Agile: внедрить и полюбить

Опыт компании Auditorius по применению Agile-подхода на практике

Agile – довольно модное слово, за которым скрывается целая философия, образ мышления со своими ценностями и подходами к разработке продуктов, совершенно не привычный для российских реалий. Где-то он выстреливает, где-то нет (вне зависимости от сферы деятельности компании). Но все ситуации объединяет одно – к Agile приходят, когда есть запрос на качественные изменения процессов и желание расти.

Так было и в Auditorius. Наша компания занимается programmatic-технологиями. Команда разработки обслуживает три системы – DSP, DMP и Trading Desk, которые исторически имеют разную архитектуру. Изначально системы заказывались у внешних подрядчиков, компания не планировала развивать их in-house. Впоследствии код по каждой системе был передан во внутреннюю разработку, а процесс передачи знаний, документации и компетенций прошел не гладко. В итоге команды по каждому проекту работали на разном стеке технологий, а дискоммуникация постепенно углублялась.

Это привело нас к такой картине:

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

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

3. Микроменеджмент. То есть желание основателей и менеджеров контролировать процесс выполнения задачи, трудности с делегированием. Можно проверять шаги, а можно – результат. Нельзя лишать сотрудников инициативы и раскрытия творческого потенциала. Лучше пару раз обжечься, научившись брать на себя ответственность, чем вечно быть ведомым и безынициативным.

4. Bus factor. Это показатель того, насколько устойчива команда. Если bus factor равен 1, то уход одного из членов команды способен парализовать работу отдела или команды. Так было и у нас, поскольку каждая система внутри компании была написана на своем языке, а документации по ней не было.

5. Рост технического долга, откладывание в долгий ящик задач необходимых для развития системы, например, рефакторинг кода, написание интеграционных тестов, исправление багов и неудобств интерфейса и т.д.

Запрос на качественные изменения осознавали не только фаундеры, но и команда. Инициаторами выступили основатели Нагорнов Геннадий и Валерий Кашин, а драйверами изменений Product Director Виктор Соловьев и я – Developer Святослав Задорожный.

Бэкграунд

Виктор отвечал за технологические продукты компании. Был основным инициатором и драйвером запуска продукта Programmatic Native. Сторонник и активный проповедник подходов Lean и Agile.

Я же занимался в компании разработкой систем Trading Desk и DSP на позиции разработчика, а также работал над созданием и продвижением продукта Native. Ленивый от природы, всегда пребываю в поиске оптимальных решений и методологий, позволяющих делать меньше при максимальном результате, придерживаюсь принципа do more with less.

Год на раскачку

Идея была предложена основателям компании в 2016 году, так как обозначенные вопросы, требующие оптимизации, существовали уже тогда. Геннадий Нагорнов и Валерий Кашин идею поддержали и дали зеленый свет на реализацию.

На практике все оказалось не так просто. Мы знали, что в команде есть несколько «фундаменталистов» (waterfall-адептов), весьма авторитетных, которые с большой вероятностью будут открыто и активно саботировать процесс изменений, поэтому начали работу с них. В ходе обсуждений изменений всем сторонам стало понятно, что дальше нам не по пути. Один из ключевых сотрудников принял решение уходить. Уже на старте проекта сыграл Bus Factor.

Фаундеры оказались в сложной ситуации. На одной чаше весов bus factor, на другой – решение наболевших вопросов. В итоге человек все равно ушел, но и проект внедрения Agile-подхода был на время «заморожен».

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

Предложение

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

Глобально проект был смесью классического Scrum со всеми артефактами и строгим следованием правилам, плюс включал несколько проверенных практик, направленных на взаимодействие с бизнесом: Impact Mapping, Story Mapping, Agile Roadmapping и огромный пласт обучающих мероприятий, коучинговых сессий для инженеров, product-менеджеров и владельцев бизнеса.

Название

Название придумали, вдохновившись примером Zolando, которые нарекли глобальную Agile-трансформацию в компании Zolando Radical Agility. В случае с Auditorius третья A напрашивалась сама, поэтому появилось Advanced, и в итоге получилось Auditorius Advanced Agility (ААA), а в народе Triple-A.

Представление проекта команде

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

• изменения, которые требует бизнес;
• как команда может влиять на эти изменения;
• ожидания бизнеса от «идеальной» продуктовой команды;
• неотвратимость предстоящих изменений;
• общий план работ по трансформации команды на ближайшие 2-3 месяца.

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

Структура команды

Как упоминалось выше, было три команды, которые исторически действовали достаточно изолированно друг от друга:

Команда Demand Side Platform

DSP реализована на Java-стеке, и глобально представляет из себя три функциональных блока:

• Bidder – собственно система real-time управления ставками, откруткой. Классический High Load;
• Backend – хранилище данных. Эта часть про Big Data;
• Предикты – Machine Learning модуль системы, отвечающий за алгоритмы предсказания вероятности целевых событий (клик, досмотр и т.д.).

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

Команда Trading Desk

Это front-end всей технологической programmatic-экосистемы, и опять же, исторически она развивалась на другом стеке – .Net.

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

Data Scientists

Блок Machine Learning обособленно развивался командой специалистов, заточенных на решение именно ML-задач.

Первоначальная реакция команды

Мы изначально не позиционировали себя как «гуру Agile», объясняя свою роль именно как драйверов изменений, и открыто призывали каждого помогать. Кто-то проявил интерес и инициативу, кто-то высказывал скепсис. Любая идея изначально получает такую реакцию. Перейдем к сути.

Динамика развития проекта

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

Первые две итерации команда по инерции сопротивлялась изменениям. Особенно плохо шло планирование и ретроспективы.

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

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

Используемые механики

Теоретическая часть по каждому из пяти направлений включала несколько типов мероприятий. Например, мозговой штурм, воркшопы, внешние конференции/meetup.

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

Пример расписания:

История одного спринта

Предыстория появления задачи

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

Назначение сервиса

Это служебный сервис синхронизации изменений между Trading Desk и DSP. Например, изменения таргетингов в рекламной кампании, вносимые баером в Trading Desk. Это ее основное предназначение. Также на базе этого сервиса была реализована часть отчетности, которой пользовались баеры.

В чем была боль?

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

Почему сложно было решить?

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

Описание задачи по SMART

Планирование

На одной из ретроспектив у команды родилась концепция эффективного планирования на базе нескольких часов предварительного обсуждения архитектуры. Фича – User Stories – цель декомпозировалась по понятным ребятам системам: DSP, TD. То есть первоначально билась по системам, и уже дальше внутри систем – по задачам.

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

Дейли

Или короткие ежедневные встречи. Есть два типа дейли: скрам и канбан. Скрам дейли идет от персоналий – каждый человек говорит о своем прогрессе, канбан дейли – от задач, когда команда смотрит, как она может их поскорее продвинуть дальше. Мы выбрали скрам дейли, потому что он попроще для старта. Канбан требует большей самодисциплины.

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

Далее мы переформулировали вопросы, придав им бОльшую ценность:

- Что я сделал вчера для того, чтобы команда достигла цели спринта?

- Что я буду делать сегодня для того, чтобы команда достигла цели спринта?

- Какие я вижу препятствия у себя, у команды для того, чтобы мы достигли цели спринта?

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

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

Процесс

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

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

Подготовка к Демо

Учитывая, что до этого было проведено два открытых Демо, и они были достаточно негативными, постепенно начали проявляться чувство ответственности за результат и желание избежать очередного фейла. Были люди, которые стали подталкивать команду к изменениям. Ребята начали готовиться. Очередное Демо проводилось уже не в виде импровизации на ходу, началось какое-то обратное планирования от дедлайна. Конечно, мы помогали, подсказывали: что от них ожидают, как лучше проводить Демо, давали best practice. Но, разумеется, это были всего лишь советы. В итоге был показан уже результат, а не рассказ о процессе, как это было в предыдущих Демо.

Ход Демо

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

Кросс-функциональность по кирпичикам

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

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

Ограничение самой scrum-команды количеством 3-9 человек является критичной рекомендацией в Scrum Guide. Само это ограничение не позволяет тебе нанимать людей, занимающихся только чем-то одним. А теперь давайте посчитаем. Даже если у вас один технологический стек, у вас есть front-end, back-end, QA, support, DevOps – это уже пять, а их бы надо продублировать, так как люди уходят в отпуск, болеют, и нагрузка не всегда равномерна. Это уже десять! А если стеков, как у нас, два? Однако, это проще объяснить неспециалисту, чем опытному разработчику. Обычно матерые кодеры активно сопротивляются такому подходу и отказываются признавать очевидное.

Поэтому в мире Agile придумали игровые механики, которые наглядно показывают, как это работает на практике. Например, для моделирования Agile и Scrum практик отлично заходит LEGO. Его цель – наглядно смоделировать работу «обычной» команды и кросс-функциональной.

Описание формата:

• имитируется работа команды, спринт;
• четыре члена команды, у каждого есть набор кубиков своего цвета. Цвет отражает его компетенцию (front-end, back-end etc). По 12 штук;
• есть план итерации, за который надо выпустить 3 фичи в продакшен. Фича – отдельная игрушка, башенка, которая собирается из кубиков, которые розданы членам команды. Каждая фича состоит из кубиков разных цветов (требует для создания различных компетенций от команды), и они, разумеется, перемешаны;
• ходы в игре представляли собой 1 день из итерации;
• команда собиралась на дейли и решала, кто что будет ставить, какой кубик для какой фичи;
• есть 10 ходов.

Проводится две итерации: в первой у каждого игрока кубики только одного цвета, во второй – по два кубика каждый игрок отдает своим коллегам. Таким образом, получалось 6 кубиков «основной» компетенции и по 2 кубика смежной.

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

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

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

Продолжительность

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

Мы показали, как это можно делать, передали компетенции ключевым лицам – Product Owner и Scrum Master. Теперь их задача продолжать, содействовать и поощрять изменения.

Три месяца – это тот максимум, который мы могли себе позволить как компания. И тот минимум, который необходим, чтобы минимальные изменения прижились в команде. Отдельно мы разработали «Подходы к обучению» (регламент о приоритетных направлениях обучения, где проговариваются часы, стоимость курсов и последующая передача полученных знаний всей команде. Важным условием является презентация по практическому применению знаний в бизнес-процессах) и «Возможности для развития сотрудников» (рост сотрудника происходит в парадигме трех измерений: роли, уровни в рамках роли и набор компетенций, которыми должен обладать сотрудник на каждом из уровней. Своего рода RPG с пересмотром достижений раз в полгода). Благодаря этим документам, сотрудник может выбрать путь развития, соответствующий его интересам и интересам компании. Предполагается, что вклад в общее дело со временем должен расти. В такой системе переход на руководящую позицию не требуется.

Сложности, которых не ожидали, но с которыми пришлось столкнуться

Внедрение AAA совпало по времени с внутренними изменениями в компании, с ее трансформацией как бизнеса. Решения созрели достаточно независимо, но для нас, как драйверов AAA, это оказалось неожиданным: кадровые перестановки, изменения в бизнес-процессах, перераспределение центров принятия решений – все наложилось, и сильно усложнило нам работу. Например, в новых условиях команде потребовался новый Product Owner, которому пришлось фактически «запрыгивать в уходящий поезд».

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

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

Результаты проекта AAA

Как реализация ААА повлияла на бизнес-процессы в компании в целом

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

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

Но об этом мы расскажем в следующий раз.

Свят Задорожный и Виктор Соловьев

#кейсы #agile #бизнес