Опубликовано

Руководство по Scrum 2020

В этой короткой статье я перечисляю основные изменения в новой версии Руководство по Скраму 2020. Если у вас нет времени, чтобы тщательно изучить руководство, эта статья для вас. Руководство доступно с 18 ноября в английской и русской версиях. 

Цель изменений

Авторы Скрама утверждают, что главный мотив изменений — сделать Скрам менее предписывающим, более бережливым (lean) и более гармонично вписывающимся в разные контексты, особенно за пределами разработки программного обеспечения (ПО). И, знаете, Руководство значительно похудело. Теперь оно насчитывает лишь 13 страниц.

Перечень основных изменений

  • Одна Скрам-команда, сфокусированная на одном продукте. Концепция отдельной команды внутри команды (Development Team), которая привела к поведению взаимоотношений «прокси» и «мы/они» между Product Owner и командой разработчиков, устранена. Теперь есть только Скрам-команда, сфокусированная на общей цели, с тремя разными зонами ответственности: Product Owner, Scrum Master и Developers. То-есть, теперь мы говорим не о ролях, а зонах ответственности (accountabilities) внутри одной системы. Как следствие, Скрам-команда коллаборативно отвечает за достижение Цели Спринта, за соблюдение определения готовности (Definition of Done) и т.д.
  • Добавление Product Goal. Добавлена концепция Product Goal, которая фокусирует Скрам-команду на достижение более широкой цели. Каждый Спринт должен приближать продукт к итоговой Product Goal. Чем может быть эта Product Goal? В зависимости от контекста, это может быть миссия, видение продукта или же тактическая квартальная цель. Руководство специально использует нейтральный термин, чтобы дать вам возможность наилучшим образом определиться в вашем контексте.
  • Место для Sprint Goal, определения готовности (DoD) и Product Goal. Предыдущие Руководства по Скраму описывали Sprint Goal и определение готовности (DoD), но они не были официальными артефактами и относились к правилам Скрама. Теперь каждый из трех артефактов содержит «приверженность». Для Product Backlog есть Product Goal, для Sprint Backlog есть Sprint Goal, для Increment есть определение готовности (DoD) (теперь без кавычек). Они существуют, чтобы обеспечить прозрачность и сфокусировать на прогрессе по каждому артефакту. 
  • Самоуправление вместо самоорганизации. В предыдущей версии команды назывались самоорганизующимися. Команда сама решала, кто и как будет выполнять работу. Версия 2020 года фокусируется на Скрам-команде, и подчеркивает важность самоуправления. Благодаря тому, что представитель бизнеса (Владелец Продукта) является частью системы, Скрам-команда может определять не только кто и как организовывает работу, но и направление движения.
  • Три вопроса события Sprint Planning. В версии 2017 были описаны два вопроса Sprint Planning: «Что» и «Как». В Руководстве по Scrum 2020 года особое внимание уделяется третьему вопросу — «Почему» — относящемуся к Sprint Goal. 
  • Исчезли вопросы из Ежедневного Скрама. Описание Ежедневного Скрама значительно сократилось. Ушли рекомендуемые вопросы: кто, что делал и т.д. Теперь разработчики сами решают как наилучшим образом инспектировать прогресс к Цели Спринта.
  • Один Владелец Продукта/Бэклог Продукта в независимости от количества команд. Если раньше и могли бы различные трактовки того, как правильно масштабироваться и сколько может быть Владельцев Продуктов и Бэклогов Продуктов, то теперь спор завершен. Руководство 2020 года явным образом говорит о том, что в случае, когда много Скрам-команда разрабатывают один продукт, то у них один и тот же Владелец Продукта/Бэклог Продукта.
  • Скрам основан на lean. В предыдущих руководствах утверждалось, что Скрам основан на принципах эмпиризма. Теперь к ним добавлены принципы бережливого мышления (lean). Лично я очень рад этому, потому что всегда утверждал, что Скрам основан на идеях Toyota Production System (TPS).
  • Отсутствуют обязательные атрибуты у элементов Бэклога Продукта (PBI). Версия 2017 требовала от нас четыре атрибута у каждого PBI: description, order, estimation, value. Теперь они могут отличаться в зависимости от уникального контекста, в котором разрабатывается продукт.
  • Исчезло ограничение в 10% на Product Backlog Refinement (PBR). Уточнение Бэклога продукта остается ongoing activity и упоминается несколько раз в тексте, но ограничение по времени отсутствует, потому что может отличаться в различных контекстах.
  • Исчезли кавычки с “Ready”. Элементы Бэклога Продукта (PBI) называются готовыми к выбору в Спринт, если они могут выполнены за Спринт. При этом слово ready осталось, но кавычки растворились.

