Блог Co-actors

Плохие решения с ретроспективы

Мы с вами знаем, что хорошее ретро заканчивается планом действий, но не каждый план хорош.
Сегодня я хочу рассказать о примерах плохих планов и как их исправить/избежать.
100500 пунктов улучшений
Проблема: Люди - оптимисты, они дают слишком оптимистичные прогнозы по задачам и на ретро любят набрать с три короба и составить масштабный план из 18ти пунктов. Но потом наступает рабочая неделя, и приходят осознание, что это всё нужно ДЕЛАТЬ. А времени совсем нет, поэтому договоренности продалбываются.
Как помочь: Вместо того чтобы поверхностно разобрать на ретро миллион проблем и составить объемный план, сосредоточитесь на самом важном. Возьмите с ретроспективы 2-3 пункта плана, но обязательно сделайте.

Всё пункты делает тимлид/один человек
Проблема: Часто ретро заканчивается тем, что все пункты плана адресованы одному человеку. Чаще всего это тимлид, как самый компетентный и инициативный. «Наверное я действительно единственный, кто может это сделать.» - устало говорит тимлид.
Как помочь: Объяснить членам команды, что взять пункт с ретро не значит сделать его самому от и до. Да, только тимлид может поговорить с директором про новый софт, но любой член команды может найти время в календаре директора, поставить встречу и подготовить аргументацию про то, чем команде поможет новый софт.
Второй вариант – начать делать пункты плана парами. Тимлид со Светой поговорят с директором, тимлид с Геной организуют встречу по обсуждению архитектуры итп. Таким образом мы простимулируем общение, передачу знаний в команде и вовлеченность людей в изменения.

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

Все пункты плана «вне зоны нашего контроля»
Проблема: Есть такие команды - жалобщики. На каждой ретроспективе они находят кучу виноватых вокруг себя. «Ресурсов недостаточно, соседняя команда козлы, менеджер не дает обратной связи, аналитики пишут плохие требования, итп»
План таких команд обычно выглядит как «Передать список жалоб руководству». А сами они даже не пытаются что то менять: «Проблема не на нашей стороне!»
Как помочь: Нарисовать 2 круга (как на картинке) и подумать что мы (команда) можем сделать чтобы повлиять на проблему, даже если она вне зоны нашего контроля. Результаты записать в план.

Решения плана супер общие «давайте будем активнее и внимательнее»
Проблема: Это решения за всё хорошее и против всего плохого. «Давайте писать без багов, лучше тестировать и прорабатывать задачи, задавать больше вопросов РО, просить помощи друг у друга итп Кто ответственный? Вся команда!»
Проблема таких решений в том, что их невозможно выполнить, потому что они слишком общие, очевидные и неизмеримые.
Как помочь: Когда команда предлагает «лучше тестировать» попытайтесь отжать у неё что именно мы будем делать? Отправим Васю и Ксюшу на курс Agile Testing? Начнём писать новые виды тестов? Напишем чекист самостоятельной проверки для разработчика перед тем как передать задачу QA? Сходим к соседней команде и узнаем какие практики используют они? Конкретика - творит волшебство!

Александра Баптизманская
#ретро_четверг