Вокруг вы найдёте множество советов, как организовать хорошую ретроспективу, что в неё включить для большей продуктивности и вовлечённости. Это, конечно, полезно, но также важно узнать о том, чего на ретро лучше избегать.
В этой статье мы собрали популярные антипаттерны — признаки неэффективной ретроспективы — и способы от них избавиться.
Нереалистичные ретроспективы
Команда придумывает для себя слишком амбициозные задачи. Этот список действий никак не выполнить к концу следующего спринта, а команда просто не задумывается об этом на момент составления. Это приводит или к разочарованию, или к халатности, потому что задачи не выполняются, а список "to do" после каждой ретроспективы пополняется.
Решение: начинайте с небольших изменений, которые не обременят команду. Шаг за шагом, от одной задачи к другой:
- выберите для ретроспективы одну проблему,
- проанализируйте её (методом «5Почему» и другими),
- создайте список изменений только по этой проблеме,
- оцените свои силы, когда будете формировать задачи.
Если команда работает с таким подходом, особенно в начале своего пути, шансы на успех выше.
Безрезультатные ретроспективы
У команды есть идеи, что нужно улучшить, но раньше она сталкивалась с трудностями в их реализации. В итоге у всех сложилось мнение, что уже ничего не изменить: нет поддержки ни сверху, ни среди коллег, ни в своей команде.
В результате ретроспектива превращается в плановое событие на полчаса, где участники обсуждают, как идут дела, и логически ничем это не заканчивают.
Решение: scrum-мастер должен добиться того, чтобы команда видела ценность в ретроспективе. Например, организовать семинар с командой, пригласить agile-коуча, добиться разрешения на реализацию улучшений у руководства (и объяснить «верхам» важность ретроспективы).
Как и в предыдущем пункте, нужно идти шаг за шагом. Большинство вещей, которые можно поменять, не выходят за пределы команды. Это позволяет scrum-мастеру создать ситуацию успеха малыми силами. Дайте команде увидеть улучшения, чтобы участники поняли важность этого события.
Публичные ретроспективы
На ретроспективе команда откровенно и искренне обсуждает друг с другом проблемы, с которыми участники встретились за спринт. Иногда у руководства возникают «светлые» идеи: или присутствовать на ретро, или записывать её на видео для отчёта или примера.
Если вариант «примера» для более опытной и открытой команды имеет место быть, то постоянная демонстрация ретроспективы другим людям превратит событие в театральную постановку. Команда не сможет достаточно заняться самой ретроспективой, а станет думать о том, как это видят другие. Никто не будет говорить откровенно о проблемах, ведь даже для того, чтобы рассказать о них внутри команды, нужно время на сплочение.
Решение: scrum-мастер должен заботиться, чтобы ретроспектива была самым безопасным и комфортным событием для команды. В ScrumGuide определены участники ретро: scrum-мастер и команда, — не нарушайте это правило. Если организация хочет получать больше информации, давайте её в другом виде (разговор после ретро; отчёт с обсуждением; отдельная встреча). Для обмена опытом не используйте записи, используйте живое общение: создайте сообщество практиков или дополнительные слёты, например, раз в несколько месяцев.
Абстрактная ретроспектива
Иногда команда старается отыскать проблемы и поставить себе цели, но это выходит чересчур абстрактно. Если в конце ретро в списке задач такие вещи, как «улучшить общение», «сокращать больше технического долга», «чаще делать рефакторинг», «писать код качественнее»... у вас проблемы. Это не конкретные действия, а всё ещё проблемы. После такой ретроспективы команда так и не знает, что с этим делать.
Решение: работайте с задачами ретроспективы так же, как с задачами из бэклога. Они должны быть проверяемыми, конкретными, измеримыми и т. д. Для каждой проблемы подберите реальное действие.
Хотим улучшить общение? Организуем совместный перекур в 15:00, где будем разгадывать загадки или решать логические задачки; будем заказывать пиццу по пятницам за полчаса до конца рабочего дня; соберёмся на отдых в выходной, введём парные проекты...
Сокращаем технический долг? Выделяем отдельные часы на такие-то задачи, назначаем ответственного, не ленимся покрывать код тестами...
Безответственная ретроспектива
Команда хорошо справляется с тем, чтобы отыскать проблемы, посетовать о том, что всё плохо, но никто из разработчиков не хочет отвечать за улучшение дел. Тогда ретроспектива только ослабит команду, превратив событие во встречу бабушек у подъезда. Если ретроспектива проходит как сбор проблем, но не как поиск решения, то это плохая ретроспектива. Scrum-мастер не может (и не должен) исправлять всё, что накидывает команда.
Решение: scrum-мастер собирает проблемы, а затем задаёт простой вопрос: «Что будете с этим делать?» Заметьте, глагол должен стоять во втором лице, чтобы команда поняла, что это забота разработчиков, и если ничего не делать, ничего не изменится.
Обычно участники попытаются определить список действий, но может быть такое, что команда продолжит жаловаться, что ничего не может сделать. Помните о подходое «шаг за шагом», будьте изобретательны и помогите команде совершенствоваться. Это трудная работа для scrum-мастера, но это того стоит. И не забудьте назначать ответственного за каждую задачу.
Непроверенная ретроспектива
Команда принимает список действий, берёт на себя ответственность, но эти задачи никогда не проверяются. Они не оцениваются и не анализируются, можно даже забыть, было ли что-то сделано.
Решение: каждое ретро должно начинаться с проверки прошлых договорённостей. Для этого можно придумать собственные критерии удовлетворённости или успешного выполнения. Для нерешённых задач придумывается новое решение, от них не отказываются, как от безнадёжных.
Мы рассмотрели частые проблемы, которые закрадываются в такое событие, как ретроспектива. Надеемся, эта статья поможет вам вывести свои ретро на новый уровень. А с какими частыми проблемами на ретро сталкиваетесь вы?