Надеюсь, эта статья была полезной для вас. Все же, рекомендую ознакомиться лично с Руководством по Скраму 2020 лично. Удачного вам использования Скрама в ближайшие годы!

Scrum ON!

Опубликовано

Унаследованный код

Сегодня я размещаю перевод статьи, над которым мы работали вместе с Артемом Кротовым по очень важной теме в разработке программного обеспечения — теме унаследованного (legacy) кода. Это глава из «белой» книги Крейга Лармана и Баса Водди Practices for Scaling Lean & Agile Development, перевод размещён с разрешения авторов.

Текст который вы найдете ниже в посте написан 10 лет назад, и на мой взгляд, со временем актуальность материала только увеличивается.

Читать далее «Унаследованный код»
Опубликовано

From MeSS to LeSS | Игра с карточками паттернов внедрения LeSS

Оригинальная статья доступна по ссылке.

Это описание воркшопа, который я провел на конференции LeSS в Амстердаме.

Можете использовать этот воркшоп для всестороннего обсуждения своей новой группы LeSS или для внесения изменений в процесс внедрения LeSS. Во время стандартного воркшопа можете использовать начальную ситуацию, о которой я писал в своих статьях о копипаст-мастшабировании здесь и здесь. Теперь я называю такую ситуацию MeSS (от англ. mess — «беспорядок»), поэтому ваша задача — перейти от беспорядка к LeSS (From MeSS to LeSS). В контексте своей организации начните с оценки текущей ситуации.

Читать далее «From MeSS to LeSS | Игра с карточками паттернов внедрения LeSS»
Опубликовано

Хватит обвинять фреймворки, улучшайте внедрения

Оригинальная концепция Скрама — потенциально готовый к релизу инкремент каждый Спринт — звучит хорошо. Кто же откажется от высокоэффективных Скрам-команд, способных быстро поставлять ценность на рынок? Другое дело, что обычно затем я слышу: “Скрам не работает в моей организации, потому что…” и следует список оправдания, почему изменения невозможны.

Существует множество других Аджайл-подходов: Extreme Programming (XP), Scrum, Nexus, Kanban, LeSS, Crystal Clear, Lean Startup, Management 3.0. В своей коучинговой практике я отдаю предпочтение фреймворкам Скрам и LeSS, но больше всего ценю ценности и принципы, стоящие за ними. Со-создатель Скрама Кен Швабер считает о том, что Скрам может быть заменен лучшим подходом, если тот будет основан на четырех принципах: самоорганизации, эмпиризме, коллективном интеллекте и прозрачности. 

Пора сделать важное заявление:

Перестаньте обвинять фреймворки, начните улучшать внедрения.

Наблюдаю, что организации переполнены поверхностными Agile / Lean инициативами. Наверняка и вы сами сталкивались со ScrumButs, FlaccidScrum, Copy Paste Scrum, фейковым Канбаном. Люди склонны обвинять инструменты и фреймворки / методы, но, по моим наблюдениям, это проблема реализации. Есть исследование, подтверждающие это мнение.

Неспособность большинства организаций в полной мере воспользоваться преимуществами инноваций имеет мало общего с конкретным инструментом совершенствования, который они выбирают. Вместо этого проблема заключается в том, как внедрение новой программы совершенствования взаимодействует с физическими, экономическими, социальными и психологическими структурами, в которых происходит ее реализация. Другими словами, это не просто инструментальная проблема, это системная проблема, которая создается взаимодействием инструментов, оборудования, сотрудников и менеджеров. (Nobody Ever Gets Credit for Fixing Problems that Never Happened, Nelson P. Repenning, John D. Sterman)

