Евгений Лабунский: «Agile помогает строить антихрупкие системы»

Как провести agile-трансформацию в IT-компании? С этим вопросом команда рекрутингового агентства Indigo обратилась к эксперту. В интервью Евгений Лабунский, Agile Coach, Scrum Master, управляющий партнер Scrum Ukraine, рассказал о том, в каких организациях «приживаются» гибкие подходы, к чему готовиться на пути к трансформации, почему изменения в команде меняют страну и можно ли использовать agile для персональной эффективности.

Евгений: На самом деле популярные agile -подходы существуют давно. Например, канбан с 50-х годов применяется в компании Toyota. Скрам впервые описали японские авторы в статье «The New Product Development Game» (Harvard Business Review), в 1986 году. Затем IT-команды в 90-х годах «смахнули пыль» с этих концепций и начали их использовать в своей сфере, потому что столкнулись с необходимостью быстро получать от клиентов обратную связь, реагировать на изменения и улучшаться. Это помогло «включать» циклы инноваций. Большинство людей, которые стояли у истоков agile, были программистами и использовали разные инженерные практики, которые относятся к гибкой методологии (например, т. н. экстремальное программирование и многие другие). Точкой отсчета развития agile в современном понимании считается 2001 год: тогда был принят Agile Манифест, основной документ, который включает 4 ценности и 12 принципов гибкой разработки. Это достаточно редкий случай, когда многим людям удалось собраться в одной локации и придумать что-то очень толковое.

Евгений: Искусство делать то, что нужно, вовремя. У многих agile ассоциируется с «выше, сильнее, быстрее». Это парадигма т. н. оранжевых организаций, цель которых – победить конкурентов. Но в первую очередь agile решает не проблему скорости: нет смысла быстро делать никому не нужную ерунду. Agile – это прежде всего о понимании клиента и о постоянных изменениях. Не выполнение однажды придуманного плана, а логика поэтапного улучшения.

Евгений: Конечно, в продуктовых. В аутсорсинговых компаниях тоже возможно применение agile, но только если команда открыто взаимодействует с клиентом, готова работать с ним как с партнером. В то время как в аутсорсинге часто наблюдается другая ситуация: есть команда, которая применяет, например, скрам, работает спринтами. Но бэклог наполняет бизнес-аналитик из этой же IT-команды, клиента не приглашают на ретроспективы – только на демо. Product Owner со стороны клиента, но команда не может рассказать ему про все неудачи – поскольку боится, что заказчик уйдет. Закрывая систему от клиента, команда теряет agile: в коммуникации появляются лишние звенья, пропадает информация, в общем, происходит все то, чего мы хотим избежать.

Евгений: Чуть больше года назад к нам обратилась продуктовая компания из Минска , которая работает в сфере RPA (роботизированной автоматизацией бизнес-процессов – прим. ред. ). Компания переживала этап быстрого роста и искала оптимальную систему для дальнейшего развития. Мы вместе с командой из 60 человек (весь девелопмент) собрались на пятидневной выездной сессии, провели обучение по agile. А затем с группой поменьше, из 25 человек, по сути с нуля разработали новую организационную структуру, ориентируясь на принципы agile: определили, какими будут команды и взаимодействие между ними, роли, задачи. Использовали один из фреймворков масштабирования скрама в организации – Large Scale Scrum (LeSS). Затем компания около полугода имплементировала эту систему. На данный момент в организации из более чем 100 человек есть 15 скрам-команд, которые взаимодействуют между собой и работают над одним масштабным продуктом. Это большая замкнутая эко-система. Мы проводим для них сессии, планирование, обучение, а также командный коучинг.

Евгений: Во-первых – бояться. Серьезно, страх парализует любые творческие инициативы и инновации. Во-вторых, agile-трансформация точно провалится без вовлечения топ-менеджеров. Они просто не поймут, что вы делаете. Инсайты, которые команда получает во время изменений, нельзя передать словами – чтобы понять суть, нужно находиться внутри этой ситуации и пробовать самому. Работает только тесная коллаборация внутри организации. Это эксперимент для всех, и прежде всего топ-менеджмент должен хотеть разобраться, как это работает. Именно менеджеры должны демонстрировать новое поведение своим примером.

В-третьих, гарантированный фейл – не выделять людей в команду на 100%, «баловаться» 10-15% занятости. У команды обязательно случится когнитивный диссонанс, люди не поймут, куда им бежать, и в итоге побегут туда, где громче кричат. В-четвертых – выбирать Product Owner, который ничего не понимает в бизнесе, не знает, куда должна прийти компания и для чего вообще делаются изменения. В продуктовой компании эту роль должен выполнять, например, Product менеджер В аутсорсинге нет никого лучше представителя клиента. Но не бизнес-аналитик самой компании, который передает информацию команде – он будет меняющим контекст звеном.

В-пятых, большая ошибка – не менять сам IT-ландшафт. Трансформация подразумевает коренные изменения в IT-инфраструктуре. Если внедрить скрам, но оставить, например, миллион этапов тестирования внутри организации, система останется такой же негибкой, сложной и медленной.

Евгений: Очень просто – запустить пилот. Не существует другого способа научиться ходить, кроме как сделать первые шаги – здесь тот же принцип. Нужно выбрать один-два продукта или направления деятельности, выделить людей, посадить их в одном помещении и попробовать работать в новом формате. При этом важно понимать, что на начальном этапе компании обязательно сталкиваются с проблемами. Когда люди начинают работать по-другому, на поверхности оказываются проблемы, которые были и раньше – просто их никто не замечал. И создается обманчивое впечатление, что во всем виноват agile. Например, кажется, что людей не хватает, нужно нанимать больше сотрудников. Хотя на самом деле это не так, и вопрос в том, чем заняты люди, делают ли они то, что нужно, с точки зрения целей бизнеса.

