Что делать, когда Scrum трещит по швам: альтернативные подходы

Еще недавно Scrum и Kanban хватало для большинства проектов, с которыми я работал. Однако портфолио начало расти, и пришлось задуматься над альтернативными вариантами, которые позволили бы наращивать численность команд без существенных трансформаций процессов. После недавнего проекта Agile-трансформации для одного клиента из Global 500 мне в голову пришла идея структурировать знания о Scaled-подходах. Я долго искал такую статью, но находил только отрывки, поэтому приходится писать самому.

Scrum of Scrums

Начнем с простого — Scrum of Scrums. Это сложно назвать новым фреймворком или методологией. Суть в том, что мы просто делим большую команду на несколько подкоманд. Каждая работает по Scrum, к daily stand-up добавляем еще один daily stand-up, где присутствуют амбассадоры от каждой команды. По сути, мы добавляем к обычному Scrum еще один митинг, на котором команды синхронизируются между собой. Частота таких митингов может варьироваться в зависимости от бизнес-потребностей. Рекомендуется проводить их не реже двух раз в неделю. Именно этот митинг и называется Scrum of Scrums. Иногда используют еще один уровень — Scrum of Scrum of Scrums.

ПреимуществаНедостатки
  • Все просто, легко внедрить.
  • Подходит для 2–3 команд.
  • Этот подход не отвечает на ряд ключевых вопросов, которые возникают при росте команд (например, работа с бэклогом, роли, планирование и прочее).
Scale: 2–4 Scrum-команды (до 25–30 человек).

Nexus

Следующий подход, который мы рассмотрим, — Nexus. Разрабатывается и поддерживается Кеном Швабером и Scrum.org. Nexus — это надстройка над Scrum, которая позволяет скоординировать работу нескольких команд над одним инкрементом. Как и Scrum, состоит из таких элементов, как роли, церемонии и артефакты.

Что нового:

  • Новая роль — команда интеграции Nexus (Nexus Integration Team) осуществляет координацию, коучинг, мониторинг и контроль процессов.
  • Новые артефакты — Nexus Sprint Backlog и Integrated Increment. Команды работают над одним общим Product Backlog, у каждой команды на спринт есть свой Sprint Backlog, но есть еще Nexus Sprint Backlog — по сути, сумма бэклогов всех команд, чтобы все видели, кто над чем работает. Integrated Increment — результат совместной работы команд.
  • Новые церемонии — они не особо новые, все то же самое, что и в Scrum, только на уровень выше и с приставкой Nexus:
    • Nexus Sprint Planning;
    • Nexus Sprint Backlog;
    • Nexus Sprint Retrospective;
    • Nexus Sprint Review;
    • Nexus Daily Scrum (то же самое, что Scrum of Scrums).

Тем, кто знаком со Scrum, думаю, понятна суть церемоний, описанных выше. Подробнее можно почитать здесь: Nexus Guide.

Чуть более детально рассмотрим Nexus-команду. По сути, это еще одна Scrum-команда, которая работает над решением любой интеграционной проблемы. Эта команда отвечает за успешную интеграцию всей работы, производимой всеми Scrum-командами в Nexus. Интеграция предполагает разрешение любых технических и нетехнических межкомандных ограничений, которые могут препятствовать поставлять интегрированный инкремент в каждый спринт.

Состав Nexus Integration Team может со временем изменяться для учета текущих нужд. Nexus Integration Team состоит из:

  • Product Owner;
  • Scrum Master;
  • одного или нескольких членов команды интеграции.

Члены Nexus Integration Team могут также работать в Scrum-командах, если это возможно и необходимо. В этом случае приоритет должен отдаваться работе в рамках Nexus Integration Team.

Подробнее о Nexus Integration Team можно почитать здесь.

ПреимуществаНедостатки
  • Знакомые процессы для тех, кто практикует Scrum.
  • Фокус на интеграцию, ответственная команда для работы над вопросами интеграции.
  • Одна команда полностью выделена на работу с интеграцией. Для небольших команд это дополнительные затраты.
Scale: 3–9 Scrum-команд (до 50–60 человек).

Итак, подытожим два предыдущих подхода. Если команда вырастает до 20+ людей, мы добавляем к обычному Scrum еще один sync-up-митинг между представителями подкоманд и получаем Scrum of Scrums. Команда вырастает еще, у нас уже 30+ людей — мы собираем отдельную команду, которая занимается интеграцией работы остальных команд, а также добавляем еще один уровень церемоний — тех же, что и в Scrum, только на уровень выше. Получается Nexus.

