Еще недавно 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.
| Преимущества | Недостатки |
|
|
| Scale: | |
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 можно почитать здесь.
| Преимущества | Недостатки |
|
|
| Scale: | |
Итак, подытожим два предыдущих подхода. Если команда вырастает до 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.
| Преимущества | Недостатки |
|
|
| Scale: LeSS — | |
Итак, подведем еще один промежуточный итог (как можно заметить, в статье мы рассматриваем подходы от простого к сложному).
Первый (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 для каждого их них. Сведу общее описание в одну таблицу:
| Преимущества | Недостатки |
|
|
| Scale: Team — | |
Следующий подход больше напоминает базу знаний или Agile Wikipedia, чем какой-то фреймворк или методологию. Он дает инструменты и предоставляет свободу действий, но требует от того, кто его применяет, достаточного опыта.
DAD
Последним в этом обзоре будет подход Disciplined Agile Delivery (DAD). Для начала разберемся, что такое Disciplined Agile (DA). Как называют его авторы, это process decision toolkit — другими словами, набор инструментов для принятия процессных решений. То есть он дает руководства, как выбирать процессы в зависимости от ситуации. DA описывает, как разные подходы работают в совокупности и в каком случае они нужны. Как и в SAFe, тут 4 уровня, но структура немного отличается.
В рамках данной статьи мы остановимся только на первом уровне, Disciplined Agile Delivery (DAD). По структуре DAD еще больше напоминает PMBoK. Здесь есть процессы, объединенные в группы. Процессы представлены в виде целей (ответ на вопрос «Чего мы хотим достичь?»). Группы процессов соответствуют стадиям проекта:
Подробнее о каждом процессе можно прочитать здесь:
| Timing | Goals |
| Inception | |
| Construction | |
| Transition | |
| Ongoing |
Помимо этого, в DAD достаточно большой выбор ролей. Есть Primary Roles, которые присутствуют на проектах любого скейла, и Secondary Roles, которые могут появляться на скейле временно или по мере необходимости.
DAD позиционируется как инструментарий, который помогает выбрать правильный подход, методологию или фреймворк из существующего набора:
Как следует из названия, основной фокус в DAD делается на Delivery. Ниже представлен процесс в обобщенном виде.
Аудитории предоставляется 6 разных видов жизненного цикла разработки на выбор:
- The Agile lifecycleи The Continuous Delivery: Agile lifecycle— эти жизненные циклы проекта основаны на Scrum, немного расширены для обеспечения отлаженной стратегии от начала до конца (подробности).
- The Lean lifecycleи The Continuous Delivery: Lean lifecycle— эти жизненные циклы построены на основе Kanban.
- The Exploratory/Lean Startup lifecycle— этот жизненный цикл построен на стратегии Lean Startup.
- Program lifecycle— это жизненный цикл для работы нескольких команд.
| Жизненный цикл проекта | Схема |
| 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.
| Преимущества | Недостатки |
|
|
| Scale: ∞. | |
Это самые распространенные, но далеко не все подходы к работе с большими командами с применением гибких (Agile) подходов. Вот их неполный перечень:
Еще больше подходов можно посмотреть здесь.
Выбор действительно непрост. Чтобы правильно подобрать нужный подход, нужно исходить из потребностей и поставленных задач. Приведенная ниже таблица поможет сориентироваться.
| Approach Comparison | ||||||
| Aspects / Criteria | Scrum-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.org | Notes |
| Description | An important mechanism that may be enough for smaller organizations but is not a full scaling approach | Larman / Vodde model as documented in Scaling Lean & Agile Development | The method documented by Dean Leffingwell and Scaled Agile, Inc. | Scott Ambler model documented in the book Disciplined Agile Delivery | Scum-based scaling with an exoskeleton called Nexus plus over 40 practices | |
| Completeness of coverage of levels, including: | Low | Medium | High | High | Medium | Note that not all Agilists believe there *should* be levels like this but they occur today in most larger orgs. Low may not = bad! |
| Portfolio | Low | Medium* | Medium | Medium | Medium | *In LeSS, Single PO and one Product Backlog is the portfolio view |
| Program Structure | Low | Medium* | High | High | Medium | *Less is Product focused not traditional Program release focused |
| Inter-team Coordination | Medium | High | High | High | Medium | |
| Team Level | Medium | Medium | High | High | High | |
| Tech Practices | Low | Medium | Medium | High | Medium | |
| Popularity / Adoption (new/growing (low) vs. established/leader (high) | High | Medium | High | Low | Low | |
| Flexibility / Emergence: Prescriptive (low) vs. emergent (high)? | High | High | Low | Medium | Medium | Note that prescriptive may still include options or allow for customization |
| Typical Cost to Implement | Low | Low | High | Medium | Can vary dramatically — usually can be free via a roll your own option | |
| Availability of Details & Support | Low | Medium | High | Medium | Low | |
| What Team level frameworks are supported? (Scrum, Kanban, XP, etc.) | Scrum | Scrum | Scrum / Kanban / specific XP practices mandated | Scrum/Lean | Scrum | |
| Emphasizes more Central control or distributed? | Distributed with light coordination | Centralized prioritization and distributed coordination | More Central & top-down on ideas but distributed ownership on how | Mixed — depending on chosen parts but can be somewhat central | Central Product view and distributed remainder | |
| Scale / Target size (small — med — large) | Small | Med — Large | Large — Enterprise | Med — Large | Small but Nexus+ can go over 9 | Small: < 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 Scrum | Has 2 suggested structures for different size organizations | Focused on enterprises | Used in many diverse organizations | New, 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 Scrum | Focused on Software or SW/HW | Focused on Software or SW/HW | Has been used outside of IT | Could use anywhere you use Scrum | |
| Big Positives / Key Differentiators | simple, standard Scrum focus on dependencies & resolutions | Good PO scaling; strong principle alignment, Non-prescriptive — gives suggestions | The big picture and completeness; getting Agile in the door at large corporations; actively evolving | Lots of content; strong in areas such as architecture, design and dev ops; incorporates many good models | Authored by Ken Schwaber | |
| Key Risks / Concerns | limited 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 specializations | Little 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 lifecycle | New approach that is growing and adapting. Some of the parts are secret unless you go to the class | |
| Training / Resource availability | None known; roll your own | Training and coaching network available | Yes, multi-level training & Certifications | Yes, multi-level Certifications | Scaled 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 site | Can roll your own but usually done with certified coaches (SPC’s) and training | Roll your own & pick from a large number of possible practices | Likely go to class and probably need SPS coaching | |
| Notes | Often misused and turned into a status meeting | Now 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 teams | Beginning to offer new certifications and have more overlap with Scrum Alliance & Scrum.org | DAD 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 methods | Still 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 | |