Читать далее «Хватит обвинять фреймворки, улучшайте внедрения»
Опубликовано

Conway’s Law**

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

Читать далее «Conway’s Law**»
Опубликовано

Области Ценностей

Trinity Cathedral/Charlie Comella Community Garden uses different garden beds to divide their work. Each bed grows one or more types of plant that are combined to produce the meals for the community.

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

✥      ✥      ✥

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

Читать далее «Области Ценностей»
Опубликовано

Как помочь команде решить любую проблему

В предыдущей статье мы рассмотрели полезную эвристику системного мышления, известную под аббревиатурой POSIWID: «Purpose Of the System Is What It Does». Беер считал POSIWID лучшей отправной точкой для понимания любой системы. Мы должны сосредоточиться на фактических результатах, а не на желаемых. Почему? Системы показывают в точности те результаты, которые определены ее целью оптимизации и поддерживающей цель структурой. POSIWID прекрасно работает для любой социальной системы: команды, продуктовой группы, организации и т.д. Давайте посмотрим на ее применение в командном контексте.

POSIWID на командном уровне

Чтобы взять на вооружение POSIWID («Purpose Of the System Is What It Does»), нужно ответить последовательно на несколько вопросов: 

  1. Какая заявляемая цель системы?  
  2. Как ведет себя система?  
  3. Что говорит поведение системы о цели системы?
  4. Есть ли соответствие между заявленной и фактической целью?  
  5. Если это не так, как выглядит структура системы?  
  6. Как мы можем изменить структуру системы, чтобы получить новое поведение?

Проиллюстрируем алгоритм на примере команды, с которой мы работали некоторое время назад. 

Читать далее «Как помочь команде решить любую проблему»
Опубликовано

Pop the Happy Bubble

…Скрам-команда преодолела некоторые препятствия и работает более эффективно, чем раньше.

✥      ✥      ✥

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

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

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

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

Некоторые команды могут не видеть пути улучшения, потому что все препятствия, которые у них есть, находятся «вне команды». Когда команда не достигает Цели Спринта, она всегда приписывает это разовым, исключительным событиям.  И всегда есть какое-то одноразовое событие. Они чувствуют, что если бы только некоторые «они» могли что-то с этим сделать, команда бы улучшилась.

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

Команда может жить в “Пузыре Счастья”. Одна из самых больших проблем состоит в том, что пузыри прозрачны – команде очень трудно его увидеть. Почти всегда требуется взгляд со стороны, чтобы осознать такое поведение. Команде нужно получить обратную связь от нейтральных наблюдателей. Это то, что команды, возможно, не хотят замечать. Наблюдатели должны иметь смелость быть честными с участниками команды и чтобы справиться с неприятием результатов их обратной связи.

С другой стороны, все команды могут улучшаться. Они просто не видят этого.

Поэтому:

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

Читать далее «Pop the Happy Bubble»
Опубликовано

Почему Аджайл-трансформация буксует

Знаете ли вы компании, которые используют Аджайл-практики и внедрили Скрам, но так и не получили ощутимых результатов после нескольких лет трансформации? Чаще всего дело в том, что цели оптимизации адаптивность и скорость противоречат организационному дизайну компании, который поддерживает другие цели. В этой статье мы научимся находить несоответствия между целями оптимизации и текущей структурой. 

POSIWID (“Purpose Of The System Is What It Does”)

Специалист по системам и управлению Стаффорд Беер разработал важную и популярную эвристику системного мышления, известную под аббревиатурой POSIWID: «Purpose Of the System Is What It Does». Другими словами, цель оптимизации определяет результаты системы. Беер считал POSIWID лучшей отправной точкой для понимания любой системы. Мы должны сосредоточиться на фактических результатах, а не на желаемых. Почему? Системы показывают в точности те результаты, которые определены ее целью оптимизации и поддерживающей цель структурой. 

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

Давайте приведем примеры, где ЗАЯВЛЯЕМАЯ и ФАКТИЧЕСКИЕ цели систем не совпадают.

