Знакомство с LeSS

Переведено Алексей Воронин при поддержке ScrumTrek

(это глава 2 из книги “Large-Scale Scrum: More with LeSS” ISBN 9780321985712)

Есть два пути проектирования [конструирования]:
Один путь - сделать все настолько просто, что очевидно не будет недостатков.
И другой - сделать все настолько сложно, что не будет очевидных недостатков.
C.A.R. Hoare

Скрам для одной команды

Скрам - это процессный фреймворк, основанный на теории эмпирического управления, в рамках которого самоуправляемая кросс-функциональная команда разрабатывает продукт, следуя итеративно-инкрементальному подходу. По итогам каждого, ограниченного во времени, Спринта разрабатывается (а в идеале - поставляется) инкремент продукта, потенциально готовый к поставке. Единственный Владелец Продукта отвечает за максимизацию ценности продукта, с помощью приоритизации элементов Бэклога Продукта и постановку цели для каждого Спринта, основываясь на постоянной обратной связи от заинтересованных лиц и конечных пользователей. За достижение цели Спринта отвечает небольшая Команда, в которой нет жестко ограничивающих одной специализацией ролей. Скрам-мастер обучает Владельца Продукта, Команду и в целом организацию Скраму и как с его помощью поставлять ценность, и выполняет роль “зеркала” для команды. В Скраме нет менеджера проекта или лидера команды.

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

В Руководстве по Скраму (Scrum Guide) и Азбуке Скрам (Scrum Primer) делается акцент на работу одной команды, а не на совместную работу нескольких команд. Это естественным образом ведет к размышлениям о реализации Скрама в больших масштабах.

LeSS

LeSS - это Скрам, применяемый к множеству команд, работающих совместно над одним продуктом

LeSS - это Скрам. Скрам на больших масштабах (LeSS / Large-Scale Scrum) - это не новый или улучшенный Скрам. И это не разделение на Скрам на уровне каждой команды и что-то другое на уровне выше. Скорее это о том, как применить принципы, назначение, элементы и элегантность Скрама в контексте большого масштаба настолько просто, насколько это возможно. Так же, как Скрам или любой другой настоящий Agile-фреймворк, LeSS является “минимально достаточным подходом” для максимальной отдачи.

Скрам на больших масштабах - это не специальный фреймворк масштабирования, работающий только на уровне команд. По-настоящему масштабированный Скрам - это тот же Скрам, но работающий на большем масштабе.

…применяемый к большому числу команд: - Имея в виду кросс-функциональные, кросс-компонентные, обладающие всеми необходимыми компетенциями продуктовые команды (feature-team), состоящие из 3-9 нацеленных на обучение участников, выполняющих всю работу (от пользовательских интерфейсов и программирования до записи видео) для создания полноценного рабочего продукта.

…работающих вместе: - Команды работают вместе, потому что у них есть общая цель: по итогам общего Спринта разработать единый, цельный, готовый к поставке продукт, и каждая команда вовлечена в это, потому что она является продуктовой командой (feature-team), и отвечает за цельный продукт, а не только за его отдельную часть.

…над одним продуктом: - Каким продуктом? Полноценным (end-to-end), клиент-ориентированным решением, которое будет использоваться реальными людьми. Понятие продукта гораздо шире, чем просто компонент, платформа, слой или библиотека.

• Предыстория •

В 2002 году, когда Крэг Ларман написал книгу Agile & Iterative Development, многие считали, что Agile применим только для небольших групп. Однако, мы оба (Крэг Ларман и Бас Водд) начали интересоваться - и стали получать большое количество запросов - в применении Скрама на больших масштабах, в мультилокационной среде и в офшорной разработке. Так, начиная с 2005 года, мы объединились для совместной работы по масштабированию Скрама у крупных клиентов. На сегодняшний день два LeSS фреймворка (smaller LeSS и LeSS Huge) применяются в больших компаниях по всему миру в различных отраслях:

  • телекоммуникационное оборудование - Ericsson и Nokia Networks;
  • инвестиции и розничные банки - UBS;
  • трейдерские площадки - ION Trading;
  • маркетинговые платформы и бренд-аналитика - Vendasta;
  • видеоконференции - Cisco;
  • онлайн-игры (ставки) - bwin.party;
  • зарубежный аутсорсинг - Valtech India.

Насколько масштабным является типовой кейс внедрения LeSS? В среднем, около пяти команд на одной или двух площадках. Мы участвовали во внедрениях LeSS на подобных объемах, на объемах в несколько сотен человек, и до более чем тысячи человек в случае LeSS Huge, с очень большим числом распределенных команд разработки, десяткам миллионов строк кода на C++ и заказным, адаптированным под клиента, системным оборудованием.

Больше о LeSS

Для помощи людям в изучении LeSS, в 2008 и 2010 годах мы опубликовали две книги о масштабировании Agile разработки с помощью фреймворка LeSS, которые основаны на нашем опыте работы с клиентами:

  1. Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum - описывает изменения в мышлении, лидерстве и подходах к организационному дизайну.
  2. Practices for Scaling Lean & Agile Development: Large, Multisite & Offshore Product Development with Large-Scale Scrum - в этой книге мы делимся результатами нескольких сотен реальных экспериментов с LeSS, полученных при работе с нашими клиентами, включая управление продуктом, дизайн архитектуры решения, планирование, распределенную работу, специфику контрактов и т.д.

Книга - Large-Scale Scrum: More with LeSS - третья в серии, описывает предысторию и основы фреймворка LeSS. Она формулирует, разъясняет и подчеркивает его наиболее важные аспекты.

Помимо этих книг, рекомендуем сайт less.works, как ресурс для онлайн-обучения (включает главы книг, статьи и видео), курсов и коучинга.

• Эксперименты, Руководства, Правила, Принципы •

Первые две книги по LeSS подчеркивали: в продуктовой разработке нет такого понятия как “лучшие практики” - есть только практики, применение которых целесообразно в конкретном контексте.

Практики ситуационны, и беспечное объявление их “лучшими” отрывает их от мотивации и контекста. Они превращаются в ритуалы, и навязывание так называемых “best practices” убивает культуру обучения, задавания вопросов, вовлечения и непрерывных улучшений. Зачем людям искать чего-то лучшего, если все уже придумано за них?

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

  • Неопытные команды принимали некомпетентные решения, применяя LeSS не по назначению, с очевидными ошибками. Например, они создавали Области Требований (Requirement Areas), каждая из которых состояла из одной команды. Ой!
  • Неопытные команды спрашивали: “С чего нам следует начинать? Что является наиболее важным?” Они, очевидно, не могли увидеть и понять базовые принципы.

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

Суммируя сказанное, LeSS включает в себя:

  • Правиланесколько правил, чтобы начать работу и сформировать основу. Они определяют ключевые элементы фреймворков LeSS, которые должны быть реализованы для поддержки эмпирического контроля над процессом и фокуса на всем продукте. Например, Проводите Общую Ретроспективу (Overall Retrospective) каждого Спринта.
  • Руководства – набор рекомендаций для эффективного применения правил и для ограниченного числа конкретных экспериментов, которые доказали свою эффективность в нашем многолетнем опыте с LeSS. Рекомендации содержат полезные советы, которые могут помочь понять область для дальнейших улучшений. Например, Три принципа внедрения.
  • Эксперименты – множество наших экспериментов, которые были очень ситуационными и которые, возможно, даже не следует повторять. Например,Попробуйте… переводчика для мультиязычной команды.
  • Принципы – и, в центре всего, набор принципов, выработанных на основании нашего опыта внедрения LeSS, и являющихся основой для Правил, Рекомендаций и Экспериментов. Например, фокус на всем продукте.

Руководства LeSS и Эксперименты не являются обязательными к выполнению. Руководства могут быть полезными, и мы рекомендуем их попробовать. Но смело пропускайте те из них, которые ограничивают вас в дальнейших улучшениях или просто вам не подходят.

Хороший способ представить LeSS приведен ниже на рисунке Верхнеуровневый взгляд на LeSS:

