Для команды разработки важно регулярно проводить ретроспективу, чтобы постоянно совершенствоваться. Но какой она должна быть?
Несколько лет на своих ретро мы использовали только некоторые из стандартных практик. В других не видели смысла, ведь положительный результат был: процессы улучшались, проблемы решались. Все и так было хорошо. На самом деле нет:
Первую и вторую проблему мы считали данностью, что делать с третьей не понимали, а о последней я даже не знал.
Прошлой весной я сходил на Okademy от ScrumTrek. Это обширный курс, включающий в себя много полезного для скрам-мастера, но для меня самым полезным оказалась часть о том, как эффективнее проводить ретроспективы. Хочу рассказать, как это нам помогло.
Изначально у нас не было установлено формальных правил. Мы просто собирались, высказывали проблемы и обсуждали в свободной форме, пока не приходили к решению. Поэтому ретроспективы и занимали так много времени.
Послушав на Okademy всякое разное о ретроспективах, я первым делом предложил команде выработать правила проведения ретро, которые бы позволили бы сократить время не бесполезные споры. Большинство правил предложил не я, а другие члены команды. Среди предложенных правил были как стандартные, так и те, которые мне бы не пришли в голову:
По каждому из предложенных правил мы провели голосование большим пальцем:
По каждому из предложенных правил мы провели голосование большим пальцем:
Благодаря этому своду правил мы снизили время ретро до часа, хотя количество обсуждаемых проблем и принимаемых решений не изменилось. Более того правило поднятой руки мы стали использовать за пределами ретро.
Через некоторое время команды разработки переформировали и в новой команде оказалось три человека, которые не участвовали в обсуждении этих правил. Чтобы все приняли правила, мы заново устроили такое же обсуждение. Как бы старым членам команды не нравились выработанные совместно правила, не все они были приняты новыми участниками. Расширенное правило поднятой руки пришлось отбросить, да и стандартное правило перестало применяться — в новой команде оно просто оказалось не нужно.
Прежде чем проводить ретроспективы, договоритесь с командой о правилах. Важно, чтобы команда сама придумала и приняла эти правила (хотя некоторые правила может предлагать и сам скрам-мастер). Если просто прийти с готовыми правилами, то возникнет эффект “not invented here” — команда не будет принимать эти правил близко к сердцу. Любой новый участник команды должен принять правила. Если какие-то из них он не примет, обсудите эти правила снова. Если состав команды сильно меняется, проведите обсуждение правил с нуля.
Ретроспективу принято делить на следующие этапы:
Каждый этап можно проводить по разному: есть игровые активности, есть серьезные. Определите какие лучше подходят для вашей команды. Некоторые люди без вопросов соглашаются на любой формат ретро. Некоторым важно понимать зачем нужна каждая из активностей. Лучше объяснять назначение каждого этапа и активности на случай, если у вас есть люди второго типа.
Чтобы увеличить вовлеченность команды бывает полезно периодически менять активности. В этом помогают карты ретроспектив.
Подробнее про разные активности для каждого из этапов, вы можете посмотреть здесь.
Этот этап нужен, чтобы вовлечь команду в работу. Для зрелых команд его обычно опускают — все и так без проблем втягивается в обсуждения. Так как у нас большой опыт проведения ретро, то и от открытия не было особой пользы. Но если вы видите, что часть людей не принимают участия в обсуждениях, возможно вам как раз не хватает открытия.
На этапе сбора данных надо выяснить, что у команды болит.
Раньше для этого мы всегда применяли активность Glad, Sad, Mad: каждый участник пишет на стикерах, что за последний спринт его порадовало, расстроило или разозлило. Эта активность хороша тем, что включает эмоции (в отличие от простого деления на положительное и отрицательное) и поэтому выполняет также роль открытия: вовлекает всех в работу. Также подобные активности заставляют вспоминать не только о проблемах, но и о всех положительных моментах, произошедших за спринт. Это важно, чтобы закрепить эффективные практики. Кроме того то, что одни оценивает положительно, другие могут оценивать отрицательно. Важно обсуждать такие различия в оценке.
Дополнительно мы в течении спринта собирали проблемы на специальной доске баттхертов. Это помогает не забыть о них к моменту ретро. Также это даёт людям, не входящим в команду, возможность поделиться своей болью (для обсуждения таких стикеров нужно звать на ретро их авторов). Но в итоге у нас скопилось большое количество проблем, которые мы не успевали разобрать.
Здесь на помощь приходит ранжирование. Не обсуждайте все проблемы, о которых люди могут вспомнить. Ранжируйте их по степени важности и обсуждайте только наиболее приоритетные. Предварительно объедините похожие проблемы в кластеры. Для ранжирования хорошо подходит dot voting:
Проблемы, за которые никто не проголосовал, можно не обсуждать. Даже не надо переносить их на следующее ретро. Если это важная проблема, то о ней и так вспомнят. Если не вспомнят, значит и время на неё тратить не стоит.
После отбора важных проблем по каждой из них нужно сгенерировать решения. Если по одной проблеме есть несколько взаимоисключающих решений, то надо из них выбрать наиболее подходящее. Тут также поможет dot voting.
Важно, чтобы все принимаемые решения были SMART:
Несколько лет назад, когда мы только начинали проводить ретроспективы, некоторые agile коучи предлагали делить решения на две доски:
Не знаю, есть ли команды, у которых Decisions Board работает, но в моей практике этот подход всегда заканчивался так:
И это при том, что мы пытались большинство решений свести к SMART.
Помнить о такой куче мелких решений невозможно. Даже запомнить, что значит каждая из этих карточек, удается не всем. Проверить, есть ли польза от этих решений, нельзя. Можно сказать, что если вы в результате обсуждения повесили карточку на Decisions Board, то время на обсуждение потрачено зря.
Выработать SMART-решение для любой обсуждаемой проблемы сложно. Нам до сих пор это удается далеко не всегда. Тем не менее я могу предложить несколько идей для улучшения в этом плане:
Например, недавно мы нарисовали на канбан доске пустые квадраты, чтобы напоминать себе заранее пулить истории.
Через месяц оценим, помогло ли это. Если не поможет — напишем бота, который будет нас ругать, если мы незапулили тикет.
Закрытие необходимо в том числе для того, чтобы оценить, насколько хорошо прошло ретро и понять, в чем его можно улучшить.
Раньше мы не проводили закрытие. При этом я был уверен, что у нас в команде довольны нашим стандартным форматом ретро и негативно воспримут любые игровые активности. Если б мы не начали проводить закрытие, я бы так и не узнал, что некоторым членам команды это однообразие наскучило и они вовсе не прочь попробовать любые новые активности. С тех пор как мы стали проводить закрытие, я получаю полезную обратную связь почти на каждом ретро.
Обратная связь по ретроспективе нужна скрам-мастеру не только, чтобы улучшаться, но и чтобы не перегореть. Помните, что вы не железный, и вам хотя бы иногда нужна похвала за вашу тяжелую работу.
Несколько лет на своих ретро мы использовали только некоторые из стандартных практик. В других не видели смысла, ведь положительный результат был: процессы улучшались, проблемы решались. Все и так было хорошо. На самом деле нет:
- на ретро тратили по 2 часа и сильно выматывались
- обсуждения периодически уходили в затяжные бесполезные споры
- некоторые мелкие проблемы не успевали решить и постоянно переносили на следующее ретро
- отдельным членам команды надоедали ретроспективы из-за однообразия
Первую и вторую проблему мы считали данностью, что делать с третьей не понимали, а о последней я даже не знал.
Прошлой весной я сходил на Okademy от ScrumTrek. Это обширный курс, включающий в себя много полезного для скрам-мастера, но для меня самым полезным оказалась часть о том, как эффективнее проводить ретроспективы. Хочу рассказать, как это нам помогло.
Определитесь с правилами
Изначально у нас не было установлено формальных правил. Мы просто собирались, высказывали проблемы и обсуждали в свободной форме, пока не приходили к решению. Поэтому ретроспективы и занимали так много времени.
Послушав на Okademy всякое разное о ретроспективах, я первым делом предложил команде выработать правила проведения ретро, которые бы позволили бы сократить время не бесполезные споры. Большинство правил предложил не я, а другие члены команды. Среди предложенных правил были как стандартные, так и те, которые мне бы не пришли в голову:
- Лимит времени на ретро — час.
- Каждая активность на ретро также ограничена по времени.
- Правило поднятой руки (стандартное): если хочется перебить и что-то сказать, подними руку.
- Правило поднятой руки (расширенное): если несколько человек подняли руку, когда ты говоришь, значит ты ушел от темы и должен остановиться.
- Обозначаем проблему: во время любого обсуждения нужно четко обозначить проблему, чтобы не отклонятся от нее.
- Использовать parking lot: если при обсуждении всплывает не связанный с текущей темой важный вопрос, записываем его на стикер и клеим на специально отведенное место (parking lot), чтобы обсудить позже.
- Постороннее — за дверь: если человеку позвонили или кто-то зашел по срочному вопросу, надо просто выйти, чтобы не мешать остальной команде.
По каждому из предложенных правил мы провели голосование большим пальцем:
По каждому из предложенных правил мы провели голосование большим пальцем:
- Все показывают большим пальцем:
- вверх — за,
- вниз — против,
- горизонтально — все-равно.
- Если есть голоса за и нет голосов против — правило принимается.
- Если нет голосов за — правило не принимается.
- Если есть голоса как за, так и против — обсуждаем, пока не придем к консенсусу.
Благодаря этому своду правил мы снизили время ретро до часа, хотя количество обсуждаемых проблем и принимаемых решений не изменилось. Более того правило поднятой руки мы стали использовать за пределами ретро.
Через некоторое время команды разработки переформировали и в новой команде оказалось три человека, которые не участвовали в обсуждении этих правил. Чтобы все приняли правила, мы заново устроили такое же обсуждение. Как бы старым членам команды не нравились выработанные совместно правила, не все они были приняты новыми участниками. Расширенное правило поднятой руки пришлось отбросить, да и стандартное правило перестало применяться — в новой команде оно просто оказалось не нужно.
Прежде чем проводить ретроспективы, договоритесь с командой о правилах. Важно, чтобы команда сама придумала и приняла эти правила (хотя некоторые правила может предлагать и сам скрам-мастер). Если просто прийти с готовыми правилами, то возникнет эффект “not invented here” — команда не будет принимать эти правил близко к сердцу. Любой новый участник команды должен принять правила. Если какие-то из них он не примет, обсудите эти правила снова. Если состав команды сильно меняется, проведите обсуждение правил с нуля.
Структура ретроспективы
Ретроспективу принято делить на следующие этапы:
- Открытие
- Сбор данных
- Генерация идей
- Выбор решений
- Закрытие
Каждый этап можно проводить по разному: есть игровые активности, есть серьезные. Определите какие лучше подходят для вашей команды. Некоторые люди без вопросов соглашаются на любой формат ретро. Некоторым важно понимать зачем нужна каждая из активностей. Лучше объяснять назначение каждого этапа и активности на случай, если у вас есть люди второго типа.
Чтобы увеличить вовлеченность команды бывает полезно периодически менять активности. В этом помогают карты ретроспектив.
Подробнее про разные активности для каждого из этапов, вы можете посмотреть здесь.
Открытие
Этот этап нужен, чтобы вовлечь команду в работу. Для зрелых команд его обычно опускают — все и так без проблем втягивается в обсуждения. Так как у нас большой опыт проведения ретро, то и от открытия не было особой пользы. Но если вы видите, что часть людей не принимают участия в обсуждениях, возможно вам как раз не хватает открытия.
Сбор данных и ранжирование проблем
На этапе сбора данных надо выяснить, что у команды болит.
Раньше для этого мы всегда применяли активность Glad, Sad, Mad: каждый участник пишет на стикерах, что за последний спринт его порадовало, расстроило или разозлило. Эта активность хороша тем, что включает эмоции (в отличие от простого деления на положительное и отрицательное) и поэтому выполняет также роль открытия: вовлекает всех в работу. Также подобные активности заставляют вспоминать не только о проблемах, но и о всех положительных моментах, произошедших за спринт. Это важно, чтобы закрепить эффективные практики. Кроме того то, что одни оценивает положительно, другие могут оценивать отрицательно. Важно обсуждать такие различия в оценке.
Дополнительно мы в течении спринта собирали проблемы на специальной доске баттхертов. Это помогает не забыть о них к моменту ретро. Также это даёт людям, не входящим в команду, возможность поделиться своей болью (для обсуждения таких стикеров нужно звать на ретро их авторов). Но в итоге у нас скопилось большое количество проблем, которые мы не успевали разобрать.
Здесь на помощь приходит ранжирование. Не обсуждайте все проблемы, о которых люди могут вспомнить. Ранжируйте их по степени важности и обсуждайте только наиболее приоритетные. Предварительно объедините похожие проблемы в кластеры. Для ранжирования хорошо подходит dot voting:
- Каждый участник может поставить n точек (обычно 2-3) рядом с кластером, с важными для него проблемами
- Можно поставить все точки в один кластер или распределить их между разными
- Чем больше точек поставили рядом с кластером, тем выше у него приоритет
Проблемы, за которые никто не проголосовал, можно не обсуждать. Даже не надо переносить их на следующее ретро. Если это важная проблема, то о ней и так вспомнят. Если не вспомнят, значит и время на неё тратить не стоит.
Генерация идей и выбор решений
После отбора важных проблем по каждой из них нужно сгенерировать решения. Если по одной проблеме есть несколько взаимоисключающих решений, то надо из них выбрать наиболее подходящее. Тут также поможет dot voting.
Важно, чтобы все принимаемые решения были SMART:
- S — Specific — точными и конкретными
- M — Measurable — измеримыми (должна быть возможность ответить на вопрос помогло решение или нет)
- A — Achievable — достижимыми
- R — Relevant — релевантными (в пылу обсуждений не забудьте, какую проблему решаете)
- T — Time bound/framed — с ограниченным сроком реализации (желательно, чтобы их можно было закончить до следующего ретро)
Несколько лет назад, когда мы только начинали проводить ретроспективы, некоторые agile коучи предлагали делить решения на две доски:
- Actions Board — SMART-решения
- Decisions Board — решения, у которых нет ограничения по времени (всевозможные правила и изменения в процессе)
Не знаю, есть ли команды, у которых Decisions Board работает, но в моей практике этот подход всегда заканчивался так:
И это при том, что мы пытались большинство решений свести к SMART.
Помнить о такой куче мелких решений невозможно. Даже запомнить, что значит каждая из этих карточек, удается не всем. Проверить, есть ли польза от этих решений, нельзя. Можно сказать, что если вы в результате обсуждения повесили карточку на Decisions Board, то время на обсуждение потрачено зря.
Выработать SMART-решение для любой обсуждаемой проблемы сложно. Нам до сих пор это удается далеко не всегда. Тем не менее я могу предложить несколько идей для улучшения в этом плане:
- Оставьте себе только два варианта — либо придете к SMART-решению, либо решения для проблемы у вас нет. Пока оставляете себе возможность принять не SMART-решение, вы будете их принимать. Если используете Decisions board, откажитесь от него. Совсем. Полумеры здесь не работают.
- Обязательно придумайте, как проверить, принесло ли ваше решение пользу. Если не можете придумать количественную метрику, хотя бы спросите у людей, стало ли лучше.
- Если решение — изменение в ваших процессах, то в рамках SMART-решения надо зафиксировать новое правило так, чтобы его сложно было забыть:
- измените вашу физическую доску с тикетами, чтобы она фиксировала это правило,
- внесите его в систему багтрекинга
- или напишите бота, который будет напоминать, когда вы отклоняетесь от нового процесса.
Например, недавно мы нарисовали на канбан доске пустые квадраты, чтобы напоминать себе заранее пулить истории.
Через месяц оценим, помогло ли это. Если не поможет — напишем бота, который будет нас ругать, если мы незапулили тикет.
Закрытие
Закрытие необходимо в том числе для того, чтобы оценить, насколько хорошо прошло ретро и понять, в чем его можно улучшить.
Раньше мы не проводили закрытие. При этом я был уверен, что у нас в команде довольны нашим стандартным форматом ретро и негативно воспримут любые игровые активности. Если б мы не начали проводить закрытие, я бы так и не узнал, что некоторым членам команды это однообразие наскучило и они вовсе не прочь попробовать любые новые активности. С тех пор как мы стали проводить закрытие, я получаю полезную обратную связь почти на каждом ретро.
Обратная связь по ретроспективе нужна скрам-мастеру не только, чтобы улучшаться, но и чтобы не перегореть. Помните, что вы не железный, и вам хотя бы иногда нужна похвала за вашу тяжелую работу.