О пробном внедрении LeSS Huge в немецкой страховой компании (часть 1) | Agile тренинги, обучение и сертификации Scrum, Kanban, DevOps в Scrum Украина
Статья отображается на оригинальном языке.

О пробном внедрении LeSS Huge в немецкой страховой компании (часть 1)

О трудностям и уроках внедрения LeSS Huge в очень забюрократизированной немецкой компании.

12 фев 2020

Автор: Вольфганг Штеффенс
Перевод с английского. Оригинальная статья Attempted LeSS Huge adoption at a German insurance company.

Вступление

Настоящий отчет описывает изменения в департаменте начиная с первичного внедрения Скрама и до внедрения LeSS Huge. Путь к LeSS Huge включал следующее (список не исчерпывающий):

  • переформирование департамента
  • определение областей требований
  • внедрение мероприятий LeSS
  • внедрение нового способа описания требований
  • реструктуризация бэклога продукта.

Предлагаемый отчет начинается с краткого описания вводных, экспериментальной фазы (с лета по декабрь 2016 года, при которой я не присутствовал) и первичного внедрения Скрама (декабрь 2016 года - март 2017 года), в ходе которого я уже осуществлял коучинг в этом департаменте.

Внедрение LeSS Huge началось в апреле 2017 года и описано здесь более подробно.

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

Цель

Цель данного отчета — получить критический разбор попытки внедрения LeSS Huge в департаменте. Несмотря на многие позитивные сдвиги отчет сосредотачивается на возникших проблемах и обсуждает их причины и результаты, что часто помогает лучше понять динамику организационных изменений, нежели ситуации «гладкого» внедрения. Поэтому не воспринимайте это описание как пример надлежащей практики.

Вводная информация

Большинство людей оформляет для себя какую-то страховку. Чтобы лучше понять контекст нашего случая, я объясню несколько важных аспектов на примере Отто.

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

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

Департамент Terra принадлежит очень крупной немецкой страховой компании Alpha [1]. Terra отвечает и за разработку собственного продукта, и за его эксплуатацию. Здесь создаются два типа продуктов, обозначенные далее как виды страхования транспортного средства «B2B2C» и «B2B».

B2B2C был услугой страхования транспортного средства на территории Германии, в то время как B2B - международной страховой услугой для агентов. B2B2C создавался как вариант уже существующего продукта для страхования транспортного средства, а также использовал общую базу данных (с данными для предприятий и потребителей).

Alt Text

Разработка существующего (названного здесь «B2C») продукта для страхования транспортного средства, а также общая база данных остались за рамками данного отчета.

В департаменте Terra работало около 250 сотрудников в двух офисах — в Германии и Индии. Из этих 250 около 150 занимались разработкой продукта, а остальные были заняты в поддержке и на «фабрике тестирования».

Еще один департамент состоял из отделов менеджмента продукта, бизнес-анализа и координации (сокращенно — PM & BA & CO). Помимо анализа рынка, ценообразования, организации и проведения маркетинговых кампаний, отдел бизнес-анализа работал над некоторыми требованиями высокого уровня, а затем передавал их в отдел координации.

Насколько я понимаю, отдел координации расставлял эти требования по приоритетности и конструировал «Продаваемые наборы функциональных элементов» в виде релизов, а затем передавал требования в департамент Terra. Кроме того, этот отдел также «принимал» функционал, функциональные элементы и исправления, поступающие от Terra. Вся эта деятельность была посвящена продукту B2B2C.

Департамент PM & BA & CO находился вне непосредственной сферы внедрения LeSS. Однако в рабочий процесс между этими департаментами внесли некоторые изменения, которые будут описаны далее.

В компании присутствовали глубинные иерархии, и первый уровень совместного менеджмента между PM & BA & CO и Terra находился на несколько уровней выше. Топ-менеджмент явно не заботило, как Terra организовывает свою деятельность, поэтому у менеджеров департамента было мало поддержки со стороны высшего руководства.

Требования клиентов к продукту B2B анализировал и расставлял по приоритетности сам департамент Terra. Его задачей была разработка обоих страховых продуктов.

Упрощенная иллюстрация Terra и его окружения:

Alt Text

Экспериментальная фаза

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

Наш департамент создал Руководящую коалицию Agile («Agile Guiding Coalition», AGC) [2] для направления и поддержки департамента, чтобы сформулировать вектор деятельности, решить, какие фреймворки использовать, помочь командам и устранить затруднения. В состав коалиции вошли старший менеджмент Terra, коучи Agile, архитектор, Скрам-мастер и владелец продукта.