Дальнейший рассказ о LeSS мы построим в соответствии с этим рисунком:

  1. LeSS Принципы, непосредственно следующий раздел.
  2. LeSS Фреймворки (определяются правилами) - в оставшейся части данной главы.
  3. LeSS Руководства - в оставшихся главах книги.
  4. LeSS Эксперименты - описаны в первых двух книгах.

• Принципы LeSS •

Правила LeSS определяют LeSS-фреймворк. Но правила очень минималистичны и не отвечают на вопрос, как следует применить LeSS в вашем конкретном случае. Принципы LeSS, в отличие от правил, предоставляют основу для принятия таких решений.

Масштабированный Скрам – это Скрам (Large-Scale Scrum is Scrum) - Это не новый или улучшенный Скрам. Напротив, LeSS позволяет понять, как применить Принципы, Правила, Элементы и базовую цель Скрам в масштабе настолько просто, насколько это возможно.

Прозрачность (Transparency) - Прозрачность базируется на осязаемых результатах, коротких циклах разработки, командной работе, общей терминологии и устранении страха на рабочих местах.

Больше за счет меньшего (More with less) - Нам не нужно больше ролей, потому что наличие большого числа ролей приводит к меньшей ответственности Команд. Нам не нужно больше артефактов, потому что большое число артефактов приводит к увеличению дистанции между Командами и Клиентом. Нам не нужно больше процессов, потому что формализация губит желание обучаться, и Команды перестают отвечать за процесс. Взамен мы хотим более ответственные Команды, за счёт введения меньшего числа ролей; мы хотим более сфокусированные на нуждах клиента команды, которые создают полезные продукты, порождая небольшое число артефактов; мы хотим больше командной ответственности и больше значимой работы за счет исключения лишнего формализма в процессах. Мы хотим больше за счет меньшего (“more with less”).

Фокус на всем продукте (Whole-product focus) - Один Бэклог Продукта, один Владелец Продукта, один Поставляемый Продукт, один общий Спринт – вне зависимости от того, работают ли совместно 3 или 33 команды. Клиенты получают ценность от всего продукта, а не в отдельности от его технических компонентов.

Ориентация на клиента (Customer-centric) - Фокус на изучение реальных проблем клиента и их решение. Определение того, что ценно, а что нет, в глазах клиента. Снижение времени ожидания с точки зрения клиента. Усиление петель обратной связи от реальных потребителей. Необходимо, чтобы каждый член команды понимал, как их совместная работа сегодня приносит пользу клиентам, приобретающим продукт.

Непрерывные улучшения на пути к совершенству (Continuous improvement towards perfection) - Вот наша цель на пути к совершенству: создавать и поставлять продукт практически непрерывно, с минимальными затратами, без дефектов; продукт, который восхищает клиентов и делает их жизнь лучше. Практикуйте непрерывные, небольшие и радикальные эксперименты по улучшению на пути к этой цели.

Lean-мышление (Lean Thinking) - Создайте такую организационную систему, основой которой будут руководители-учителя, применяющие и прививающие Lean-мышление, практикующие управление, направленное на улучшения, поощряющие подход “остановись и исправь”, которые используют подход “Иди и посмотри” (Go See - подход Тойота, когда менеджер присутствует там где непосредственно происходит выполнение работы). Два столпа такого управления – это уважение к людям и мышление, направленное на постоянный поиск улучшений текущего положения вещей. Все на пути к совершенству.

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

Эмпирический контроль процесса (Empirical process control) - Непрерывно инспектируйте и адаптируйте продукт, процессы, поведение, организационную структуру и практики, чтобы развиваться в направлении, адекватном текущей ситуации. Делайте это вместо того, чтобы следовать прописанным, так называемым “лучшим” практикам, игнорируя контекст, вместо слепого следования ритуалам, которое препятствует обучению и изменениям и снижает тем самым вовлеченность и ответственность людей в компании.

Применение теории массового обслуживания (Queuing theory) - Изучайте, как методы работы с очередями могут быть применены в R&D домене, и применяйте полученные знания в управлении размером очередей, ограничениями на количество незавершенной работы, многозадачностью, размерами работ и вариативностью.

• Два каркаса: LeSS и LeSS Huge •

Скрам на больших масштабах состоит из двух фреймворков:

При этом сам термин LeSS несколько перегружен и означает как Скрам на больших масштабах в целом, так и обычный LeSS-фреймворк до 8 команд.

Магическое число восемь

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

В любом случае, в какой-то момент, когда (1) один Владелец Продукта более не может держать в голове полный контекст, (2) у Владельца Продукта более не получается соблюдать баланс между внутренними и внешними коммуникациями и (3) Бэклог Продукта разрастается настолько, что один человек более не способен с ним справляться.

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

Общее для двух каркасов LeSS

LeSS и LeSS Huge имеют следующие общие элементы:

  • Один Владелец Продукта и один Бэклог Продукта;
  • Один общий Спринт для всех команд;
  • Один поставляемый инкремент продукта.

Следующие два раздела данной главы детально описывают эти фреймворки, сначала меньший LeSS, затем LeSS Huge далее в.

Каркас LeSS

• Коротко о каркасе LeSS •

Меньший LeSS-каркас подразумевает одного (и только одного) Владельца Продукта, который владеет продуктом, оптимизируя продукт в целом, и управляет одним Бэклогом Продукта, над которым работают команды в рамках общего для всех Спринта. Элементы LeSS-фреймворка практически идентичны элементам Скрам для одной команды:

Роли - Один Владелец Продукта, от двух до восьми Команд, Скрам Мастер, сопровождающий от одной до трех команд. Важно, чтобы эти команды были продуктовыми командами (feature team) – действительно кросс-функциональными и кросс-компонентными командами, которые работают совместно в едином пространстве кода и каждая из них делает всё, чтобы создать полностью готовый элемент бэклога продукта.

Артефакты - Один инкремент продукта, потенциально готовый к поставке; один Бэклог Продукта и отдельный Бэклог Спринта для каждой Команды.

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

Правила и Руководства - Правила описывают минимально достаточный фреймворк для обеспечения эмпирического контроля над процессом и фокуса на всем продукте. Руководства могут помочь вам в внедрении LeSS.

• LeSS Истории •

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

Простые истории— истории, описанные ниже, не покрывают сложные аспекты разработки на больших масштабах, от политики до приоритизации, с которыми мы сталкиваемся в нашей консалтинговой работе, - они раскрываются в следующий главах. Сюда же мы намеренно включили простые истории, только чтобы показать базовые принципы Спринта LeSS. Если вы ищете захватывающих диалогов или драмы, то почитайте лучше книгу Lean.

Правила и Руководства— внутри каждой истории вы увидите отсылки на правила и руководства, которые используются в рамках данной ситуации. Это сделано, чтобы вы смогли отследить четкую связь между правилами, руководствами и рассматриваемым примером ситуации.

Два ракурса—для того, чтобы вам было проще ознакомиться с динамикой работы в LeSS, ниже вы найдёте две связанные истории, рассматривающие ситуацию с двух основных ракурсов:

  1. Динамика работы и взаимодействия команд в ходе LeSS Спринта.
  2. Динамика клиентоориентированных элементов бэклога (features) в ходе LeSS Спринта.

• LeSS История: Поток работы команд •

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

Марк заходит в комнату, где работает его команда (Продажи), и видит Миру, которая встречает его словами: “Доброе утро! Хочу напомнить, что в этом Спринте мы с тобой являемся представителями нашей команды, и сессия Первого Планирования Спринта начнется через 10 минут”. “Хорошо”, - отвечает Марк, - “Встретимся в большой переговорной”.

Планирование Спринта Часть 1

Настало время для Первой Части Планирования Спринта, и в комнате собрались десять представителей пяти команд продуктовой группы. Все вместе они работают над флагманским продуктом компании по продаже облигаций и деривативов. Сэм, Скрам-мастер команд Trade и Margin, тоже присутствует на встрече. Он планирует наблюдать за обсуждением и подключаться как коуч, если потребуется. (ПРАВИЛО: Существует единственный общий продуктовый спринт для всех команд, а не отдельные спринты для каждой из команд).

