Кто-нибудь переживал процесс перехода на Agile? Как вы справились?

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

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

• Во-первых, некоторые церемонии — ретроспективы, стендапы и планирование спринта — проводились формально. По расписанию, да. Но менеджер тратил первую половину встречи на рассказ о KPI, а к моменту, когда пора было переходить к важным вопросам, время заканчивалось, и все участники просто расходились. Никакого пространства для обсуждения реальных проблем не было.

• Во-вторых, внутри компании ощущалось сильное сопротивление изменениям, причём не только от сотрудников, но и от топ-менеджеров. Некоторые просто не понимали, зачем им вникать в новые процессы, если «всё и так работает».

• В-третьих, руководители искренне верили, что делают всё правильно и выбирали те части agile, которые по описанию были похожи на то, что им нужно. И честно выполняли все пункты от А до Б.

В одной из продуктовых команд я познакомился с разработчиком Славой. Отдел, в котором он работал, ещё полгода назад полностью придерживался последовательного подхода к разработке — принципа водопада. А после самостоятельного внедрения Scrum всем сотрудникам пришлось подстраиваться под новые организационные требования, которые постепенно обрастали свежими слоями регламентов и новыми workflow в Jira. Но не давали результата.

«Нас разделили на «кросс-функциональные» команды. То есть теперь мы работаем в группах по 7 человек вместе с тестировщиками и аналитиками. Конечно непривычно, но удобно — можно решать вопросы «здесь и сейчас» и не бегать по разным отделам. Сели, обсудили и быстренько сделали.

Ещё мы стали разбивать задачи на user stories — что нужно сделать и зачем с точки зрения пользователя, и перестали зашивать слишком много требований в одну задачу. Короче, смогли быстрее доводить до ума отдельные фичи. Это конечно плюс.

Да, формально мы собираемся на планирование спринта и утренние стендапы, но приоритеты всё равно спускают «сверху» и не учитывают нашу скорость работы и потенциальные риски. В итоге требования к нам прилетают почти так же, как это было до перехода на Scrum.

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

С одной стороны, нас подталкивают брать на себя ответственность, а с другой — сваливают противоречивые требования. При этом почти никогда не спрашивают, как нам проще и эффективнее их выполнять.

Проджект: Как успеть сделать все фичи к релизу?
Разраб: Давайте удалим локализацию на испанский и push-уведомления с обновлениями.
Проджект: Мы не можем этого сделать, мы уже пообещали это заказчикам!

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

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

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

Основной минус водопадной модели в том, что у заказчика постоянно меняются хотелки по ходу проекта. Хорошо было бы знать заранее, как будут меняться требования к продукту, который мы разрабатываем, но это нереально:

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

Просто представьте, что слышите такое на демо после того, как завершились все этапы разработки. Зна��омая ситуация? А теперь давайте как-то подпишем акт и согласуем с заказчиком, в какие сроки мы будем это дорабатывать.

Модель водопада хороша, например, в строительстве — там мы на этапе проектирования можем сделать все чертежи и 3D-модель здания. Тем самым почти до нуля снизив риски, что заказчик в процессе передумает или захочет что-то изменить. Например, вместо 5-этажки построить 24-этажный дом. Но в разработке ПО всё немного иначе.

Чтобы дать разработчикам больше пространства для манёвра и помочь справиться с постоянным вращением флюгера, и появился agile-подход. Пользуясь гибким методом управления проектами, вы будете чаще получать полезную обратную связь от заказчика, поэтапно собирать все хотелки, и улучшать продукт до релиза. Кстати, именно аджайл принёс с собой понятие MVP (минимально жизнеспособного продукта), который помогает быстро протестировать гипотезы, и при этом ��кономить бюджет.

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

Если так трудно внедрить гибкий подход правильно (судя по тому, как много компаний делают это неправильно), может, логичный вывод в том, что, хотя идея и крутая, на практике она просто не работает?

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

В России многие крупные бигтех-компании давно перешли на agile: МТС, Тинькофф, Сбер, Яндекс, VK, Авито, HeadHunter — и это только часть списка. Однако, учитывая, что в таких компаниях работают сотни команд, не всем из них удается полностью внедрить гибкий подход, и в некоторых до сих пор возникают вышеописанные проблемы. Но всё поправимо.

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

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

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

Отсюда и возникает впечатление, что agile «не работает». Если компаниям не нравится результат внедрения аджайл, значит, они неправильно его используют. Или их продукт больше подходит для каскадной модели, как в примере с домом, что на самом деле тоже неплохо.

А как у вас проходил процесс перехода с на Agile? Насколько спокойно вы это пережили?

Дмитрий Лобасев, Managing Partner консалтинговой компании OnAgile.

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

Подробнее о примерах внедрения из IT, банкинга, телекома и других сфер мы пишем в нашем Telegram-канале. А прямо сейчас вы можете узнать, с чего начать использование гибких методик и пройти наш бесплатный мини-курс по Agile, Scrum и Kanban. Это занимает всего 20 минут, а за 70% правильных ответов мы дарим подарки.