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

5374

Что делать, когда 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 человек).

 

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

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
Nexus

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

Nexus Integration Team
Nexus Integration Team

Состав 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-команда адаптирует тот жизненный цикл, который ей подходит больше других. Более детальное описание того, как выбрать жизненный цикл, можно найти здесь: A Full Agile Delivery Lifecycle.

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

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

Enterprise-focus Inter-Team focus Transformation Focus
Disciplined Agile (DA) Crystal Family CollabNet Agile Transformation Strategy
Enterprise Agility Driving Strategy, Delivering More (DSDM) EBM — Agility Path
Enterprise Unified Process (EUP) Enterprise Scrum Enterprise Transformation Framework (ETF)
laCoCa Model FAST Agile Leading Agile
Recipes for Agile Governance in the Enterprise (RAGE) Goal Driven Agile ScALeD
Scaled Agile Framework(SAFe) Large Scale Scrum (LeSS) Aditi Agile Transformation Maturity Model
Scrum@Scale Nexus Agile Maturity Model
XScale PRINCE 2 Agile Agile Capability Maturity Model Integration
Scrum of Scrums Comparative Agility
Scrum Pattern Language of Programs (PloP) Roadmap for Agile success
Spotify Model Scrum Capability Ratings
Sustainable Cultural Agile Release in the Enterprise (SCARE)
Matrix of Services
Scrum Lean in Motion (SLIM)

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

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

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

Источник https://dou.ua/lenta/articles/scrum-alternatives/