Далее рассмотрим Large Scaled Scrum (LeSS). Он очень похож на Nexus, но все же имеет свои отличия.

LeSS

Общие черты LeSS и Nexus:

  • до 8 Scrum-команд;
  • один Product Owner;
  • общий бэклог;
  • общий DoD;
  • выровненные спринты;
  • общий инкремент.

Отличия между двумя подходами:

  • на первый этап планирования в LeSS предлагается приглашать не представителей команд, а всю команду целиком;
  • в LeSS появляется идея параллельного планирования на втором этапе;
  • Nexus описан в одном документе всего на 12 страницах, LeSS предлагает ресурсную базу данных (less.works), которая содержит множество описаний принципов и практик.

LeSS Huge

Когда количество команд становится больше 8, в LeSS предусмотрен расширенный вариант — LeSS Huge.

Что общего между LeSS и LeSS Huge:

  • один Product Backlog;
  • общее Definition of Done;
  • один Potentially Shippable Product Increment;
  • один (общий) Product Owner;
  • общий синхронизированный Sprint.

Что нового в LeSS Huge по сравнению с LeSS:

  • новая роль— Area Product Owner;
  • новые артефакты — Requirement Areas в Product Backlog и Area Backlog.

ПреимуществаНедостатки
  • Эффективное использование ресурсов, нет нефункциональных команд (Nexus) или нефункциональных спринтов (PI-Sprint).
  • Имеет две версии: до 8 и более 8 команд
  • Есть своя база знаний.
  • Требует тщательного разделения области работ между командами для минимизации зависимостей.
  • Данный подход в меньшей степени подходит для работы распределенных команд.
  • Некоторые церемонии подразумевают, что вся команда работает в одной локации или хотя бы временной зоне.
Scale: LeSS — 2–8 Scrum-команд, LeSS Huge — более 8 команд, <1000 FTE.

Итак, подведем еще один промежуточный итог (как можно заметить, в статье мы рассматриваем подходы от простого к сложному).

Первый (Scrum of Scrums), по сути, представляет собой один дополнительный митинг, второй (Nexus) — четкий процесс-надстройка над Scrum, третий и четвертый (LeSS и LeSS Huge) — это уже не только процесс, но и база знаний, где можно найти информацию по многим сопутствующим аспектам работы команд.

SAFe

Следующий подход ценен в равной степени и как методология, и как набор лучших практик и свод знаний (аналог PMBoK в мире Agile) — Scaled Agile Framework (SAFe). Так как база знаний постоянно обновляется и пополняется, он имеет версионность. На момент написания статьи актуальная версия — 4.6. По сути, SAFe не пропагандирует ничего сверхнового — это микс различных существующих практик, объединенных под одним большим зонтом. База данных отлично структурирована и имеет хорошую навигацию через главную страницу с кликабельными иконками. Даже если вы не планируете внедрять SAFe, можете просто почитать об интересующем аспекте работы Agile-команды.

О SAFe на DOU есть отличная статья — «Обзор Essential SAFe: про методологию человеческим языком».

Не буду повторять ее, дам лишь короткое описание. SAFe предусматривает 4 уровня скейла и свой набор Best Practices для каждого их них. Сведу общее описание в одну таблицу:

ПреимуществаНедостатки
  • Подходит для проектов разных размеров — от одной-двух команд до 25 000 человек («Почта Австралии»).
  • Отличная база знаний.
  • Предусмотрены очень многие аспекты процесса разработки, для каждого уровня есть свои роли, церемонии.
  • Описана не только процессная часть, но и технические аспекты (DevOps, архитектура и прочее).
  • Отличная экосистема сертификации и тренингов.
  • На уровне программы добавляется дополнительный нефункциональный PI-спринт.
  • Некоторые церемонии подразумевают, что вся команда работает в одной локации или хотя бы временной зоне.
  • Выглядит достаточно сложным для понимания.
Scale: Team — 5–9. Program — <125 FTE. Large Solutions & Portfolio Level — ∞.

Следующий подход больше напоминает базу знаний или Agile Wikipedia, чем какой-то фреймворк или методологию. Он дает инструменты и предоставляет свободу действий, но требует от того, кто его применяет, достаточного опыта.

DAD

Последним в этом обзоре будет подход Disciplined Agile Delivery (DAD). Для начала разберемся, что такое Disciplined Agile (DA). Как называют его авторы, это process decision toolkit — другими словами, набор инструментов для принятия процессных решений. То есть он дает руководства, как выбирать процессы в зависимости от ситуации. DA описывает, как разные подходы работают в совокупности и в каком случае они нужны. Как и в SAFe, тут 4 уровня, но структура немного отличается.