Много Спринтов назад на Первой Части Планирования Спринта присутствовали все участники команд. Такой формат был более полезным пока участники команд еще не научились эффективно прояснять задачи и подготавливать их к работе, а также не наладили обмен знаниями о продукте между командами.
На этой встрече звучали ответы на множество вопросов, которые должен был услышать каждый. Со временем ситуация улучшилась, и сейчас группа экспериментирует, приглашая на эти встречи меняющихся из раза в раз представителей команд, благодаря чему встреча стала проходить просто и быстро. Обычно на ней поднимается и обсуждается всего несколько вопросов. Если такой новый подход не заработает, этот вопрос, вероятно, будет поднят на Общей Ретроспективе, и будет инициирован другой эксперимент по Планированию Спринта. (ПРАВИЛО: Планирование спринта состоит из двух частей. Первая Часть Планирования Спринта является общей для всех команд, в то время как Вторая Часть Планирования Спринта обычно осуществляется каждой из команд по отдельности. В случае связанных элементов бэклога проводите Межкомандную Вторую Часть Планирования Спринта.).

Вот в комнату заходит Паоло и приветствует собравшихся. Паоло является Владельцем Продукта, а также ведущим продукт-менеджером. Он раскладывает на столе 22 карточки и комментирует: “Вот наши главные темы: немецкий рынок, управление заказами и несколько регуляторных отчётов. Я разложил их в соответствии с их приоритетами. Полагаю, каждый из вас понимает, почему приоритеты именно такие, поскольку мы уже довольно долго обсуждали это в ходе сессий по Уточнению Бэклога Продукта. Но, пожалуйста, не стесняйтесь переспросить, если вам что-то не понятно”. (ПРАВИЛО: На Первой Части Планирования Спринта присутствуют Владелец Продукта и Команды, либо представители команд. Они ориентировочно выбирают те элементы бэклога, над которыми будет работать каждая из команд. Команды проясняют существующие вопросы и возможности совместной работы.).

Мира и Марк, наряду с представителями других команд, обходят стол и выбирают себе две карточки, относящиеся к облигациям на немецком рынке. В течение двух последних Спринтов их команда обсуждала и детально изучала эти области в ходе внутрикомандных встреч по Уточнению Бэклога Продукта (“PBR”, Product Backlog Refinement).

Ещё они берут две карточки, касающиеся управления заказами, которые обе команды Trade и Margin понимают достаточно хорошо - они прорабатывали эту тему в ходе совместных встреч по Уточнению Бэклога Продукта. Зачем они делали это вместе? Дело в том, что они хотели определиться с привязкой этой функциональности к конкретной команде максимально поздно, в ходе одного из будущих Планирований Спринта. Это увеличивает гибкость всей группы команд, позволяет легче реагировать на изменения, а также расширяет общие знания по продукту, что улучшает самоорганизацию и общую координацию.

Минуту спустя Мэри из команды Margin, просматривая карточки, отобранные другой командой, спрашивает их представителей: “Вы не будете против, если мы возьмём вот этот отчёт себе? Мы делали нечто очень похожее в последнем Спринте, и я готова поспорить, что мы сможем сделать его быстро. Может быть, обменяем его на вот эту карточку по немецкому рынку?”. На этом они и договорились.

Через несколько минут, исходя из своих сильных сторон и интересов, команды определяются с выбором, завершают обмен задачами и концентрируются на задачах группы в целом.

Сэм (Скрам-Мастер) говорит: “Я заметил, что команда Margin выбрала себе четыре задачи, являющиеся наиболее приоритетными. Может ли это обернуться проблемой для нас?”. После небольшой дискуссии участники встречи приходят к тому, что если дела у команды Margin пойдут не так гладко, то есть риск того, что одина из высокоприоритетных задач бэклога может быть не выполнена. Поэтому они решают перераспределить часть высокоприоритетных задач между командами, в соответствии с уровнем их знаний в той или иной области, чтобы увеличить вероятность того, что к концу спринта все высокоприоритетные задачи будут готовы.

В результате встречи участники отобрали 18 карточек, оставив на столе четыре, наименее приоритетные. Паоло проходит взглядом по оставшимся карточкам, берет две из них и говорит: “Эти две задачи важны для меня в этом Спринте. Возможно, мне стоило с самого начала дать им больший приоритет, но я этого не сделал, и сейчас хочу изменить свое решение. Давайте найдем способ поменять их с какими-нибудь из тех, что вы уже выбрали. И, конечно, если какая-то из команд закончит раньше, вы всегда можете взять в работу те, что остались”.

Когда вопрос с перераспределением решен, Паоло говорит: “Отлично, теперь давайте потратим некоторое время на решение долгоиграющих вопросов. Как вы знаете, до последнего времени я был полностью сфокусирован на уточнениях по более важным задачам, но сейчас предлагаю посмотреть, что мы вместе можем сделать, чтобы подчистить лист менее приоритетных задач.” (ПРАВИЛО: На планировании спринта команды проясняют существующие вопросы и возможности совместной работы).

Параллельно Мира, Марк и остальные формулируют открытые вопросы по своим темам и выписывают их на флипчартах, развешанных по стенам комнаты. Паоло ходит по комнате, от одного к другому, обсуждая неясные моменты с участниками команд. Все слушают и активно помогают дискуссии. Через 30 минут участники закрывают все вопросы, которые не требуют дополнительных уточнений.

Далее участники встают в круг для подведения итогов, но никто не поднимает вопросов, связанных с координацией команд, и Сэм берет инициативу в свои руки: “Я заметил, что команды Trade, Margin и NotDerivative отобрали себе все задачи, относящиеся к теме управления заказами.” Мира восклицает: “О, это же отличный шанс поработать вместе! Давайте тогда организуем общее Второе Планирование Спринта для наших команд.” Все соглашаются. На этом встреча завершается.

Командная и межкомандная Вторая Часть Планирования Спринта

После перерыва две из пяти команд проводят внутрикомандные Вторые Части Планирования Спринта, чтобы сформировать собственные Бэклоги Спринта, а также продумать и распланировать свою работу на ближайший Спринт. (ПРАВИЛО: У каждой команды свой Бэклог Спринта).

Команды Trade, Margin и NotDerivative, наоборот, остаются в большой переговорной для проведения межкомандной Второй Части Планирования Спринта, так как задачи, которыми им предстоит заниматься, тесно связаны друг с другом и уже обсуждались ими ранее, в ходе межкомандного PBR. Команды ожидают получить дополнительную ценность от совместной работы. (ПРАВИЛО: В случае связанных элементов бэклога проводите Межкомандную Вторую Часть Планирования Спринта в общем рабочем пространстве).

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

Динь! Отведенные 30 минут завершаются, и многие из деталей все еще остаются непроясненными, но команды решают двигаться дальше. Они расходятся по разным углам комнаты, где проводят индивидуальную Вторую Часть Планирования Спринта, в деталях обсуждая потенциальные сложности с дизайном решения и создавая Бэклогов Спринта на стикерах. Дальнейшая координация между командами происходит посредством продвинутого варианта техники “просто поговорите” (just talk) в LeSS: “просто крикните” (just scream).

В ходе обсуждения участники приходят к пониманию, что необходимо проведения глубокой межкомандной Сессии по Проектированию Решения (Design Workshop). Они договариваются провести её в тот же день, но чуть позже.

Многокомандная сессия по Проектированию Решения

После Планирования Спринта и ещё одного перерыва, Мира и Марк из команды Trade, и ещё несколько человек из команд Margin и NotDerivative проводят ограниченную по времени часовую сессию по Проектированию Решения, чтобы глубже погрузиться в общую архитектуру решения, которое им предстоит разрабатывать. Они делают наброски на большой доске и идет совместное обсуждение, чтобы добиться понимания и согласия в отношении подхода к дизайну решения и общих технических задач. В ходе обсуждения возникают сложности и вопросы, и команды приходят к выводу, что есть проблемы с процессом, так как стоило бы поднять и обсудить вопросы архитектуры раньше. Но, к счастью, результаты, к которым они в итоге приходят, серьезно не влияют на существующие планы Спринтов.

Активности разработки для Поддержки Координации и Непрерывной Поставки (Continuous Delivery)

