Масштабирование Agile 🌄 — как сохранить гибкость в больших проектах

Это применение работы по Agile в крупных организациях, в которых работают десятки и сотни команд. Фреймворки масштабирования Agile помогают таким компаниям не потерять свою гибкость и эффективность.

Применение Agile в больших компаниях помогает продолжать работать эффективно при решении большого количества задач — поставлять высококачественные продукты и услуги, более точно попадать в потребности клиента.

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

Стратегия Agile–трансформации — это долгосрочный план компании, направленный на преобразование культуры организации и методов поставки продукта, которые будут воплощают ценности и принципы в соответствии с Agile–манифестом. Стратегия может включать в себя различные Agile–практики, фрейморки или методологии.

Отправной пункт Agile–трансформации – это понимание, где компания находится в данный момент и куда нужно двигаться. Чтобы ответить на этот вопрос, необходимо разобраться с двумя понятиями.

Во–первых, важны ценностные установки компании в контексте планирования. Что для вас более ценно – предсказуемость поставки или способность адаптироваться к изменениям?

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

Второе — ценность продукта для клиента с точки зрения планирования. Стараетесь ли вы понять, что нужно клиенту (это называется «открытая экосистема»)? Или вы сосредоточены на выполнении обязательств (замкнутая экосистема)?

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

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

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

Приходят какие–то люди, берут какого–то генерального директора и устраивают ему экскурсию по Силиконовой долине: в Apple, Google, FB. И начинаются изменения, которые могут длиться годами.

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

Ближе всего определение «компания, которая подчиняется Агиле–манифесту, его ценностям и практикам». А это вообще возможно? А нужно?

Если да, тогда с охранником банка можно договориться, чтобы он вас впустил. Или уборщицы устраивают дэйли стендапы на тему «У кого какие зоны ответственности?». Нужно понять глубину этих изменений.

Для этого нужно определить состояние А и Б. Но как понять процент перехода из одного состояния в другое – не ясно.

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

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

Самое плохое, что происходит потом – создаются замкнутые сплочённые сообщества. Почему плохо? Люди ограничены только одним кейсом, одной компанией. При попытке применить знания на чём–то другом, он терпит неудачу. Потому что знания узки и адаптированы только под одно.

Такие сообщества выдавливают инакомыслие (картинка про выбрасывание в окно). Поэтому им нужна подпитка снаружи в виде консалтинга.

Такие сообщества выдавливают инакомыслие. Поэтому им нужна подпитка снаружи в виде консалтинга.

Сначала продукт не приносит денег, потом он начинает нравится клиентам, достигает пика, а потом он умирает.

С помощью картинок уже можно понимать, где нужен Agile, а где нет.

• Продуктовый портфель

• Стратегия

• Что конкретно нужно достичь

• Сколько денег возможно заложить на эксперименты и т.д.

Они могут запуститься. И даже сработать. Но если применять Скрам в виде водопадного процесса, то он будет дороже обходиться: из–за собраний и sprint review. Например, что полезного могли бы сделать топ–менеджеры, если бы не собирались на sprint review? Уверен, много чего!

«Если хочешь построить корабль – не собирай людей, чтобы они принесли лес и не распределяй задания, а лучше пробуди в них тоску по бескрайним далям моря» © Антуан де Сент–Экзюпери

А что дальше? Первый шторм – и корабль разобьётся. Потому что никто не научил команду строить корабли.

Поэтому должен быть разумный баланс между:

• Менеджментом и лидерством

• Хаосом и иерархией

• Регуляцией и самоорганизацией

• Обучение, менторингом и коучингом

Потому что контекст имеет значение: что хорошо условному Сбербанку – плохо условному Тинькову.