В рамках данной статьи мы остановимся только на первом уровне, Disciplined Agile Delivery (DAD). По структуре DAD еще больше напоминает PMBoK. Здесь есть процессы, объединенные в группы. Процессы представлены в виде целей (ответ на вопрос «Чего мы хотим достичь?»). Группы процессов соответствуют стадиям проекта:

  1. Inception.
  2. Construction.
  3. Transition.

Подробнее о каждом процессе можно прочитать здесь:

Помимо этого, в DAD достаточно большой выбор ролей. Есть Primary Roles, которые присутствуют на проектах любого скейла, и Secondary Roles, которые могут появляться на скейле временно или по мере необходимости.

DAD позиционируется как инструментарий, который помогает выбрать правильный подход, методологию или фреймворк из существующего набора:

Как следует из названия, основной фокус в DAD делается на Delivery. Ниже представлен процесс в обобщенном виде.

Аудитории предоставляется 6 разных видов жизненного цикла разработки на выбор:

Жизненный цикл проектаСхема
DAD’s Agile lifecycle
DAD’s Lean lifecycle
DAD’s Continuous Delivery: Agile lifecycle 
DAD’s Continuous Delivery: Lean lifecycle
DAD’s Exploratory (Lean Startup) lifecycle
DAD’s Program (team of teams) lifecycle

DAD-команда адаптирует тот жизненный цикл, который ей подходит больше других. Более детальное описание того, как выбрать жизненный цикл, можно найти здесь: A Full Agile Delivery Lifecycle.

ПреимуществаНедостатки
  • Очень гибкий подход, дает свободу действий и выбора в зависимости от поставленной задачи.
  • Подход достаточно сложен в применении, требует высокого уровня от практиков.
  • DAD чаще полезен как отдельный набор компонентов, чем как целостная методология.
Scale: ∞.

Это самые распространенные, но далеко не все подходы к работе с большими командами с применением гибких (Agile) подходов. Вот их неполный перечень:

Enterprise-focusInter-Team focusTransformation Focus
Disciplined Agile (DA)Crystal FamilyCollabNet Agile Transformation Strategy
Enterprise AgilityDriving Strategy, Delivering More (DSDM)EBM — Agility Path
Enterprise Unified Process (EUP)Enterprise ScrumEnterprise Transformation Framework (ETF)
laCoCa ModelFAST AgileLeading Agile
Recipes for Agile Governance in the Enterprise (RAGE)Goal Driven AgileScALeD
Scaled Agile Framework(SAFe)Large Scale Scrum (LeSS)Aditi Agile Transformation Maturity Model
Scrum@ScaleNexusAgile Maturity Model
XScalePRINCE 2 AgileAgile Capability Maturity Model Integration
Scrum of ScrumsComparative Agility
Scrum Pattern Language of Programs (PloP)Roadmap for Agile success
Spotify ModelScrum Capability Ratings
Sustainable Cultural Agile Release in the Enterprise (SCARE)
Matrix of Services
Scrum Lean in Motion (SLIM)

Еще больше подходов можно посмотреть здесь.

Выбор действительно непрост. Чтобы правильно подобрать нужный подход, нужно исходить из потребностей и поставленных задач. Приведенная ниже таблица поможет сориентироваться.

