Как обеспечить развитие организации. Часть 3: Специфичные роли в SAFe | OnAgile Consulting

Как обеспечить развитие организации. Часть 3: Специфичные роли в SAFe

Итак, пришло время разобраться с нетипичными для Agile ролями, присутствующими в Scaled Agile фреймворке: Машинист (Release Train Engineer), Архитектор решения и Системный архитектор.

Release Train Engineer

Для того чтобы понять глубину и уникальность каждой роли, обратимся к биологии и для этого возьмем наименее изученный орган человеческого тела, а именно головной мозг. Итак, что мы имеем: нейроны передают данные внутри головного мозга, имеют возможность формировать пары, образуя синапсы; аксон же в свою очередь обеспечивает проведение информации от тела нейрона к другому нейрону. Ничего не напоминает? Именно так работает организация, которую можно представить в виде нейронной сети, для эффективной работы которой необходимы качественные связи.

И как раз в этом нам поможет роль машиниста (RTE) из SAFe, ведь по своей природе он является эволюционным развитием роли Скрам-мастера, но с большим фокусом на уровень программы и межкомандного взаимодействия. RTE предоставляет такие сервисы как: фасилитация ART встреч, идентификация и своевременная эскалация препятствий/ ограничений,  управление рисками и обеспечение непрерывного процесса улучшений. 

Общий список обязанностей содержит более 20 пунктов, но в целях экономии вашего времени мы объединили их в 7 групп:

  • Коучинг стримов (ART) в контексте улучшений, направленных на продуктивность и процесс
  • Результативное и эффективное проведение встреч: PI планирование, системные демо, формирование видения, построение Roadmap, встречи по подготовке к PI, встречи по завершению PI, встречи по синхронизации и другие.
  • Обучение команд в таких направлениях как Продукт, Проект, DevOps, Команда, SAFe, и адаптация Agile ценностей и принципов
  • Проведение внутреннего аудита с целью определения точек роста (Agile зрелость) и дальнейшего построения стратегии развития
  • Определение и настройка структуры ART с учетом  роста организации
  • Обеспечение прозрачности на уровне программы, особенно в контексте установленных целей на PI
  • Обеспечение взаимодействие между продуктовым штабом (PM, Владельцы продукта, Владельцы бизнеса) и продуктовыми командами.

Архитекторы

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

И начнем мы с архитекторов решения (Solution Architect). Правда сначала нужно определится с тем, что такое решение. Условимся, что под решением мы понимаем сквозные изменения, которые требуется провести на уровне множества систем с целью решения поставленной задачи. Например, обновить алгоритм скоринга по потребительскому кредиту — это уровень одной системы, а вывести новый продукт, скажем, кредит для учащихся — это комплексное решение, и одной системой тут не ограничиться. Часто это еще называют сквозным решением.

 В общем и целом архитектор решения (объединение архитекторов) определяет и коммуницирует техническое и архитектурное видение. Взаимодействие же с бизнесом хорошо иллюстрирует ниже представленный постер. 

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

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

Хотите узнать больше о каркасе SAFe, приходите к нам на тренинг Leading SAFe.

Интересно узнать подробнее?

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

Вопросы и ответы по теме

Почему роль RTE в SAFe сравнивают с аксоном в нервной системе организма?

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

Как Release Train Engineer решает главную проблему масштабирования Agile?

RTE решает ключевую проблему масштабирования – потерю эффективности при росте организации. Он выступает единым центром координации, проводя системные демо, PI планирование и обеспечивая прозрачность целей на уровне программы. Это позволяет сохранить agile-преимущества даже при большом количестве команд.

Почему системному архитектору в SAFe иногда доверяют роль архитектора решений?

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

Какое неожиданное преимущество дает разделение архитектурных ролей в SAFe?

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

Чем RTE кардинально отличается от классического Скрам-мастера?

В отличие от Скрам-мастера, который фокусируется на одной команде, RTE работает на уровне программы и объединяет множество команд. Он отвечает за коучинг целых стримов, проводит PI планирование и системные демо, обеспечивая согласованную работу всего потока создания ценности.

Как архитектор решений в SAFe трансформирует бизнес-требования в технические решения?

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

Еще публикации по Agile в Гибкие организации

2 часа вместо 7 суток. Внедрение Agile в международном банке
Кейс Банкинг

2 часа вместо 7 суток. Внедрение Agile в международном банке

Как оптимизация внутренних процессов помогла в разы увеличить скорость выпуска карт.

Мотивирующий кейс о том, как успешно инициировать изменения в компании «снизу»
Кейс Производство

Мотивирующий кейс о том, как успешно инициировать изменения в компании «снизу»

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

Уход на дому самоуправляющимися командами медсестер: модель голландской Buurtzorg
Публикация Медицина и здравоохранение

Уход на дому самоуправляющимися командами медсестер: модель голландской Buurtzorg

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

Ближайшее обучение по Agile и Scrum

С 2015 года мы помогаем адаптировать к изменениям культуру и процессы компании

Связаться с нами

Дмитрий Лобасев

Managing Partner

+7 495 221 87 39

dmitry@onagile.ru

Наш Telegram канал об Agile и гибких организациях, присоединяйтесь!