Аварийное завершение спринта
Редко, но гадко. Бывает, приходится останавливать спринт. Дело идет медленно и не туда. Команда упарывается, нужных доступов нет, кризис у клиента или еще какая-нибудь гадость. Дергаем стоп-кран, останавливаем спринт. Проводим ретроспективу, решаем проблемы. Делаем рескоупинг (перепланируем спринт). Едем дальше. Таких форс-мажоров допустимо не больше 5 %. Ибо нефиг.
3.8. Ретроспективы. Бородачи тоже плачут
Допустим, на демонстрации Product Owner разнес вашу работу в пух и прах. Справедливо, методично. Или просто очень эмоционально: он оказался злобным, неуязвимым говнюком. Команда сидит подавленная. Кто-то курит прямо в опенспейсе. Провал. Полный капут. «Что я тут делаю?» – читается в глазах бородатых программистов. Пятница, вечереет. Ваши действия?
Рохля разведет руками. Распустит команду по домам. Ага, щас! Мы пойдем в ближайший бар. И будем всякую фигню думать. Про процессы. Технологии. И ме-е-неджера. Рано его руководить поставили.
Люди будут смаковать неудачу, искать причины провала. На минуточку, не в себе, а в руководителе продукта, менеджере, проекте или процессах. Сами выберут такую позицию, когда они – Д’Артаньяны, а остальные – нет. И будут ныть. Пару-тройку раз повторятся такие ситуации, и дело разладится.
Сильный, во-первых, такого не допустит. Во-вторых, если уж подобное случилось, примет огонь на себя. Прикроет команду. И сразу начнет действовать: обсудит с сотрудниками ситуацию, вместе они разберут ошибки, выработают меры на будущее. У команды по итогу сложится чувство, что меры помогут.
В скраме есть специальная активность, где мы с командой подводим и обсуждаем итоги спринта. Ретроспектива. Цель ретроспективы – не поныть (хотя иногда хочется), не выпить (хотя кому-то иногда необходимо), не байки потравить. А улучшить рабочие процессы.
Давайте исходить из того, что намеренно никто не гадит. Ну ладно, ладно. За редким исключением отбитых чудаков на букву М, которых легко вычислить и отчислить. Но вы серьезно думаете, что программист специально пишет хреновый код? Дизайнер специально рисует дрянной интерфейс? Сложно управлять людьми, которых вы считаете упырями.
Все не так. Им может не хватать ресурсов: времени, мотивации, энергии. В том числе квалификации, чтобы сделать на должном уровне. Вот с этим уже можно работать.
Итак, намеренно никто не гадит. На основе этой идеи вы должны гарантировать безопасность команде на ретроспективах. У людей должна быть уверенность, что:
? по итогам ретроспективы никого не накажут;
? на ретроспективе ни на кого не наорут, не затроллят и морально не опустят;
? за обсуждение проблем не посчитают слабаком (но только на ретроспективе – ежедневных нытиков отправим к мамочке);
? и так далее.
Придется стать сильным и тактичным, чтобы вскрывать проблемы команды, не вскрывая при этом людей.
3.8.1. Формат ретроспективы
1. Подготовка
Мы заранее планируем встречу и собираем команду в одной комнате, без посторонних ушей. Сложно, знаете ли, исповедаться на базарной площади. Напомните ребятам, где и когда планируете провести ретроспективу – возможно, они захотят посмотреть свои записи, коммиты или еще как-то подготовиться.
На 2-х недельный спринт и команду в 3–4 человека планируем минут 40–60. На месячные спринты или большие команды может уйти часа полтора. Я бы не советовал делать ретроспективы еще длиннее – это контрпродуктивно.
Иногда уместна пицца: задушевные разговоры за едой сплачивают команду и снижают уровень агрессии.
Один человек будет ведущим. Как правило – скрам-мастер или менеджер, если он совмещает эти роли.
2. Настройка
Первые пару минут включаем команду в
работу.
Здороваемся, налаживаем контакт. Например, задайте простой вопрос, типа «Как дела?». И получите хоть какую-то реакцию. Кивок головы или угрюмое: «Расскажи, дружок мой, Вова, отчего мне так хреново», это окей.
Альтернативные техники, которые мне нравятся:
1. 10-пальцевый опрос. Попросите всех выбросить на пальцах, насколько довольны текущим спринтом.
2. Happiness radar. Чертим матрицу 3?3. По вертикали – смайлики настроения. По горизонтали – Технологии, Люди, Процесс. Каждый ставит палочку, насколько удовлетворен каждым из аспектов. Стикеры нужны для фиксации предложений по ходу.
3. Проверка безопасности. Просим также на пальцах выкинуть, насколько каждый себя чувствует сейчас в безопасности.
Напоминаем цель ретроспективы. Если есть новые участники, не привыкшие к ретроспективам – рассказываем про формат и гарантируем безопасность. Рассказываем про «намеренно никто не гадит».
3. Накидывание на вентилятор
Далее просим по кругу рассказать о плюсах (хорошем) и минусах (плохом) на спринте. Начинайте не с новичков. Идеи приветствуются и фиксируются, но не критикуются.
Знаю пару ребят, которые ведут блокнотики и записывают туда всю бяку по ходу спринта. А потом зачитывают по пунктам. Боюсь, что если прочитать вслух блокнотик от корки до корки, – явится ноющий дьявол. Но раз им так проще – пусть пишут.
Модератор должен чувствовать настроение команды. Уметь разговорить. Уметь слушать. В споры не вступать. Не говниться. Не обесценивать предлагаемые идеи. Модерировать, если идет неконструктивный треп. Подталкивать к поиску решений. Параллельные потоки (когда параллельно обсуждается парочка-другая тем) и болтовню – закрывать. Вытаскивать тыкающихся в телефон наружу. Стараться выявить те проблемы, в которых команда старается не сознаваться даже сама себе.
Модерируем глупые споры, является ли озвученная проблема проблемой. Или про важность проблем. Вместо споров – просто фиксируем. Может, человеку это важно.
4. Подрывай!
Это не каноническая техника ретроспектив. Но иногда я так делаю.
Я люблю порой посидеть на чужих ретроспективах. Одна из интересных проблем, с которой сталкиваешься в сработавшихся коллективах, – ребята не любят взрывать медленно тлеющие конфликты. Всех бередит, но по-тихому.
Например, между тестировщиком и программистом возникла вялая напряженность из-за того, что тестировщик очень тщательно и придирчиво все проверяет. А программист считает, что это излишние придирки и пиксель-дрючево. Но вслух никто ничего не высказывает. Так, срутся в комментах к баг-листам, вяло препираются «баг-не-баг», на что улетает вагон времени и нервов. Копится недовольство: друг другом, проектом, менеджером, клиентом или погодой за окном.
Одна из интересных задач модератора – по косвенным признакам найти такой конфликт и вскрыть (взорвать) его. Еще дядька Макаренко завещал.
Впрочем, на ровном месте накалять не надо. И так, знаете ли, хватает!
5. Идеи. Генератор добра
Нам нужны идеи. Что поменять, чтобы стало чуть легче и светлее. На первой стадии годятся любые, самые безумные мысли. Критиковать идеи нельзя. Отсев будет дальше.
Тут важно выделить две фазы, как в брейншторме:
1. обсуждение проблем и генерация идей по устранению проблем;
2. выбор среди тех идей, которые будем реализовывать.
В идеале, на каждый наш минус придумываем две-три идеи по его устранению. Собираем, аккуратно записываем. Могут помочь техники из главы 11 по работе с факапами.
6. Хороший план! Плохой план
Далее из идей выбираем несколько (5±2) конкретных улучшений, которые команда готова сделать. Устройте голосование, если идей целая куча. Желательно успеть за следующий спринт.
Некоторые типы идей я отсеиваю. Или прошу переформулировать.
1. «Мы работали плохо, теперь давайте работать лучше».
Спасибо за лозунги. Но я не знаю, как это реализовать.
2. «Не жрать после 18:00» или «Проводить стендап за 10 минут ровно».
Богатая идейка! Больше похожа на правило.
Если бездумно добавлять правила – место кончится. Или будет вагон правил, которые не блюдут. А это дискредитирует власть. Или это будут правила, которые помнит только их автор. И ненавидит коллег за несоблюдение.
Переформулируйте на локальное и исполнимое: «Не жрать после 18:00 в течение следующего спринта», например. Вот это реалистичнее.
3. «Давайте будем закладывать больше времени на подготовку и архитектуру».
Во-первых, это тоже правило. Во-вторых, не люблю, когда добавляются буферы времени.
На это есть Закон Паркинсона: работа занимает все отведенное на нее время. И даже чуть больше. Сколько буферов ни закладывай – будет мало.
Давайте лучше адекватно оценивать задачи и делать дело так быстро, как это возможно, не?
4. «Давайте проверять после тестировщика – другим тестировщиком».
Ну уж нет! Чем больше проверяющих, тем хуже качество. Зачем мне стараться, если за мной перепроверят и под носом подотрут? Рассеивается ответственность.
Я хочу «встроенное» качество как можно ближе к центру создания ценности. Я хочу встроенное в программистов качество. И они это могут!
5. «Пусть менеджер нам кофе приносит. С козинаками. И веером нас обдувает».
На ретроспективах менеджеру легко наловить себе обезьян на голову. Я видел ретроспективы, где команда навешивала на менеджера-слабака кучу правил, которые должен выполнять только менеджер.
С одной стороны, решение проблем команды и правда потребует менеджерского ресурса. С другой стороны, если после ретроспективы вы выходите с ворохом задач чисто для себя – тут явно какой-то косяк.
Надо помогать команде самостоятельно справляться с проблемами, а не быть еврейской мамочкой. Следите за тенденциями.
6. «Давайте все к черту перепишем».
Вот это происходит у меня прямо сейчас, в работающем проекте аптечной сети, где 5000 аптек, первая в стране доставка лекарств online, тысячи пользователей. Просто проекту 4 года, и там нет реактивного фреймворка. А это не так весело и круто. Программисту скучно.
То есть, идея предложена как бы во благо проекта, но чувствуется сильный личный мотив. Почесать ЧСВ, поиграть с технологиями, стать незаменимым и так далее. Словом, почувствовать себя крутым! Я не вижу ничего дурного в таких личных мотивах – они полезны. И без их удовлетворения не будет кайфа на работе.
Но формулировку мы поменяем. «Составить план рефакторинга» – уже теплее. Этот план я внимательно изучу на целесообразность, адекватность прогнозов. Согласую с клиентом и внедрю. Постепенно.
7. «Пусть дизайнеры всегда теперь делают по-другому».
Это когда проблемы пытаются решить за счет отсутствующих на ретроспективе людей. Иногда – оправданно. Но! Естественно, отсутствующие будут не согласны.
Или придумываем правила, которые нужно распространить на всю компанию, а не только на одну команду.