Первичное внедрение «Скрама»

Организация

Первоначально департамент состоял из следующих функциональных отделов:

  • Проектирование
  • Кодирование
  • Тестирование

У каждой команды был технический руководитель (тимлид, TL) [4] и руководитель бизнеса (бизнес-лид, BL). Кроме того, был еще и менеджер программы (РМ). Дополнительно присутствовало несколько вспомогательных функций, таких как архитектура, менеджмент релиза, менеджмент дефектов, эксплуатация и некоторые другие группы.

В самом начале первичного внедрения Скрама эти функциональные отделы распустили с целью создания новой структуры.

Структуру сформировал менеджмент, основав ее на четырнадцати распределенных Скрам-командах (кросс-функциональных, но ограниченных одним компонентом). У каждой такой команды был собственный владелец продукта (PO), а над ними — Главный владелец продукта (CPO) [4]. Другие отделы (производство, архитектура и т. д.) свою структуру не меняли.

Такая структура была разработана без коучинга от экспертов Large-Scale Scrum. Изменение внедрили форсированно [5], сверху вниз, без добровольного участия сотрудников и вышестоящей поддержки для старшего менеджмента департамента Terra [6].

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

Структурное преобразование из функциональных отделов в компонентные команды:

Alt Text

В ходе этой фазы AGC определила:

  • Дату, когда заново сформированные команды начнут работать в новой структуре
  • Двухнедельную продолжительность Спринта
  • Рамку с основными церемониями Скрама, а также семинар по проработке (на каждый Спринт)
  • Обзор Спринта на уровне продукта, в котором некоторые команды добровольно представляли функционал другим командам, старшему менеджменту, менеджменту продукта
  • Отдельную функцию тестирования системы
  • Скрам Скрамов (Scrum of Scrums).

Владельцы продуктов создали:

  • Подборку неявных списков задач от команд, объединенную в один бэклог продукта (PB).

Команды создали:

  • Общее определение сделанного для всех команд
  • Различные сообщества [7] — например, Java

Скрам-мастера создали:

  • Сообщество Скрам-мастеров [8]

Что случилось потом ...

Ко времени первичного внедрения «фальшивого» Скрама требования для следующего релиза продукта (6.5) уже были проанализированы и «спроектированы». Согласно старым способам работы, «оставшиеся» задачи для отделов разработки и тестирования зафиксировали в Jira. Эти элементы работы не получили осмысленных оценок, что сделало почти невозможным планирование релиза и отслеживание прогресса; налицо было отсутствие прозрачности. Такие задачи даже назвали «Пользовательскими историями», хоть они и были весьма далеки от первоначальных идей в основе реальных Пользовательских историй [9], а именно непосредственного разговора между разработчиками и клиентами.

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

Поскольку местные команды были просто однокомпонентными группами, а не настоящими Скрам-командами разработчиков, способными выполнять всю работу от начала до конца, в создании функционального элемента клиента они очень сильно зависели друг от друга [10].

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

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

Пытаясь быстро решить проблему с перебрасыванием дефектов, AGC созвала центральное координационное совещание, Скрам Скрамов (Scrum of Scrums, SoS), которое помогло с ней справиться.

Примечание: SoS не устранил первопричину проблемы с перебрасыванием дефектов между командами, а именно структуру «один компонент на команду», он просто отреагировал на нее.

Как и говорилось в эксперименте «Попробуйте... Скрам Скрамов», эта встреча в краткосрочной перспективе помогла разобраться с обработкой дефектов. На Скраме Скрамов использовалась одна физическая доска, откуда все команды выбирали элементы и видели, что с ними происходит. Это была встреча команд для команд [11]. Каждая команда действительно отправила туда своего представителя, который не был их же Скрам- мастером [12]. Представители команд сменялись каждый Спринт или через один [13].

С другой стороны, Скрам Скрамов не справился с основной причиной этой проблемы, состоявшей в следующем:

  • Структура организациив виде компонентных команд, зависимых друг от друга.
  • Существование группы менеджмента дефектов. [14]
  • Отсутствие соответствующей информационной системы
  • Если организация хочет улучшить рабочую среду и таким образом устранить препятствующие элементы, рекомендуется избегать централизованных совещаний, таких как Скрам Скрамов [15].

Поскольку стабильность продукта не поддерживалась, разработка функционального элемента закончилась «заморозкой» кода (code freeze), за которой последовал период «затвердевания» ("hardening") [16], совпавший с периодом приемочного тестирования у пользователя перед тем, как был разрешен запуск этого нового релиза.

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

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

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