После Планирования Спринта команды погружаются в разработку выбранных элементов Бэклога, с фокусом на коммуникации через программный код. Все команды постоянно интегрируют изменения. Непрерывная интеграция (continuous integration) кода между всеми командами поддерживает их взаимодействие, позволяя разработчику увидеть, кто из коллег сделал изменения в конкретном компоненте. Это полезно, так как группа использует интеграцию, как средство информирования и обеспечения общей координации.

Например, на второй день Спринта Марк, разработчик из команды Trade, забирает утром из репозитория последнюю версию кода и быстро проверяет последние изменения. Он обнаруживает связанные изменения, сделанные Максимилианом из команды Margin. Он не сильно удивлен, так как знает, что задачи, над которыми они работают, тесно связаны. Он решает немедленно обсудить изменения с Максимиллианом, так как по сути изменения в коде послужили сигналом о необходимости коммуникации, и указали на конкретного человека, с которым требуется поговорить. В результате простого разговора, они договорились каким образом необходимо организовать совместную работу, чтобы каждый из них мог извлечь пользу. (ПРАВИЛО: Предпочтительнее децентрализованная и неформальная координация вместо централизованной).

Для функционала, которые разрабатывает команда Trade, а, в действительности, для каждой задачи каждой из команд, до старта написания кода создаются автоматизированные приемочные тесты. В дополнение к непрерывной интеграции кода, происходит интеграция автотестов. Эти приемочные тесты запускаются регулярно, и, если какие-либо из них не проходят, команды получают сигнал скоординироваться. Код говорит им: “Эй! У нас проблема! Вы должны поговорить и разобраться с ней.”

Еще одно важное преимущество практик непрерывной интеграции, автоматизированного тестирования и немедленного исправления ошибок в случае неуспешной сборки билда, заключается в том, что продукт практически постоянно находится в состоянии, готовом к поставке. При этом нет отдельных команд, отвечающих за интеграцию и за тестирование, создающих дополнительные задержки, дополнительные цепочки передачи работ, и вносящих дополнительную сложность в процесс работы. (ПРАВИЛО: Цель совершенства – это совершенствование DoD до такой степени, что итогом станет возможность отгружать продукт каждый спринт или даже чаще.)

Общая Ретроспектива

На второй день Спринта Сэм вместе с другими Скрам-Мастерами, Владельцем Продукта Паоло, руководителем всей программы и представителями почти всех команд собираются на максимум полуторачасовую сессию Общей Ретроспективы прошедшего Спринта. (ПРАВИЛО: Общая Ретроспектива проводится после того, как проведены ретроспективы команд, для обсуждения кросскомандных и системных проблем, и для разработки экспериментов по совершенствованию системы.)

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

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

Координационные активности

(RULE: Кросскомандная координация организуется самими командами.)

Четвертый день принес множество идей по координации в LeSS:

В LeSS, как и однокомандном Scrum, каждая Команда проводит Ежедневный Скрам (Daily Scrum). И это удобный повод для координации. Поэтому для поддержки координацию между Командами Trade и Margin, Мира направляется Разведчиком (Scout) в Команду Margin, чтобы поприсутствовать на их Ежедневном Скраме,и затем поделиться наблюдениями со своей командой. Аналогично, кто-то из команды Margin приходит в Trade с той же целью.

Согласно договоренностям на Общей Ретроспективе, команды проводят 45-минутную встречу по координации и обмену знаниями в общем Открытом Пространстве (Open Space), с едой и напитками. Сэм выступает в роли фасилитатора, и его цель - показать участникам, как проводить такого рода мероприятия. На встречу приглашаются все, но большинство команд ограничивается отправкой своих представителей. Мира и Марк из команды Trade приходят вдвоем. Группа хочет попробовать проводить такие встречи раз в неделю.

Комьюнити (Community) по тестированию, состоящее из представителей большинства команд, собирается на получасовую встречу для того, чтобы выслушать и обсудить предложение Мэри по использованию новой утилиты для автоматизированного приемочного тестирования. Предложение многих заинтересовало, и они договариваются, что в следующем Спринте Мэри вместе со своей командой Margin, как самые заинтересованные в изучении, проведут эксперимент по ее использованию.

Мира состоит в группе, отвечающей за Дизайн/Архитектуру решения. В текущем Спринте нет необходимости проводить встречу по обсуждению архитектуры, но в следующем она хочет выделить полдня для проведения технологического спайка. Она делает пост об этой идее в соответствующем инструменте для колоборации сообщества, и предлагает сообществу реализовать этот спайк всем вместе в режиме mob-программирования, чтобы расширить их общие знания.

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

Позже Мира вместе с коллегами из других команд навещает службу поддержки и группу обучения, которые напрямую работают с пользователями их Продукта. Ее команда недавно завершила работу над первой фичей для них, и теперь они хотят получить раннюю обратную связь от людей, находящихся в непосредственном контакте с клиентами. У одного из сотрудников есть время, и он пробует новую функциональность, после чего Команда Trade уходит с несколькими идеями по ее улучшению.

Далее Марк и остальные участники Trade приступают к разработке второй задачи. Марк только что закончил десятиминутный цикл TDD (test-driven development) и получил стабильную версию кода после внесения небольшого изменения. Еще раз: каждые десять минут он заносит свои правки в общий репозиторий (в основную ветку, “head of trunk”), чтобы непрерывно интегрироваться с командой и остальными. После этого переводит взгляд на большой красно-зеленый экран на стене, и видит, что система сборки один за другим прогоняет тесты для всей группы.

Общая сессия по Уточнению Бэклога Продукта

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

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

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

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

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

Командные и многокомандные сессии по уточнению бэклога (PBR)

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

На шестой день все участники от трех команд собираются на общую PBR сессию в большой переговорной.

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

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

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

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

Беседа о Бэклогах Команд и Владельцах Продукта

После многокомандной PBR сессии, Майк, недавно пришедший в компанию, видит Сэма, стоящего у кофемашины, и подходит к нему для того, чтобы начать разговор.

  • Привет, Сэм, можно узнать твое мнение по одному вопросу? Я обратил внимание, что на сессии по уточнению бэклога, на которой мы только что присутствовали, мы работали напрямую с трейдерами и обсуждали требования вместе с ними. Тебе не кажется это излишним? На моем предыдущем месте работы у каждой команды был свой Владелец Продукта, который описывал пользовательские истории, задавал общие рамки, готовил спецификации и отдавал все это нам, после чего мы могли спокойно фокусироваться только на программировании. При этом у каждой команды был свой Бэклог Продукта и отдельный Владелец Продукта, отвечающий за его приоритизацию. Но здесь все по-другому. Почему вы делаете это иначе?

Сэм отвечает:

  • Интересный вопрос. Не возражаешь, если я задам тебе пару встречных вопросов, чтобы разобраться?

  • Конечно, продолжай.

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

  • По опыту моей предыдущей компании - будет тяжело, - отвечает Майк.

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

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

  • Ну, с точки зрения компании получается, что эти команды “эффективно” работают над низкоприоритетными задачами, и происходит это вследствие того, что фокус каждой из них ограничен собственным бэклогом и они не видят общей картины. Разреши задать тебе вопрос: является ли такой подход действительно гибким? И каким образом, с точки зрения компании, он направлен на то, чтобы делать только самые важные для бизнеса задачи?

  • Кажется, я начинаю понимать… - после небольшой паузы продолжает Майк. - То, что мы делали, на самом деле не было Agile, в то время как группа позиционировала это как Agile. Мы не были нацелены на самые важные для компании задачи, и Владелец Продукта в моей команде всегда говорила, что она выставляет приоритеты только в рамках нашего бэклога. Но сейчас я вижу, что моя команда эффективно работала над задачами, которые вообще-то могли быть далеко не самыми важными, если взглянуть на них с уровня выше. (ПРАВИЛО: Для всего поставляемого продукта есть только один Владелец Продукта и один Продуктовый Бэклог.)

