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

13 Июн 2019

Источник: New Historian

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

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

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

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

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

Застопорившиеся agile-путешествия

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

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

В какой-то момент эти предложения могут встретить сопротивление со стороны руководства, так как ставят под сомнение устоявшиеся и работающие управленческие практики. В результате даже имеющиеся зачатки гибких подходов могут быть уничтожены, а agile-лидеры и коучи могут потерять работу. Конечно, это не делается явно. Напротив, руководители празднуют победу: «Мы уже agile. Нам больше не нужны agile-лидеры и коучи». В результате попытки применения гибких подходов или прекращаются, или остаются на том же уровне, или продолжаются «подпольно».

Застопорившееся agile-путешествие. Автор – Стив Деннинг. Источник

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

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

Брендовый agile

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

Некоторые из таких «брендированных» вариантов agile могут нести правильные ценности и смысл agile-подходов. Многие фокусируются на Втором Законе Эджайла – Законе маленькой команды, так как он наиболее прост для применения. При этом минимум внимания уделяется другим двум Законам – Закону клиента и Закону сети.

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

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

Можно согласиться с высказыванием Люка Халивела примерно 10-летней давности:

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

Многочисленные формы «брендового agile» могут запутать и ввести в заблуждение относительно базовых ценностей agile. «Брендовые» подходы совмещают в определенной степени и фейковый, и подлинный agile. Главное предостережение здесь – отличать консультантов и тренеров, которые настаивают на использовании исключительно их авторского подхода как «единственного правильного».

Фреймворки масштабирования: SAFe

Особенно досадная форма использования «брендового agile» – это фреймворки масштабирования. Это схемы, направленные на то, чтобы помочь фирмам распространить работающие в отдельных командах гибкие практики на другие подразделения и снять напряжение между ИТ-блоком и другими бэкофисными системами (стратегическое управление, управление финансами, управление человеческими ресурсами, бюджетирование, планирование), которые чаще всего работают по классических бюрократическим процессам.

Задача обычно ставится как «масштабирование agile». Проблема здесь в том, что, когда компания фокусируется на расширении agile, она уже на неверном пути. Задача подлинного agile – уменьшить монолитные системы и разделить их на задания, с которыми могут работать небольшие команды.

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

Фреймворк SAFe. Источник

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

Лайтовый agile

Еще одна форма agile, которая вызывает опасения, это нечто, называемое «лайт-agile». Это понятие появилось в статье Harvard Business Review в прошлом году, которая описывала, как HR-сервисы предпринимали попытки перейти на agile. Заголовок статьи утверждает «HR переходит на agile». Но из текста становится понятно, что используют упрощенный подход: декларируется применение общих принципов agile без применения всех инструментов и протоколов технического мира. Если проанализировать примеры, получается, что лайтовый agile – это, наоборот, применение инструментов и практик agile без обязательного следования гибкому образу мышления. А без философии agile остается косным, безжизненным набором ритуалов.

 

Стив Денинг выделяет 7 ситуаций фейкового agile:

• Agile без лейбла,
• Agile только по названию,
• Agile только для программного обеспечения,
• Застопорившиеся agile-путешествия,
• Брендовый agile,
• Фреймворки масштабирования,
• Лайтовый agile,

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

Описывая некоторые из этих ситуаций Стив может быть чересчур критичен, но выделенные типы будут полезны для периодической проверки состояния вашего agile: не стали ли применяемые в вашей организации практики имитацией и карго-культом?

 

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

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

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

•  Тренинг “Agile Certified Professional”
• 7 примеров фейкового agile. Часть 1
• Новая версия руководства Domains of Business Agility
• Тихий убийца вашего agile