СистемаНаблюдаемая проблемаЗаявляемая цельЦель, сформированная с помощью POSIWID
ШколаМного не вовлеченных детейВоспитание полноценных и самостоятельных людейШкола хорошо достигает цели в том, чтобы сделать обучение для детей как можно более скучным
Программное обеспечение XYZБольшой отток клиентовПомощь малому бизнесуПродукт прекрасно достигает цели в том, чтобы заинтересовывать клиента, а затем сделать все возможное, чтобы он ушел.
ПарламентКоррупция, слияние власти с крупным бизнесомПредставлять интересы граждан и защищать их интересыПарламент замечательно выполняет цель, которая заключается в обогащении и лоббировании интересов крупного бизнеса.

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

Каждая система идеально разработана для достижения результатов, которые она получает. (Дон Бервик)

Хороший пример, когда поставленная цель не работает — Copy-Paste масштабирование. Это самый распространенный способ использования Скрама в больших организациях по всему миру. 

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

Такая структура порождает зависимости и длинные релизные циклы. Кроме того, команды работают не над самой важной функциональностью из-за наличия многочисленных Бэклогов Продукта. Copy-Paste масштабирование имеет мало общего с заявленными оптимизационными целями. Чаще всего фактические цели оптимизации: сохранение статуса-кво и структур власти, индивидуальная эффективность, создание видимости изменений для того, чтобы отрапортовать руководству о том, что “трансформация завершена”. Поэтому фактическая цель, определенная с помощью POSIWID, может звучать так: 

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

Итак, можно до посинения доказывать, что целью системы является [XYZ], но если это не подтверждается результатами и поведением системы, то это ЗАЯВЛЕННАЯ цель, а не ФАКТИЧЕСКАЯ. Давайте дальше разбираться в том, как привести к соответствию цели оптимизации и организационный дизайн.

Читать далее «Почему Аджайл-трансформация буксует»
Опубликовано

Определение продукта в LeSS. Часть 2.

Перевод оригинальной статьи Сезарио Рамоса.

Этот блог-пост  – глава-прототип моей готовящейся к выходу книги Coaching Agile Organizations.

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

Некоторые элементы равнее, чем другие.

Ниже представлен упрощенный вид организационных элементов одного из моих клиентов.

Мы обнаружили, что некоторые организационные элементы требуются чаще, чем другие для разработки функциональности. Чем чаще требуется конкретный элемент, тем сильнее зависимость. Мы визуализировали силу зависимостей с помощью тепловой карты (heat map) – см. рисунок анонимного упрощенного примера ниже.

По шкале y находятся элементы функциональности. По шкале x – организационные элементы. Зеленый цвет показывает, какой элемент нужен, чтобы доставить этот элемент.

Элементы, которые “нагреваются” больше всего, указывают на силу зависимости – это горячие точки. Обратите внимание, что элемент WEB необходим в 28% времени для разработки функциональности продукта, APP– в 20% времени, в то время как для LEGAL требуется всего 7%.

ПРИМЕЧАНИЕ. Старайтесь не уделять слишком много внимания процентам, это не точная наука, а скорее руководство, которое поможет вам двигаться вперед. Помимо процентов, я также успешно использовал различные шкалы для оценки силы зависимостей, таких как: Редко, Сейчас и Затем, Частота.

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

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

Найдите баланс между адаптивностью и скоростью

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

Следовательно, размер области тепловой карты, которую охватывает команда, сильно определяет ее

  • скорость поставки фич
  • гибкость в выборе работы из Бэклога Продукта.

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

  • Когнитивные способности команд. Когда команды специализируются на клиентском домене, они могут по-прежнему работать с клиентскими фичами (end-2-end), не разбираясь в других клиентских доменах продукта.
  • Тип зависимостей между элементами. Это помогает командам определить какой организационный элемент охватить в первую очередь, а какой потом. 

Специализируйтесь на домене клиента

