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

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

 

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

 

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

 

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

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

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

 

Для простоты я рассматриваю ретроспективы, привязанные к окончанию спринта.

При попытке проведения ретроспективы по вышеописанной структуре, многие команды:

  • Выписывают множество жалоб на что-то, что было, по их мнению, не очень хорошо;
  • Генерируют множество идей;
  • На этом расходятся.

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

 

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

 

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

 

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

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

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

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

Советую почитать вам следующие материалы по ретроспективам:

 

Статья Rachel Davies

“How To: Live and Learn with Retrospectives”

  

Книга Norman Kerth

”Project Retrospectives: a handbook for team reviews”

 

Книга Esther Derby, Diana Larsen

”Agile Retrospectives: Making Good Teams Great”

 

Книга Jean Tabaka

“Collaboration Explained”

Статья от 02/2008


Write a comment

Comments: 0