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

Ретроспектива принадлежит команде.

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

Ретроспектива принадлежит команде и точка – это инструмент улучшения командного взаимодействия и улучшения самой команды. Значит, на ней должны присутствовать только люди «своего круга» и именно те, кто будет потом отвечать за реализацию идей по улучшению работы команды. Более того, одно из основных правил ретроспективы – это «безопасность». Т.е. все участники должны чувствовать себя безопасно, чтобы не боятся высказывать свои мысли и признавать свои ошибки. Если команда чувствует себя не комфортно в присутствии менеджера проекта или даже Владельца Продукта – не приглашайте их. Лучше уже после ретроспективы связаться с ними и согласовать с ними план действий, который придумала команда.

Не превращайте ретроспективу в жалобную книгу

Некоторые команды собираются на ретроспективу только для того, чтобы обсудить, что было плохо. Люди всегда найдут, на что пожаловаться, и чем моложе и больше ваша команда, тем длиннее будет список. Как показывает практика, не все из того, что записывается, вообще является проблемой или требует улучшения. С другой стороны, если проблем действительно много, то мы собрались не для того, чтобы их все перечислять, а для того, чтобы адаптировать нашу работу к реалиям жизни. Мы должны найти несколько ключевых причин и выработать план действий по их устранению. Это и будет inspect and adapt и это главная цель ретроспективы.

Выбирайте только одну цель

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

Лучше выбрать одну цель и разработать качественный план действий для ее достижения. Собственно понимание, что нам нужно делать, и является результатом ретроспективы. А составление списка – это лишь первый шаг.

Будьте последовательны и доводите начатое до конца

Если на каждой ретроспективе вы ищите «новые» улучшения, то что же вы делаете со старыми? Несколько раз видел, что команды уже в середине спринта бросали практику, которую они решили ввести на прошлой ретроспективе. Это может быть peer review или парное программирование или написание тестов – что угодно, главное чтобы команда нашла в себе силы и мужество продолжать до конца итерации и уже на следующей ретроспективе подвести итоги.

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

Проводите ретроспективу активно

Если вы проводите ретроспективу однообразно, сидя за столом, и всего-лишь высказываясь на тему «что было хорошо, что плохо, что нужно сделать лучше», то в скором времени она может выродиться в «очередное собрание», и члены команды предпочтут играть в Bullshit bingo, а не участвовать своими мыслями и идеями по улучшению. Собственно и улучшений после этого не будет. Эдак можно вообще дойти до того, что каждый письмом вышлет свои замечания, а ПМ потом вышлет обратно план действий по самому «популярному» предложению об изменениях.

Задача участников заранее правильно настроиться, а того, кто ведет ретроспективу,  — сделать так, чтобы все участвовали. Можно использовать разные подходу к сбору идей по улучшению и к тому, как выработать план действий (о них отдельной статьей). Любые виды активных действий делают ретроспективу гораздо лучше.

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

Несколько полезных мыслей о Ретроспективах
  • Елена

    Однажды услышала про книгу, которая посвящена ретроспективам: как их проводить, чтобы было всегда по-новому, чтобы люди не «закисали». В момент прослушивания этого доклада запись о книге не сделала. Помню только пару моментов: книгу написала женщина, и в названии есть слово Retrospective. Что за книга, кто автор? Не подскажете?

  • yevgrashyn

    Возможно вы имеете в виду книгу «Agile Retrospectives: Making Good Teams Great» by Esther Derby and Diana Larsen.
    Вот ссылка на амазоне http://www.amazon.com/Agile-Retrospectives-Maki

  • Svetlana Kolupaeva

    Agile retorspectives: making good teams great

    Хорошая книга. Эта часовая презентация в целом транслирует основные идеи: http://video.google.com/videoplay?docid=-791040

  • Елена Володина

    Спасибо за ссылки, скорее всего именно эта книга 🙂

  • Pingback: Ретроспективы для распределенных команд | The Improved Methods()