Какие важные аспекты Agile не учитывают компании?13.02.2024 08:30

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

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

Однако вокруг массового перехода компаний на Agile сложилось поверхностное понимание и неправильная интерпретация Agile подходов и философии. 

Более того, у многих компаний Agile превратился в карго-культ, который не просто не приносит ценности, а мешает.

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

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

Что заложено в Agile?

Если вы думаете что Agile — это набор фреймворков, практик и инструментов, то вы лишь на 10% правы. Часто, когда говорят про Agile, вспоминают инструменты, доски, итерации, стори поинты, встречи команды.

Но так ли это? Совсем нет. 

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

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

Давайте рассмотрим все слои того, что входит в Agile

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

1. Практики. Scrum, Kanban, XP и тд. Фреймворки и практики формируют скелет процесса и задают условия в которых теперь должны работать команды. В теории они довольно понятны и их не сложно изучить, однако извлечь реальную пользу намного сложнее. Наверняка вы наблюдали команды, которые старательно проводят все мероприятия Скрама, используют доски, но реального value не получают, а именно — частых поставок, быстрого фидбека с рынка, вовлеченной и самоорганизованной команды. Так происходит из за того, что не работают ключевые принципы в компании.

2. Принципы. Например: «наш наивысший приоритет производить работающий и полезный инкремент каждые 2 недели, который можем показать пользователям и получить обратную связь» (всего принципов 12, вы можете их почитать, поискав Agile manifesto). 

Работает ли этот принцип у вас в компании? Компании у которых этот принцип в фокусе, будут всячески оптимизировать процесс чтобы это работало.

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

1. Ценности. Например «готовность к изменениям важнее следования первоначальному плану» (всего ценностей 4, вы можете их почитать, поискав Agile manifesto). Зная эту ценность, компании уходят от жестких планов, приходя к планированию по метрикам, а планы остаются гибкими. При этом если компания реально хочет быть адаптивной, ей нужно научиться менять планы на всех уровнях, создавать гибкие стратегии. Например на уровне компании и продуктов — это квартал и цели по ОКР, а внутри — спринтовые циклы. Здесь же меняются и процессы бюджетирования. Например используется подход Lean budgeting, когда бюджеты выделяются также на квартал и каждый квартал происходит ревью метрик и строятся планы далее. 

2. Мышление. Agile — это в том числе про культуру компании. Если вы успели поработать в разных компаниях, наверняка заметили что в каждой компании своя атмосфера и свои ценности? Где-то присутствует микроменеджмент и тотальный контроль и недоверие, а где-то наоборот компания стремится раскрыть потенциал каждого, дать автономию, ответственность и управление через обратную связь и метрики. Везде по разному. Каждая компания ценит свой подход к управлению. Agile же закладывает свои ценности и принципы, однако также есть важный фундамент — это мышление внутри организации. Это те вещи, в которые верит компания. Также как например  компания Amazon пропагандирует культуру Day one — культура стартапа или первого дня, что означает что компания не должна бояться экспериментировать и жить в духе стартапа, даже если уже большая корпорация. Это то, во что верит компания. 

Мышление в Agile компании основано на трех важных убеждениях:

• complexity (запутанность) означает, что любую проблему в зоне неопределенности стоит решать экспериментами, чтобы сокращать риски потери и быстрее находить ответы за счет множества экспериментов. Это мышление позволяет формировать структуру и процессы в компании, которые позволят это делать.

• trust (доверие).  Мышление основано на том, что если мы нанимаем профессионалов в своем деле, то мы должны доверять их экспертизе. А если не доверяем, то зачем нам такие люди в компании? При таком мышлении компания стремится создавать автономные команды, которые в своей зоне ответственности могут принимать решения как сделать продукт. Это увеличивает скорость коммуникаций и принятия решений. Оценка же работы таких команд происходит по метрикам продукта. Цель таких команд растить метрики, а внутри, то как будет реализован продукт лежит в их зоне ответственности и компания им это доверяет.

• kaizen (постоянное улучшение). Стремление к постоянному улучшению. Kaizen пришел из завода Toyota, где компания была убеждена в том что нужно бесконечно улучшать качество продукта и процессы. 

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

Выводы

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

Если вам понравилась статья, подписывайтесь на мой телеграм-канал, где рассказываю про построение процессов и делюсь кейсами, а также скидываю полезные материалы.

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

© Habrahabr.ru