Безопасный путь. Что такое SAFe и как его внедрить
Всем привет, я — Виталий Бараш, Project Manager и Agilist до мозга костей в Luxoft. А конкретнее — в Excelian Financial Services.
За годы в роли менеджера я повидал много разных шлюпок, капитанов, матросов, весел. Роль менеджера — это достигнуть максимума при заданных ограничениях. Максимума в чем? В ожиданиях всех стейкхолдеров: команды сервисной компании, команды заказчика, самого заказчика, конечного пользователя, непосредственного руководства и т.д. Ограничения — зарплаты, домены, технологический стэк, рынок труда в локациях, межкультурные особенности, регуляторы и прочее. Хочется, чтобы все это заработало вместе — как одно целое. Для этого существует много подходов, техник, методологий, фреймворков, whatever.
Сегодня мы пойдем безопасным путем — путем SAFe. Я попытаюсь на пальцах объяснить фундамент, на котором строится этот фреймворк. Перед началом добавлю, что меня радует интерес к этой теме украинской аудитории. Чуть раньше мой тренер по SAFe Елена Лубчак уже успела опубликовать выжимку по SAFe Essentials. Эта статья будет о другом — о том, на чем всё это держится, и как мы начали внедрение этого фреймворка у себя.
Эффективность и использование
Сегодня в управлении командой, подразделением или компанией существует достаточно много методов и инструментов, которые помогают избежать негативных результатов или уменьшить их последствия и достигнуть цели. Почему же именно SAFe?
Бесплатная и исчерпывающая вики
По ссылке вы можете найти всё необходимое для работы с SAFe: блоги, форумы, статьи, энциклопедию, словарь, кейсы и т.д. Именно там стоит искать ответ, как лучше провести трансформацию бизнеса, продукта, проекта. Невзирая на возможный скепсис, для вас нет лучшего инструмента и союзника, чем наличие такого бесплатного образовательного портала или вики для ваших коллег. Хорошая база, чтобы быть on the same page — понимание того, что мы делаем, и что «same» значит одно и тоже для вас и коллег.
Кейсы успешных трансформаций в разных доменах
ОК, вики, энциклопедия и вдохновение — это хорошо. А это вообще хотя бы один раз заработало? Да, много больших организаций уже работают, применяя SAFe, а некоторые — в процессе трансформации. Множество кейсов доступно для ознакомления на все том же портале. Там вы увидите таких лидеров, как Nordea, Capital One, Deutsche Bank, Standard Bank, Westpac в финансовом мире, а также Sony, Intel, Dell, Motorola, McAfee и других с разных доменов.
Roadmap по проведению трансформации
Как бы нам ни хотелось, но трансформация сама по себе не произойдет. Нужно с чего-то начинать.
У SAFe есть понятная Roadmap, которой рекомендуется придерживаться для успешного старта и окончания трансформации как таковой. Нет серебряной пули, как говорил Фредерик Брукс, но это уже что-то для начала, верно?
Обучение и сертификаты
Разводить холивары на тему значимости «лычек» не хочу, да и нету смысла, но наличие четкого плана тренингов для различных ролей — это большой плюс при обучении сотрудников компании. Это еще один источник для обучения ваших топ-менеджеров, инженеров, фасилитаторов. Как только вы начнете трансформацию, почувствуете большую необходимость в возможности общения на одном языке. В этом плане тренинги и курсы сократят фазу обучения в разы.
И да, согласно
Конфигурации
«Чистая» реализация по книге встречается очень редко, и на практике мы видим некие комбинации из Scrum + Kanban (Scrumban), где-то RUP + ATDD, или даже Crystal Clear + SAFe и другие. Тем не менее SAFe попытался максимально продумать «уникальности», с которыми могут столкнуться агенты трансформации. Как результат, SAFe декларирует приведенные ниже конфигурации.
Essential
База, основа, сердце фрейморка. Это отправная точка для реализации SAFe и всех последующих конфигураций. Определяет самые базовые элементы и понятия, которые необходимо запустить, чтобы прочувствовать выгоду.
Масштаб: подходит организациям, которые работают над одним потоком бизнес-ценностей и вовлекают в работу около 150 человек.
Другими словами: организации, которые работают исключительно над одним продуктом средней или высокой сложности.
Portfolio
Помогает синхронизировать выполнение портфеля и стратегию организации, реализовывая гибкую разработку вокруг одной бизнес-ценности через один или несколько потоков.
Масштаб: подходит организациям, которые работают над несколькими потоками бизнес-ценностей, каждый из которых вовлекает до 150 человек.
Другими словами: несколько продуктов средней-высокой сложности — это цель организации. Из этого возникает необходимость в управлении портфелем, где принимаются решения по распределению бюджета между потоками и т.д.
Large Solution
Эта конфигурация предназначена для разработки больших и сложнейших решений, которые разрабатываются несколькими ART (Agile Release Train) с возможным привлечением вендоров, но при этом нет необходимости в управлении портфелем.
Масштаб: подходит организациям, которые работают над одним комплексным и сложным решением и делают ставку только на это решение. Вовлекают в процесс более 150 человек. Например, создание нового космолета однозначно требует разработки software (SW), hardware (HW), firmware (FW) и других вещей, при том, что над каждой может работать до или более 150 человек одновременно.
Другими словами: организации, которые занимаются исключительно одним, но комплексным и сложным решением (как следствие, нет нужды в управлении портфелем).
Full
Это наиболее исчерпывающая конфигурация фреймворка. Предназначена для поддержки организаций, которые разрабатывают несколько комплексных и сложных решений одновременно, где вовлекаются все уровни SAFe: team, program, large solution и portfolio. В такого рода организациях могут быть реализованными несколько различных конфигураций SAFe.
Масштабы: подходит организациям, которые работают над несколькими потоками бизнес-ценностей, где каждый такой процесс вовлекает более чем 150 человек. Теперь уже строим и спутники ☺
Другими словами: Цель организации — несколько комплексных и сложных решений. Возвращается необходимость в распределении денег и решении других важных вопросов при помощи уровня портфеля.
Итого
У нас есть 4 конфигурации для поддержки любого рода организаций: от одного продукта средней-высокой сложности до нескольких комплексных и сложных решений одновременно. Сам же SAFe при этом достаточно обширный и основывается на принципах Lean и Agile. А что же лежит в основе SAFe?
Фундамент SAFe
Давайте начнем с базовых вещей, а именно с ценностей и принципов.
Ценности
Внедрить Scrum на уровне команд — задача порой не из простых. Можете представить, что такое провести трансформацию организации?
Схемы выглядят довольно сложно, но это работает. Трансформируясь по SAFe, необходимо разделять его ценности.
Alignment
Как и машины, которые не соблюдают правила дорожного движения, так и хаотичность внутри организации может привести к серьезным проблемам. Ими тяжело управлять, и они сложно поддаются изменениям. Даже когда все понимают, куда двигается команда, в конечном счете она наверняка окажется в другом месте.
Звучит знакомо? Я не раз наблюдал нехватку коммуникации — в одной команде, между несколькими командами, организациями, поставщиками и третьими сторонами. И если мы все же планируем проводить трансформацию, необходимо убедиться, что коммуникацией легко управлять, и она достаточно быстрая и простая, иначе мы потеряем много денег. 1 день 150 высококвалифицированных профессионалов делали неправильные вещи. Стало грустно уже от самой фразы ☺
Build-in Quality
SAFe утверждает: «You can’t scale crappy code». Я добавлю — «You can’t scale crappy agility». Те же 150 высококвалифицированных профессионалов потратили на сомнительную архитектуру 2 месяца. Результат тот же, только масштаб больше. В конечном итоге мы просто избавимся от наработок и начнем с начала. Мы не можем позволить себе сомнительный дизайн и архитектуру, когда через несколько месяцев мы увидим, что наше решение уже неподдерживаемое. Время прошло, деньги потрачены, продукт... продукт, возможно, закрыт.
Кроме того, что мы не хотим, чтобы это случилось, нам еще бы и сохранить необходимые гибкость и маневренность при разработке, которая ведет к техническому долгу. Основная цель этой ценности — это сохранить вариационность. Это позволит быстро расширять архитектуру, чтобы можно было удовлетворить бизнес-потребности. Нужно продолжать «улучшаться» при помощи реализации PoC, поддерживать уровень технологической инновационности, научиться предугадывать развитие продукта и формировать для этого фундамент как можно ранее. Не может быть никакой неточности и неопределенности в ценности built-in-quality для больших решений. Это просто must have.
Transparency
Никто не может пофиксить тайну. Да и мы не читаем мысли. Разработка решений сложна, иногда даже болезненна. Увы, чтобы таки достигнуть успеха, мы не можем делать всё самостоятельно (да-да, хочешь что-то сделать, сделай это сам). Как следствие, мы должны в значительной мере положиться на коллег, отделы, подразделения и при этом работать как одно целое с предсказуемым результатом. Механизм не будет работать без доверия, где прозрачность — это всего лишь рычаг включения доверия. Каждый знает, что он делает, почему мы это делаем сейчас, когда ожидать конечного результата, что мы будем делать дальше, какая у нас пропускная способность и многое другое. Процессы должны быть прозрачными для каждой из команд: разработка, операционка, бизнес, аккаунт, отдел продаж и других.
Program execution
Выполнение — это ключевая составляющая. Если мы не можем, как говорится, «заделиверить» бизнес-ценность, то ничто другое не имеет значения. Это касается не только уровня команд. Все мы знаем, чтобы успешно провести гибкую трансформацию, её должен поддержать топ-менеджмент. В противном случае, максимум, чего мы достигнем — гибкий пузырь, в котором будут жить команды, тогда как весь остальной мир будет продолжать работать по устоявшимся подходам. Просто показуха, при которой теряются все остальные плюшки. Лидеры Lean-Agile поддерживают команды и выступают гарантами соблюдения принципов Lean-Agile каждой из команд.
Принципы SAFe
Перейдем к «безопасным» принципам.
Всегда держать в голове экономическую составляющую (Take an economic view).
Наиболее распространенная причина неудач продуктов связана именно с деньгами. Да и речь вовсе не об инвестициях, а об их окупаемости. Сам же принцип состоит из двух составляющих:
- Деливерить как можно раньше и чаще (Deliver Early and Often). Достаточно очевидная (привет, айджалисты!) вещь для нас. «Водопады» против гибких подходов — просто оставлю картинку.
- Понимать экономические компромиссные параметры (Understand Economic Trade-off parameters). Выделю 5 таковых: время цикла (и вот тот же Kanban со своим lead time), костовая составляющая продукта, траты на разработку, ценность и, конечно же, риски. Успех или провал решений и будет определяться эффективностью управления этими параметрами.
Системное мышление (Apply system thinking).
«Моя хата скраю — нічого не знаю» ☺ К сожалению, люди стремятся изолировать себя от всего вокруг, чтобы упростить существование. Программисты, ООП, абстракции.... Берем самое важное и про остальное не думаем. При создании больших решений это приведет к тому, что мы не сможем заинтегрироваться в конце и получим полуживое решение. Потому используем этот принцип — фиксируем картину в целом, а не частично. Вовлекаем все касты при планерке. Рисуем зависимости на Program Board.
Предполагаем вариационность, сохраняем опции (Assume variability, preserve options).
Этот принцип про наличие плана Б. Всегда и в любой ситуации. И чем больше таких планов мы имеем про запас, тем выше наши шансы на успех. Мы очень часто ограничиваемся вначале только одним целевым решением и на более поздних фазах запугиваем команду продукта фразами: «Нужно переписать всё приложение», «Это потом в фазе тестирования просидит вечность» и другими. С другой же стороны, излишняя вариационность очень усложняет и так достаточно сложный продукт и может привести к негативным эффектам. Потому держим баланс и помним про set-based design.
Разрабатываем инкрементально с быстрыми циклами обучения и интеграции (Build incrementally with fast, integrated learning cycle).
«Plan-Do-Check-Act», — говорят нам agilist’ы. И правильно делают. Про цикл Деминга знают многие, кто посещал тренинги по гибкостям, кто читал TPS (!=PMS), кто применяет SCRUM или что-то SCRUM-подобное. Чем чаще циклы, тем быстрее мы получаем фидбэк и обучаемся, а конечная наша цель — в каждой итерации получить рабочую систему кросс-модулей и компонентов, а также синтегрированные при необходимости soft и hardware-ные части.
Основывать майлстоны на объективных оценках работающих систем (Base milestones on objective evaluation of working systems).
Вместо того, чтобы обозначать наши майлстоны, базируясь на фазах (разработка, тестирование), мы должны думать о более мелких частях системы и ставить цели итерациям, над которыми трудятся команды. Это дает нам понимание, где мы есть и куда движемся.
Визуализация и лимитирование WIP, сокращение размера пакетов и управление длиной очередей (Visualize and limit WIP (work-in-progress), reduce batch sizes, and manage queue lengths).
«You can’t manage what you don’t measure», — причитает нам Питер Друкер. WIP, размеры пакетов, длина очередей — это только некоторые вещи, за которыми необходимо следить, чтобы повысить наши шансы на успех и убедиться, что наш роадмэп вообще выполним. Как много всего мы можем сделать через
Соблюдение каденции, синхронизация с кросс-доменным планированием (Apply cadence, synchronize with cross-domain planning).
Представим роту солдат, около 150 человек. Как выглядит в их случае строевой шаг? Все солдаты соблюдают синхронность шагов. Аналогично и тут — около 150 разработчиков, которые движутся командами итерационно и синхронно (2 недели — один шаг). Наша задача заключается в выборе этой каденции и её следовании кросс-командно. Это «must have» для частых интеграционных циклов. В противном случае — не видать нам интеграции и рабочего продукта в конце.
Раскрыть внутреннюю мотивацию сотрудников (Unlock the intrinsic motivation of knowledge workers).
Autonomy, Purpose и Mastery — те самые «золотые ключи» к мотивации сотрудников, как утверждает Дэниел Пинк. Сможем раскрыть потенциал наших команд, как только набьем руку в правильном подходе к творческим людям: убрать микроменеджмент и предоставить необходимую автономность, дать возможность развиваться и развивать других, а также показывать, как их работа влияет на общий результат.
Децентрализованное принятие решений (Decentralized decision-making).
Как же уменьшить время цикла? Один из вариантов — делегировать принятие решений. Конечно же, мы не можем делегировать все решения — мы должны держать при себе стратегические вопросы, а остальное — забота наших коллег. Это еще и поможет открыть внутреннюю мотивацию сотрудников, а также увеличит их вовлеченность. Если у вас не практикуется делегирование, то для начала такую культуру вам необходимо внедрить. С этим вам может помочь «Delegation Poker & Management 3.0» авторства Jurgen Appelo.
Как мы начали внедрение
Большинство прочитавших подумают: «Какие красивые слова... Вот только на практике всё иначе». Отчасти согласен, все «уникальны» по-своему. Немного расскажу о том, как мы стартовали SAFe-трансформацию. Оговорюсь сразу, что это тот самый кейс, когда «пролетариат» инициировал трансформацию снизу.
Сама идея зародилась давно, а мы как консалтинг-структура эту возможность упустить просто не могли. Чистое деливери хорошо, но никто не отменял added value. Начали подготавливать почву для нашего консервативного клиента, где практически все проекты ведутся итеративно (изначально Waterfall). Это значит четко выделенные стадии, меняющийся скоуп по ходу релиза («это впихнем, но вот это тоже пока оставь.... вдруг проскочит»), периодические демо, длительность релизов зависит от требований для имплементации (от 2 недель до квартала). И не каскадная модель, но и не SCRUM или Kanban. Вроде, все работает, да вот только:
- Change Management занимает много времени у лидеров;
- много команд, которые живут своей жизнью, а зависимости между командами довольно сильные;
- lead time задач достаточно высокий из-за отсутствия автоматизации как таковой (быстро выкатить значимое value на рынок затруднительно).
Начали делать обоснование, исходя из вышесказанного. Переводили слова в доллары:
- CoD (cost of delay) нового функционала;
- стоимость выкатки релизов;
- стоимость фикса багов, связанных с неразрешенными зависимостями между командами;
- количество героев-часов (это число часов, которые люди проводили в режиме овертаймов, авралов и т.д.).
Были и другие, но эти статьи — самые затратные. «Сейчас мы точно начнем трансформацию», — думал я. Однако, после представления этих данных клиенту, люди не прониклись и ничего не сдвинулось с места, а при малейших попытках продвинуть обсуждение дальше, можно было услышать: «У нас сейчас очень важные релизы идут. Мы не можем начать это делать прямо сейчас». Разумеется, с течением времени релизы всё ещё оставались важными ☺
Если гора не идет к Магомету, то Магомет идет к горе. Во время командировки в Нью-Йорк мы с командой решили действовать проактивно и провели обучение и тренинги для разных уровней: директора, тимлиды, разработчики, продактовики. Побывали мы с аналогичной программой и в Индии, охватив там широкую аудиторию специалистов. Работа была проделана, да вот результатов было немного и ничего не завелось.
Пока мы обдумывали как быть дальше, сарафанное радио таки запустилось, добралось до менеджмента. Через некоторое время нас пригласили в одну инициативу для старта трансформации как консультантов, предложив примерить роли RTE (Release Train Engineer). Здесь трансформация и берет свое начало.
Продать идею и стартовать процесс — это долго, безуспешно, обидно, досадно, пока вашу идею не поддержит топ-менеджмент. Без поддержки сверху трансформацию не запустить. Проводите обучение в разных локациях (как советует SAFe), показывайте текущие проблемы и как трансформация поможет их решить, попытайтесь найти время у директоров и менеджмента. В целом, делайте всё возможное, чтобы ваши усилия были услышаны наверху.
На сегодня начало переходу на SAFe положено. У нас уже:
- успешно стартовал Architectural Runway вместе с CTO и другими техническими специалистами;
- команда продукта начинает внедрять WSJF для приоритезации;
- команды начали реализовывать SCRUM Framework с двухнедельными спринтами и классическим набором встреч;
- для старта использовали двухуровневое планирование и уже начали отказываться от валидации capacity, т.к. velocity команд выровнялось;
- команды определили DoD и стандарты качества, основываясь на SonarQube, Burp Suite и Veracode.
Сейчас новые команды еще формируются, и мы стремимся к идеальному PI Planning’у, но System Demos уже проводим успешно.
Для лучшего визуального восприятия, как некий бонус для тех, кто дочитал до этого места, поделюсь одной из презентаций по фреймворку.
Выводы
Как упоминала Елена в своем посте, SAFe — это не лекарство от всего, а принимать решения нужно, исходя из среды обитания. Недавно я наткнулся на статью в Forbes, где SAFe как раз критикуют по нескольким аспектам. Я рад, что зарождается дискуссия вокруг фреймворка, но давайте перейдем к нашим выводам.
В этой статье мы рассмотрели, на чем же базируется SAFe:
- 4 конфигурации, которые рассчитаны для различных организаций;
- 4 ценности (alignment, built-in-quality, transparency, program execution), на которых построена культура (Culture eats strategy on the breakfast — Drucker);
- 9 принципов, которыми мы оперируем при принятии решений каждый день.
Фактически мы посмотрели на план внедрения, рекомендованный SAFe, из которого видно, что мы начинаем с обучения коллег. Если кто не читал Management 3.0 от Jurgen Apello , крайне рекомендую. Книга рассказывает о подходах к управлению и связанных с ними особенностях: от примитивных конвейеров до современных технологических предприятий. В ней автор приводит 3 версии менеджмента:
- 1.0 — Doing wrong things;
- 2.0 — Doing the right things wrong;
- 3.0 — Doing the right things right.
Как показывает и мой опыт в том числе, именно обучение сотрудников и коллег позволяет начать делать вещи правильно, а правильные вещи — это, например, решение начать трансформацию организации с SAFe.
Не забывайте, что без поддержки топов, никакой трансформации не будет. Мы можем играть на нашем уровне сколько хотим, создавать мыльные пузыри SCRUM и выставлять внешние интерфейсы для взаимодействия с waterfall-миром сколько угодно. Но реальную пользу все участники получат только тогда, когда вам дадут зеленый свет для старта.
Я собираюсь больше фокусироваться на точечных моментах реализации SAFe: экономических обоснованиях, роли DevOps, Built-in-Quality практиках и других топиках. И, разумеется, рассказать, как проходит трансформация в личном кейсе.
