Agile-трансформация
AgileSurvey
Beyond Budgeting
DevOps
HR
Kanban
LeSS
OKR
PMI
Project management
SAFe
Scrum
Scrum-мастер
Архитектура
Бюджетирование
Игра
Инженерия
Конфликты
Менеджмент
Обучение
Фасилитация
Применить

Сравнение LeSS и SAFe

Nokia использовала фреймворки масштабирования Agile: LeSS и SAFe. Какую проблему они решали и как?

Перевод статьи Ари Тикка и Рана Нюмана LeSS SAFe comparison выполнен с разрешения авторов.

coord-chaos-ru

Как Large-Scale Scrum (LeSS), так и Scaled Agile Framework (SAFe) имеют публичные истории применения в компании Nokia. Однако, не многие знают, что Nokia представляла собой две большие слабо связанные компании. LeSS использовался и преимущественно используется в Nokia Networks (сейчас называется так же), в то время как SAFe в основном использовался в подразделениях Nokia Mobile Phones (сейчас по большей части принадлежат Microsoft или закрыты).

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

Наш анализ компании Nokia может показаться грубым, но на это есть причина. Мы хотим ясно донести свою точку зрения. Координационный Хаос — это серьезный и опасный шаблон (прим. пер. — перевод видеоролика). Его реальное влияние будет описано ниже.

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

