Процесс спринта и события в LeSS

Представьте, что над одним продуктом работают сразу несколько команд. Как тогда сохранить привычный ритм спринтов и не утонуть в бесконечных совещаниях по их синхронизации? Для этого Large-Scale Scrum (LeSS) предлагает всем командам двигаться едиными спринтами и вместе участвовать в общих событиях. Давайте изнутри посмотрим, как устроены события и итерации в LeSS, если бы сам автор методологии вёл нас по пути размышлений о каждом из элементов процесса.

Один спринт на все команды и единый инкремент продукта

В основе LeSS лежит стремление сохранить итеративный подход классического Scrum, даже когда команд становится много. Как этого достигнуть? За счет того, чтобы на один разрабатываемый продукт – был один общий бэклог, синхронизированные спринты и единые инкременты. Все команды берут задачи из общего Product Backlog и в конце каждой итерации вместе выпускают один потенциально пригодный к поставке инкремент продукта. В LeSS все команды находятся в общем спринте, то есть стартуют и завершают итерацию одновременно. Нет отдельных «мини-спринтов» для каждой группы – вместо этого множество команд действует синхронно, как единая большая Scrum-команда, разделенная на несколько малых.

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

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

Двухэтапное планирование спринта

С самого начала спринты в LeSS отличаются от классического Scrum – планирование спринта здесь проходит в два этапа. Дело в том, что при множестве команд нужно одновременно сохранить общую картину и дать автономию в планировании работы.

Первая часть планирования собирает вместе представителей всех команд, Product Owner’а и Scrum-мастеров. На этой встрече задаётся вопрос «Что делать?» и ищется ответ на него – какие из элементов общего бэклога взять в работу в новом спринте. Вместо того чтобы сверху назначать задачи командам, LeSS поощряет самоорганизацию в выборе работы. Команды совместно с Product Owner’ом обсуждают приоритетные элементы бэклога и самостоятельно решают, какая команда какой элемент возьмет в спринт. Здесь происходит открытый диалог: команды задают Product Owner’у последние уточняющие вопросы и вместе проясняют цели спринта. 

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

Вторая часть планирования – здесь каждая команда уже работает отдельно у себя. На этом этапе звучит вопрос «Как будем делать?». Команда детально продумывает, как именно будет выполнять задачи, взятые в спринт. Это очень похоже на обычное планирование в Scrum-команде: разбивка задач на подзадачи, их оценка и распределение ролей внутри команды. 

Хотя команды и разошлись по разным комнатам, дух сотрудничества никуда не исчезает. Если два или более коллектива взялись за тесно связанные функциональности или затрагивают одни и те же компоненты системы, они могут провести вторую часть планирования совместно в одном помещении. Это формат multi-team planning – команды находятся рядом, могут в любой момент задать друг другу вопрос, вместе набросать архитектурное решение на доске, а то и провести кросс-командную парную проработку. 

Это живой пример того, как LeSS организует взаимосвязь без бюрократии – через прямое общение и сотрудничество по инициативе самих команд. К концу второй части планирования каждая команда выходит с четким планом достижения Definition of Done по каждой задаче, и с уверенностью, что учтены все взаимозависимости и общая цель.

Ежедневная синхронизация и координация без бюрократии

Возвращаемся к вопросу, как же координировать множество команд ежедневно и не утонуть в совещаниях по их синхронизации?

В LeSS все организовано очень комфортно и естественно: каждая команда проводит свой ежедневный Daily Scrum самостоятельно, как и положено. В рамках своей команды люди синхронизируются, планируют день и решают, что делать с возникающими сложностями. Никаких дополнительных многочасовых митингов между командами на ежедневной основе не вводится. Вместо этого работает принцип: доверять профессионализму и инициативе участников. Если командам нужно координироваться – они просто делают это напрямую в рабочем порядке, без создания новых ролей и бюрократических процедур.

При необходимости – разговаривайте друг с другом

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

Кроме разговоров лицом к лицу, команды в LeSS синхронизируются через сам продукт. Практика «Communicate in Code» (общение через код) означает, что все команды постоянно интегрируют свой код в общий репозиторий и наблюдают изменения друг друга. Кодовая база становится еще одним каналом коммуникации: разработчики видят обновления, сделанные коллегами, и если что-то затрагивает их работу – снова-таки, идут и обсуждают напрямую. Таким образом, сама техническая среда поддерживает прозрачность: проблемы интеграции обнаруживаются на берегу, и команды учатся решать их сообща в ходе спринта.

LeSS также поощряет и другие неформальные подходы к координации. Команды могут обмениваться участниками на время – так называемые «travellers» – когда, скажем, один разработчик присоединяется к другой команде на несколько дней, чтобы помочь им с вопросом, в котором нужна его компетенция, и заодно наладить поток знаний между группами. 

Периодически можно созывать открытые форумы или Open Space-встречи для обсуждения общих тем, технических решений или улучшений процесса. Все эти способы объединяет одно: они возникают по потребности, снизу вверх, вместо регламентации сверху. Минимум бюрократии – максимум доверия к командам. В результате ежедневная координация в LeSS происходит естественно, гибко и быстро, сохраняя высокую скорость движения без лишних организационных затрат.

Общий обзор спринта