Менеджерам нужно ответить на вопрос: «Готовы ли мы к этому?» Что выбрать: вернуться назад, к старым системам работы, и опять делать вид, что проблем нет; или решать проблемы и все-таки начать путь в agile. Есть конкретная точка принятия решения, которая делит работу на «до» и «после». Многие компании изъявляют желание стать agile. Но здесь желания слишком мало. Есть два уровня следования цели: compliant to go – когда ты согласен идти, но в принципе тебе окей и так. И commitment to go – когда ты действительно готов пройти этот путь. Так вот для трансформации подходит только второй вариант.

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

Евгений: Есть разные модели, например, ADAPT, которая состоит из пяти этапов: Awareness (осведомленность о том, что изменения неизбежны), Desire (желание изменений), Ability (способность произвести изменения), Promote (внутренние циклы связи, обмен знаниями) и Transfer (переход к новой господствующей организационной модели, культуре управления).

Евгений: Первое условие запуска пилота – только Product Owner может давать работу команде. Вместе с Product Owner команда создает бэклог и дорожную карту. Скорее всего, и другие люди в организации, особенно линейные менеджеры, захотят вмешаться в работу, что-то проконтролировать, внести свои коррективы. Очень важно оградить команду от внешнего влияния. Здесь культура всегда следует за структурой. Если вчера люди работали в департаментах, а сегодня их собрали в одну кросс-функциональную команду, это не значит, что завтра они забудут предыдущий опыт. Например, первое время они могут согласовывать каждое движение с прежним линейным менеджером.

На изменение ментальных моделей нужно время. Прежде всего, поймите, на каких убеждениях строилась работа. Создайте безопасное окружение, чтобы люди увидели, что можно открыто говорить о проблемах, которые обычно замалчивают. Что за ошибки теперь не наказывают, поскольку это тоже часть цикла обратной связи, а новые знания делают команду умнее. Хорошо, когда есть поддержка коуча, внешнего или внутреннего, который работает с командой, но не является ее заинтересованным участником, и может дать обратную связь. Все это помогает перестраивать систему взаимодействия. Как результат мы получим learning organization – компанию, которая постоянно обучается и «шерит» свои знания. Но это длительный процесс, его установка занимает от года. Зато потом изменения чувствуются буквально с порога – сразу замечаешь, что в компании люди активно коммуницируют, все переговорки заняты, а стены пестрят визуализацией.

Евгений: Если у вас в руках молоток, все вокруг превратится в гвозди. Поэтому нужно учитывать, что именно компания хочет улучшить. Например, канбан помогает понять и оптимизировать производственный end-to-end process, скрам – продуктовую разработку. Это взаимодополняющие вещи. Но я знаю организации, у которых нет ни канбана, ни скрама – и при этом они очень гибкие. Холакратия со стороны может показаться хаосом, но это тоже отличная гибкая модель для зрелых команд. Хотя и присутствие иерархии – это не плохо. Важно, что менеджер делает в этой иерархии: раздает задачи «дуэрам» или помогает людям развивать идеи и достигать результатов. Структура может быть любой. Фреймворки включают много элементов, и команда сама определяет, что именно ей нужно. Можно придумать и собственную систему, которая сработает.

Евгений: Об этом редко говорят, но до того, как говорить о фреймворках, читать, например, Джеффа Сазерленда или Майка Кона, имеет смысл разобраться в глубинных основах построения организаций. Стоит почитать книги о спиральной динамике, теории хаоса, системном мышлении, например, «Пятая дисциплина» Питера Сенге. Ознакомиться с концепциями кайдзен и Lean – это основа, а также моделью Cynefin, которую предложил Дейв Сноуден. Рекомендую книги Нассима Талеба – «Черный лебедь» и «Антихрупкость». Потому что agile помогает строить антихрупкие системы, которые с каждым витком улучшаются на основании своего опыта. Agile намного глубже известных всем слов «скрам» и «канбан».

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

Евгений:Этот инструмент включает всего три шага: Mobilize (помещение, в котором «мобилизуется» команда), Visualize (доска, на которой визуализируется рабочий процесс), Ritualize («ритуалы», регулярные встречи в своем пространстве возле доски). Но это применимо, например, в HR-командах, для IT он слишком прост. Хотя, возможно, это могут быть первые шаги.

Евгений: Со второго курса я начал работать в сфере IT на позициях Project Manager. С 2011 года стал изучать и применять agile, затем получил сертификацию Scrum Master. Последние два года мы с компанией Scrum Ukraine занимаемся организационным консалтингом и проектами agile-трансформации. В нашем портфеле есть как продуктовые IT-компании, так и другие крупные организации, например, банки — Райффайзен Банк Аваль, УкрСибБанк, ПУМБ. Тема agile интересна мне потому, что я верю: меняя организации, делая людей счастливее в рамках компании, можно изменить страну. Когда начинаешь по-другому работать, легче понять, насколько все взаимосвязано. Понимая что-то новое о работе и о себе, вкладывая душу в то, что делаешь – хочешь вкладывать больше и в окружающий мир.

Евгений: В личной эффективности все очень индивидуально. Конечно, можно жить спринтами. Но это сложно – я пробовал. Многие вещи продолжаешь делать только потому, что «закомитился» на всю неделю. Пропадает фан и эмоции. А жизнь должна быть непредсказуемой – тогда от нее можно взять лучшее.

Диалог вела Катя Маевская