О пробном внедрении 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.

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

тренинг
Евгений Лабунский  

Двухдневный курс по основам Agile и фреймворкам Scrum и Kanban. Курс сертификационный, по его окончанию участники получают именные сертификаты ICAgile Certified Professional - Agile Fundamentals (ICP), которые признаются во всем мире.

тренинг
Евгений Лабунский  

Однодневный онлайн-тренинг для Advanced специалистов, о работе с бэклогом, а именно о практиках его декомпозиции. Большое количество проблем в аджайл командах возникает при работе с бэклогом. Этот тренинг научит вас одной из практик его структурирования - User Story Mapping

тренинг
Евгений Лабунский  

Двухдневный углубленный класс посвященный фасилитации. Курс сертификационный, по его окончанию участники получают именные сертификаты ICAgile Certified Professional.

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

Как работает оценивание задач в Kanban на практике?

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

Advanced Certified Scrum Master

Углублённая 6-недельная программа развития и поддержки Скрам Мастеров с сертификацией

25 идей, как остаться эффективной командой, работая из дома

23 марта мы провели мега-вебинар на 500+ человек, посвященный поиску идей, как командам эффективно работать по ремоуту и обмену опытом. Всего получилось больше 50 идей, все они изложены: здесь

Полная видеозапись вебинара: здесь!

Смотрите и будьте продуктивны!

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

По вопросам коучинга и корпоративных программ:
+380 67 6783099 офис
+380 63 8107225 Евгений
hello@scrum.ua

По вопросам публичных классов, регистраций, счетов:
+380 67 6783099 офис
+380 93 4974661 Катерина
backoffice@scrum.ua

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

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