Авторы участвовали во внедрении и развитии LeSS и SAFe в Nokia Networks, а также работали с SAFe в Nokia Mobile Phones. Основатели компании Gosei (прим. пер. — https://gosei.fi/about) работали со всеми финскими компаниями, которые в числе первых начали пробовать SAFe около пяти лет назад (прим. пер. — 2010 год). Одна из них сейчас (прим. пер. — март 2015 года) массово внедряет SAFe в огромной глобальной продуктовой компании. В прошлом году (прим. пер. — 2014 год) авторы прошли SPC-тренинг по SAFe от Дина Леффингвелла (прим. пер. — Dean Leffingwell, создатель SAFe ), а сейчас сертификационные тренинги по LeSS от База Водда и Крэйга Лармана (прим. пер. — Bas Vodde и Craig Larman, создатели LeSS).

Какую проблему решает «масштабирование Agile»?

В течение долгого времени Nokia росла на 35% каждый год, чем очень сложно управлять. Естественным решением была специализация: компонентные и функциональные команды, специалисты знают, что нужно делать, но решения принимают менеджеры, а команды их исполняют. Так было и в Nokia Networks, и в Nokia Mobile Phones. Обе компании отчаянно возлагали надежды на то, что со всем этим справится программное и проектное управление.

Но со временем становилось только тяжелее. Чем больше организационная структура ориентирована на узкую специализацию, тем больше требуется внешней координации. Этот шаблон Координационного Хаоса (прим. пер. — перевод видеоролика) стал одной из основных причин знаменитой «Горящей Платформы» Nokia Mobile Phones (прим. пер. — «Горящая платформа по имени Nokia» или письмо CEO Nokia).

Скрытая проблема — обучение

При специализации и внешнем контроле инженеров на местах Nokia все меньше нуждалась в обучении большинства из них. Специалисты знали, что нужно делать, а руководители проектов их координировали, что позволило продвинутым рекрутерам легко ориентироваться в таких узких ролях. Эта практика позволила думать, что большее обучение не требуется, и укрепила метафору «организации как машины» в головах руководителей. Подобное мышление руководства оптимизирует ресурсы и издержки, причем локально и краткосрочно. Обучение воспринимается издержками, особенно за рамками своей специализации.

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

И LeSS, и SAFe базируются на Scrum на уровне команд. Каждый из фреймворков имеет собственный набор бережливых (Lean) и гибких (Agile) практик для поддержки масштабирования. Ключевое отличие в том, как предлагаемые процесс и организационная структура стимулируют обучение, поскольку Организации обучаются подобно лошадям.

SAFe и проблема Nokia Mobile Phones

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

В качестве решения примерно в июне 2009 года в Nokia Mobile Phones было проведено первое внедрение SAFe-процесса c поездами релизов (release train), совместными планированиями и 4-уровневой иерархией в бэклоге продукта. Это была первая версия знаменитой общей картины SAFe (прим. пер. — SAFe big picture), которую снабдили 170 слайдами, кропотливо проработанными Дином и руководством Nokia. С тех пор SAFe вобрал в себя широкий набор Agile-практик и избавился от устаревшего «душка» Nokia. Однако, ключевая ценность все еще представлена в нем явным образом:

Исполнение Программы

– SAFe

Если посмотреть на рынок, кажется, что это было решением проблемы, осознанной многими организациями.

Ядро SAFe — новый очень детализированный процессный слой поверх Scrum, нацеленный на координацию бардака и обеспечение предсказуемости. Часто новый процесс позволяет отказаться от устаревших глупостей и сделать шаг навстречу Agile-ценностям. Например, запуск всеобщего планирования может придать энергии и улучшить коммуникации. SAFe устраняет проекты и стимулирует контроль незавершенной работы (прим. пер. — Work In Progress).

Авторам трудно вообразить, что старая погрязшая в неприятностях организация смогла бы внедрить SAFe как есть «по книжке». Компетенции людей ограничивают возможности. В большой организации обязательно будут отличия между различными внедрениями SAFe. И со временем порядок вещей в каждой из реализаций процесса SAFe обязательно будет меняться. Это лишь вопрос времени: когда и как долго новый подход все еще будут называть SAFe.

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

Обучение в SAFe

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

Во-вторых, новые роли, определяемые процессом, требуют новых Lean и Agile- принципов работы. Для лиц принимающих решения — это новое обязательство на увеличение инвестиций в обучение. Сеть консультантов SAFe поддерживает этот шаг тренингами и консультациями. Но актуальные практики, используемые в SAFe, не уникальны, поэтому вопрос лишь в том, насколько хороших консультантов вы привлекаете и сколько инвестируете в обучение.

LeSS в Nokia Networks

Nokia Networks производит невероятно сложные продукты с длительным сроком службы. Для некоторых продуктов требовалось обеспечить 20-летний срок обслуживания. И по-прежнему разработка в основном координировалась внутри программ с тяжеловесными релизами, часто длящимися годами.

Эволюция LeSS не может быть приписана единственной корпорации. LeSS в Nokia Networks начался примерно в 2005 году. Сейчас (прим. пер. — в 2015 году), через приблизительно десять лет, в Nokia Networks продолжают функционировать подразделения калибра LeSS Huge.

Так какую же проблему осознали в Nokia Networks? Недостаток продуктивности и гибкости в разработке продуктов. Более тщательный анализ выявил смертельный штопор, в который свалилась компания: фрагментация организации, загроможденный поток работ, растерянные руководители и ограниченное обучение. Это ключевые причины Координационного Хаоса (прим. пер. — перевод видеоролика). LeSS разрывает этот замкнутый круг. Авторы формулируют ценностное предложение LeSS так:

Большее через меньшее.

– LeSS

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

Фича-команда — ключевая концепция в LeSS. Специализация необходима. Она создает ясность и эффективность. Однако, важно, в каком направлении вы развиваете специализацию. LeSS явным образом рекомендует специализироваться в “клиентоцентричности” и продукте, а не компонентах.

Если организация новая и развивающаяся, то LeSS может быть идеальным вариантом, чтобы избежать смертельного штопора.

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

Обучение в LeSS

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

Стратегическое решение

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

SAFe предполагает прямое решение через сжигание осознанной проблемы — новый улучшенный программный процесс, объясненный знакомыми терминами. Его проще понять классическому операционному менеджменту. Он расчесывает тот же координационный зуд, что и вся отрасль тяжеловесного проектного и программного управления, но добавляя при этом методы Lean/Agile.

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

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

Далее…

В следующих заметках блога мы более детально исследуем, к примеру, различные варианты масштабирования Scrum, а также сравним организационные слои SAFe и клиенто-ориентированные команды LeSS. Мы опишем: 1) лидерство и власть; 2) организационную структуру и иерархию; 3) поток ценности; 4) обучение, адаптацию и непрерывное улучшение.

А еще проведем сессию по этой теме на XP2015 в Хельсинках!

13 янв 2018, Руслан Юсупов
Другие статьи
29 ноя 2018, Алексей Сохин
Запусти поезд SAFe с правильным бизнесом на борту

Кто такие представители бизнеса? В чем отличие от заинтересованных лиц? Как их определить в иерархии компании? Сколько по количеству их может быть? В чем их обязанности и полномочия?

scaled-agile-framework
26 ноя 2018, Илона Ноженко
Пять Ключевых Компетенций Lean Enterprise

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

Исследование Agile в России