Бессмысленный Agile


В своей статье на Hacker Noon, John Cutler рассказывает о причинах непринятия Agile подходов в компаниях и о том, как с ними работать.

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

Но недавно мне показалось, что для любого здравомыслящего человека – без большой практики использования этих подходов в реальной жизни и наблюдения за тем, как они работают, – Agile не имеет смысла. Парное программирование? Ты шутишь? Mob-programming (групповое программирование)? Ты определенно псих. Выпустить некачественную, но полезную версию продукта через неделю? Зачем? Выяснить ближайшую цель и идти к ней без длительного планирования и кучи документации? Безумие! Пригласить клиентов участвовать в рабочем процессе? Они сойдут с ума! Позволить командам стать самоуправляемыми, самостоятельно организовываться и решать, где сосредоточить усилия по непрерывному улучшению? Это что, Повелитель мух? Цели команды, вместо персональных KPI? Ты что социалист? Снова и снова.

Если бы это имело смысл, все бы так делали, верно?

Мы предполагаем, что эти подходы очевидны и интуитивны. Но это не так, если только вы не говорите о размытых, высокоуровневых идеях предназначенных для кивков с умным видом. Возьмите фразы типа «Люди и взаимодействие важнее процессов и инструментов» (принцип из Agile-манифеста, прим. пер.) и «Сделайте безопасность обязательным условием» (принцип из манифеста Modern Agile, прим. пер). Оба звучат разумно – даже круто – но легковесный процесс и «открытая культура» для одного человека – бюрократия и культура страха / запугивания для другого. Таким образом, обнаруживается проблема размытости смысла громких слов.

Во многих контекстах Agile не кажется интуитивно понятным, потому что Agile, как мне кажется, ориентирован на устойчивость и долгосрочную жизнеспособность («Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки», Agile-манифест). Преимущества проявляются не сразу, а в краткосрочной перспективе вы, вероятно, даже испытаете некоторый дискомфорт и диссонанс. Например, акцент на качестве действительно окупается, но только когда продукт становится безумно сложным, а вы все еще можете продолжать инновации. Постоянная поставка небольших инкрементов окупается, когда клиент чрезвычайно удовлетворен конечным результатом (из-за вашего обучения и своевременных корректировок курса), а не когда клиент пробует убогую, урезанную версию вашего продукта после первого спринта и дает обратную связь. Если вы привыкли к быстрым результатам (как большинство людей), фокус на Agile - не ваш лучший инструмент (а вот бег вслепую – вполне может помочь).

Даже когда вы углубляетесь в детали в своих объяснениях, большая часть смысла теряется из-за различий в восприятии информации (с примесью когнитивного диссонанса). Я помню, как рассказывал друзьям, что работал в компании, где был крайне успешный продукт и всего один небольшой дефект каждые 4-6 месяцев. Это просто не сходилось с их десятилетиями опыта, так не бывает. Что-то должно было это объяснить: другая доменная область, инженеры, которых они не могли позволить себе, другие технологии, выигрышная стратегия продукта с использованием срезания углов (которая, в конечном итоге, провалится) и т.д. Это тупик. Для многих Agile – это работать спринтами и использовать Jira. Таким образом, они уже «делают» Agile. А остальное – это своего рода культ, который работает только в блогах.

Затем у вас есть куча когнитивных искажений и интуитивных ловушек, такими как влияние высокой утилизации ресурсов, стоимость простоя работы в очередях, различия между производством и умственной работы и т.д. (См. книгу Дона Рейнерцена «The Principles of Product Development Flow» там без догм описаны разные ловушки). Подсказка: даже когда люди прочитают эту книгу, они будут знать много теории, но им будет не хватать тонны контекста.

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

Как только вы поймете, что Agile не имеет никакого смысла, вы сможете начать работать над продвижением экспериментов с хорошо известными шаблонами Agile. Первый шаг - снять вашу шляпу Евангелиста. Нет смысла проповедовать вещи, которые не имеют смысла … вас назовут Еретиком (и мы знаем, что происходит с еретиками). Так же, не надо быть Последователем. Люди не доверяют последователям вещей, которые не имеют смысла. Не упоминайте, что работало в другой компании … потому что «здесь это не сработает» (и это звучит самоуверенно и высокомерно). Самое главное: измените свою установку с «я тот, кто знает как надо … они просто не понимают» на «это не имеет смысла … это моя проблема».

Что вы можете сделать?

Какое самое малое действие, которое может принести пользу (и имеет смысл)? Лучше проведенный стендап? Лучшая ретроспектива? Приглашение клиента на демо? Парное программирование в течение дня? Соглашение получить какой-то инкремент продукта через пару дней? Попробуйте это. Сделайте одно дело имеющее смысл, чтобы сказать «вау, я вижу как это действие приносит пользу».

Когда вы примете этот скромный подход - вместо того, чтобы “запускать” кучу артефактов, инструментов, ролей и ритуалов и “делать Agile” - я думаю, вы поймете истинный дух Agile.

Оригинал статьи. Перевод публикуется с разрешения автора.


Чтобы не пропускать следующие статьи, подпишитесь на наш канал в Telegram, или на e-mail рассылку. Обещаем не спамить!

Нажимая на кнопку "Подписаться", вы соглашаетесь с Лицензионным соглашением и Политикой конфиденциальности.

Содержание