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

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

Indigo: Женя, культура применения agile сформировалась именно в IT. Как думаешь, почему?

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

Indigo: Твоя любимая формулировка: agile – это…

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

Indigo: В каких IT-компаниях и командах гибкие подходы «приживаются» успешнее?

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

Indigo: Приведи, пожалуйста, пример интересного проекта agile-трансформации в IT-компании.

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

Indigo: Какие «вредные советы» о том, как гарантированно провалить agile-трансформацию, можно дать? В частности, для C-Level.

Евгений: Во-первых бояться. Серьезно, страх парализует любые творческие инициативы и инновации.

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

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

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

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

Indigo: Как компании протестировать свою готовность «делать agile»?

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

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

Менеджерам нужно ответить на вопрос: «Готовы ли мы к этому?» Что выбрать: вернуться назад, к старым системам работы, и опять делать вид, что проблем нет; или решать проблемы и все-таки начать путь в agile. Есть конкретная точка принятия решения, которая делит работу на «до» и «после».

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

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

Indigo: Из каких основных этапов состоит трансформация?

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

Indigo: Как перестроить взаимодействие в компании при трансформации?

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

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

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

Indigo: Как компании выбрать оптимальный фреймворк?

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

Indigo: Какие книги ты советовал бы прочитать тем, кто только планирует погрузиться в контекст agile?

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

Indigo: Как подбирать в команду людей, которые примут agile-подход?

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

Indigo: А что касается инструмента 123Agile – из каких элементов он состоит и подходит ли IT-командам?

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

Indigo: Как и почему ты сам заинтересовался agile-подходами?

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

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

Indigo: А могут ли принципы agile применяться не на уровне команд, а, например, для персональной эффективности?

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

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

588 просмотров

Обратная связь

Оставьте сообщение и мы свяжемся с Вами

Обратная связь

Оставьте сообщение и мы свяжемся с Вами

Обратная связь

Оставьте сообщение и мы свяжемся с Вами