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

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

Зачем вообще строить команду

Можно же просто пригласить хороших специалистов, раздать им задачи, потом получить результат, какие еще команды? Или можно поработать одному и, например, создать небольшой pet-проект. Но когда-нибудь все равно придется подключать к работе других людей. Это могут быть исполнители, которым вы будете ставить четкие задачи, а могут быть и командные игроки. Всё зависит от того, какой подход вам ближе.  На эту тему написано много книг: например, «Командный игрок» и «Пять пороков команды» Патрика Ленсиони, «Работа в команде» и «17 неопровержимых законов работы в команде» Джона Максвелла. 

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

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

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

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

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

Казалось бы, всё просто: хочешь прокачать команду — внедряй ретро, чтобы регулярно следить за апдейтами и не накапливать проблемы, которые потом могут выстрелить в самый неподходящий момент. Но многие мои коллеги скрам-мастера сталкивались с непониманием со стороны команд (а зачем это все-таки делать?) и разными видами отрицания.

 Расскажу, с какими барьерами сталкивалась я и как их преодолевала.

Отрицание первое: «Лучше поработать, чем два часа болтать ни о чем»

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

Первая причина: команда не понимает, зачем она приходит на ретро, какую именно выгоду ретроспектива им приносит.

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

Вторая причина: у ретро нет четкой структуры и адженды, неясно, о чем будем говорить.

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

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

Решение: понятно, что сложно одинаково хорошо совмещать две разные рабочие роли. Однако ретроспектива помогает в решении практически любых проблем внутри команды. Это значит, что она может здорово облегчить всем жизнь. Если вы проводите ретро, но сами точно не знаете, зачем это делаете, лучше выделить немного времени для изучения вопроса. А как будете готовы — рассказать об этом коллегам. Есть много различных ресурсов с форматами и пояснениями, которые помогу в изучении. Например, форматы различных радаров помогут выяснить, какая именно область вашего процесса проседает и что важно подтянуть именно сейчас. Или формат «Плюс и дельта-плюс» поможет понять, что и как именно можно улучшить, опираясь на мнения и предложения членов команды. Это только пара форматов, на самом деле их намного больше, можно выбрать тот, который подойдет именно вам. Главное — понимать зачем. Не проводите ретро просто потому, что так написано в скрам-гайде.

Отрицание второе: «Да и так всё хорошо, зачем она нужна»

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

Решение: Поздравляю, вы восхитительны. Продолжайте в том же духе, а если вы скрам-мастер — ищите себе новую команду, ведь эта уже и так команда мечты. Такое действительно бывает. Чтобы понять, насколько зрелая ваша команда, можно пройти, например, тест Сишора — это психометрический тест, который показывает степень сплоченности команды. Это лишь пример, инструментов много.

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

Решение: Печально, но в этих случаях это значит, что у вас нет команды, есть просто рабочая группа, которая выполняет задачи. Хорошая новость — это поправимо. Нужно договориться, установить правила и потихоньку взращивать доверие, иными словами, растить команду. Это нелегко, но результат того стоит. Команды более сплоченные и продуктивные, чем рабочие группы, а также они более креативны и умеют предлагать интересные решения. На эту тему можно почитать исследования Такмена, Тимоти Биггса, Стенфорда и Роарка. Исследования отличаются друг от друга, но все они о стадиях формирования команды и об отличиях (в том числе и в производительности) на разных стадиях. Например, сотруднику в рабочей группе не придет в голову проводить аналитику какого-то процесса, если у него нет такой задачи. А участники команды заинтересованы в улучшении своих процессов, даже если никто «сверху» об этом не просит. Кто-то из команды может следить за трендами и предлагать использовать новые инструменты, когда об этом может не подумать, например, тимлид, потому что он сосредоточен на других метриках.  Кстати, про развитие доверия в командах есть полезный телеграм-канал.

Отрицание третье: «Скучно, надоело, одно и то же»

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

Решение: Используйте различные форматы для ретро. Мне нравится метод «Шести шляп» — это формат, позволяющий посмотреть на проблему под разными углами. Или формат «визуализации яхты», где яхта — это команда, якорь — это известные проблемы, айсберг — риски и попутный ветер — всё то, что помогает команде в работе. На Retromat множество идей, при этом их можно комбинировать. Таким образом вы будете подогревать интерес к ретро, при этом решая проблемы. К тому же, всегда можно адаптировать к ретро, например, настольную игру. Периодически мы с командами играем в ретро-имаджинариум. Он похож на обычный, но мы выбираем из набора картинок те, которые наиболее сильно ассоциируются у нас с прошедшим спринтом. Один человек выбирает себе картинку и в закрытую пишет на стикерах, почему именно ее. Затем другой человек пытается понять, почему первый выбрал эту картинку, и пишет на стикерах свое мнение. Когда все предположения написаны, мы открываем стикеры и сверяем их между собой. Это весело и при этом дает понимание того, что человек испытывал во время спринта, насколько хорошо члены команды понимают друг друга. Но важно помнить, что это все-таки рабочая активность, и не переборщить с игрой, оставив основную функцию ретро.

Отрицание четвёртое: «Я приду, конечно, но в процессе буду кодить»

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

Причина: Этот барьер некоторая модификация нашего первого барьера «Лучше поработать, чем два часа болтать ни о чем». Просто здесь команда решила все же посетить встречу, однако фокусироваться и работать на ней она не будет, а будет заниматься своими делами. Опять же, вся проблема в непонимании ценности встречи.

 Решение:

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

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

Отрицание пятое: «Мы поговорили, но дальше ретро дело не уходит»

Причина: Команда потратила время и силы на ретро, составила экшен-план, но не выполняет его. Значит, она не видит ценности в этом экшен-плане.

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

Отрицание шестое: «Скрам-мастер говорит, что ретро это бред, лучше поработаем»  

Причина: Некомпетентный скрам-мастер.

Решение: Гоните его палкой из вашей команды. Довольно радикальное решение, но оно, по моему мнению, было единственно возможным в этом абсолютно реальном кейсе. 

Что в итоге

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

• Если вы скрам-мастер и сталкиваетесь с барьерами, описанными в статье, объясните команде, зачем вы проводите ретро. Найдите нужные слова и аналогии, нарисуйте, покажите на куклах. В моей практике были команды, которые сразу же понимали, что такое ретро, и начинали продуктивно работать с первой-второй встречи. А была команда, которая шла к этому полгода. Важно не “перестроить” людей, главное помнить, зачем вы это делаете, и постепенно, шаг за шагом, учить команду новым практикам. Рано или поздно это откликнется, но нужно терпение. Верьте в себя и любыми способами донесите свои мысли до разработчиков, этим вы облегчите жизнь команде.

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

Ценность ретроспективы в том, чтобы собрать всю команду, оглянуться на прошедший спринт, всем вместе подумать и понять, что мы можем сделать такого, чтобы следующий спринт был лучше предыдущего? Что мы должны предпринять, чтобы в будущем избежать прошлых ошибок? Что у нас было такого хорошего и полезного в этом спринте, что можно повторить в следующем? Ретроспектива — это про действия, а не про разговоры. Составляйте экшен-план, следуйте ему и улучшайте свои процессы и команду.