Approach Comparison
Aspects / CriteriaScrum-of-Scrums (SoS)
PO meta-scrum
Large Scale Scrum (LeSS)
Larman/Vodde
Scaled Agile Framework (SAFe)
Leffingwell
Discipled Agile Delivery (DAD) + Agility at Scale
Ambler/Lines
Nexus / Scaled Professional Scrum Scrum.orgNotes
DescriptionAn important mechanism that may be enough for smaller organizations but is not a full scaling approachLarman / Vodde model as documented in Scaling Lean & Agile DevelopmentThe method documented by Dean Leffingwell and Scaled Agile, Inc.Scott Ambler model documented in the book Disciplined Agile DeliveryScum-based scaling with an exoskeleton called Nexus plus over 40 practices
Completeness of coverage of levels, including:LowMediumHighHighMediumNote that not all Agilists believe there *should* be levels like this but they occur today in most larger orgs. Low may not = bad!
PortfolioLowMedium*MediumMediumMedium*In LeSS, Single PO and one Product Backlog is the portfolio view
Program StructureLowMedium*HighHighMedium*Less is Product focused not traditional Program release focused
Inter-team CoordinationMediumHighHighHighMedium
Team LevelMediumMediumHighHighHigh
Tech PracticesLowMediumMediumHighMedium
Popularity / Adoption (new/growing (low) vs. established/leader (high)HighMediumHighLowLow
Flexibility / Emergence: Prescriptive (low) vs. emergent (high)?HighHighLowMediumMediumNote that prescriptive may still include options or allow for customization
Typical Cost to ImplementLowLowHighMedium Can vary dramatically — usually can be free via a roll your own option
Availability of Details & SupportLowMediumHighMediumLow
What Team level frameworks are supported? (Scrum, Kanban, XP, etc.)ScrumScrumScrum / Kanban / specific XP practices mandatedScrum/LeanScrum
Emphasizes more Central control or distributed?Distributed with light coordinationCentralized prioritization and distributed coordinationMore Central & top-down on ideas but distributed ownership on howMixed — depending on chosen parts but can be somewhat centralCentral Product view and distributed remainder
Scale / Target size (small — med — large)SmallMed — LargeLarge — EnterpriseMed — LargeSmall but Nexus+ can go over 9Small: < 100 people or 10 teams
Med: >100 < 500 people or 50 teams
Large org.: >500 people or 100s of teams
*Ranges may be changed by anyone using this tool, based on their relative size preferences
Used typically by what Organization Types?Any that are running ScrumHas 2 suggested structures for different size organizationsFocused on enterprisesUsed in many diverse organizationsNew, so adoption is unclear
Focal point
(teams/structure — enterprise/ROI)
team/structure
Inter-team dependencies
org descaling, team/structure
Agile thinking, PO scale via areas
team/structure
A customizable but prescriptive framework for most aspects of Agile at scale
team/structure
Larger project stages; Technical process gaps for craftsmanship at scale
Using Scrum concepts and mindset at scale
Software centric — how often used outside of SW or IT?Could use anywhere you use ScrumFocused on Software or SW/HWFocused on Software or SW/HWHas been used outside of ITCould use anywhere you use Scrum
Big Positives / Key Differentiatorssimple, standard Scrum
focus on dependencies & resolutions
Good PO scaling; strong principle alignment, Non-prescriptive — gives suggestionsThe big picture and completeness; getting Agile in the door at large corporations; actively evolvingLots of content; strong in areas such as architecture, design and dev ops; incorporates many good modelsAuthored by Ken Schwaber
Key Risks / Concernslimited scaling, limited documentation, not clearly defined
Not likely sufficient for large scale; some differences in implementation
A more radically agile approach that may be a hard sell in larger traditional orgs with many layers and specializationsLittle info on how, most need certified SPCs to implement properly;
Seen as prescriptive; not agile enough in its structures; quick start and leave issues some places
vague in some areas about the how; can come across as a bit disjointed. Not prescriptive in lifecycleNew approach that is growing and adapting. Some of the parts are secret unless you go to the class
Training / Resource availabilityNone known;
roll your own
Training and coaching network availableYes, multi-level training & CertificationsYes, multi-level CertificationsScaled Professional Scrum training & certification is available
Deployment Approach
(how to get started and make it sustainable)
Self-Organize;
roll your own
Covered now on their siteCan roll your own but usually done with certified coaches (SPC’s) and trainingRoll your own & pick from a large number of possible practicesLikely go to class and probably need SPS coaching
NotesOften misused and turned into a status meetingNow offering certifications as practitioner or trainer. Many of its aspects are based on a fairly profound de-scaling of the org and removing of most specialist teamsBeginning to offer new certifications and have more overlap with Scrum Alliance & Scrum.orgDAD is a hybrid approach which extends Scrum with strategies from Agile Modeling (AM), Extreme Programming (XP), Unified Process (UP), Kanban, Lean Software Development, Outside In Development (OID) and several other methodsStill evolving. There is an approach for > 9 teams (Neus+) but it is only taught at SPS class. Currently, practices are also only taught at SPS class and are not publicly available
Похожие статьи:
У 2016 році в Україні запрацював Єдиний реєстр декларацій осіб. А вже наступного року стало відомо, що прокуратура проводить...
Сегодня знанием английского языка работодателя не удивишь. А вот незнанием — не только удивишь, но и расстроишь....
У свіжому випуску новинного дайджесту DOU News розповідаємо про Defence Tech кластер і що він пропонує компаніям уже...
Що потрібно, аби стати бізнес-аналітиком, як виглядає типовий робочий день такого спеціаліста й на які...
Компания Transcend представила новую карту памяти microSD промышленного класса емкостью 64 ГБ с расширенным...
Яндекс.Метрика