Бизнесу нужен Agile

Недавно в Москве прошла конференция Agile Business Conference 2016, организованная компанией ScrumTrek, на которой Agile-коучеры, а также главы компаний, которые уже прошли Agile-трансформацию, рассказывали о своем опыте.

Кто такой Scrum-мастер ?

Объясняет главный идеолог ScrumTrek Асхат Уразбаев.

Асхат Уразбаев

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

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

При этом Scrum должен не забывать, что он — тоже часть команды и имеет право высказывать свое мнение. Давайте, представим ситуацию: команда на очередном митинге подняла вопрос, нужна ли вообще ретроспектива. Зачем тратить время на анализ того, что уже завершилось. Вам как Scrum-мастеру понятна важность и значение ретроспективы, но команда не хочет тратить на это время. Что вы должны сделать в такой ситуации? Твердо обозначить, что вы против, а ретроспектива будет всегда. Со временем команда поймет ценность ретроспективы. И в ваших интересах сделать ее эффективной. Еще одна важная задача Scrum-мастера — все время открывать команде новые точки роста. Допустим, у вас уже налажены все процессы, команда выдает стабильно хороший результат, ретроспектива проходит эффективно. Попробуйте задать команде вопросы. Знают ли они своего пользователя? Как он себя ведет? Какие ценности продукта для него важны? Осознавая это, команда будет более четко представлять, какой продукт должен получится на выходе.

Scrum-мастер всегда должен задавать себе вопрос: как конкретная проблема может быть решена так, чтобы зрелость команды выросла? Именно постановка этого вопроса и попытка его разрешить будет выдавать в Scrum-мастере руководителя нового типа.

А что насчет Agile-коучера?

Если задача Scrum-мастера — сделать крутую команду, то задача Agile-коучера — сделать таким подразделение или целую компанию. Есть мнение, что при разработке продукта 60% успеха зависит от того, как команда стартует. А 30% зависит от того, как вы ее «коучите», от практик, которые вы используете, от того, насколько они приживаются в команде (10% — другие факторы).

Основная задача Agile-коучера состоит в том, чтобы Agile-мышление закрепилось в культуре компании.

Agile-коучер сочетает в себе четыре функции:

1.Менторинг
2.Обучение/тренинг
3.Фасилитация
4.Коучинг

Как эти функции себя проявляют?

-Если у вас есть проблема, ментор вам ответит: «Знаете, у меня однажды сработало «это» и «вот это». Попробуйте!».
-Тренер даст вам конкретные указания: «Делайте: «а», «б» и «в»».
-Фасилитатор скажет: «Давайте проведем совместное обсуждение и решим проблему».
-И, наконец, коучер спросит: «Почему ты считаешь это проблемой? Какие варианты решения ты видишь?».

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

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

Agile-коучер не решает проблемы. Он выстраивает систему таким образом, чтобы она сама решала проблемы. Элементарный пример: член команды регулярно опаздывает на стендапы. Как поступил бы руководитель в обычной организации? Сделал бы выговор, ввел штрафы и санкции. Agile-коучер предложит команде обсудить и решить эту проблему. Есть интересные примеры из практик разных компаний, когда они рисовали графики из серии: «Мы не опаздываем на стендап уже 6-й день».

Как наладить работу Agile

Рассказывает Клаус Леопольд, управляющий партнер Leanability Gmbh.

Клаус Леопольд

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

Механизмы обратной связи

В Agile очень важна роль двусторонней коммуникации, анализа процессов, внедрений и преобразований. При разработке продукта очень важно давать обратную связь тем людям, которые занимаются стратегическим развитием, в частности, Product Owner'у. Схема, при которой сверху спускаются задачи, а разработчики их просто выполняют одну за другой, работать не будет. Команда знает процесс изнутри и то, как его улучшить. Именно для такой двусторонней коммуникации в Agile существуют определенные мероприятия-демонстрации, ретроспектива и так далее.

На каком уровне внедрять Agile

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

коммуникацию внутри компании.

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

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

Я не верю в корпоративный Agile

Что делать, если заказчик не верит в Agile-трансформацию, объяснили заместитель генерального директора EPAM Артак Оганесян и Agile-коучер Алексей Ионов.

Артак Оганесян и Алексей Ионов

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

Для чего руководителю нужен Agile?

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

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

А где управление? Где отчетность? Как и с кого спрашивать?

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

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

Важно, чтобы в вашем бизнесе появились два человека: Scrum-мастер и Product Owner. Это те люди, которые должны помочь команде понять принципы и нюансы Agile. Воспитать этих людей — самая важная задача. Они должны понимать, как работает схема, и одновременно осознавать, что не являются начальниками.

Какие есть метрики, как измерить эффективность?

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

Будет ли Agile работать в большой команде, где в IT задействованы сотни человек?

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

С чего начать, на что обратить внимание вначале?

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

Где Agile работать не будет?

Agile не приживется в той компании, где:

• Нет заинтересованности в гибкости с точки зрения бюджета и процесса.
• Люди не могут делегировать принятие решений.
• Команда не хочет разделять ответственность при принятии решений.