Наш продукт был большой системой страхования. Мы использовали интервью и анкеты, чтобы определить, где пользователи проводят большую часть своего времени при использовании продукта.  Оказалось, что было несколько основных групп пользователей (для этого блога я просто использую 2 группы «Заявки и оценка» и называю их красным и желтым). Некоторые пользователи в основном использовали фичи красного цвета – красную область, в то время как другая группа в основном использовала фичи желтого цвета – желтую область. Оранжевые фичи используются обеими группами пользователей: они перекрывают или пересекают как красные, так и желтые области.

Красные и желтые области позволяют командам специализироваться на домене клиента — см. Области требований в LeSS (less.works) и паттерн Области Ценностей. Это снижает когнитивную нагрузку на команды.

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

Тип зависимостей между элементами

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

  • Правило 1  Pooled Dependencies – содержание взаимных зависимостей внутри одной Области Ценности: Работа одной команды является входом для другой команды, и наоборот, и существует неопределенность в том, как выполнить задачу, что делает необходимым частое выравнивание. 
  • Правило 2 Sequential Dependencies – обеспечение последовательных зависимостей между Областями Ценностей с помощью итеративного планирования: команда зависит от работы, которая должна быть  выполнена другой командой. Применимо для работы с низкой неопределенностью и предсказуемой работой.
  • Правило  3 Reciprocal dependencies –  управление зависимостями между командами и Областями Ценностей с помощью простых правил координации: например, совместное использование единой тестовой среды или зависимость от человека с дефицитным навыком.

Ниже вы можете увидеть пример результата для красной Области Ценностей.

WEB, APP, SIEBEL, PORTAL компоненты часто используются вместе и их взаимозависимости двусторонние. Команды в красной области Команды красной области решили, что им нужно будет охватить хотя бы эти элементы.

Кроме того, вы можете увидеть, что область имеет объединенную взаимозависимость с LEGAL и что это относительно сильная зависимость. Самая слабая взаимозависимость – 14% с SALES FORCE. Мы решили не включать SALES FORCE изначально, а добавлять его только тогда, когда команды освоят другие элементы. LEGAL также не был включен, потому что это была общая зависимость.

Желтая Область Ценности ниже имела другой состав зависимостей.

Команды решили что им нужно охватить как минимум APP, SALES FORCE, SIEBEL и WEB компоненты.

Для этой области LEGAl был не нужен совсем. И слабая последовательная зависимость от PORTAl. Мы решили не включать PORTAl на первом этапе. В исключительном случае, когда какая-либо фича нуждалась в изменении PORTAl, команды могли координировать свою работу с красной областью, чтобы выполнить это. Мы также использовали это, как возможность, чтобы узнать больше о PORTAL.

Что делать с элементами функциональности в пересекающейся оранжевой области? Решение состоит в том, чтобы решать, на основе самой фичи.

Например, F10 может быть выбрана как красной так и желтой областью. F18 задействует только APP и может быть выбрана желтой областью. Единственная сложная фича – F11. Она задействует SALES FORCE и PORTAL, которых нет ни у красной ни у желтой области. Итак, как быть с ней? Хорошо…., вспоминаем золотое правило Скрам-мастерства: “Всегда спрашивай команду.”

Итоговый результат

Определение продукта включает все элементы, но мы выбрали не включать LEGAL-компетенции ни в одну из команд на старте. Почему? Потому что это общая и слабая зависимость. Кроме того, команды чувствовали, что еще не готовы охватить больше навыков с самого начала. Вместо этого, LEGAL стал следующей активностью для включения в Definition of Done.

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

На Планировании Спринта, команда, которая выбирает эту фичу будет координировать свою работу с кем-то из LEGAL для ее завершения. Предпочтительно, чтобы члены LEGAL также использовали эту возможность, чтобы обучать команду, чтобы они немного больше узнали о LEGAL к концу Спринта. Когда команда продолжает выбирать фичи LEGAl-компонентом, в конечном итоге они обучатся достаточно, чтобы добавить LEGAL в Definition of Done. Бас Водди называет это случайной специализацией. 

ПРИМЕЧАНИЕ. Не всем командам необходимо знать все обо всех элементах определения продукта с самого начала. Команды могут иметь свою специализацию до тех пор, пока все команды в группе смогут выбирать все элементы из верхней части Бэклога Продукта.