Сэм отвечает:

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

  • Еще я заметил, - добавляет Майк, - что в моей предыдущей компании командам было гораздо сложнее работать вместе, так как у нас были не синхронизированные Спринты с разными целями. Здесь же я чувствую, что у всех команд есть общий фокус в рамках единого Спринта.

  • Так оно и есть! - отвечает Сэм, а затем продолжает. - И здесь напрашивается еще один вопрос: Если у нас есть только один Бэклог и один истинный Владелец Продукта, отвечающий за его приоритизацию, но при этом в каждой команде есть свой так называемый Владелец Продукта, который по определению не приоритезирует командный бэклог, так как его просто не существует, - так чем же он целыми днями занимается?

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

  • Майк, а до того как ты вообще узнал про Скрам и про термин ‘Владелец Продукта’ - как ты называл людей, находящихся между разработчиками и реальными клиентами - тех, что собирали требования и передавали их разработчикам?

  • Я пришел в компанию еще до того как мы начали внедрять Скрам, - отвечает Майк, - и в то время этим занималась группа бизнес-аналитиков. После внедрения Скрам нас попросили называть их Владельцами Продукта.

  • Сегодня на PBR сессии, - задает еще один вопрос Сэм, - разговаривал ли ты с трейдерами, которые были там?

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

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

(ПРАВИЛО: Владелец Продукта не должен работать один над Уточнением Продуктового Бэклога; он поддерживается множеством команд, которые работают непосредственно с заказчиками/пользователями и другими заинтересованными лицами.)

(ПРАВИЛО: Вся приоритизация происходит через Владельца продукта, но прояснение элементов бэклога должно проходить как можно более напрямую между командами и заказчиками/пользователями, а также другими заинтересованными лицами.)

Больше Разработки

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

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

(ПРАВИЛО: Есть только один Обзор Спринта и он общий для всех команд.)

Наконец, наступает последний день и время для общего Обзора Спринта. Кто в нем участвует? Паоло (Владелец Продукта и ведущий продукт-менеджер), все трейдеры компании, несколько тренеров, отвечающих за обучение по продукту, представители отдела клиентской поддержки, отдела Продаж, и еще четыре пользователя, представляющие внешних клиентов, для которых компания снижает годовые взносы в обмен на участие их сотрудников в подобных сессиях. Также присутствуют все представители команд.

Так как исследования и ревью ожидает большой объем новой функциональности, группа начинает с часовой “ярмарочной” сессии (bazaar): это что-то вроде “научного выставки”, когда в комнате расставляются устройства и гаджеты, каждый из которых предоставляет возможность изучить свой набор фич. Некоторые представители команд остаются у своих “стендов”, чтобы послушать и собрать отзывы, в то время как остальные, перемещаясь от одного к другому, пробуют и обсуждают новые фичи.

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

Командные Ретроспективы

(ПРАВИЛО: Каждая команда проводит свою Ретроспективу Спринта.)

После перерыва Команда Trade (как и все остальные) проводит свою командную Ретроспективу Спринта. Они соглашаются, что проведение совместной Сессии по Проектированию решения с Командой Margin, состоявшееся не до, а после Планирования Спринта, было далеко от идеального, поскольку критичные вопросы, обнаруженные в ходе нее в самый последний момент, могли серьезно усложнить или даже остановить разработку на какое-то время. Поэтому они решают, что, начиная со следующего Спринта, в ходе PBR сессий они будут стремиться заранее определить сложные с точки зрения проектирования задачи, которые имеет смысл обсудить с другими командами, и при необходимости проводить совместные сессии по Проработке Дизайна как можно раньше.

Конец

Спринт завершен! Сэм приглашает Команду Trade присоединиться к ним с Мирой в бельгийском пабе неподалеку, чтобы отметить ее день рождения. (ПРАВИЛО: Если пиво, то Belgian Tripel Karmeliet.)

Резюме

Несколько ключевых моментов в этой истории:

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

• LeSS История: Поток работ •

Эта история о том, как происходит работа над элементами бэклога в течении спринта, в основном в течение Уточнения Бэклога и разработки.

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

Позже Порша встретилась с Паоло. Она выписывает на карточках и обобщает новые правила, которые потенциально затронут их продукт, а также формирует список клиентов, которые по ее мнению, захотят получить данную функциональность в первую очередь. Паоло указывает на пять карточек и спрашивает:

  • Ну что, ты думаешь, вот эти покроют всю работу?
    Порша, улыбнувшись, отвечает:
  • Это ведь регуляторка. Она никогда не бывает полной и понятной.
  • Можешь поместить вот эти в Бэклог Продукта для меня, пока что внизу списка без приоритетов? - спрашивает Паоло.
  • Конечно.

Неделю спустя Паоло рассказывает Порше:

  • Мы скоро собираемся приступить к поставке части требований из большого набора регуляторных требований по долговым деривативам. Поэтому в следующем Спринте, в рамках сессий по Уточнению Бэклога, я планирую попросить часть команд сфокусироваться на этом. Ты лучше всех разбираешься в этой теме, поэтому, пожалуйста, поучаствуй в Общей сессии PBR, а также в командных сессиях, если потребуется. И еще - можно тебя попросить создать wiki-страницу со ссылками на новые нормативные документы, чтобы поделиться ими с командами?
  • Уже сделано, - отвечает Порша.

Общая сессия PBR

Паоло открывает Общую сессию PBR:

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

Группа берет одну очень большую задачу и делит на несколько крупных частей, чтобы понять ее основные составляющие. Дальнейшее разделение будет проведено в ходе одно- или многокомандных PBR-сессий. Порша подходит к доске и пишет в левой ее части “регуляторные требования по долговым деривативам”. Затем, в процессе обсуждения с группой они рисуют древовидную диаграмму с четырьмя ветвями, представляющими четыре основные подзадачи. На этом они останавливаются, избегая на данном этапе чересчур глубокого анализа.

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

Далее, Паоло спрашивает:

  • Ну что, Порша, из этих четырех больших задач - какая должна идти первой?

Она указывает на вторую карточку:

  • Внебиржевые экзотические деривативы.

Паоло говорит:

  • Нам нужно начать поставлять функционал по этой задаче как можно раньше. Поднимаем ее приоритет в Бэклоге Продукта, и я бы хотел, чтобы в следующем Спринте одна из команд “попробовала бы ее на зуб” (начала бы с ней разбираться). Кто хочет этим заняться?

Вызвалась команда Trade.

Затем, по итогам встречи, участники из трех других команд решают провести Многокомандную сессию PBR для обсуждения связанных задач.

Командный PBR: Пробуем истории на зуб

На следующий день Команда Trade проводит командную сессию PBR с Поршей. Им предстоит разобраться с одной крупной задачей из четырех: “Новые регуляторные требования по внебиржевым (over-the-counter, OTC) нестандартным долговым деривативам”. Сэм (их Скрам-мастер) также присутствует на встрече. Порша говорит:

  • Это действительно гигантская и комплексная задача, причем в той области, в которой, признаться, никто из нас достаточно хорошо не разбирается. Нам потребуется немало времени, чтобы ее разделить, понять и хорошо описать.

Сэм спрашивает:

  • Действительно ли нам нужно понимать ее целиком? И действительно ли этот анализ поможет нам разобраться, или в действительности только задержит наше изучение этой темы?

Он обсуждает с ними идею “Отломить кусок” (Take a Bite): выделить один небольшой фрагмент, действительно в нем разобраться, после чего быстро реализовать.

Сэм заключает:

  • Вы же знаете, диаграммы не могут сломаться и документы невозможно запустить.

Вместе с Поршей команда выделяет кусочек клиент-ориентированной сквозной функциональности.

С этого момента они концентрируются только на этом маленьком фрагменте, уточняя и реализуя его. Только после его реализации и получения обратной связи, намного позже, они вернутся к дальнейшему разделению и уточнению. Используя подход “спецификация через примеры”, Порша и Команда Trade проводят остаток дня, “пережевывая откушенный кусок”.

Многокомандная сессия PBR: Уточнение с ротацией

Одним из результатов Общей сессии PBR было решение о взятии в работу Командой Trade маленького фрагмента функциональности. Еще одним - решение трех команд провести совместную PBR-сессию по связанным задачам с целью усилить их обучение и гибкость в понимании и взглядах на одни и те же задачи.

