Ожидание | Реальность. Подводные камни agile-трансформации: разбор ошибок и советы

Привет! Меня зовут Артур Нек, я Kanban-консультант, основатель компании Neogenda и управляющий партнер Kaiten. Сегодня на примере реального кейса хочу разобрать ошибки agile-трансформации и рассказать, как избежать их и добиться крутых результатов, визуализируя рабочие процессы.

Этот кейс — Клауса Леопольда — одного из драйверов мирового Канбан-сообщества и автора книги «Переосмысляя agile». Речь пойдет о банковской компании, которая хотела улучшить Time To Market, чтобы успевать за рынком и использовать новые технологии. В штате представлено большое разнообразие команд — более 600 человек (преимущественно из IT-сферы). Для того чтобы выстроить единый процесс работы, было принято решение делать agile-трансформацию.

Time To Market (T2M) — время, которое проходит с момента создания продукта до его поступления в продажу.

Agile-трансформация — история о том, как создавать команды, формировать бэклог и регулярно поставлять новые продукты.

Главное правило: agile — это про мировоззрение, ценности и принципы, которые должны стать основой для работы команды.

Трансформироваться ребята решили по всем agile-канонам. Согласно подходу:

При этом обязательно должны быть:

Возвращаемся к банку из нашего примера. Команда очень серьезно подошла к трансформации:

📌 Для начала они составили 1,5 годовой план трансформации, в котором расписали, как реорганизовать IT-структуру.

📌 Провели базовый онлайн-тренинг на всю команду и несколько специализированных занятий, как Scrum Master, Product Owner и Kanban System Design.

📌 И пригласили 16 внешних экспертов-тренеров и 11 внутренних коучей поработать над трансформацией.

Согласитесь, размах и вложения в такой проект — огромны. Остается только придерживаться плана трансформации и ждать, когда Time To Market на графике будет выглядеть так:

Каких же успехов компания добилась спустя 12 месяцев работы:

Но что же происходит с метриками? К сожалению, произошла ситуация в духе мемов «Ожидание/реальность»:

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

Предлагаю вместе найти подводные камни, из-за которых так замедлился T2M.

На первый взгляд — классическая scrum-система: есть бэклог, куда складываются задачи, перетаскивает карточки на sprint, столбы «В работе» и т.д.

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

❓ Почему так происходит, если год назад банк уже сделал кросс-функциональные команды, которые должны быть независимы друг от друга?

Для поиска ответа Клаус Леопольд поднял графики зависимости подразделений друг от друга и попытался разобраться, почему задачи блокируются. Ведь в теории кросс-функциональные команды должны быть независимыми. Но на деле это не всегда возможно, т.к. над продуктом обычно трудятся несколько человек. Например, для создания лендинга, задействуются сразу несколько команд: верстальщики (front-end), программисты (back-end), SEO-специалисты, копирайтеры, веб-дизайнеры, маркетологи и другие сотрудники.

Приведу еще один пример. Представьте, что компания — это клавиатура, а каждый ряд клавиш — команда. Главная задача компании — написать письмо. Чтобы задействовать все символы и написать складное письмо, командам нужно скооперироваться.

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

Отсюда делаем вывод:

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

Далее эксперт обратился к команде, работающей на доске из нашего примера, и задал вопрос: «А получает ли заказчик уведомление о выполнении задачи, когда сотрудник перетаскивает ее в столбец “Готово”?». Спойлер — нет.

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

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

Немного поработав на доске, Клаус задался вопросом: «Может быть в компании не лучшая end-to-end производительность?».

End-to-end — процесс создания продукта, начиная с первоначального понимания идеи и заканчивая моментом передачи реализации заказчику.

Так обнаружилась третья проблема. Оказалось, что за этапом «Утверждение» скрываются 2 временных промежутка:

После чего сотрудников спросили: «А задачи в эту команду поступают сразу из бэклога? Или есть еще какие-то этапы, которые мы не видим?».

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

В итоге все пропущенные этапы вытащили на доску и получили еще один промежуток работы:

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

Вип-лимиты (WIP) — ограничения максимального количества задач на каждом этапе работы.

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

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

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

В итоге были сделаны новые визуализации — две новые доски:

Задачей первой было подружить Бизнес и IT. Левая часть доски предназначалась для группы менеджеров, которые отвечают за бизнес-идеи, а правая — для IT-специалистов, которые их реализуют.

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

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

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

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

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

Сначала дам общий совет. Процесс внедрения agile-метода должен быть каскадным. Если руководство решило, что компания будет работать по новой системе, то нужно начинать с головы. Ведь руководство — пример для подражания.

Что еще сделать, чтобы Agile-трансформация прошла успешно:

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