Что такое less scrum
LeSS — Scrum на больших масштабах
LeSS — это Scrum, применяемый к множеству команд, работающих совместно над одним продуктом.
Тема работоспособности и, вообще, возможности применения Agile в больших масштабах не дает покоя отрасли разработки программного обеспечения последний десяток лет. Появилось большое количество подходов таких как Scaled Agile Framework, Disciplined Agile Delivery, Nexus, примитивный Scrum-of-Scrums и т.п. Все они либо сложны, поэтому применение их очень затруднительно и часто не дает ожидаемых результатов, либо настолько просты, что решают лишь частные проблемы в ограниченном количестве кейсов.
Хочется найти какую-то золотую середину, что-то «элегантное», такое же «элегантное», простое и провоцирующее к развитию продукта, процессов и команд, как Scrum.
И вот оно свершилось. Встречайте Large-Scale Scrum, сокращённо LeSS, или по-русски Скрам на больших масштабах. LeSS — это Скрам, применяемый к множеству команд, работающих совместно над одним продуктом.
С этого момента мы начинаем серию статей о подходе Large-Scale Scrum и о том, как он применяется в реальных компаниях. Начнем мы с простого — рассмотрим, из чего состоит LeSS в целом и его особенности.
Коротко о LeSS
LeSS — это Скрам. Скрам на больших масштабах (LeSS, Large-Scale Scrum) — это не новый или улучшенный Скрам. И это не разделение на «Скрам на уровне каждой команды» и «что-то другое на уровне выше». Скорее это о том, как применить принципы, назначение, элементы и элегантность Скрама в контексте большого масштаба настолько просто, насколько это возможно. Так же, как Scrum или любой другой настоящий Agile-фреймворк, LeSS является «минимально достаточным подходом» для максимальной отдачи.
Скрам на больших масштабах — это не специальный фреймворк расширения, работающий только на уровне команд. По-настоящему масштабированный Скрам — это тот же Скрам, но работающий на большем масштабе.
В LeSS основная часть команд — это кросс-функциональные, обладающие всеми необходимыми компетенциями продуктовые команды (feature-team), состоящие из 3-9 нацеленных на обучение участников, выполняющих всю работу (от пользовательских интерфейсов и разработки до снятия продуктовых метрик) для создания полноценного рабочего продукта.
Эти команды работают вместе над одним Бэклогом Продукта, потому что у них есть общая цель: по итогам общего Спринта разработать единый, цельный, готовый к поставке продукт, и каждая команда вовлечена в это, потому что она является не компонентной, а продуктовой командой (feature-team), и отвечает за end-to-end продукт, а не только за его отдельную часть.
Что представляет собой продукт в LeSS? Это полноценное (end-to-end), клиенториентированное решение, которое будет использоваться реальными людьми. Понятие продукта в LeSS гораздо шире, чем просто компонент, платформа, слой или библиотека.
LeSS — это не просто процессный фреймворк. LeSS включает в себя:
Скрам на больших масштабах состоит из двух фреймворков:
Обычный LeSS-фреймворк предполагает наличие одного (и только одного) Владельца Продукта, который владеет продуктом, оптимизируя продукт в целом, и управляет одним Бэклогом Продукта, над которым работают команды в рамках общего для всех Спринта. Элементы LeSS-фреймворка практически идентичны элементам Скрам для одной команды, только применяются уже не к одной команде, а к «команде команд».
LeSS Huge
В какой-то момент, когда один Владелец Продукта более не может держать в голове полный контекст, у него не получается соблюдать баланс между внутренними и внешними коммуникациями, а Бэклог Продукта разрастается настолько, что один человек более не способен с ним справляться. Это сигнал для перехода от обычного LeSS к LeSS Huge.
В LeSS Huge по-прежнему есть один владелец Продукта, но у него есть команда помощников (Area Product Owners). В LeSS Huge работа над продуктом разделяется по Областям Требований (Requirement Areas). Область требований — это не компонент продукта, а определённая группа end-to-end функционала продукта с точки зрения клиента, то есть каждый элемент Бэклога Области Требований (Area Backlog) несет конечную ценность для клиента. Работа над Requirement Area осуществляется Area Product Owner и от 3-х до 8-ми команд.
Вот в целом как выглядит LeSS, но, конечно же, под капотом много нюансов: как плавно запустить LeSS, какие изменения необходимы в организации, как происходит распределение команд, как плавно перейти к feature-team, как определить, что является продуктом в вашей компании? Об этом всем читайте в наших следующих статьях.
Приходите на наш тренинг
Переход от Scrum к LeSS и SAFe
Скрам (Scrum) — фреймворк, предназначенный для разработки, поставки и поддержки сложных продуктов. Он работает эффективно в рамках одной команды, но при масштабировании могут возникнуть проблемы. Проект слишком большой и у владельца продукта возникают сложности с управлением бэклогом? Над проектом работает много команд и появляются проблемы с интеграцией отдельных решений? Не хватает системности и синхронизации между командами? Тогда вам следует обратить внимание на SAFe или LeSS.
Согласно 13th Annual State of Agile Report от VersionOne, SAFe является самым популярным фреймворком для масштабирования скрама — 30 % компаний используют его. LeSS используется только в 3 % случаев.
В данной статье будут рассмотрены отличия в организации работы с использованием скрама, LeSS и SAFe.
LeSS (Large-Scale Scrum) в переводе на русский означает «скрам на больших масштабах». Это фреймворк, позволяющий применить принципы скрама в больших проектах. В зависимости от количества команд используется либо LeSS (2–8 команд), либо LeSS Huge (больше 8 команд).
Одним из принципов LeSS является «получать большее за счёт меньшего», что значит не создавать бюрократии и обходиться без лишних ролей, процессов и артефактов.
Организация работы по LeSS
Таблица 1. Отличия LeSS от Scrum
| Этап цикла | Отличия |
| Планирование спринта | Проходит в два этапа: общее и командное планирование (если у команд есть связанные элементы бэклога, то межкомандное) |
| Межкомандная сессия по проектированию решения | Проводится командами со связанными задачами, чтобы продумать архитектуру решения |
| Координация и интеграция | Каждый участник команды синхронизирует данные по несколько раз в день и просматривает, нет ли изменений, связанных с его работой |
| На ежедневном скраме могут присутствовать представители других команд | |
| Создаются онлайн-сообщества, чтобы объединить людей, работающих над одними и теми же компонентами продукта в одно и то же время | |
| Уточнение бэклога продукта | Проводится общее и командное (при необходимости межкомандное) уточнение для разделения и детализации больших элементов бэклога |
| Ретроспектива спринта | Проходит в два этапа: общая и командная ретроспектива спринта |
Когда количество команд превышает 8, то требуется дополнительная структура, используется LeSS Huge:
Организация работы по LeSS Huge
Таблица 2. Отличия LeSS Huge от Less
| Нововведение | Описание |
| Область требований | Сгруппированный набор требований к функционалу. Внутри каждой области требований работа организуется по LeSS: должно быть не более 8 команд, свой бэклог, спринт и т. д. |
| Команда помощников владельца продукта | Существует только один владелец продукта, но теперь у него есть команда помощников, каждый из которых отвечает за одну область требований |
Если LeSS является масштабированной версией Scrum, то SAFe — это комбинация Lean, Agile и DevOps. SAFe расшифровывается как Scaled Agile Framework, или масштабированный гибкий фреймворк. Это открытая база данных, на официальном сайте можно найти подробную информацию по каждому элементу SAFe — по ролям, обязанностям, артефактам и событиям, необходимым для внедрения концепции Lean-Agile в масштабе предприятия.
Фреймворк содержит четыре конфигурации. Чем больше человек работает в организации, чем сложнее продукт, тем больше требуется инструментов для эффективной организации работы и, соответственно, выбирается более сложная конфигурация.
Essential SAFe
Это основа фреймворка, которая представляет из себя минимальный набор инструментов, необходимый для получения результата. На этой базовой конфигурации основаны все остальные. Подходит организациям, которые работают над одним продуктом средней или высокой сложности.
Portfolio SAFe
В рамках этой конфигурации идёт разработка нескольких продуктов средней или высокой сложности. Возникает необходимость в управлении портфелем, где принимаются решения по распределению бюджета между потоками, решения о покупке или слиянии с другими компаниями, создании новых направлений бизнеса и закрытии старых.
Large Solution SAFe
Подходит организациям, занимающимся разработкой одного большого, комплексного решения несколькими командами команд. Создаются планы работ на 12–36 месяцев, проводится анализ экономической целесообразности изменений.
Full SAFe
В рамках этой конфигурации идёт разработка нескольких комплексных и сложных решений. Вовлекаются все уровни.
Базовая конфигурация состоит из двух уровней — уровня команды и уровня программы. На уровне команды работа осуществляется по Scrum, Kanban, XP.
На уровне программы вводятся новые роли.
Таблица 3. Роли SAFe на уровне программы
| Роль | Описание |
| Менеджмент продукта | Один или несколько человек, определяющих направление развития продукта, отвечают за бэклог продукта |
| RTE (Release Train Engineer) | Аналог роли скрам-мастера. |
Отвечает за координацию и организацию процесса работы не отдельной команды, а программы
Используется много терминологии, связанной с поездами: ART (Agile Release Train), RTE (Release Train Engineer). Это связано с тем, что работа команд в какой-то мере похожа на работу поезда — имеется стабильное расписание. Если вы не успеваете на один поезд, то всегда можно сесть на следующий. Если в текущий инкремент не получается уместить какие-то цели, то их можно поместить в следующий.
Организация работы на уровне программы в SAFe напоминает организацию работы по скраму, только в более крупном масштабе, с планированием на более долгий период.
Таблица 4. Сравнение этапов работы в Scrum и SAFe на уровне программы
| Scrum | SAFe Program Level |
| Спринт (1–4 недели) | Инкремент программы (8–12 недель) |
| Планирование спринта | Планирование инкремента программы |
| Ежедневный скрам | Дополнительные встречи для синхронизации команд, владельцев и менеджмента продукта |
| Обзор спринта | Демонстрация системы |
| Ретроспектива спринта | Инспекция и адаптация |
События SAFe Essential
Заключение
В статье были рассмотрены основные отличия LeSS и SAFe от скрама. У каждого фреймворка свои особенности.
LeSS более простой и понятный. Не требует таких сильных изменений, как SAFe.
SAFe предлагает более комплексный подход. Появляются дополнительные роли, артефакты и события. Введение требует больше ресурсов.
Невозможно сказать однозначно, какой подход лучше. Всё зависит от специфики работы вашей компании. Если над одним продуктом работает небольшое количество команд, то введение LeSS поможет вам повысить эффективность работы с меньшими затратами. Когда масштабы увеличиваются, появляется неразбериха и требуется больше системности, то стоит обратить внимание на SAFe.
Large-Scale Scrum (LeSS)
Это Скрам, примененный ко всей организации.
Ниже представлен наименьший каркас LeSS, который так и называется «LeSS»:
Как вы видите из иллюстрации, множество команд (магические числа здесь от 3 до 8) в одном Спринте работают над разработкой и поставкой одного Инкремента Продукта. Их направляет один Владелец Продукта посредством одного Беклога Продукта.
LeSS основан на ряде основополагающих принципов. Вот несколько из них:
Чуть больше о принципах в кратком экскурсе по LeSS (на английском):
Больше о LeSS вы можете узнать на официальной странице: www.less.works и посетив тренинг. Также, скоро на русском под редакцией Алексея Кривицкого выходит книга «Large-Scale Scrum» от авторов LeSS.
Не пропустите Certified LeSS Practitioner (CLP)
Тренинги проходят несколько раз в году.
Так что по сути, это мастер-класс по организационному дизайну и системному мышлению.
Конечно же будут детально рассмотрены каркасы Large-Scale Scrum (LeSS и LeSS Huge). Вопросы внедрения этих каркасов и вопросы поэтапного перевода текущих иерархий и структур компаний на LeSS.
Culture follows structure
В мае мы провели третью встречу Scrum Master Club. Эта встреча была посвящена работе с культурой компаний. Неисчерпаемая тема. Все мы хотим поменять культуру компаний к лучшему. Но как?
Я провёл воркшоп по системного мышлению, где мы изучали влияние определенных орг структур на образ мышления, поведение сотрудников и в итоге культуру компаний.
Очевидна вторая. Там и столы для парной работы. И стен достаточно для визуализации. Выходит внешняя среда формирует культуру? Так и есть:
Зачастую подобная структуру приводит в полностью противоположной динамике: выделение платформенной команды изолирует их лидеров от целей пользователей и бизнеса, что приводит к тому, что у платформа зачастую начинает восприниматься как «продукт в себе». Это в свою очередь ведёт к тому, что в таком отделе заводится свой «технический продакт оунер» со своим «роудпэмом» и «стратегией развития платформы». А это всё локальные оптимизации, мешающие видеть общую систему и общие бизнес цели. И поэтому зачастую такое орг решение (выделение платформенной команды) приводит к повышению зависимостей между командами, усложняет координацию, приводит к избыточным инженерным решениям, усложняющих общую архитектуру, и всё это удлиняет циклы выпуска продукта с точки зрения конечных пользователей.
Всё это контринтуитивно и зачастую неявно в организации, от этого в первую очередь страдают инженеры и пользователи. Но кто-то ведь принимал подобные решения? Кто-то ведь решил выделить платформу в «продукт» и наделить властью «технического продакт оунера».
Вот пример дебрифа одной из групп:
Другие два кейса, тоже по своему интересны. Эти орг. решения приводят к своей динамике, не менее удивительной, чем при платформенной работе:
Приходите на наши новые встречи Клуба Скрам Мастеров. Анонсы вывешиваются на нашей facebook-странице.
Слайды выступления:
Доклад на PM Day Kyiv 2016: Complexity and system thinking
Моё выступление на главной (она же «гнучка») сцене PM Day Kyiv 2016 прошло под знаменем сложности, спагетти и японской поэзии.
Избранные слайды и фото
Слайды доклада
Large-Scale Scrum with LEGO
Мои слайды с воркшопа на AGILEEE 2017 по масштабированию Скрам.
Continuous Improvements в LeSS
Продолжаю цитировать перевод новой книги по #LeSS:
Избегайте представителей отделов контроля качества, технологических процессов, трансформаций и усовершенствований.
В крупных организациях обычно имеются отделы контроля качества и технологических процессов, сотрудники которых носят черные пояса Шести Сигм и занимаются проектами по усовершенствованию.
Избегайте их!
Непрерывное улучшение должно осуществляться везде, всеми и постоянно. Наличие одного отдела, отвечающего за улучшения, — это самый верный способ уничтожить как сами улучшения, так и участие в них команд. В место этого пользуйтесь существующими организационными структурами для поддержки внедрения и усовершенствований.
Large-Scale Scrum: Законы Лармана об Организационном Поведении
Мне выпала огромная честь выступить редактором русского издания недавно вышедшей книги по LeSS «Large-Scale Scrum».
Кроме того, что я давно хотел перечитать книгу полностью, а не частями и помочь с ее адаптацией на наш рынок, сам проект выдается очень увлекательным. Я не только редактирую текст, с точки зрения LeSS, я правлю перевод, пытаясь найти в русском адекватные переводы таких терминов как к примеру: «cross-functional cross-component end-to-end colocated feature team».
Пожелайте мне удачи с этим!
Сегодня дошел до законов Лармана из главы про Внедрение, не могу не поделиться:
Законы Организационного Поведения Лармана гласят следующее:
Внедрение LeSS
При масштабировании следует придерживаться такого принципа внедрения: непрерывное улучшение до полного совершенства.
Так при внедрении LeSS отсутствует как инициатива изменения, так и группа и менеджеры по реализации изменений. Изменения в LeSS происходят постоянно посредством экспериментирования и совершенствования, и сами изменения являются новым порядком вещей.
Не пропустите Certified LeSS Practitioner (CLP)
Киев, апрель 2017
Так что по сути, это мастер-класс по организационному дизайну и системному мышлению.
Конечно же будут детально рассмотрены каркасы Large-Scale Scrum (LeSS и LeSS Huge). Вопросы внедрения этих каркасов и вопросы поэтапного перевода текущих иерархий и структур компаний на LeSS.
Краткое руководство по масштабированию Scrum встреч до 50+ участников (без дополнительных затрат)
Скрам масштабируется
На первый взгляд, Scrum тяжело уживается с ростом организации, ведь этот фреймворк не поощряет создание дополнительных ролей, увеличение состава команд и тиражирования беклогов. Поэтому в поиске “канонических” решений так легко не заметить весь сокрытый потенциал возможностей Скрам по масштабированию.
Масштабирование организации по Scrum происходит за счёт повышения внутреннего интеллекта системы, позволяя её компонентам работать независимо, но при этом слажено. Это похоже на молекулы воды, которые уничтожают грязь и помогают нам стирать одежду, мыть посуду, машины и даже детей…
Не то, чтобы участники команд буквально уничтожали элементы беклога при планировании спринтов… но ход мысли и общая идея вам должны быть понятны.
Вам не нужно управлять молекулами воды, чтобы они выполняли свои функции. Нужно позволить им сделать свою работу. Именно так и Scrum помогает решать сложные и трудоёмкие задачи: спуская их на уровень команд и конкретных людей, позволяя им самостоятельно разбираться во всех необходимых деталях.
Скрам встречи масштабируются
По правде говоря, все Scrum встречи масштабируются настолько просто, что я довольно долго сомневался, писать ли об этом вообще.
Для масштабирования Scrum церемоний фасилитатору необходимо сделать следующее:
Давайте посмотрим на практическое воплощение этих идей.
Масштабирование работы над беклогом продукта
Подготовка места проведения встречи
Когда мы пытаемся масштабировать разработку продуктов, мы часто обращаемся к совету из Large-Scale Scrum: фокусируйтесь на всём продукте. На этом этапе я обычно помогаю группе стейкхолдеров, визионеров и продуктоводов совместно создать общее понимание “большей картины”, чем те, что есть у каждого. Иногда они приносят свои мини-беклоги, и мы начинаем склеивать продукт по кусочкам. Это зачастую довольно длительный процесс.
В большинстве организаций это процесс создания “большой картины” может занять довольно много времени. Это связано в первую очередь с тем, что практики сегодняшнего продуктового менеджмента (так сказать его статус-кво) как раз поощряют разбиение больших продуктов на мелкие удобоваримые куски. Поэтому у меня всегда при себе, помимо маркеров и стикеров, есть баночка супер клея. Также с её помощью я могу выделывать всякие штуки, но это совсем другая история.
Приглашение участников и объяснение целей
Пока детский лепет, не правда ли? А вот теперь будет весело!
Маленькие самоуправляющиеся группы
Благодаря этому упражнению, каждый участник из каждой реальной команды будет знать хотя бы часть беклога, а вместе, как команда, они будут знать обо всех элементах. Это упражнение ускоряет получение знаний, увеличивает их распространение и позволяет менеджерам продукта изменять приоритеты без необходимости помнить о структуре команд и потенциальных пробелах в знаниях.
Это то, что гибкость на продуктовом уровне на самом деле означает (помимо других вещей).
Краткие рекомендации для команд
Когда мы сформировали смешанные группы, наш процесс выглядеть следующим образом:
Не вмешиваться (напоминание менеджерам)
Эта встреча выглядит довольно неорганизованной, даже хаотичной, и, если посторонний человек случайно войдёт в середине совещания, то ему, скорее всего, покажется, что совещание просто неуправляемое: некоторые рабочие группы иногда распадаются на ещё более меньшие, кто-то спонтанно подбегает к доске и начинает чертить диаграммы, другие внезапно решают пообщаться один-на-один посреди комнаты…
Или всё, что вы хотели знать о Скрам-мастере, но боялись спросить.
Бисексуальность удваивает ваши шансы на свидание в субботний вечер.
Вуди Аллен
Расскажу вам об одном недавнем случае. Ездил я как-то на open space конференцию (они ещё бывают называются “unconference”, но по-русски это звучит смешно), на которой матёрые agile-тренеры пытались проранжировать все виды agile-коучей: от фасилитатора команды (он же “коуч без власти”) до agile-коуча на уровне организации (он же “agile бог”). Скажем так, дискуссия не задалась.
Но фабрики по выдачи сертификатов уже давно печатают сертификаты и их не остановить, так что я не буду бороться с ветряными мельницами. Поэтому я пойду в обход и попытаюсь донести до вас, милый человек, почему это раздвоение личности (фасилитатор команды против Enterprise agile-коуча) не приносит никакой пользы.