В целом, SAFe наиболее эффективно работает в организациях, которые сосредоточены на высоких технологиях и имеют монолитную архитектуру. Фреймворк идеален для тех компаний, которые избегают неопределенности, хотят сохранить значительный уровень контроля и не считают, что им нужно много прорывных инноваций, но нуждающихся в синхронизации большого количества взаимозависимостей между командами. Разумеется, SAFe может работать и там, где организации обладают достаточным опытом и уверенностью, чтобы настроить процесс и повысить его гибкость в соответствии с их собственными культурными потребностями.
Scrum@Scale (Scrum of Scrums)
Джефф Сазерленд (Jeff Sutherland), партнер по созданию Scrum, публично представил платформу Scrum@Scale в 2014 году. Тем не менее, он охотно соглашается, что группы Scrum-команд существуют так же долго, как и Scrum – около двадцати пяти лет. Сазерленд разработал фреймворк Scrum@Scale для координации нескольких команд с «минимально жизнеспособной бюрократией» в том, что он называет «немасштабированная архитектура». Система предназначена для масштабирования всей организации: всех отделов, всех продуктов и всех услуг во всех типах подразделений. Сазерленд намеренно избегает увеличения сложности, которая может снизить производительность отдельных команд. Scrum@Scale упрощает распространение, «используя Scrum для масштабирования Scrum»; он расширяется в соответствии со скоростью изменений, определяемой организацией. По сравнению с SAFe, Scrum@Scale стремится к более всесторонней трансформации предприятия с меньшим количеством предписываемых процессов.
Чтобы координировать взаимозависимость между командами, фреймворк регулярно собирает владельцев продуктов, чтобы обсудить, что делают их команды, и привлекает штатных Scrum-мастеров, чтобы они делились тем, как команды это делают. Другими словами, вместо того чтобы собирать группы целиком, Scrum@Scale приглашает лишь их представителей – для управления взаимозависимостями. Фреймворк нацелен на формирование в организации общих ценностей: открытости, смелости, сосредоточенности, уважения и приверженности, – используя прозрачность, изучение и адаптацию в процессе. Руководящая команда MetaScrum выступает в качестве главного владельца продукта для всей организации, работая с другими владельцами продуктов над созданием организационного видения, определением стратегических приоритетов и согласованием всех команд, идущих к общим целям. Руководящая рабочая команда выступает в качестве основного Scrum-мастера компании, работая со Scrum-мастерами над устранением ограничений, препятствующих прогрессу команд. Две руководящие группы используют общие инструменты обратной связи и общие показатели для поддержания взаимозависимости.
Сильные стороны Scrum@Scale: стремление повысить гибкость всей организации; полная согласованность структуры с успешными ценностями, принципами и практикой Scrum; сокращение числа уровней и узких мест бюрократии при очень низких накладных расходах. Сторонники Scrum@Scale также указывают, что этот фреймворк нацелен на сокращение времени, необходимого для принятия решений, и на высокий уровень прозрачности, что позволяет командам быстро снижать объем работ, которые не создают ценности. Scrum@Scale признает роль знаний и инфраструктуры команд, которые поддерживают Scrum-команды, но формально не работают по этому методу.
Слабые стороны подхода Scrum@Scale: ограниченные особенности и предписываемые практики, небольшое число методов эффективной координации большого числа значительно взаимозависимых команд и ограниченное число примеров успешных преобразований в масштабах всего предприятия. Компании, использующие другой фреймворк (например, SAFe), могут столкнуться с трудностями при переходе на Scrum@Scale и, скорее всего, решат сохранить элементы предыдущих фреймворков, которые они считают наиболее полезными.
В целом, Scrum@Scale эффективнее всего работает в организациях, которые хотят масштабировать подходы Scrum, чтобы укрепить фундаментальные ценности и принципы этого метода. Эта потребность возникает, когда компании готовы мириться с некоторой неоднозначностью и хотели бы адаптировать свой подход к масштабированию. То есть там, где организации больше полагаются (или хотят полагаться) на прорывные инновации, а не на нисходящий контроль.
Модель Spotify
Spotify, поставщик услуг мультимедиа и аудиостриминга, максимально четко описывает свою модель масштабирования. Она была создана в уникальном техническом подразделении и в уникальной культуре. Как уже говорилось, компания предупреждает, что модель постоянно развивается и что ее не следует копировать другим компаниям или даже другим подразделениям Spotify. Тем не менее, начиная с 2012 года, когда Хенрик Книберг и Андерс Иварссон опубликовали статью о масштабировании Agile в Spotify, нашлись компании, которые проигнорировали советы организации, скопировали структуру технического отдела и попытались применить ее ко всему предприятию.[6] Результатом стало взрывное появление отрядов, племен, отделов и гильдий в соответствии с терминологией Spotify. Отряды похожи на команды Scrum. Племена – это группы из десяти или менее отрядов (менее ста человек), работающих в смежных областях. Отделы – это группы людей с аналогичными функциональными навыками, работающих в одном племени, используя принцип матрицы. Гильдии – это неформальные сообщества по интересам, которые обмениваются знаниями и практиками.
Модель Spotify интуитивна и проста для понимания; она хорошо работает в техническом отделе самой компании, хотя и не стала основополагающим фактором в таких областях, как стратегическое планирование или финансы. Этот подход приводит к высокой автономии команды, руководствующейся общими целями, что в свою очередь позволяет группам создавать собственные способы работы, поощряя гибкость в использовании инструментов и Agile-методов. К слабостям модели можно отнести недостаточное количество предписаний. Поскольку Spotify разработала свою модель для уже существующей культуры, ей не нужно было предписывать или менять культурные нормы и способы работы, которые делают ее столь эффективной. Многие пользователи модели Spotify считают, что ключ к успеху – это организационная структура. В действительности же она опирается на доверие и сотрудничество, присущие культуре компании. Кроме того, модели не достает разработки логических таксономий и управления взаимозависимостями между командами, поскольку для команд Spotify из-за модульной архитектуры продуктов и технологий характерно меньшее число взаимозависимостей, чем для большинства организаций. В результате в компаниях, пытающихся скопировать модель Spotify, но имеющих линейки продуктов, требующие тесной координации взаимозависимостей, часто возникают племенные структуры, что создает хаос. Модель не описывает структуры, роли или права на принятие решений для операций, функций поддержки и управления за пределами разработки.
В целом модель Spotify эффективна для инновационных отделов с культурой и архитектурой, схожими по структуре, а в технической культуре данной компании особое внимание всегда уделялось лидерству как служению, минимизации взаимозависимости между командами, автономии, демократическим решениям и инновациям, а не минимизации рисков. Адаптация модели Spotify к различным культурам или различным частям компании требует сложной настройки.
Как показывают эти краткие обзоры, модели масштабирования Agile значительно различаются. Все они скорее обеспечивают успех в различных деловых и культурных условиях, и поэтому полезны для перехода к масштабированному Agile, но ни один из них еще не показал сильных результатов в создании Agile-предприятий. Пока этого не произойдет, компаниям придется объединять, настраивать и дополнять фреймворки для решения своих конкретных и уникальных задач.
1. Существуют значительные различия (как в образе мышления, так и в методах) между теми компаниями, которые намереваются создавать Agile-предприятие, и теми, чья цель – масштабированный Agile.
2. Чтобы масштабировать Agile, достаточно создавать десятки или сотни Agile-команд. Но если доминирующие умонастроения и операционные системы останутся бюрократическими, потенциал Agile будет ограничен.
3. Создание Agile предприятия требует баланса и интеграции операций и инноваций. Agile-предприятия управляют бизнесом надежно и эффективно, они меняются, чтобы извлекать выгоду из непредсказуемых возможностей, и синхронизируют два вида деятельности.
4. Лучший способ управлять переходом к Agile-предприятию – это управлять им так, как вы управляете Agile-командой.
5. Компании, создавшие Agile-предприятие, видят серьезные изменения в бизнесе. Масштабирование же меняет структуру работы, чтобы внедрять больше инноваций, чем при обычных операциях.
Глава 3Какой уровень Agile вам нужен?
Внимание, спойлер: название этой главы – вопрос с подвохом. Скоро вы узнаете, почему. Но давайте начнем с другого.
В феврале 1982 года Марку Аллену было двадцать четыре, два года назад он закончил колледж. Молодой человек хорошо плавал, работал спасателем в Сан Диего и время от времени успешно участвовал в соревнованиях. Сан Диего – родина современного триатлона: комбинации плавания, велогонок и бега на длинные дистанции. Это был новый спорт, и многие сомневались, что он приживется.
Однако Аллен увлекся троеборьем. Он решил участвовать в шестом чемпионате мира Ironman на Гавайях, запланированном на октябрь. Это изнурительная гонка: заплыв на 2,4 мили (3,86 км), велогонка на 112 миль (180,25 км), а затем полный марафон на 26,22 мили (42,20 км).
Вначале Марк решил изучить вопрос, как быстро бегают лучшие триатлонисты мира, и он узнал, что они пробегают милю примерно за пять минут. Юноша добился таких же показателей. При беге с такой скоростью его пульс достигал 190 ударов в минуту, но Марк верил своим тренерам, которые говорили, что без боли нет результата. К сожалению, все закончилось печально. В 1982 году он принял участие в соревновании, но не дошел до финиша.