К концу этого релиза был готов только самый основной и критически необходимый функционал.

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

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

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

Выводы

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

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

Сноски

  1. Из-за NDA мне не разрешается упоминать название компании.
  2. AGC в основном выполняла эксперимент «Попробуйте… Препятствия вместо менеджмента изменений». AGC действительно приняла несколько важных решений — например, инициировала «первичную проработку бэклога продукта», которая стала толчком для принятия LeSS Huge.
  3. Фактически, менеджер субпроекта.
  4. Координатор эксперимента - попробуйте избежать / см. ниже.
  5. Не выполнялся эксперимент «Попробуйте ... Постепенный переход от компонентов к командам по функциональным элементам.
  6. Избегайте / попробуйте ... Принятие с поддержкой менеджмента сверху вниз.
  7. Попробуйте ... Сообщества.
  8. Попробуйте ... Сообщество для Скрам-мастеров.
  9. Этот подход был более «создающим agile», чего, конечно, следует избегать.
  10. Должен отметить, что некоторые из старших менеджеров имели представление лишь о «фальшивом Скраме» и хотели, чтобы старшие менеджеры стали менеджерами-координаторами. Благодаря коучингу мы избежали этой ситуации (Избегайте ... Скрам-мастеров как координаторов).
  11. Избегайте… Скрама Скрамов как статусной встречи для менеджмента.
  12. Избегайте ... Скрама Скрамов как встречи Скрам-мастеров.
  13. Попробуйте ... Ротацию представителей Скрама Скрамов и Избегайте ... частой ротации представителей.
  14. Эта группа описана позже в разделе «Организация».
  15. Руководство: Возможно, не стоит проводить Скрам Скрамов.
  16. Этого следует избегать (см. Избегайте ... Необходимости "затвердения"); однако, поскольку системное тестирование отставало, открылось временное окно, в котором коррекция исправления ошибок имела высший приоритет.

Конец первой части. Во второй части речь пойдет о переходе на LeSS Huge.

Рекомендованные мероприятия

Jurgen De Smet, Евгений Лабунский  

The Certified LeSS Practitioner course is an in-depth course covering the LeSS principles, framework and rules, and guides. It provides essential information for adopting LeSS to your product development group. This highly interactive course ensures you are ready to start adopting LeSS in your organisation!

Дмитрий Незабытовский, Павел Камышов  

Друзья, мы хотим общаться! Встречи на тренингах это здорово, но там мало места для импровизации, ведь есть четкое расписание, которому нужно следовать. Поэтому мы приглашаем вас на Lean Coffee!

Алексей Кривицкий, Евгений Лабунский  

Это официальный двухдневный интенсивный сертификационный класс от ScrumAlliance. Курс читает Алексей Кривицкий - Certified Scrum Trainer, разработчик, скрам-мастер и практикующий agile-коуч с 2004 года.

Рекомендованные статьи

How to achieve more with LeSS – эксклюзивное интервью с Басом Водде

Вначале были эксперименты, эмпирика и накопление опыта. Далее появились структура, стандарты и настройка системы. Фреймворк LeSS вырос на плодородной почве практических примеров от гуру масштабирования Баса Водде и Крейга Лармана. Читайте полное интервью автора LeSS.

Конференция "LeSS Day Europe 2020 Kyiv"

Scrum Ukraine проводит в апреле уникальный ивент - конференцию, посвящённую кейсам глубоких многолетних agile трансформаций, включая кейсы SAP, BMW, страховой и коммунальной индустрий.

Новый год 2020 — уже в пути!

Дорогие друзья — клиенты, коллеги!

Время подводить итоги-2019 и готовиться к новому, 2020 году. Мы потрудились на славу: проводили Agile и LeSS-трансформации в крупнейших украинских и зарубежных компаниях, организационный коучинг и коучинг продуктовых команд, тренинги и обучение сотрудников, …

Мы активны в социальных сетях и хотим общаться. Добавляйтесь на нашу страничку в facebook и присоединяйтесь к нашим сообществам.

По вопросам корпоративных программ и коучинга:
063 810-72-25 Евгений
093 497-46-61 Екатерина
hello@scrum.ua

Во вопросам мероприятий, тренингов, регистраций и счетов:
095 014-5900 Татьяна
backoffice@scrum.ua

По всем номерам - голос, sms, viber.

©2017 - 2020 Scrum Ukraine. Все права защищены.