О трудностям и уроках внедрения LeSS Huge в очень забюрократизированной немецкой компании.
Автор: Вольфганг Штеффенс
Перевод с английского. Оригинальная статья 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 создавался как вариант уже существующего продукта для страхования транспортного средства, а также использовал общую базу данных (с данными для предприятий и потребителей).
Разработка существующего (названного здесь «B2C») продукта для страхования транспортного средства, а также общая база данных остались за рамками данного отчета.
В департаменте Terra работало около 250 сотрудников в двух офисах — в Германии и Индии. Из этих 250 около 150 занимались разработкой продукта, а остальные были заняты в поддержке и на «фабрике тестирования».
Еще один департамент состоял из отделов менеджмента продукта, бизнес-анализа и координации (сокращенно — PM & BA & CO). Помимо анализа рынка, ценообразования, организации и проведения маркетинговых кампаний, отдел бизнес-анализа работал над некоторыми требованиями высокого уровня, а затем передавал их в отдел координации.
Насколько я понимаю, отдел координации расставлял эти требования по приоритетности и конструировал «Продаваемые наборы функциональных элементов» в виде релизов, а затем передавал требования в департамент Terra. Кроме того, этот отдел также «принимал» функционал, функциональные элементы и исправления, поступающие от Terra. Вся эта деятельность была посвящена продукту B2B2C.
Департамент PM & BA & CO находился вне непосредственной сферы внедрения LeSS. Однако в рабочий процесс между этими департаментами внесли некоторые изменения, которые будут описаны далее.
В компании присутствовали глубинные иерархии, и первый уровень совместного менеджмента между PM & BA & CO и Terra находился на несколько уровней выше. Топ-менеджмент явно не заботило, как Terra организовывает свою деятельность, поэтому у менеджеров департамента было мало поддержки со стороны высшего руководства.
Требования клиентов к продукту B2B анализировал и расставлял по приоритетности сам департамент Terra. Его задачей была разработка обоих страховых продуктов.
Упрощенная иллюстрация Terra и его окружения:
Экспериментальная фаза
Отдел экспериментировал с однокомандным Скрамом и инженерными практиками на двух независимых субпродуктах. Каждая команда состояла из одного владельца продукта, одного Скрам-мастера и одной команды разработчиков. Команды пилотировали Скрам около 6 месяцев и получили хорошие результаты. Положительный фидбэк, а также другие факторы (например, потребность в большей гибкости, восприимчивость к изменениям, возрастание ценности бизнеса, снижение риска при запуске продукта, улучшение качества продукции) привели к решению начать agile-путешествие для всего департамента.
Наш департамент создал Руководящую коалицию Agile («Agile Guiding Coalition», AGC) [2] для направления и поддержки департамента, чтобы сформулировать вектор деятельности, решить, какие фреймворки использовать, помочь командам и устранить затруднения. В состав коалиции вошли старший менеджмент Terra, коучи Agile, архитектор, Скрам-мастер и владелец продукта.
Первичное внедрение «Скрама»
Организация
Первоначально департамент состоял из следующих функциональных отделов:
Проектирование
Кодирование
Тестирование
У каждой команды был технический руководитель (тимлид, TL) [4] и руководитель бизнеса (бизнес-лид, BL). Кроме того, был еще и менеджер программы (РМ). Дополнительно присутствовало несколько вспомогательных функций, таких как архитектура, менеджмент релиза, менеджмент дефектов, эксплуатация и некоторые другие группы.
В самом начале первичного внедрения Скрама эти функциональные отделы распустили с целью создания новой структуры.
Структуру сформировал менеджмент, основав ее на четырнадцати распределенных Скрам-командах (кросс-функциональных, но ограниченных одним компонентом). У каждой такой команды был собственный владелец продукта (PO), а над ними — Главный владелец продукта (CPO) [4]. Другие отделы (производство, архитектура и т. д.) свою структуру не меняли.
Такая структура была разработана без коучинга от экспертов Large-Scale Scrum. Изменение внедрили форсированно [5], сверху вниз, без добровольного участия сотрудников и вышестоящей поддержки для старшего менеджмента департамента Terra [6].
К моменту моего прихода как коуча эти недавно сформированные компонентные команды уже встретились впервые. На стартовых встречах менеджер программы объяснил причины изменений и сообщил об избранном направлении деятельности.
Структурное преобразование из функциональных отделов в компонентные команды:
В ходе этой фазы 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, в основном с менеджером программы, я пришел к очевидному выводу, что такая организационная структура не жизнеспособна. На деле многие сотрудники поняли и осознали, что координация потребовала огромных усилий, работа велась фрагментированно из-за использования неявных списков, и поэтому сотрудники выразили желание поменять структуру, чтобы в ней стало больше независимо работающих команд.
Кроме того, мы пришли к выводу, что требования необходимо описывать по-другому, структуру бэклога продукта поменять, а для его ведения использовать другую рабочую модель.
Сноски
Из-за NDA мне не разрешается упоминать название компании.
AGC в основном выполняла эксперимент «Попробуйте… Препятствия вместо менеджмента изменений». AGC действительно приняла несколько важных решений — например, инициировала «первичную проработку бэклога продукта», которая стала толчком для принятия LeSS Huge.
Фактически, менеджер субпроекта.
Координатор эксперимента - попробуйте избежать / см. ниже.
Не выполнялся эксперимент «Попробуйте ... Постепенный переход от компонентов к командам по функциональным элементам.
Избегайте / попробуйте ... Принятие с поддержкой менеджмента сверху вниз.
Попробуйте ... Сообщества.
Попробуйте ... Сообщество для Скрам-мастеров.
Этот подход был более «создающим agile», чего, конечно, следует избегать.
Должен отметить, что некоторые из старших менеджеров имели представление лишь о «фальшивом Скраме» и хотели, чтобы старшие менеджеры стали менеджерами-координаторами. Благодаря коучингу мы избежали этой ситуации (Избегайте ... Скрам-мастеров как координаторов).
Избегайте… Скрама Скрамов как статусной встречи для менеджмента.
Избегайте ... Скрама Скрамов как встречи Скрам-мастеров.
Попробуйте ... Ротацию представителей Скрама Скрамов и Избегайте ... частой ротации представителей.
Эта группа описана позже в разделе «Организация».
Руководство: Возможно, не стоит проводить Скрам Скрамов.
Этого следует избегать (см. Избегайте ... Необходимости "затвердения"); однако, поскольку системное тестирование отставало, открылось временное окно, в котором коррекция исправления ошибок имела высший приоритет.
Конец первой части. Во второй части речь пойдет о переходе на LeSS Huge.
Comments