«Да кто такой этот ваш аджайл?! Мы же не продуктовая команда!», «И как меня угораздило в это вляпаться?!» — такие выражения (и много чего еще) я часто слышала на командных встречах архитекторов в роли агента изменений.
Всем привет! Я – Мадина, скрам‑мастер в Департаменте управления технологиями МТС, у нас это подразделение называют Департаментом Technology Governance (TechGov).
Наше подразделение (относительно недавно созданное) занимается управлением технологиями на уровне всей компании. Если коротко – структура Департамента представляет собой Центры компетенций и Центры практик.
Центры компетенций описывают практики, методологии и стандарты, центры практик занимаются внедрением и масштабированием этих практик по всем продуктам компании. Трансформация, а тем более технологическая – дело непростое, и без применения гибких методологий тут не обойтись.
Agile не ограничивается только продуктовыми командами, любое подразделение в компании может получить пользу от внедрения этой методологии. Ведь Agile – это не просто модное слово, это философия работы, которая позволяет улучшить процессы и более эффективно достигать поставленных целей. Тем более, наш департамент занимается Продуктовой трансформацией в том числе, а это значит мы должны следовать принципу Eat your own dog food (практика использования компанией или командой разработчиков собственных сервисов и продуктов).
Но одно дело (тоже весьма непростое) — внедрять скрам или канбан в командах разработки, где есть понятный инкремент и стейкхолдеры. И совсем другое — внедрять гибкие подходы в Центрах компетенций или практик. Таких, например, как архитектура, управление производственным процессом, R&D или даже сам Центр практик Agile.
Мой путь агента изменений был нелегок и тернист, я набила кучу шишек, случались и провалы. Но я извлекла из этой истории много уроков и, кажется, мы с командой смогли нащупать верную дорогу, используя здравый смысл, и начали ощущать пользу от внедряемых изменений.
Итак, от директора по развитию технологий TechGov поступил запрос на скрам-мастера в Центры практик и компетенций управления корпоративной архитектуры. Запрос звучал примерно так: «Нужен гибкий подход к реализации задач. Продуктовые практики при разработке стандартов и методологий».
Ключевые стратегические направления, которыми занимается Центр:
ArchOps;
Бизнес-архитектура;
CloudNative;
Архитектурные стандарты;
Технологический радар;
Open/Inner Source;
и другие направления.
Стоит ли говорить о том, как было тяжело первое время вникать в суть дискуссий и задач на командных встречах? Например, тема встречи такая: «Обсуждение метамодели аналитических и архитектурных артефактов». Я гуглю: «Что такое метамодель?» и получаю ответ: «Метамодель – это модель, описывающая другую модель».
Эммм... спасибо…
Что я увидела на старте: каждый сотрудник занимался своим, на первый взгляд, узкоспециализированным делом и особо не заботился о том, что происходит за пределами своей области ответственности. И да, до меня команда уже работала в спринтах, проходили синхронизирующие встречи.
Было множество митингов, презентаций и писем друг другу, но на практике реализация и внедрение проходили туго. Спринты закрывались и открывались формально, никаких процессных метрик не велось. Во избежание бунта я решила начать процесс изменений поэтапно. Сначала встретилась с каждым членом команды на индивидуальной встрече, и мы заполнили шаблон STATIK.
Основной моей задачей было погрузиться в работу центра и понять, какие проблемы есть на поверхности.
Вот какие проблемы мы вместе обозначили:
много зависимостей, которые очень сложно решаются или не решаются совсем;
непрозрачный канал коммуникации между руководством, смежными подразделениями;
«я не понимаю, чего от меня хотят».
Пообщавшись с директором и каждым участником команды я для себя сделала вывод, что команда находится примерно на красном уровне развития, если оценивать по спиральной динамике:
А значит, нам надо постепенно выходить на синий уровень, а это инструкции, правила, постоянные ритуалы. Если короче – дисциплина.
Этап 1. И тут мы пришли к гигиене Jira…
Что было (тут прошу понять и простить за «англицизмы», но в нашей профессии без них никак:)):
Lead time* задач несколько месяцев, выполнение запланированных задач на спринт только 20%. Задачи и истории не соответствовали объектной модели**, принятой в департаменте.
*Lead time задач — промежуток времени, необходимый для выполнения задачи.
**Объектная модель Jira — это совокупность объектов (epic, story, task) их свойств, параметров и взаимосвязей (звучит почти также как объяснение термина метамодель, знаю?).
Очевидно, что для управляемости и прозрачности ситуацию нужно было улучшать.
И тут начались вопросы: «а зачем?», «а почему?», «я не хочу опускаться на уровень задач, мне достаточно эпика на квартал, это мой фокус». Но, конечно же, для меня, агента изменений, это все не ново. Где-то вопросы решались уговорами, где‑то «шантажом», где-то пряником, а где-то кнутом.
И тут есть немаловажная деталь — это полная поддержка директора. Он четко понимал ценность всех этих шагов и помогал мне на каждом шагу, донося до команды, что я не просто какой‑то «внешний коуч», а такая же часть команды, нацеленная на результат.
Постепенно с командой мы стали улучшать метрику «план/факт» по спринту. То есть ребята научились планировать как минимум на 2 недели с фокусом на какую-либо ценность.
Я настроила дашборды (информационные панели), которые визуализировали работу и фиксировали «нарушения» гигиены и нашей объектной модели. Кажется, теперь не надо уже вести кучу разной отчетности, разрозненные таблицы в Confluence с отчетом о прогрессе по какому-либо направлению, ведь все описано в Jira, по результатам приложен артефакт и достаточно в плагине Structure посмотреть ход выполнения задач. Выглядит это примерно так:
А вот так выглядит завершенная работа по спринту во встроенных дашбордах Jira:
Причем доступ к задачам есть у любого сотрудника департамента, каждый может посмотреть прогресс и чем занимается центр.
По регулярным событиям: помимо планирования/обзора спринта у нас появились ежедневные короткие стендапы и ретроспективы. На начальных этапах казалось, что ежедневные встречи для синхронизации — это лишнее время, которое можно потратить на более полезную работу. Но постепенно команда осознала, что такие встречи помогают нам следить за прогрессом каждого участника и оперативно решать проблемы. Эти стендапы стали нашей ежедневной рутиной, без которой мы уже не можем представить работу.
А ретроспективы – это место, где мы обсуждаем насущные проблемы и пытаемся их решить.
Чего удалось достичь на первом этапе: появилась сфокусированность на конкретных задачах, ребята стали больше общаться друг с другом, научились решать зависимости друг перед другом более эффективно. Улучшение гигиены Jira помогло решить вопрос с прозрачностью, все реже и реже мы слышим от руководства вопросы о том, кто чем занят и какого результата удалось достичь по тем или иным активностям, так как к любой задаче всегда приложен артефакт.
Этап 2. Взаимодействие снаружи
Теперь, когда мы более или менее разобрались с работой «внутри», пора понять, что происходит у нас «снаружи». Тем более, что ком зависимостей и проблем во взаимодействии копился все это время во всем департаменте. Очень много работы зависело от смежных центров/платформ/отделов. Мы то и дело слышали:
«Ну я встречу закинул, а он не пришел».
«Ну мы встречу провели, а ничего не меняется».
«Ну я отправил письмо, а ответа нет».
Вывод напрашивается сам: нужна общая «синхровстреча». Мы в Центре практик Agile всей командой методологов и скрам мастеров долго думали, как эту проблему решить. Поначалу были попытки проведения таких встреч онлайн, но каждый раз то ключевые сотрудники не подключались, то вовлечение было минимальным.
Поэтому мы решили собрать всех в одном месте и в одно время, чтобы сначала обозначить друг другу зависимости (пресинк), а потом после цикла квартальных планирований рассказать. приняли ли мы обязательства по выполнению зависимостей или нет (постсинк). Для нас это был эксперимент, мы не очень представляли, сколько зависимостей есть по факту и есть ли смысл в проведении такого мероприятия. Чисто интуитивно понимали, что оно необходимо. Что интересно, что и сами сотрудники считали, что зависимостей не так много. И тут мы подготовили доску в Miro, где попросили весь департамент обозначить зависимости, чтобы на встрече уже предметно их обсуждать. И вот как выглядела доска:
Итак, встреча проходила ровно 1 день в офлайн формате. Собрать всех в одном месте стало тем еще приключением. Мы долго прорабатывали адженду, обсуждали, как настроить эффективную работу в группах, артефакты и образ конечного результата. Встреча была проведена, многие зависимости были проговорены вообще впервые. Но уже к обеду опрос показал, что очень многие смогли договориться:
Что же касается центра архитектуры, то на пресинке к архитекторам выстроились очереди из зависимых центров. Это очень четко подсветило, насколько важные задачи решает этот центр и сколько коллег в буквальном смысле слова от него зависят.
После проработки зависимостей, мы пришли к тому, что в Центре архитектуры пора вводить практику проведения PI Planning.
Этап 3. Масштабируем и каскадируем
Теперь наступило время погрузиться в процесс внедрения и масштабирования практик, которые разрабатывает центр корпоративной архитектуры по всей компании. Давайте вернемся к структуре, которую я описывала ранее более детально:
Как происходит сейчас:
Центр компетенций разработал стандарт и отдал его в Центр практик на внедрение. Центр практик встречается с Главными архитекторами и рассказывает о стандарте и о том, как его внедрить.
На «уровне техники» это воспроизводится процессом каскадирования эпиков. То есть Центрами компетенций и практик прорабатываются эпики и 1 раз в квартал эти эпики массово каскадируются* (назначаются) на Главных архитекторов. Например: необходимо, чтобы все продукты компании внедрили у себя определенный стандарт. Для этого создается эпик, описывающий этот стандарт и какие действия необходимо проделать, чтобы его внедрить.
Далее эпик массово клонируется (каскадируется) на представителей всех кластеров компании, а они уже клонируют этот эпик в продукты. У продуктов есть требование на реализацию стратегических эпиков технологической трансформации (от нашего департамента) в виде 25% от бэклога, поэтому они выбирают скаскадированные эпики, которые смогут «осилить» за квартал.
Так, главные архитекторы кластеров также массово каскадируют «архитектурные» эпики на продукты. Все это происходит в асинхронном режиме с «посредниками» в виде центра практик Стратегия.
А теперь представьте масштабы нашей компании и продуктов в ней. То есть, когда мы каскадируем массово эпики на все продукты и ожидаем, что эпики должны быть реализованы в срок, кажется, что это заранее невыполнимый KPI.
А вот как это выглядит со стороны продуктов — когда к тебе 1 раз в квартал «прилетает» эпик (даже очень хорошо описанный и с понятной ценностью) все равно непонятно как «впихнуть» это в свой бэклог, когда там висят очень важные и горящие идеи для бизнеса. Вот и получается «кидание мяча» от одних к другим, претензии и недовольства.
Видится, что формат PI-планирования — очевидный шаг, который поможет синхронизации и выравниванию. Во втором квартале мы уже провели пилотное PI-планирование сначала внутри центров архитектуры (что, кстати, помогло решить проблему «я не понимаю, чего от меня хотят»), в следующих кварталах планируем подключить к этому Главных архитекторов, чтобы процесс был обоюдовыгодным и каждый чувствовал свою сопричастность и ответственность за результат.
Циклы планирования будут выглядеть так:
И, наконец, этап 4. Метрики, исследования и выводы
Внедрение продуктовых практик мы начали с базового тренинга по продуктовке. Теперь мы прорабатываем дерево метрик и проводим исследования эффекта от внедрения той или иной практики. Результатом этой деятельности должна стать ситуация, когда Владельцы продуктов сами будут обращаться к нам с просьбой помочь внедрить ту или иную практику, видя, как у соседнего продукта стали улучшаться показатели.
В целом, внедрение Agile в центр корпоративной архитектуры стало сложным процессом, но правильная организация работы помогла достичь успеха.
Сегодня, как мне кажется, мы стали более продуктивными и адаптивными к изменениям, более открытыми для общения и сотрудничества в команде, непрерывно улучшаем наши метрики, процессы и инструменты. И эти достижения стали возможными только благодаря командной работе и полной поддержке руководства.
Впереди еще много работы, ведь трансформация — это непрерывный процесс.
Можно сказать, что мы уже на четвертом уровне. Как достигнем пятого – ждите еще одну статью:)
Совместим ли Agile и Центры архитектуры? Думаю, что однозначный ответ — да. Я, наверное, впервые услышала от руководителя Центра фразу: «Первый раз вижу скрам-мастера, который приносит пользу».
P.S. Если у вас есть вопросы – с радостью отвечу на них в комментариях. Там же жду ваши истории о внедрении Agile в непродуктовых командах и опыте работы со скрам-мастерами.