2.3.2 Масштабирование гибких практик управления

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

2.3.2.1 Традиционные фреймворки

Первый и наиболее распространенный способ – применение одного из традиционных фреймворков масштабирования: масштабированный гибкий фреймворк (Scaled Agile Framework), масштабированный скрам (Large-Scale Scrum), скрам над скрамом (Scrum of Scrums) и другие.

Наиболее популярным фреймворком для небольшой организации является

«скрам над скрамом» (SoS). По степени популярности уступает лишь SAFe:

применялся в 27 организациях из 100.87 Его отличительная черта – ежедневное пятнадцатиминутное собрание избранных членов нескольких команд, работающих над одним клиентским направлением, для обсуждения текущего прогресса и обмена знаниями.88

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

87The 11th Annual State of Agile Report Op. cit. P. 14

88Radigan D. Moving on up: Scaling agile in large organisations // Atlassian, 30 November 2016: https://ru.atlassian.com/agile/ways-to-scale-agile

37

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

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

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

Масштабированный гибкий фреймворк (SAFe) является наиболее популярным способом масштабирования гибких методов управления: применялся в 28% случаев.90 Он применим для наиболее крупных организаций, поскольку использует более структурированный подход к трансформации и имеет в своей основе три уровня: уровень Команды, уровень Программы и уровень Портфеля.

Каждая команда работает по скраму в течение двухнедельного цикла. Для координации деятельности команд, работающих над связанными задачами, создан уровень Программы. На этом уровне все задачи подразделяются на 2 группы:

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

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

89Large-Scale Scrum // LeSS, 2017: https://less.works/

90The 11th Annual State of Agile Report Op. cit. P. 14

91SAFe 4.0 for Lean Software and Systems Engineering // Scaled Agile, 2017: http://www.scaledagileframework.com/

38

2.3.2.2 «Модель Spotify»

Второй крупный подход – трансформация банка на основе «Spotify модели»,

получившей свое название в честь крупнейшего музыкального онлайн сервиса, в

котором она была впервые разработана и применена. Сегодня эта модель находит активное применение в быстроразвивающихся инновационных IT-корпорациях,

таких как Google, Netflix, Amazon.

Данная модель функционирует на основе матричной структуры. Каждый сотрудник компании входит одновременно и в команду («squad») и в «чаптер» –

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

«трайб» в зависимости от разрабатываемого продукта или реализуемой бизнес-

цели, что упрощает координацию между командами. Глава трайба (топ-менеджер компании) устанавливает приоритеты, выделяет бюджет, отвечает за взаимодействие с другими трайбами. Помимо этого, каждый трайб имеет собственного agile тренера, который помогает отдельным сотрудникам и командам взаимодействовать с максимальной эффективностью. Специалисты, разделяющие единые интересы (не обязательно члены одного отдела), входят в состав определенной гильдии. (см. Приложение 3) Размер гильдии может варьироваться в зависимости от конкретного направления. В гильдии участники обмениваются опытом, проводят тренинги, получают обратную связь.92

92 ING Scaling Agile // Frismakers, 15 September 2016: https://frismakers.com/ing-scaling-agile

39