Помимо всех участников всех трех команд, на встрече присутствуют внутренние трейдеры: Таня, Тед и Тревис, чтобы помочь командам разобраться с дюжиной новых требований. (ПРАВИЛО: Вся приоритизация происходит через Владельца Продукта, но прояснение элементов бэклога должно проходить максимально напрямую между командами и заказчиками/пользователями, а также другими заинтересованными лицами).

Для начала они формируют три временные смешанные группы, включающие участников из каждой команды. Разойдясь по углам комнаты, группы начинают проводить уточнения по разным задачам. У каждой из них есть маркерная доска, большое пространство на стене, ноутбук и проектор. Таня присоединяется к одной группе, Тед - ко второй, Тревис - к третьей.

Затем они делают уточнение с ротацией (rotation refinement): после 30 минут звенит таймер. Динь! Одна группа переходит в зону, которую только что занимала другая, и наоборот, но Таня, Тед и Тревис остаются на своих местах. Снова запускается таймер, и трейдеры разъясняют текущие результаты новой группе, и вместе они продолжают уточнение.

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

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

Владелец Продукта и обновление Бэклога Продукта

На следующий день после проведения PBR Порша вместе с несколькими участниками команд:

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

Затем в том же составе они встречаются с Паоло, чтобы просмотреть изменения в Бэклоге Продукта и ответить на его вопросы.

Конец

Некоторые ключевые моменты истории:

  • ‘Отломите Кусочек’ гигантской задачи, чтобы научиться на поставке чего-то небольшого и избежать преждевременного и чересчур глубокого анализа.
  • Проводите многокомандные сессии PBR для элементов бэклога, чтобы усилить распространение знаний между командами, что в свою очередь увеличивает организационную гибкость, общепродуктовые знания и усиливает самоорганизацию координации команд.
  • Стремитесь к фокусу всем продукте, даже при наличии большого количества команд.

Далее—Следующая секция переключает внимание на фреймворк LeSS Huge, использующийся для крупных групп и большого числа команд.

LeSS Huge Framework

• Области Требований •

With 1000 or even just 100 people on one product, divide-and-conquer seems unavoidable because of the complexity of so many requirements and people. Traditional large-scale development divides these ways:

  • single-function groups (analysis group, test group, …)
  • architectural-component groups (UI-layer group, server-side group, data-access component group, …)

This organizational design yields slow inflexible development with (1) high levels of waste (inventory, work-in-progress, handoff, information scatter, …), (2) long-delayed ROI, (3) complex planning and coordination, (4) more overhead management, and (5) weak feedback and learning. And it is organized inward around single-skills, architecture, and management, rather than outward around customer value.

But in the LeSS Huge framework when above about eight teams, division is around major areas of customer concerns called Requirement Areas. This reflects the customer-centric LeSS principle.

Size—A Requirement Area is big, usually with between four and eight teams, not one or two. The following Area Feature Teams section explains why.

Dynamic—Requirement Areas are dynamic. Over time an area will change in importance, and then it grows or shrinks with teams joining or departing—most likely to or from another existing area.

Example—For example, in a Securities product (to trade stocks), these could be some major areas of customer interest—Requirement Areas:

  • trade processing (from pricing to capture to settlement)
  • asset servicing (e.g. handling a stock split, dividends)
  • new market onboarding (e.g. Nigeria)

Conceptually in the one Product Backlog, a Requirement Area attribute is added, and each item is classified into one and only one area:

Item Requirement Area
B market onboarding
C trade processing
D asset servicing
F market onboarding
 

Then people can focus on one Area Product Backlog (conceptually, a view onto one Product Backlog), such as the market onboarding area:

Item Requirement Area
B market onboarding
F market onboarding

Common Sprint—Does each Requirement Area work separately in its own Sprint, with delayed integration until a far-future date? No.

In LeSS Huge, Integrate Continuously in One Common Sprint
There is one product-level Sprint, not a different Sprint for each Requirement Area. It ends in one integrated whole product, and all the teams across all the Requirement Areas are striving to integrate continuously across the entire product.

• Area Product Owners •

In LeSS Huge one new role is introduced. Each Requirement Area has an Area Product Owner who specializes in that area and focuses on its Area Product Backlog.

Large product groups usually have several supporting product managers specializing in different customer areas, and some of these are likely to serve as the Area Product Owners. Sometimes the Product Owner also serves double duty as an Area Product Owner for one area; that’s more likely in small less huge LeSS Huge groups!

• Area Feature Teams •

Area feature teams work within one Requirement Area (e.g. asset servicing), with one Area Product Owner focusing on the items in one Area Product Backlog. From a team’s perspective, working in the area is like working in the smaller LeSS framework—they interact with their Area Product Owner as though she were the Product Owner, and so on.

The team members come to know the customer domain of that area well. And fortunately, the items of one Requirement Area tend to cover a semi-predictable subset of the entire code base, thereby reducing the scope of what they have to learn well within a vast product.

Key point about size: Many feature teams work in a Requirement Area.

A Requirement Area normally has four to eight teams.
An implication is that a Requirement Area is big.

The Magic Number Four

First, why does a Requirement Area have a suggested upper limit of eight teams? See The Magic Number Eight.

What about the lower limit of four teams? Why not one or two teams? Naturally, four isn’t a magic number, but it strikes a balance so that the product group is not composed of many tiny Requirement Areas.

What’s the problem with many tiny areas? They reduce visibility into overall product-level priorities, increase local optimizations, increase coordination complexity, require more positions, and create teams that are too narrowly specialized and lack the flexibility (agility) to take on the emerging highest-value items from a company perspective. Furthermore, in a tiny area the Area Product Owner is increasingly likely to act as a business analyst between the users and one or two teams.

Are there any reasonable exceptions to the lower limit of four? Yes:

  • An early transitional situation when the group is incrementally growing a new area that is fully expected to ultimately have four or more teams. Then, start small and simple with one team.
  • When re-balancing teams from an area with a decreasing demand to one with an increasing demand causes an area to go from four to three teams. Ultimately, merge two reduced small areas back into a new larger area.

Example Requirement Areas and Teams

In summary, a Securities product could have

  • one Product Owner and three Area Product Owners, all together forming the Product Owner Team
  • six feature teams in the trade processing area
  • four feature teams in the market onboarding area
  • four feature teams in the asset servicing area

• LeSS Huge Framework Summary •

Each Requirement Area works as a (smaller framework) LeSS implementation, each working in parallel in one overall Sprint. We sometimes summarize a Sprint in LeSS Huge as a stack of LeSS.

From the viewpoint of a team in one area,
LeSS Huge looks like (smaller) LeSS regarding events.

As with LeSS, there are rules and optional guides for LeSS Huge; those are introduced in the following stories and fleshed out in later chapters.

Roles—Same as LeSS, plus two or more Area Product Owners, and four to eight Teams in each Requirement Area. The one Product Owner (who focuses on overall product optimization) and the several Area Product Owners form the Product Owner Team.

Artifacts—Same as LeSS, plus a Requirement Area attribute in the one Product Backlog and thus an Area Product Backlog view for each area.

Events—There is still only one common Sprint for the product; it includes all the teams and ends in a common potentially shippable product increment.

• LeSS Huge Stories •

Learning LeSS Huge—Readers who prefer exposition can comfortably skip ahead to following chapters, bypassing these stories.

Simple stories—These are intentionally plain and simple stories just to introduce basics in LeSS Huge.

Two topics—Following are two stories with distinct topics:

  1. Creating and growing a new Requirement Area to deal with a new gigantic requirement.
  2. Working with multi-site teams. (This happens in the smaller LeSS framework too, but is especially common in LeSS Huge.)

• LeSS Huge Story: A New Requirement Area •

Priti welcomes Portia to her first day in her new job. As a mid-level Operations manager in the Securities division of the large trading company as well as Product Owner for their internal Securities system, Priti is also responsible for finding and retaining talent for her Product Owner Team of Area Product Owners. And she thinks Portia is a fantastic find, as her expertise is exactly what is required for dealing with some new huge requirements.

