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

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

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

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

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

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

Как проходила трансформация

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

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

  • нужны кросс-функциональные команды, способные полностью реализовать продукт;
  • одна команда должна отвечать за один продукт;
  • важно выбрать подход, который близок компании: scrum или kanban.

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

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

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

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

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

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

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

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

Спустя год

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

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

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

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

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

Ошибки и их решения

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

<p><i>Задачи на примере вымышленные, я хотел лишь передать структуру доски</i></p>

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

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

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

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

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

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

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

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

Ученый Рассел Акофф дает такое определение: производительность системы — не сумма отдельных ее частей. Это продукт их взаимодействия.

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

  • Гибкость организации — не наличие большого количества Agile-команд.
  • Организационная гибкость — это гибкое взаимодействие между командами.

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

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

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

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

<p><i>Пропущенные этапы на доске </i></p>

Пропущенные этапы на доске

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

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

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

  • ежемесячно,
  • ежеквартально.

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

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

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

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

  • ежемесячно,
  • ежеквартально,
  • дважды в год.

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

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

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

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

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

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

Чтобы увеличить количество проектов, нужно сократить их число.

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

<p><i>Вип-лимиты </i></p>

Вип-лимиты

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

  • рассмотрение проектов,
  • продуктовый портфель.

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

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

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

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

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

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

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

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

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

Вот так в компании вырос Time To Market практически в 3 раза.

Подытожим

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

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

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

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

44
21 комментарий

Круто, спасибо. Очень полезный кейс

2
Ответить

это не просто статья, а прямо исследовательская работа.

1
Ответить

да, неплохо потрудились над этой статьей

2
Ответить

На секундочку: Kanban - это Scrum, а не Agile

Ответить

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

3
Ответить

Ага, а рыба это тигр.

1
Ответить

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

1
Ответить