Что не так с нашими ретроспективами?

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

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

И так. Как же проводить ретроспективы?

Базовые материалы по СКРАМ говорят, что после спринт ревью митинга (или проще говоря демонстрации результатов спринта) команда собирается на ретроспективный митинг, где обсуждаются следующие вопросы:

• Что в ходе спринта было хорошего?
• Что было не очень хорошо?
• Что можно улучшить в следующем спринте?

Это же касается ретроспективы по окончанию релиза или другой фазы проекта. Для простоты я рассматриваю ретроспективы, привязанные к окончанию спринта.

Команды, которые я видел, при попытке проведения ретроспективы по вышеописанной структуре, выписывают множество жалоб на что-то, что было по их мнению не очень хорошо; генерируют множество идей и на этом расходятся. Иногда в ходе выписки проблем ищутся виновные (что может показаться весьма логичным шагом), и разговор таким образом переходит на личности.

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

А что если ничего не будет сделано? В следующий раз команда cгенерирует очередной список, и так до тех пор, пока практика ретроспектив справедливо (для такого типа ретроспектив) не будет объявлена бесполезной.

Что же здесь не так?

Я думаю (и надеюсь это уже стало очевидно), что при таком подходе явно не хватает как минимум следующих вещей:

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

А что не так в ваших ретроспективах?

Обсуждения ретроспектив в группе дискуссий Agile Ukraine.

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

• Что если не всем членам команды комфортно на ретроспективе?
• Есть ли рекомендуемая структура ретроспектив, с которой стоит начать?
• Наши ретроспективы заканчиваются ничем, есть ли подходы получить план действий на выходе?
• Стоит ли привлекать представителей заказчиков на ретроспективы?
• Похоже нашему СкрамМастеру самому есть что сказать как участнику проекта. Кто в этом случае должен проводить ретроспективы?
  

Алексей Кривицкий

Материалы по ретроспективам:

• Статья Rachel Davies
  “How To: Live and Learn with Retrospectives”
• Статья Boris Gloger’s blog and presentation
  “Heartbeat Retrospectives”
• Книга Norman Kerth
  ”Project Retrospectives: a handbook for team reviews”
• Книга Esther Derby, Diana Larsen
  ”Agile Retrospectives: Making Good Teams Great”
• Книга Jean Tabaka
  “Collaboration Explained”