During the recent job interview—when Portia was still a product manager specializing in regulatory issues at a company that made a system for trading bonds—Priti had laid out the situation. “Portia, after the last crash, the regulators are coming down hard and they require us to be compliant with Dodd-Frank. Right now, we don’t know what it exactly means or how it will impact our system. You’ve got incredible knowledge of this space, and a great professional network with the regulators. I would love it if you would join our group and help us figure out how to deal with this.”

A Big Surprise

A few days later… Priti welcomes Portia, Peter, and Susan into her office. Peter is Area Product Owner for market onboarding, and Susan is a Scrum Master from the trade processing area.

Priti says, “As you know, Dodd-Frank is coming, and it’s huge. What you don’t know is that this morning the regulators called us and they want us to take action now. I’d been working under the assumption we could start next year. So we’re going to have to adapt, big time.

“I don’t think anyone is clear what it means in detail—even the regulators. And we don’t know how it will impact our system and how much work this is going to take, other than, a lot! But now Portia’s joined us and she has a better understanding of this than anyone, although she’s totally new to our systems. So, how can we help her start tackling this mountain of work?”

Susan asks, “You guys understand the Dyslexic Zombies, right?”

Peter and Priti nod. Everyone knows about them—and it isn’t just their name. The Dyslexic Zombies have probably the broadest experience of all the teams. They’ve been around for years and they were a true pain in the ass when they adopted LeSS. The team contained two former members of their now-abandoned architecture group and a couple of people who had been working on the system for over fifteen years. Those people’s resistance to the LeSS adoption was legendary as they were afraid they’d lose their “system perspective.” To their surprise, the opposite happened! Because of their deep knowledge they continuously get tough items to develop. And they regularly participate as expert-teachers in current-architecture-learning workshops with newcomers, and Mario—one of the former PowerPoint architects—is now coordinator for the architecture community. When fed enough beer, he’ll admit that working closer with code and tests has increased his real understanding of the system.

zombies.png

Susan continues, “If any team can quickly help Portia get a better understanding of the size and impact of Dodd-Frank, it’ll be the Zombies. And they led the work on Sarbanes-Oxley a few years ago. Tomorrow is their PBR session. They are just about wrapped up on a new feature. Why don’t we re-direct the meeting to include them in a discussion on Dodd-Frank, and soon after, ask them to focus full-time on it?”

Refining with Zombies

Next day at the refinement meeting with the Zombies, Portia explains the situation, “You’ve probably all heard about the Dodd-Frank legislation. But here’s the surprise: We’ve just been told by the regulators that they want us to take action ‘now’ and demonstrate significant compliance by the end of the year. Otherwise they might restrict our trading.”

The Zombies are visibly surprised. They had heard rumors but didn’t expect such a rush!

Mario says, “OK Portia, give us a quick summary of what this means. And how is it different from Sarbanes-Oxley?”

Portia picks up a pen and starts sketching on a whiteboard. After about 45 minutes, she is finished with the overview and the Zombies looked a little stunned.

“End of the year, they said?” says Mario. “If the whole group started today, it wouldn’t get finished. This is huge!”

He takes a pen and at the whiteboard starts a rough sketch of their system, talking with the other Zombies about the impact it might have.

He says, “Portia, let’s also use this as a chance to help you understand the system better. Ask away.”

Portia says, “Can you hold on for a second? Let me start a video recording to help me remember this.”

Michelle, a veteran in the team, says, “We’d better start on some real development soon and learn more as we go because otherwise we’ll end up analyzing forever. I’ve seen this story before.”

Susan, their Scrum Master, says, “Reminds me… Tom DeMarco once said that the reason for every failed project is that it started too late.” Everyone laughs. She continues, “So here’s a suggestion: take a bite.”

Creating a New Requirement Area

The next day, Portia, Priti, and rest of the Product Owner Team meet. Portia shares a summary of the scope as she understands it now.

Priti says, “This is even bigger than I expected, and we need to show some tangible progress to the regulators within a few months, and major progress before fiscal year end—seven months from now. To state the obvious, they’re now authorized to require more from us, and with the power to shut us down. As you know, just last month the CEO made it crystal clear that new regulatory requests take priority over any other concern. It’s my experience that our goodwill and flexibility with the regulators goes up if we can give them something early, and be transparent and responsive. So that’s what we’re going to do.”

Priti continues, “It seems to me that we’ll need a new area for this big surprise. And of course that’s probably going to impact some of our existing high-priority goals, since we’ll have to shift some teams. Let’s prepare for a deeper discussion of overall prioritization impact in a couple of days. But for now, I’d like your input about spinning up a new area.”

After a short discussion, it’s clear that everyone recognizes the importance of creating a new area.

Priti then says, “Portia, I know you are new to us, but do you think you would be able to handle the Area Product Owner responsibility for this?”

Portia nods.

Priti continues, “Peter, do you think the Zombies could start work on this? And we’ll need them to learn more Dodd-Frank and figure out the impact on our system before we can add more teams to this.”

Peter says, “I don’t think we’ve got any choice.”

Priti says, “OK Portia, so currently we’ve got a few items in Peter’s Area Backlog, the one huge item I think you called “remainder of Dodd-Frank” and the tiny item which the Zombies and you split off of it. Please ask Peter to show you how to set up a new area in the Product Backlog and move the items over to it.”

Priti continues addressing the group, “The next Sprint starts in three days. Let’s move the Zombies into your area and get started on this monster. Probably in a couple of Sprints we’ll be ready to—and need to—grow your area by moving in another team. Folks, please think about two major concerns: First, preparing for a serious prioritization impact meeting in a few days. And second, what other teams will be good candidates for the new area.”

Sprint Planning in the New Requirement Area

Each Requirement Area holds its own Sprint Planning meetings, all more or less in parallel. In Portia’s new area, she starts her Sprint Planning by introducing two unfamiliar faces to the Zombies.

She says, “Gillian and Zak have been in contact with the regulators regularly and will help us flesh this thing out. They’ve agreed to help us now in Planning, during our PBR sessions, and as much as they can spare daily during upcoming Sprints.”

She continues, “Here’s my tentative plan of attack for the next two Sprints. First, together we need to learn more about Dodd-Frank, and also split it into some major and manageable pieces so we can start to clear the fog and get a better sense of priorities.

“Second, we implement the smaller bite we’ve taken, starting this Sprint. That’ll give us better information about the real work and the impact on our product. And we’ll have some concrete visible progress.

“Third, we prepare for more teams to join our area. What do you think of this approach? Other suggestions?”

During the short discussion, Mario says to his team, “Let me give a bit more context, because I represented our team in the recent Product Owner Team meeting with all the Area Product Owners and Priti. To start with, it’s just us to start. We’re going to take the lead on early implementation, and getting the big picture of the item, and understanding the overall impact on our architecture.”

Michelle interrupts, “Like a tiger team working on a new product?”

“Yes, like that,” says Mario. “Think of Dodd-Frank support as a new product that needs to be continuously integrated into the rest of the product. But we’re in a hurry and it’s a ton of work, so in a few Sprints one more team will join us and shortly after, probably two more teams. We keep developing too, but we’ll be the leading team, which means we’ll need to bring the other teams up to speed and make sure we keep the overall product in mind.”

Michelle says, “It’s starting to sound to me like we’re going to become the architecture and project management team!”

Mario laughs, “No. I’m done with that. We’re still a normal feature team, but besides development we’ll focus on mentoring and bringing the new teams up to speed as fast as possible. But let’s be clear: team coordination and management is still the responsibility of each team.”

The First Sprint in the New Requirement Area

Their first Sprint is an unusual balance of clarification versus development, but nevertheless quite useful in this extreme situation. They spend almost half the Sprint in clarification with Portia, Gillian, and Zak. That’s because even for this extremely small bite, trying to understand what is wanted in the obscure realm of new government regulations—with no direct access to the politicians and policy writers—required a lot of investigation, reading, discussion, and communicating with outsiders. They expect that in future Sprints, the amount of time needed for clarification will soon drop down to a more common 10% or 15% of their Sprint.

And so they also only spend about half the Sprint developing one small item. But the discussion and the learning from coding pays off. Slowly but surely they start to split Dodd-Frank apart—at least the parts that any of them can understand.

