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

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

В переводе статьи Стивена Ко вы найдёте 7 потерь, присущих компаниям, которые внедряют у себя гибкие методологии, а также узнаете, почему идея о быстром, дешевом и лучшем результате за счёт Agile — самый большой миф.

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

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

Сравнение семи потерь в бережливом производстве и гибкой разработке:

В Lean сокращение этих потерь приводит к производству товаров более высокого качества по более низкой цене. И тут возникает резонный вопрос: а разве внедрение Agile не означает более быстрый, дешевый и лучший результат за счет сокращения потерь?!

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

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

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

Например, подробная документация или прототип. И речь не о том, что они сами по себе недоделаны. Работа выполнена частично, когда они не реализованы в виде кода, то есть по факту считаются work-in-progress (WIP).

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

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

Очевидно: не стоит тратить слишком много времени на оттачивание планов, документации и прототипов.

Если сотрудники организации поделены на функциональные группы, некоторые из них становятся склонны к чрезмерной работе: стратегов частенько оценивают по детальности и достаточности их плана, бизнес-аналитиков — по толщине их аналитических документов, а дизайнеров … ну, вы поняли.

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

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

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

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

Чтобы гибко реагировать на изменения, нужна некоторая степень расслабленности. Когда вы используете рабочие ресурсы на пределе их возможностей, увеличивается время ожидания задач и задержка их выполнения. А это уже не Agile.

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

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

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

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

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

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

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

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

Из всех потерь перепроизводство — худшее, поскольку усугубляет все другие.

Ритуалы и практики Agile полезны, поскольку улучшают производительность команды. Но лишь до тех пор, пока команда не упрётся в ограничения — потери, которые возникают из-за:

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

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