7 примеров фейкового agile. Часть 1

07 Июн 2019

Источник фото

На тренингах по agile часто приводят пример карго-культа как бездумного следования ритуалам и практикам. Термин возник после того, как во время военных действий между Японией и США на островах в Тихом океане была создана американская военная база. Военные какое-то время жили на острове, получая снабжение и провиант с помощью авиации. Островитяне, увидев, какие полезные вещи получают американцы, начали копировать их действия и оборудование с помощью подручных материалов: маршировали с бамбуковыми ружьями, строили самолет из травы, мастерили наушники из половинок кокосовых орехов. Надежды на появление «даров» от больших железных небесных богов за предпринятые усилия островитян, к сожалению, не оправдались.

Предлагаем вашему вниманию взгляд на проблему карго-культа вокруг темы agile от Стива Деннинга, эксперта в области agile, лидерства и инноваций. Одна крупная корпорация попросила Стива объяснить, как понять, действительно ли в организации работают гибкие подходы. В ходе подготовки Стив выделил 7 типов некорректного применения agile и предложил несколько вариантов причин, по которым такие ситуации возникают в компаниях, и как перестроить работу в правильное русло. В этой статье мы опишем 4 ситуации, три из которых являются примером фейкового (ложного) agile, а одна – лишь естественной стадией развития.

Важность такого запроса вполне понятна. Стив приводит прекрасную аналогию использования псевдо-agile: он говорит, что это как носить костюмы фламенко и говорить о фламенко, но не тренировать шаги и фигуры танца и не «гореть» музыкой этого стиля.

Постепенно в компаниях все больше приходит осознание того, что «Agile поглощает мир». Исследования Deloitte и McKinsey показывают, что более 90% топ-менеджеров считают переход на agile высокоприоритетной задачей. При этом менее 10% отмечают, что их компании на текущий момент можно признать в высокой степени гибкими. Разрыв между желанием и реальностью привел к возникновению большого количества менеджеров, консультантов и коучей, утверждающих, что они сами используют гибкие подходы и готовы помочь фирмам перейти на agile. И с другой стороны, довольно много руководителей фирм задаются вопросом: «А почему мы все еще не agile?»

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

Определяем agile

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

Три закона agile формулируются так:

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

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

Agile без лейбла

Некоторые компании, из наиболее успешно применяющих agile, используют «доморощенную» терминологию. Другими словами, эти компании даже не говорят «мы работаем по agile» и избегают официальной терминологии agile, часть которой (например, Scrum) намеренно придумана, чтобы быть непривлекательной для менеджеров. Таким образом, большинство самых крупных и быстро растущих компаний в мире – Amazon, Apple, Facebook, Google, Netflix и Microsoft явно используют гибкие подходы в большинстве вещей, которые они делают. При этом большей частью они не используют стандартную терминологию agile. Бизнес-гибкость этих компаний – это важная причина, по которой они стали лидерами своего рынка.

Ранний agile

Agile это путешествие. Ни одна крупная фирма не сможет за один день начать применять все элементы гибких подходов. Оттачивание разных методик, инструментов и практик занимает время. Когда организация находится на ранних стадиях применения гибких подходов, это можно назвать «ранним agile». Это не фейковый agile: это неполный agile. Если agile-путешествие продолжается успешно, компания постепенно разовьет мастерское выполнение всех трех законов в операционной гибкости и привычку думать о стратегической гибкости. Развитие в области гибких подходов бесконечно: компании все лучше и лучше выполняют практики и добиваются результатов, разрабатывают свои подходы.

Последовательность шагов у разных компаний будет отличаться. Например, Microsoft 10 лет назад начинала с небольших agile-команд. Компания продолжала экспериментировать в немного ускоряющемся темпе в период 2008 – 2014. Это был период «раннего agile». Только после того, как Сатья Наделла занял пост CEO Microsoft, agile-подход начал распространяться по всей компании. В этот период Microsoft могла служить примером компании, применяющей идеи бизнес-гибкости.

«Путешествие» Microsoft. Автор – Стив Деннинг. Источник

Напротив, Amazon сфокусировалась на максимизации ценности для клиента с момента выхода на фондовый рынок в 1997. В этот момент компанию тоже можно было назвать применяющей «ранний agile», несмотря на то, что первый шаг отличался от выбранного Microsoft. Всего пять лет спустя компания включила в свои практики «2pizza-team» (количество участников в команде должно быть таким, чтобы их можно было накормить двумя пиццами) и начала связывать команды в сеть, отказываясь от вертикальной иерархии.

Agile только по названию

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

Понятие «agile только по названию» также применимо к компаниям, которые применяют ритуалы и процессы agile-фреймворков без понимания и принятия ценностей agile. Они «делают» agile вместо того, чтобы «быть» agile. Например, в период до 2016 года в Wal-Mart было несколько предположительно agile-команд, но от их усилий компания не получала ожидаемых выгод. Команды применяли процессы agile, но руководство не верило в этот подход. Им не хватало agile-мышления.

Только в 2016 WalMart купил Jet.com и поручил дальнейшее развитие в области agile Марку Лору. В течение года универмаг резко расширил ассортимент товаров, доступных онлайн, предлагал бесплатную доставку в течение двух дней. Финансовые результаты не заставили себя ждать.

Agile только для программного обеспечения

Для многих сторонников гибких подходов Agile-манифест 2001 года служит путеводной звездой. 4 ценности и 12 принципов, изложенные в Манифесте, послужили руководством тысячам разработчиков, «ищущих лучшие способы разработки программного обеспечения, следуя этим принципам и помогая другим следовать им».

Agile-манифест действительно часто служит отправной точкой для тех, кто хочет распространить идеи agile за пределы разработки ПО, и основой для развития бизнес-гибкости. В 2011 году 10 авторов Манифеста вновь собрались, но не продемонстрировали и малейшей склонности к изменению хотя бы слова в Манифесте или распространения его действия за пределы ИТ. Манифест сейчас – это легендарный исторический документ, как Великая хартия вольностей (Магна карта) или Декларация независимости США. Несмотря на то, что эти документы имеют мало общего с современным миром, тем не менее, в свое время они послужили основой для дальнейшего развития соответствующих областей.

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

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

Это была первая часть статьи о фейковом agile. Мы рассмотрели понимание «правильного» agile, три ситуации фейкового agile:

• Agile без лейбла,
• Agile только по названию,
• Agile только для программного обеспечения,

и одну ситуацию, которая является естественной в процессе развития гибких подходов в организации и не считается фейковым agile – это «ранний agile».

Во второй части статьи рассмотрим еще 4 ситуации фейкового agile: «застопорившиеся agile-путешествия», «брендовый agile», «угрозы фреймворков масштабирования» и «лайтовый agile».

 

 

Мария Белых, ведущий консультант, PRINCE2 Practitioner, ICAgile Certified Professional

Источник: https://www.forbes.com/sites/stevedenning/2019/05/23/understanding-fake-agile/#7cf8600a4bbe

 

Если вы хотите стать Agile, то вы можете зарегистрироваться на наш открытый тренинг Agile Certified Professional в онлайн или очном формате.

 

Смотрите также:

• Новая версия руководства Domains of Business Agility
• Тихий убийца вашего agile
• 10 вредных советов новичку в Agile