Почему провалить Agile так легко

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

Проникнитесь Agile заранее

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

Agile — это способ мышления, целая культура

Чтобы мыслить иначе, нужно изменить мировоззрение — но мы-то уже успели сформироваться, и потому меняться слишком тяжело, болезненно. Надо выйти из зоны комфорта, нарушить статус-кво. Сделать это должна не только команда разработчиков, но и все, кто с ней связан.

Понять, как меняется наше поведение и от чего это зависит, поможет книга «Психология позитивных изменений» Джеймса Прохазки. (Под таким названием книга вышла на русском языке, в издательстве «МИФ». В оригинале она называется «Changing for Good». — Пер.)

Прежде чем работать по Agile, надо внутренне принять Agile

Бывало, что я пытался внедрить эту практику с ходу, хотя не все в команде были знакомы с принципами и ценностями Agile. Каждый раз получалось так себе. Я видел это везде: работая с государственным сектором и частными компаниями, с большими и маленькими командами, со стартапами и уже сложившимися предприятиями. Самый лучший путь — работать с небольшими командами и не форсировать, а идти последовательно, шаг за шагом. Такой подход меньше вредит отношениям с клиентами и владельцами компании.

Часто я слышал от руководителей, что их команды уже перешли на Agile, так как проводят встречи стоя (в формате stand-up meeting), используют канбан или спринты³ и тому подобное. Я начинал расспрашивать — и оказывалось, что никакого Agile у них и в помине не было.

Трудясь, они не создавали нечто ценное (да и вряд ли об этом задумывались), а просто работали по плану. Мотивация команды была на нуле, непрерывное обучение осталось за бортом, и разработчикам по-прежнему навязывались дедлайны. Их спринты длились месяцами. Руководители проектов и владельцы продукта (product owner) появлялись, лишь чтобы накидать команде новых задач. Запуск продукта был подлинной болью. Между командой и руководством будто выросла стена, да и вообще компания цеплялась за традиционный подход.

И они решили, что работают по Agile?! Ну-ну.

Agile нельзя внедрить пошагово

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

Если хотя бы в паре утверждений вы узнаёте свою компанию, то никакого Agile у вас нет.

• Вместо вдумчивой работы над 2-3 задачами у вас круговерть внезапных проектов с горящими сроками.
• Руководители отменяют решения команды.
• Самые талантливые сотрудники тащат слишком много проектов сразу.
• Участники команды постоянно встречаются и совещаются; это съедает немало рабочего времени.
• Чрезмерный контроль на всех этапах.
• У вас борются с ошибками — и потому ввели отчётность или контроль (а может, так было и раньше).
• Менеджеры и руководство компании больше говорят, чем слушают.
• Руководство педалирует пустячные идеи — в том числе те, которые команда пока отложила.
• У вас часты конфликты и переделки, потому что недосуг обсудить всё заранее.
• Культ качества — это не про вас.
• Команда принимает в штыки любые изменения.
• Если изменить что-то пытается сама команда, то ей вряд ли пойдут навстречу.
• Внедрение и интеграция болезненны: приходится работать сверхурочно, автоматизация хромает или же проект сложно утвердить.
• Отзывы клиентов или пользователей можно отфутболить — потому что исходный план и утверждённый объем работ превыше всего.

Некоторые руководители уверены, будто у них и так уже всё по Agile, хотя до Луны и то ближе. Именно на такие случаи у меня уходило больше всего сил. Убеждая руководителей, что они на ложном пути, я показывал им реальный Agile и его преимущества. А мне возражали, что такой Agile приведёт к анархии, хаосу и потере качества.

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

Лёгкое решение дорого обходится

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

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

Да, по моему опыту, примерно 5 из 10 команд после перехода на Agile уже в среднесрочной перспективе повышают производительность труда, удовлетворённость клиентов и качество разработки, а в долгосрочной — снижают общие затраты и улучшают другие KPI.

Но у тех команд, которые выбрали Agile сами (буквально каждый участник этого хотел), эти показатели улучшаются чаще: соотношение будет примерно 8 из 10 команд.

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

Главная фишка Agile в том, что это не готовая структура или некий свод правил, диктующий, что и как нужно делать. Нет, вся команда думает, что лучше для их проекта. Она может выбрать любую методологию (Scrum, Kanban, XP, Lean, SAfe…) или даже создать свою собственную. Это же касается и любых рабочих инструментов.

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

Иногда Agile не нужен

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

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

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

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

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

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