Коллеги, всем привет!

Наверняка многие, кто слышал слова «ретроспектива», «scrum» и «agile» и сталкивался с ними на практике, также слышали слова «пустая трата времени», «разговоры ни о чем», «лучше б заняться чем-то полезным»… а может еще и другие уже менее печатные выражения:)

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

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

На словах получается идеальная картина, которая должна приводить команды к улучшению производительности, эффективности и прочим красивым словам, которые радуют слух консультантов по трансформации и менеджеров.

Но тогда почему к этим теоретически очень полезным встречам бывает такое негативное отношение?

Можно, конечно, предположить, что так думают только консерваторы-социопаты, которые против любых улучшений и совместных встреч, но… но скорее всего, дело все-таки в чем-то другом:)

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

1. Нет четкого понимания, зачем нужна ретроспектива и какая ее цель.

2. Ретроспективы, которые проходят в команде, ничего не меняют в лучшую сторону – т.е. собрались, проговорили 2-3ч, и после этого все остается также, как было.

3. Ретроспектива занимает много времени, и это время не учитывается в проектных планах и roadmap-ах, и потом придется «дорабатывать» потраченное на ретроспективе время, чтоб успеть выполнить все запланированное (иначе придет большой начальник и.. далее по списку, как говориться).

4. Участники считают, что все уже и так работает хорошо, и «лучшее – враг хорошего».

Как исправить причины 1 и 3 понятно и очевидно, с 4ой причиной несколько сложнее, однако тоже вполне решаемо (об этом чуть позже). Но все эти меры будут бесполезны, если не устранить причину 2 – ретроспективы будут оставаться встречами вида «поболтали-разошлись-ничего не поменялось». Давайте посмотрим, что можно сделать с этой проблемой.

Вариант 1 (совсем очевидный).

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

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

Хорошая практика - по итогам обсуждения формулировать конкретные задачи и явно договариваться о том, кто их будет делать. Эти задачи можно заносить в backlog команды или на отдельную «доску», фиксировать ответственных за их выполнение, и регулярно проверять статус выполнения.

Кстати, часто возникает соблазн назначать ответственным за выполнение подобных задач кого-то из менеджеров или scrum-мастера – они ведь должны устранять препятствия, вот пусть и устраняют:)

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

Вариант 2 (чуть менее очевидный).

Нередко бывает так, что на ретроспективе команда выявляет какую-то проблему и начинает сразу придумывать для нее решения, упустив важный этап – поиск и анализ причины проблемы.

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

В результате команда вырабатывает план действий, который решает гипотетическую «болячку», но ничего не делает с реальной (просто потому, что реальной причины никто не выявил).

В итоге ситуация не меняется, проблема и ее первопричина никуда не уходят, и у команды складывается ощущение, что ретроспективы в целом бесполезны и не решают никаких проблем (почему-то).  

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

Вариант 3 (уже чуть более продвинутый).

Как уже говорили ранее, ретроспектива – это обсуждение проблем и способов их решений/улучшений. Если есть проблема с эффективностью ретроспективы, то почему бы тогда не провести ретроспективу про ретроспективу, где обсудить вопросы:

1. Как участники команды видят идеальную для них ретроспективу?

2. Чем текущие ретроспективы отличаются от идеальных?

3. Что нужно изменить в текущем варианте проведения ретроспективы, чтоб приблизиться к желаемому результату?

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

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

Примечание. Одним из вариантов «ретроспективы про ретроспективу» может быть ретроспектива формата «Исследователь-Заключенный-Покупатель (турист)». Не буду подробно останавливаться на нем, т.к. в интернете куча статей, где этот формат описан очень детально.

Вариант 4 (немножко коучинговый). 

Можно много рассказывать команде о пользе ретроспективы, перепробовать все форматы с retromat.org-а и подобных ресурсов (рисуем «кораблики», «машинки», «домики поросят» и прочие прикольные структуры, стимулирующие мышление), но ничего из этого не будет работать, если:

1. Команда будет выносить на обсуждение темы, которые на самом деле не являются значимыми и важными.

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

3. Команда не вкладывается в обсуждение и поиск решений, ожидая, что эти решения будут предложены кем-то другим (снова менеджером, scrum-мастером и т.п.).

Чтобы избежать подобной ситуации, в начале работы с командой необходимо честно обсудить эти моменты и объяснить следующее:

1. Никто лучше команды не знает все детали рабочих процессов команды и связанные с ними проблемы.

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

3. Человек в принципе устроен так, что с большим удовольствием внедряет в жизнь то, что придумал сам, и ему самому кажется ценным и важным, чем то, что ему предлагают/насаждают другие.

4. Если тебе что-то не нравится, то ничего не изменится, если с этим ничего не делать, и никто об этом не узнает, если об этом никому не говорить.

Не факт, что это обсуждение сразу принесет результат. НО! если вы дальше будете наблюдать подобные признаки у команды, вы сможете вернуться к этому разговору и вашим договоренностям, после чего разобрать уже конкретные примеры поведения и то, как они влияют на эффективность ретроспектив.

Вариант 5 (когда все хорошо, и никто не хочет ничего менять).

В этой ситуации можно сделать следующее:

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

2. Предложить провести самооценку по шкале 1 до 10, где 10 – команда мечты по совокупности таких параметров как эффективность, сложность решаемых задач, отлаженность процессов и т.д. и т.п. Если оценка будет не 10 – обсудить, что нужно сделать, чтоб прийти к 10ке.

3. Предложить команде поставить себе амбициозную цель на предстоящий период, а на следующей ретроспективе оценить результат. Если цель не будет достигнута – провести анализ того, что не позволило ее достичь. Если достигнута – проанализировать, что позволило ее достичь, после чего найти новую амбициозную цель. 

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

5. Если вы испробовали все предыдущие идеи, и все равно оказывается, что команда действительно идеальна, и лучше быть не может, то просто порадоваться, что вы молодцы и разойтись до следующей ретроспективы:)

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

Вот собственно и все на сегодня. Надеюсь, эти идеи помогут сделать ваши ретроспективы более эффективными и интересными.