While implementing the small item they had bitten off first, they spend much of the time together at whiteboards to discuss the overall design implications on the system. The team moves frequently back and forth between the code and the wall.

Sprint Review in the New Requirement Area

The overall Securities product group works together in one Sprint, with one final shippable product increment. But each Requirement Area holds its own Sprint Review, all more or less in parallel.

In Portia’s area, during their Review, she, Gillian, and Zak explore the one “done” item that the Zombies have managed to complete and integrate into the overall product. They had originally forecast two items, but Portia is impressed that they got even one done, given how fast this new work was thrown at them.

The Second Sprint

In the second Sprint they’re able to make slightly better progress on items, though they once again spend a lot of time clarifying together with Portia, Gillian, and Zak.

In the middle of the Sprint they hold a multi-team PBR session with the second team that is planned to soon join the area, teaching them about Dodd-Frank. They hold a current-architecture learning workshop to introduce the team to the major design elements already in place.

The Zombies know how big the work is and look forward to more help.

Product Owner Team Meeting

A few Sprints later… It’s time once more for the per-Sprint Product Owner Team meeting. They use it to align and coordinate between the different Area Product Owners, and for Priti to give guidance.

The Area Product Owners each share in turn their situation and upcoming goals. When it’s her turn, Portia says, “To none of our surprise, the progress is little and the surprises are big. But the fog is clearing and the teams and I are getting our heads around the work. Gillian and Zak have been tremendous help.”

Pablo, the Area Product Owner of asset servicing, comments on some close item relationships he now sees between their areas. Portia agrees to meet with Pablo and some team representatives later.

Priti asks, “Portia, about our upcoming Sprint. What are your goals?”

Adding a Third Team

Two Sprints later… At the Product Owner Team coordination meeting, Priti says, “As you know, Portia’s area still has only two teams. I know that Pablo would like to keep his six teams in asset servicing, but Dodd-Frank is just too important to me this year. So we’re going to move one team from Pablo’s area into Portia’s. Pablo, please ask for a volunteer team from your group and let me and Portia know.”

The End

Some key points from the story in LeSS Huge:

  • The Product Owner is responsible for finding Area Product Owners and developing their talents.
  • The Product Owner is responsible for deciding to start, grow, or wind down Requirement Areas.
  • Requirement Areas are large, normally requiring four to eight teams, but during initial startup they may be smaller, especially if initiated with one team using a Take a Bite approach.
  • A Leading Team works solo to tackle a gigantic item until they understand the domain and development, and then they coach more incoming teams to help with the vast work.

• Multi-Site Teams: Terms & Tips •

Next is a LeSS Huge story involving multi-site teams. But first, some clarifying definitions, because the common term distributed teams confusingly means several things. The clarifying terms are as follows:

  • dispersed team—One team of (e.g. seven) people spread out in different locations; either different rooms, buildings, or cities
  • co-located team—One team working literally at the same table
  • multi-site teams—One co-located team working at one site, and another co-located team working at another site

Second, an observation and guidance:

  • A dispersed team is rarely a real team; it is much more likely a loosely connected groups of individuals. The communication and coordination frictions are higher, and they seldom jell as a team.
  • When your product group is 50 or 500 people, dispersed teams aren’t necessary. Each team of seven-ish people can easily be co-located. However, some teams may be in different sites, so that the product group has multi-site teams. Dispersed teams are usually the result of bad organizational decisions and ignorance about the cost of not having co-located teams. (Rule: Each team is (1) self-managing, (2) cross-functional, (3) co-located, and (4) long-lived.)

• LeSS Huge Story: Multi-Site Teams •

Portia is the Area Product Owner for a new Requirement Area in a Securities trading system. The new area started with just one team for focus and simplicity. A few Sprints later Portia’s area adds a third team. Her first two teams are based in London with her. But her third new team, HouseDraculesti, is based in Cluj Romania at a major development site for the company.

Why not add a third team from the London site? That would have avoided the many aggravations and efficiency penalties that can come from multi-site development within one area—costs potentially so high that adding a team can effectively result in deleting a team.

But on the positive side in this case, Cluj is only two time zones from London, and everyone there speaks English well. And they are all strong developers with Computer Science degrees, in a city that values long-term and hands-on engineering mastery. Also, this is a dedicated internal development site for the company, so these are experienced internal teams that have in-depth knowledge of the product and domain.

And bottom line, Priti (the Product Owner) didn’t want any of the other London teams to shift from their current areas.

Priti knows that multi-site teams are a new situation for Portia, and so at their next meeting, she says, “Please ask your Scrum Master to talk with Sita, and also ask Sita to coach some of your events. She’s a Scrum Master in asset servicing, and she’s observed their multi-site situation for a few years. She knows the importance of Scrum Masters co-located with their teams, and she’s helped facilitate many multi-site meetings.”

Priti continued, “Also, we’ve had a super profitable year, so I’m providing funding for you and the Zombies team—at least those that can travel—to spend a Sprint in Cluj as soon as possible. Work closely with them, all in one room. The Cluj team could come here to London, but you want to send a strong signal that they are important, at their site. Try to avoid making them feel that London is more important than Cluj. Oh—and you’ll want to regularly visit every few months.”

Multi-Site Sprint Planning Part One

A few Sprints later, Portia walks into the room. There’s a computer projector attached to a laptop, displaying via video a room in Cluj. The whole team in Cluj are sitting and waiting. Sita suggested it would improve learning and engagement if the entire Cluj team participated in multi-site meetings for the first few months of their addition to the area.

All the team representatives have tablets or laptops with them.

Portia begins. “Welcome and let’s get started. My offer of items this Sprint are highlighted in the shared spreadsheet. Can you all see it? I think you all understand why these are the themes and priorities, since we’ve been discussing this in PBR and it reflects your input and mine. But please ask again if you’d like clarification. Other than that, you’re invited to enter your team names beside the items you want.”

That done, the group enters a Q&A phase to wrap up lingering questions about the items. The London representatives tape up some flip-chart papers and start writing questions. The Cluj team members enter their questions in separate sheets of a shared spreadsheet. Portia spends some time at the different paper flip charts, discussing answers and sketching on the paper. And she spends some time at the spreadsheet, typing in answers for the Cluj team, while also talking with them face-to-face via the video session.

After about 30 minutes the separate questions have been resolved, and Portia asks everyone to come back together. She says, “Any issues or questions that you want to discuss together, before we wrap up?”

Multi-Site Overall PBR

People enter the workshop room in London for multi-site PBR. Two projectors are set up. One shows a video session of the workshop room in Cluj. The other displays a browser on Portia’s computer.

Portia says, “Let’s get started. I want to focus on splitting some items. I’ve invited Zak to join us because he knows quite a lot about this.”

Using a mind-mapping, browser-based graphics tool, Zak starts to create some branches, while discussing with the group.

Afterwards, they use a shared spreadsheet to discuss and write a single example for each of the new split items, so that the people at both sites gain a lightweight but concrete understanding of the details. Later, the group does estimation of the new items, using especially big planning poker cards that can be easily seen by the cameras and video when held up.

The End

Some key points from the multi-site story in LeSS Huge:

  • Multi-site teams frequently create both obvious and subtle frictions and costs that are surprisingly large in their negative impact.
  • Qualities that reduce the friction of another site include similar time zone, internal dedicated site (not outsourced), developers that are fluent in the same spoken language, a location and culture that highly values long-term hands-on developer excellence.
  • A Scrum Master must be co-located with their teams.
  • Each site must feel like a peer, not a second-class citizen.
  • Sites must be visited regularly and cross-pollinated.
  • In meetings, strive for face-to-face with video tools.
  • The use of shared-document tools make it easy for everyone to modify artifacts together and at the same time.

Onwards

Rather than asking, “How can we do agile at scale in our complex and awkward organization?”, ask a different and deeper question, “How can we simplify the organization, and be agile rather than do agile?” And since truly scaling Scrum starts with changing the organization rather than changing Scrum, the next major section focuses on understanding and adopting a simpler customer-focused LeSS organization.

This is followed by major sections on a more customer-focused product and Sprint in a simpler LeSS organization.