Когда спринт подходит к концу, наступает время продемонстрировать результаты. В традиционном Scrum одна команда проводит Sprint Review со своими стейкхолдерами. В LeSS же, поскольку продуктом занимаются несколько команд, обзор спринта проводится один на всех – общий для всех команд и заинтересованных лиц. Задача встречи: проинспектировать общий инкремент продукта, получить обратную связь от пользователей и бизнес-заказчиков и скорректировать дальнейший бэклог при необходимости.

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

Практика показала, что эффективнее всего превратить Sprint Review в «выставку достижений спринта». В большом помещении каждая команда организует небольшой стенд или демо-станцию, где показывает свою функциональность заинтересованным лицам. Стейкхолдеры могут свободно перемещаться от одной демонстрационной точки к другой, задавать вопросы разработчикам, пробовать новые функции в действии. В центре зала Product Owner и представители команд отслеживают общую картину: какие идеи и замечания возникают у пользователей, не противоречат ли изменения друг другу, удалось ли достичь целей спринта.

Такой динамичный обзор спринта дает сразу несколько преимуществ:

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

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

Многокомандные ретроспективы

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

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

LeSS вводит дополнительное событие – общую ретроспективу (Overall Retrospective). Это отдельная встреча, в которой участвуют представители всех команд, Scrum-мастера и Product Owner. Формат может быть разным, но обычно от каждой команды приходит по 1-2 человека (часто по очереди, чтобы со временем побывали все), и вместе с ними собираются те, кто отвечает за продукт в целом. 

Зачем нужна такая ретроспектива? Чтобы взглянуть на систему разработки продукта целиком. Цель встречи – выявить системные препятствия и найти пути улучшения процесса на уровне всей организации. Здесь обсуждаются вопросы, которые выходят за рамки одной команды: насколько хорошо сработала координация между ними, не мешают ли какие-то организационные правила общей продуктивности, как улучшить взаимодействие с внешними стейкхолдерами, хватает ли командам поддержки от инфраструктуры, и так далее. 

Общая ретроспектива – это время для откровенного разговора между командами и владельцем продукта. На ней Product Owner делится своим видением, а Scrum-мастера наблюдениями о том, как команды росли и чему научились. Команды совместно ищут, как улучшить общую среду разработки, а не только отдельные практики. 

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

Максимальная длительность общей ретроспективы – около 45 минут на неделю спринта, то есть для двухнедельного спринта это примерно полтора часа. За это время участники успевают сфокусироваться на главных темах, не растекаясь мыслью. Таким образом, LeSS сохраняет дух непрерывного улучшения (Kaizen) на уровне всей системы: команды учатся не только на своих ошибках, но и на ошибках соседей, обмениваются находками и вместе совершенствуют организацию работы.

Прозрачность, самоорганизация и быстрое обучение в действии

Рассматривая все события спринта в LeSS, прослеживается общая логика: методология сознательно укрепляет прозрачность, поощряет самоорганизацию команд и ускоряет цикл обучения на всех уровнях. Масштабирование agile не должно перечеркивать те преимущества, которые делают Scrum таким эффективным в малой команде. Наоборот, LeSS стремится усилить эти преимущества, распространив их на множество команд.

Прозрачность проходит через все процессы LeSS. Один бэклог на продукт делает приоритеты и планы видимыми для всех команд одновременно. Единый инкремент означает, что к концу спринта не остается «черных ящиков» – все результаты будут интегрированы и предъявлены стейкхолдерам. Общее Планирование спринта открыто демонстрирует, кто над чем работает, а общий Обзор спринта – что именно получилось. 

В течение спринта проблемы не замалчиваются благодаря открытой коммуникации. Если что-то идет не так, это об этом сразу становится известно всем, кого касается, и проблема совместно решается. Без прозрачности невозможны ни доверие, ни эффективная самоорганизация, поэтому LeSS делает информацию открытой, а процесс – наглядным для всех участников.

Самоорганизация в LeSS – это практический принцип, заложенный в каждое событие. Команды сами распределяют работу на первой части планирования спринта, сами решают, как ее выполнять во второй части. Никто не диктует им план действий на день – на Daily Scrum команда автономно корректирует свой курс. Для межкомандной координации не существует центрального менеджера, команды сами находят точки соприкосновения и способы синхронизироваться. 

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

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

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

LeSS не добавляет лишнего, а усиливает главное  

Подводя итог, процесс спринта в LeSS кажется знакомым тем, кто уже работает по Scrum – планирование, ежедневные встречи, обзор и ретроспективы – но при этом каждый элемент адаптирован под работу множества команд без усложнения. Общий спринт сохраняет единый ритм и цель. Планирование в два этапа обеспечивает и согласованность, и автономность. Неформальная координация держит систему гибкой, а общие обзоры и ретроспективы помогают направить взгляд на продукт целиком. Всё это вместе поддерживает прозрачность на каждом шагу, дает командам пространство для самоорганизации и создает условия для быстрого обучения. 

Именно поэтому LeSS зачастую описывают как «обычный Scrum, только больше». Такой вдумчивый подход к организации итераций – ключ к успешному масштабированию agile-принципов без потери их сути. LeSS сохраняет душу Scrum, позволяя большим продуктовым командам работать слаженно, прозрачно и непрерывно учиться на пути к общей цели.