что такое ретроспектива в scrum
Ретроспектива в Scrum — как проводить и зачем вообще ретроспектива нужна в Scrum?
Ретроспектива нужна, в первую очередь, для команды. И проводят её для достижения нескольких целей:
Найти «слабые места», обозначить недостатки в процессах работы команды
Запланировать улучшения по процессу
Не давать конфликтам внутри команды перерастать во что-то большее
Расслабиться и порефлексировать 🙂
Проводить рекомендуется в конце каждого спринта. Также можно проводить в конце проекта (обычно ретроспектива по всему проекту занимает целый день или даже больше, в зависимости от размера команды). А ещё лучше иногда проводить ретроспективу ретроспектив, чтобы понять, как можно улучшить само мероприятие.
Стандартно ретроспективу можно разбить на несколько этапов:
Открытие: напомнить команде, почему мы все сегодня собрались и как мы проведем выделенное под ретроспективу время
Проверка гипотез: обзор результатов запланированных улучшений с прошлой ретроспективы
Сбор данных: на этом этапе определяются основные несовершенства
Генерация идей: обсуждение путей улучшения процессов
Определение экспериментов: выбор конкретных мероприятий для следующего спринта, установка метрик для определения эффективности изменений и назначение ответственных за эти эксперименты
Закрытие: резюмируем идеи, кратко проводим ретроспективу спринта
Про ретроспективы и способы их проведения Марк Лоффлер написал крутую книгу «Ретроспектива в Agile». Мы прочитали сами и вам тоже советуем!
5 способов борьбы с унылыми ретроспективами
Коллеги, всем привет!
Наверняка многие, кто слышал слова «ретроспектива», «scrum» и «agile» и сталкивался с ними на практике, также слышали слова «пустая трата времени», «разговоры ни о чем», «лучше б заняться чем-то полезным»… а может еще и другие уже менее печатные выражения:)
В сегодняшней статье хотелось бы поделиться идеями о том, почему ретроспектива может превращаться в унылое для команды мероприятие, и как можно исправить эту ситуацию.
Для начала давайте вспомним, что ретроспектива – это периодическая встреча, на которой команда собирается вместе, анализирует прошедший спринт (или просто какой-то период совместной работы), смотрит, все ли было ОК с точки зрения взаимодействия, процессов, коммуникаций и т.д. и т.п. И если в итоге что-то было не ОК, то все вместе решают, какие изменения необходимы, чтоб все стало ОК.
На словах получается идеальная картина, которая должна приводить команды к улучшению производительности, эффективности и прочим красивым словам, которые радуют слух консультантов по трансформации и менеджеров.
Но тогда почему к этим теоретически очень полезным встречам бывает такое негативное отношение?
Можно, конечно, предположить, что так думают только консерваторы-социопаты, которые против любых улучшений и совместных встреч, но… но скорее всего, дело все-таки в чем-то другом:)
Взрослые люди не любят делать то, в чем не видят смысла, и лично я на практике чаще всего сталкивался со следующими причинами подобного отношения к ретроспективам:
Нет четкого понимания, зачем нужна ретроспектива и какая ее цель.
Ретроспективы, которые проходят в команде, ничего не меняют в лучшую сторону – т.е. собрались, проговорили 2-3ч, и после этого все остается также, как было.
Ретроспектива занимает много времени, и это время не учитывается в проектных планах и roadmap-ах, и потом придется «дорабатывать» потраченное на ретроспективе время, чтоб успеть выполнить все запланированное (иначе придет большой начальник и.. далее по списку, как говориться).
Участники считают, что все уже и так работает хорошо, и «лучшее – враг хорошего».
Как исправить причины 1 и 3 понятно и очевидно, с 4ой причиной несколько сложнее, однако тоже вполне решаемо (об этом чуть позже). Но все эти меры будут бесполезны, если не устранить причину 2 – ретроспективы будут оставаться встречами вида «поболтали-разошлись-ничего не поменялось». Давайте посмотрим, что можно сделать с этой проблемой.
Вариант 1 (совсем очевидный).
Если вы несколько часов обсуждаете что-то, то результатом этого обсуждение должно быть не просто просветленное сознание участников из серии «ну мы раньше делали плохо, но не знали этого, а теперь мы знаем и будем делать хорошо», а конкретный список действий и ответственных за их выполнение. Если этого списка нет, то с высокой долей вероятности через пару дней после встречи все забудут про то, о чем говорили, и по итогам встречи ничего не изменится.
Кстати, часто возникает соблазн назначать ответственным за выполнение подобных задач кого-то из менеджеров или scrum-мастера – они ведь должны устранять препятствия, вот пусть и устраняют:)
Звучит заманчиво и даже в чем-то логично, но в этом случае у команды не возникает чувство собственной ответственности за результат изменения. И если вдруг задача окажется невыполненной, то легко будет сказать, что виноват кто-то другой, и продолжать дальше ничего не менять. А один из принципов эффективной ретроспективы – команда сама должна взять ответственность за то, чтоб изменить свои процессы.
Вариант 2 (чуть менее очевидный).
Нередко бывает так, что на ретроспективе команда выявляет какую-то проблему и начинает сразу придумывать для нее решения, упустив важный этап – поиск и анализ причины проблемы.
А еще бывает так, что кто-то из участников говорит что-то типа «Наверное, так происходит потому что…», и дальше выдвигается какое-то предположение, которое никто не проверял, но все принимают на веру, т.к. это проще и быстрее. После чего все начинают придумывать варианты, как побороть эту предполагаемую причину.
В результате команда вырабатывает план действий, который решает гипотетическую «болячку», но ничего не делает с реальной (просто потому, что реальной причины никто не выявил).
В итоге ситуация не меняется, проблема и ее первопричина никуда не уходят, и у команды складывается ощущение, что ретроспективы в целом бесполезны и не решают никаких проблем (почему-то).
Выход простой. Продумать сценарий ретроспективы таким образом, чтоб он обязательно включал этап поиска причин проблем и обсуждение того, как предложенные варианты решения повлияют на эти причины. Тут могут помочь вопросы вопросы вида «Почему мы считаем, что это решение должно помочь», «На какую причину проблемы это решение должно повлиять и каким образом», «Почему мы не делали этого раньше» и т.п.
Вариант 3 (уже чуть более продвинутый).
Как уже говорили ранее, ретроспектива – это обсуждение проблем и способов их решений/улучшений. Если есть проблема с эффективностью ретроспективы, то почему бы тогда не провести ретроспективу про ретроспективу, где обсудить вопросы:
Как участники команды видят идеальную для них ретроспективу?
Чем текущие ретроспективы отличаются от идеальных?
Что нужно изменить в текущем варианте проведения ретроспективы, чтоб приблизиться к желаемому результату?
После обсуждения необходимо зафиксировать план действий, задачи и ответственных. Плюс этого варианта в том, что здесь команда сама может честно признать, что именно ее не устраивает, и взять на себя ответственность за необходимые изменения.
Если после этого ситуация не изменится, и команда и дальше будет считать ретроспективу пустой тратой времени, то можно задать команде прямой вопрос о том, почему не работают те идеи по улучшению, которые сами участники команды предложили, и что они сделали, чтоб эта ситуация изменилась.
Примечание. Одним из вариантов «ретроспективы про ретроспективу» может быть ретроспектива формата «Исследователь-Заключенный-Покупатель (турист)». Не буду подробно останавливаться на нем, т.к. в интернете куча статей, где этот формат описан очень детально.
Вариант 4 (немножко коучинговый).
Можно много рассказывать команде о пользе ретроспективы, перепробовать все форматы с retromat.org-а и подобных ресурсов (рисуем «кораблики», «машинки», «домики поросят» и прочие прикольные структуры, стимулирующие мышление), но ничего из этого не будет работать, если:
Команда будет выносить на обсуждение темы, которые на самом деле не являются значимыми и важными.
Команда будет считать, что за эффективность ретроспективы отвечает кто-то другой (менеджер, scrum-мастер или кто-то еще), чья обязанность сделать команду эффективнее, но ни в коем случае не сама команда.
Команда не вкладывается в обсуждение и поиск решений, ожидая, что эти решения будут предложены кем-то другим (снова менеджером, scrum-мастером и т.п.).
Чтобы избежать подобной ситуации, в начале работы с командой необходимо честно обсудить эти моменты и объяснить следующее:
Никто лучше команды не знает все детали рабочих процессов команды и связанные с ними проблемы.
Человек в принципе устроен так, что с большим удовольствием внедряет в жизнь то, что придумал сам, и ему самому кажется ценным и важным, чем то, что ему предлагают/насаждают другие.
Если тебе что-то не нравится, то ничего не изменится, если с этим ничего не делать, и никто об этом не узнает, если об этом никому не говорить.
Не факт, что это обсуждение сразу принесет результат. НО! если вы дальше будете наблюдать подобные признаки у команды, вы сможете вернуться к этому разговору и вашим договоренностям, после чего разобрать уже конкретные примеры поведения и то, как они влияют на эффективность ретроспектив.
Вариант 5 (когда все хорошо, и никто не хочет ничего менять).
В этой ситуации можно сделать следующее:
Внимательно наблюдать за командой и возвращать им примеры ситуаций, когда не все так хорошо, как им кажется.
Предложить провести самооценку по шкале 1 до 10, где 10 – команда мечты по совокупности таких параметров как эффективность, сложность решаемых задач, отлаженность процессов и т.д. и т.п. Если оценка будет не 10 – обсудить, что нужно сделать, чтоб прийти к 10ке.
Предложить команде поставить себе амбициозную цель на предстоящий период, а на следующей ретроспективе оценить результат. Если цель не будет достигнута – провести анализ того, что не позволило ее достичь. Если достигнута – проанализировать, что позволило ее достичь, после чего найти новую амбициозную цель.
Если вы испробовали все предыдущие идеи, и все равно оказывается, что команда действительно идеальна, и лучше быть не может, то просто порадоваться, что вы молодцы и разойтись до следующей ретроспективы:)
Если без шуток, то список вариантов можно предложить и дальше, но все они будут сводиться к тому, чтоб показать команде скрытые или неявные зоны роста, договориться о целях и шагах по развитию в этих зонах, а на последующих ретроспективах уже анализировать результаты и динамику продвижения к поставленным целям.
Вот собственно и все на сегодня. Надеюсь, эти идеи помогут сделать ваши ретроспективы более эффективными и интересными.
Ретроспектива Спринта (Sprint Retrospective)
Ретроспектива Спринта — это одно из 5 Мероприятий Скрама, дающее Скрам-команде возможность провести инспекцию своей работы и создать план улучшений на следующий Спринт. Ретроспектива проходит после Обзора Спринта, перед Планированием следующего спринта. В нем принимает участие вся Скрам-команда.
Руководство по Scrum 2020 следующим образом описывает цель и содержание Ретроспективы:
Для Спринта длиной в месяц эта встреча ограничивается 3 часами. Для более коротких Спринтов она обычно короче.
Ретроспектива Спринта — командообразующая встреча, весьма непростая для проведения. Поэтому ее обычно фасилитирует Скрам-мастер. На Ретроспективе ведутся откровенные разговоры, в том числе, о неприятных вещах; проходят сложные мозговые штурмы. Если из раза в раз встреча будет оставлять чувство неудовлетворенности у команды, а ее результаты не будут реализовываться в следующих Спринтах, команда будет демотивироваться.
Типичная Ретроспектива включает ответы участников Скрам-команды на следующие вопросы:
Эти ответы так или иначе визуализируются, а далее служат основой для генерации новых практик и правил, влияющих на процесс работы команды.
Однако если каждый раз Ретроспектива будет проходить в одном и том же формате, это быстро наскучит людям. Кроме того, далеко не всегда такие прямолинейные вопросы позволяют получать откровенные ответы и вскрывать реальные проблемы. По этим причинам Скрам-мастера стараются разнообразить формат обсуждений на Ретроспективе, используя десятки различных техник.
Варианты проведения каждого из 5 этапов ретроспективы вы можете посмотреть в этих видео:
Одно из 5 Мероприятий Скрама. Эта встреча длится не более пятнадцати минут и проводится каждый рабочий день в одном и том же месте в одно и то же время. В нем принимают участие все разработчики. На нем озвучивается информация для оценки прогресса и отмечаются препятствия. В результате разработчики могут прийти к необходимости перепланирования работы внутри Спринта.
Одно из 5 Мероприятий Скрама. Проводится в конце Спринта, чтобы клиенты и заинтересованные лица провели инспекцию Инкремента и дали обратную связь по нему, а Скрам-команда, при необходимости, сделала адаптацию Бэклога Продукта. Для Спринта длиной в месяц Обзор Спринта длится не более 4 часов.
Одно из 5 Мероприятий Скрама. На этой встрече Скрам-команды происходит планирование работы на следующий Спринт. Для Спринта длиной в месяц встреча длится не более 8 часов. Она завершается созданием Бэклога Спринта и включает обсуждение 3-х тем:
Одно из 5 Мероприятий Скрама, которое является контейнером для других мероприятий. Спринты — это короткие регулярные циклы длиной не более четырех недель. Итерации работы должны быть достаточно короткими, чтобы команда не теряла концентрацию, и при этом достаточно длинными, чтобы поставлять значимый инкремент работы. Все остальные Мероприятия Скрама проводятся в рамках Спринта. Следующий Спринт начинается сразу же по окончании предыдущего.
Активность, которая проводится Владельцем Продукта при участии всех членов команды. Включает добавление деталей, оценку и упорядочивание элементов в Бэклоге Продукта.
Не относится к официальным Мероприятиям Скрама, однако зачастую проходит в виде мероприятия (встречи).
Уточнение бэклога обычно занимает не более 10% времени Скрам-команды в Спринте.
Мы хотим, чтобы компании были крутыми, а люди в них — счастливыми
«Василий не сделал свою задачу, мы завалили спринт!»: как не повторить старые ошибки в новом проекте
Менеджер проектов в Techstack
Метод Scrum остается одним из самых популярных способов управления командой. Его используют 58% компаний, которые внедрили методологию Аgile (совокупность подходов гибкого менеджмента команд). А самая популярная и эффективная практика в Scrum – ретроспектива. Главное – знать, как ее правильно применять.
Команда Techstack внедрила практику ретроспективы после каждого спринта (короткого временного интервала, в течение которого Scrum- команда выполняет заданный объем работы. – Прим. ред.). Количество успешно выполненных задач на следующем этапе возросло на 30%. Мы стали адекватнее оценивать собственные возможности, лучше понимать сильные и слабые стороны, а еще научились слышать друг друга.
Немного Scrum-теории
Scrum как набор правил для управления разработкой продуктов программного обеспечения появился в 80-е годы прошлого столетия. Термин пришел из популярной американской игры регби. Там он описывает ситуацию, когда игроки наваливаются друг на друга и образуют плотную толпу.
Из спорта эта метафора перекочевала в IT-индустрию: разработка продуктов – тоже командная работа, которая без правильного управления рискует превратиться в полный хаос. Scrum и его инструменты не дают этому произойти.
За последние годы методология эволюционировала, менялась и адаптировалась к реалиям IT-рынка. Сегодня Scrum основывается на пяти базовых постулатах. Один из них – inspect and adapt («анализируй и улучшайся») – реализован в традиционной практике ретроспективы.
Как работает ретроспектива в Scrum
Руководство по Scrum описывает ретроспективу как регулярное собрание команды после каждого спринта для обсуждения удачных и провальных моментов. А также для определения конкретных действий, которые помогут устранить сложности предыдущего спринта, предотвратить возникновение новых и усилить слабые стороны.
Обычно в ретроспективе участвует Scrum-мастер и команда разработки. Но если вы хотите сохранять открытые и доверительные отношения с клиентом, то результатами можно поделиться с ним. Заодно обсудить, какие из пунктов улучшений находятся в его зоне влияния.
Почему команды не хотят участвовать в ретроспективах
Отчет State of Agile за 2020 год показал, что более 80% команд, работающих по методологии Agile, используют технику ретроспективы в своей работе. Казалось бы, если это такой популярный инструмент, то почему многие команды не находятся в процессе постоянного улучшения? И почему большинство разработчиков считают ретро очередным скучным собранием, отвлекающим от настоящей работы?
Причин тому несколько. Вот самые распространенные из них:
Все эти факторы могут отвратить команду от участия в ретроспективе. Чтобы этого не произошло, важно научиться использовать метод эффективно.
Как правильно внедрить метод ретроспективы: лайфхаки и советы
Вот пара фишек, которые помогут проводить ретроспективу так, чтобы она вызывала энтузиазм у команды и приносила пользу проекту.
Ретроспектива призвана улучшать процесс разработки. Но не забывайте, что собрание тоже можно преобразовать. Никто не дает более объективные советы по улучшению, чем сами участники мероприятия.
Небольшой совет: после каждого собрания можно спросить ребят из команды, как они оценивают прошедшее мероприятие, что бы хотелось изменить и почему.
Основная причина отсутствия активности и искренности на ретроспективах – недоверие. Зачем открываться, генерировать предложения по улучшению, если все равно ничего не изменится?
Запомните: задача Scrum-мастера – убирать препятствия в работе команды. У ребят появится вера, если активно внедрять улучшения, мониторить и контролировать, как их выполняют другие участники. Это действительно работает.
Личный опыт. На проекте собралась команда разработчиков, которая никогда не работала по методике Scrum. Ребят шокировало количество свалившихся на них собраний, каждое из которых они считали потерей времени.
Чтобы изменить сопротивление на принятие, я попросила озвучить хотя бы одну сложность, которая мешает работать. Оказалось, что требования к задачам спринта не всегда понятно описаны. И выясняется это, когда работа уже началась. В результате называют слишком оптимистичные сроки выполнения задачи, в которые команда не может уложиться.
Обсудив проблему, мы договорились, какие моменты прописать подробно. Когда требования стали более четкими, команда увидела, что времени на выяснение подробностей тратится меньше и больше остается на разработку. Уже на следующей встрече команда охотнее делилась идеями.
Коллективная ответственность зачастую значит, что она ничья. Проследите за тем, чтобы за всеми решениями был закреплен человек, ответственный за их выполнение. Уточняйте сроки, когда можно ждать готовый результат.
Если у вас команда инициативно сгенерировала большой список с улучшениями, не пытайтесь внедрить все сразу. Дайте ребятам возможность проголосовать за самые важные и возьмите в работу несколько из них.
Если какой-то формат проведения ретроспективы подходил и работал раньше, это еще не значит, что со временем он не утратит свою эффективность. Будьте готовы попробовать что-то новое.
Если формальные ретро утомили команду, добавьте немного геймификации: предложите команде представить, что вы летите на воздушном шаре, и что-то дает шару свободно лететь в небе, а что-то тянет его вниз. Попробуйте коллективно определить, что это может быть.
Личный опыт. В одной из команд мы использовали стикеры и доску для проведения ретро: каждый участник писал свои мысли на стикерах, мы клеили их в соответствующие колонки на доске, группировали и голосовали. Через пару спринтов стикеров становилось меньше, а по поведению ребят было видно, что они делают упражнение с меньшей охотой.
Перед очередным ретро я накупила печенюшек и отправила всех делать чай. Когда ребята вернулись, предложила поболтать на тему прошедшего спринта. Все идеи фиксировала в таблице. Мы распределили ответственных и установили сроки – все важные моменты остались. Новый формат беседы раскрыл мысли, которые невозможно было кратко сформулировать на стикере, и внес разнообразие в уже привычные встречи.
Люди приходят на ретроспективу, погруженные в свои рабочие задачи. Дайте им возможность переключиться и оказаться в текущем моменте. Для этого хорошо подходят короткие упражнения, которые позволят переключить мозг. Примеры, которые я использую со своими командами:
«Никто не знает, что я….» Каждый участник по очереди начинает с этой фразы и продолжает каким-то фактом о себе.
Сила и слабость. Каждый член команды (по желанию) называет свою сильную и/или слабую сторону.
Задача на логику. Попробуйте дать ребятам решить небольшую логическую задачку. Такая совместная работа не только переключит людей с их текущих задач, но и настроит на командный лад.
Комментарии в стиле: «Ох, было что-то плохое в этом спринте, но я уже не помню», – не помогают добиться улучшений. Приучайте себя и команду по ходу спринта делать пометки: что мы делаем удачно, или что произошло такого, чего не стоит больше делать, или идеи, как улучшить процесс. Тогда сама ретроспектива будет емкой, не займет много времени и даст измеримый результат.
Не ставьте процесс выше результата
Ретроспективы ваших команд станут полезными и действенными тогда, когда вы сами в них поверите и научитесь правильно пользоваться этим инструментом.
Помните, что все методологии – не догма. Это не процесс ради процесса, а средства для организации грамотного и эффективного управлении процессами разработки.
Задача хорошего менеджера и Scrum-мастера – знать весь арсенал инструментов, но использовать только те, что полезны и подходят конкретному проекту и команде.
Этот материал – не редакционный 
Это – личное мнение его автора. Редакция может не разделять это мнение.
Завершение спринта в Scrum – демо и ретро
В этой, тринадцатой статье из серии «Менеджмент цифрового мира» я продолжу рассмотрение схемы скрам и буду говорить про завершение спринта – Демо, оно же Sprint Review и Ретроспективу. Она продолжает предыдущие статьи «Итерации Scrum – целостная схема, а не прикольная картинка», где мы рассмотрели переход к итеративной работе и планирование, и «Схема Scrum – ежедневная работа внутри спринта».
Назначение Демо – показ результатов, достигнутых командой, и их оценка стейкхолдерами. Именно получение оценки от стейкхолдеров является основной функцией демо: соответствует ли это их ожиданиям, решает ли поставленные задачи и приносит ли ценность. И официальное название в Scrum Guide – Sprint Review это подчеркивает. Но термин «Демо» является устоявшимся в сообществе, гораздо более коротким и я предпочитаю использовать именно его, тем более, что исторически именно это название я узнал первым, прочитав в 2007 книгу Хенрика Книберга «Скрам и XP: заметки с передовой», которую уже упоминал в предыдущей статье.
Если бы ценность задачи можно было бы обеспечить выполнением чек-листа, то никакой бы Agile был не нужен, с организацией IT-проектов хорошо бы справились методы классического менеджмента. Проблема состоит в высокой сложности социотехнических систем, в результате чего все представления о необходимых функциях и о работе пользователей – не более чем гипотезы, подлежащие проверки. А на бытовом уровне эта ситуация хорошо описывается словами «заказчик сам не знает, чего он хочет». Именно поэтому разработанный софт требует постоянной проверки: несет ли он ценность пользователям. Впрочем, тоже самое можно сказать о любых других продуктах – проверить, полезен ли продукт потребителям, нужен ли им можно только экспериментально.
Обычно Демо проводится в виде встречи, на которой присутствует команда и все заинтересованные стейкхолдеры: члены команды демонстрируют созданную ценность и получают обратную связь. Именно такую форму рекомендует Scrum Guide. Процедура кажется простой, однако практически с таким способом связано несколько проблем, которые мы обсудим далее.
Итак, какие же проблемы могут быть связаны с простой демонстрацией?
Во-первых, далеко не всегда на Демо удается обеспечить присутствие необходимых стейкхолдеров, среди них часто встречаются реально занятые люди.
Во-вторых, далеко не всегда стейкхолдеры в принципе могут оценить ценность сделанного на основе демонстрации. Например, если вы разрабатываете продукт, отдел из отдела маркетинга, который является внутренним заказчиком, поступают предложения о новых необходимых фичах, которые, однако носят статус гипотез, восприятие пользователями которых неизвестно, и в задачу команды входит не только разработка, но и оценка реакции пользователей, доработка по ней.
Да и при заказной разработке софта случается, что заказчиком является руководитель бизнес-подразделения, который приносит проблему не эффективного выполнения каких-либо операций, которую должен решить новый функционал, и, не выполняя операционную работу непосредственно, он часто не может оценить реализацию, а пользователям, которые могут это сделать, надо для оценки самим попробовать функционал на реальных данных…
В-третьих, далеко не всегда получается организовать продуктивную коммуникацию на демо, вовлекающую и членов команды и стейкхолдеров из-за культурных различий. Впрочем, тут работает легкий метод: часть коммуникации со стейкхолдерами ведет аналитик, владеющий их языком. Часть, а не всю: полезно, чтобы показ выполнял не он, а те, кто разрабатывал, комментируя свои действия и получая обратную связь, ощущение ценности собственной работы важно.
Отметим, что далеко не всегда эти проблему могут быть в конкретно вашем проекте. Наоборот, в большинстве проектов демонстрации стейкхолдерам достаточно, иначе бы в Scrum Guide не было бы рекомендованного способа. Ну или так было, когда Scrum формировался. Отметим, кстати, что переход от функциональных требований к user story отчасти проблемы демонстрации решал: мы вместо выполнения функций описывали цели пользователей, и демонстрация, как пользователи будут их достигать, работая используя разработанный софт, должна быть достаточна.
Однако, что делать, если проблема в вашем проекте существует? Правильный способ решения этих проблем – придумать альтернативные механизмы получения релевантной обратной связи и встроить в процесс именно их, чтобы обеспечить выполнение основной функции демо. Например, в цикл выполнения задачи может быть включено не только тестирование, но выкатка на боевые сервера и A/B тестирование на пользователях. Или установка его на тестовые сервера заказчика с приближенными к боевым данными, и проведение обучения и демонстрации конечным пользователям. Таким образом, есть различные варианты.
Но на практике вместо разработки механизмов часто просто назначают формального ответственного «ты будешь смотреть и оценишь результат». И в результате команда идет по неверному пути, а выясняется это только на внедрении функционала. Я слышал истории, когда эти проблемы возникали даже когда таким ответственным стейкхолдером был руководитель проекта от заказчика: он был на демо, был очень доволен, команда была вдохновленной. А потом оказалось, что он не слишком давно работает у заказчика, и его представления о процессе были основаны на опыте работы в другом месте. Поэтому, когда функционал принесли конечным пользователям, то выяснили его слабую пригодность для реального процесса. Заметим, что техническая выкатка изменений на боевые сервера не спасает, так как пользователи, не зная о новых функциях им просто не пользуются. А вот изменение работы пользователей в любом случае надо отдельно организовывать.
Отмечу, что примерно те же проблемы возникают и при применении Scrum для не IT-проектов: новые продукты или новые материалы недостаточно просто сделать и предъявить, могут быть необходимы испытания, тестирование на пользователях или у заказчиков. Типичный пример – маркетинг, конечным результатом маркетинговой компании тут являются привлеченные пользователи или покупатели, а вовсе не публикация рекламы, и именно по ним можно определить ценность.
Как было отмечено выше, в ряде случаев получение релевантной обратной связи подразумевает долгий по времени процесс. И далеко не всегда это может решено внутри спринта по объективным причинам. Если такие задачи встречаются изредка, то можно получение обратной связи выделять в отдельный поток, при этом может быть допустим перенос их в следующий спринт. Если же такие задачи составляют большинство, то надо придумывать другие механизмы.
Другой вариант – вынести получение обратной связи от пользователей за пределы Scrum в отдельный Kanban-процесс. Он целесообразен в том случае, если с ним связаны длительные временные лаги, не укладывающиеся в короткий Scrum-цикл.
Отметим, что оба этих механизма могут применяться так же для предварительной подготовке бэклога к разработке, об этом я буду рассказывать в следующей статье.
Независимо от выбранного способа, должны быть сделаны механизмы, реализующие еще одну функцию демо: обратная связь по ценности результата должна быть не только получена, но и донесена до всей команды. И не только отрицательная, но и положительная. Об этом часто забывают, успех очередной фичи маркетинг празднует у себя, а на команду транслирует только проблемы. Важно, чтобы команда тоже ощущала успех.
То же касается и механизмов, описанных ранее, например, когда выделенные сотрудники из команды обучают новому функционалу пользователей заказчика – обратную связь надо донести до команды. В том числе положительную эмоциональную обратную связь, чтобы люди ощутили ценность сделанного, а не просто приняли это к сведению.
Отметим, что бывают очень тяжелые ситуации, когда реальная обратная связь может запаздывать на месяц-другой из-за реально длительного процесса, включающего, например, производство конечного продукта на основе того проекта, который разрабатывает Scrum-команда. В этом случае все равно надо заботиться о механизмах обратной связи, хотя готовых рецептов у меня тут нет…
Помимо описанной выше задачи получения обратной связи от стейкхолдеров о ценности созданного продукта, Демо решает еще пару задач.
Во-первых, на демо идет оценка достижения целей спринта со стороны стейкхолдеров. И связанное с этим позиционирование достигнутого результата как часть более крупных циклов планирования или целеполагания: вклад спринта в разработку релиза, в продвижение к квартальным или годовым целям. Подробнее о цикле релизного планирования я буду говорить в следующей статье, рассказывая полную схему Scrum. А вот работа с квартальными и годовыми целями находится за пределами обеспечиваемого Scrum, для этого можно применять OKR (Objectives and Key Results). До OKR я тоже доберусь в будущих статьях, хотя, наверное, без подробностей. Но независимо от метода, в демо полезно включить оценку продвижения к целям по мнению стейкхолдеров.
Во-вторых, на Демо стоит получить обратную связь от стейкхолдеров по работе и восприятию команды в целом. Не по созданной ценности, а по характеру коммуникаций и другим аспектам взаимодействия.
Впрочем, обе этих задачи следует ставить только в том случае, если стейкхолдеры достаточно квалифицированы в высказывании такой публичной обратной связи, а команда – достаточно зрелая, чтобы ее принять. В противном случае вместо конструктива можно получить негатив и демотивацию команды.
Однако, как и в случае оценки ценности, если эти виды обратной связи на Демо получить нельзя, необходимо обеспечить другие механизмы ее получения. Ответственным за получение и донесение до команды обратной связи по целям является Product Owner, а по взаимодействию – они делят эту ответственность со скрам-мастером. Почему делят? Потому что к части стейкхолдеров Product Owner все равно пойдет по первому вопросу, и может заодно выяснить второй, нет смысла в двойной коммуникации. В то же время, взаимодействие Команды со стейкхолдерами может не ограничиваться теми, кто получает ценность от созданного продукта, это могут быть смежные и обслуживающие подразделения и команды, и задача взаимодействия с ними в целом лежит на скрам-мастере.
Всю обратную связь полезно получить до Ретро, чтобы на нем команда могла это обсудить. Впрочем, эти циклы обратной связи можно делать и более редкими, не обсуждая это каждый спринт, а проводя большие внешние ретроспективы с участием стейкхолдеров и оценкой ими достижений команды. Это – тоже работающая практика.
И в заключении стоит поговорить о том, что происходит, когда спринт окончился неудачно, и команда сильно не успела сделать запланированные работы. Тут следует явно сформулировать принцип, который я в свое время услышал от Хенрика Книберга: не бывает медленной скорости, бывает неверное планирование.
В моменте необходимо решить, что делать с задачами незавершенного спринта. Вернее, необходимо сделать заранее, когда Product Owner явно увидит из Burndown Chart и доски, что в спринте не будет завершено существенное количество задач. Это может быть видно уже в середине спринта, и точно становится явным за два-три дня до окончания. Product Owner должен оценить масштаб проблемы, и провести коммуникацию со стейкхолдерами и командой, выработать решение – на каких задачах делаем фокус, а какие – оставляем на будущие спринты. В некоторых случаях спринт может быть продлен на один-два дня, если такое решение может существенно повысить создаваемую ценность за целостности набора решенных задач.
Но в целом это – исключительная ситуация. О том, как проводить планирование и оценку, что именно поместится в спринт я буду говорить в следующей статье.
А в заключении этой статьи я буду говорить про Ретроспективу – встречу, на которой команда сама оценивает прошедший спринт и достижение целей и работает над улучшением процесса. Непрерывный процесс улучшений – неотъемлемая часть любого Agile-метода. Отсутствие реального ретро часто означает, что команда погрязла в самодовольстве. О проведении ретроспективы есть достаточно много книг и докладов, но в ней, наверное, наиболее сильно проявляются особенности культуры команды и компании, а я никогда на ней не фокусировался, поэтому я не готов рекомендовать конкретные книги и доклады.
Однако, я немного расскажу о полезных практиках, которые, на мой взгляд, не являются тривиальными.
Первое – это позитивное мышление им нацеленность на улучшения. Не «что было хорошо, а что плохо», а «что было хорошо, что нам мешало и как это устранить, и что можно улучшить».
Второе – вовлеченность всех членов команды. Но не стоит побуждать всех высказаться, или директивно требовать этого, люди стесняются, у них могут быть разные другие причины молчать. Так что лучше применять косвенные методы. Можно предложить каждому написать тезисы о том, что было хорошо, препятствия и идеи улучшений на стикерах и вывесить. Стикеры можно использовать разных цветов, в зависимости от вида тезиса и эмоционального отношения к ней: для позитива оценивать его вид – счастье, сюрприз и так далее; для препятствий – силу возмущения, для улучшений – накал желания. А уже потом объединить близкие идеи и обсудить по порядку: что хорошо, какие препятствия и как можно устранить, что можно улучшить. Обсуждение тоже можно начать не всем вместе, а в парах – это стимулировать высказаться всем, а не самым активным.
Третье – в результате должен быть план улучшений, в котором выделены те, которые считаем наиболее важными и берем в работу на следующий спринт. Важность стоит определять не в обсуждении, а голосованием точками. Можно оценивать не только рациональную важность, но и эмоциональное отношение к идеям, тоже какими-то смайликами.
Четвертое – идея изменений может быть сложной, и предполагать несколько шагов, как и в любой задаче, в том числе включать взаимодействие со стейкхолдерами для получения одобрения действий. А реализация может быть достаточно длительной. Их можно включать в общий список задач, или вести на отдельной Kanban-доске со своими фазами.
В случае отдельной доски препятствия и идеи можно вешать на нее не только на ретро, но и течении спринта, немедленно, как оно обнаружено. Но даже если доски нет, полезной является список, который в течении спринта все могут дополнить, или личные списки. Но все равно, это не должно быть единственным входом для ретроспективы.
Ретроспектива требует выйти из основного потока работ и перейти из позиции специалиста, который делает работу, в позицию наблюдателя, который эту работу оценивает. И это – отдельное мыслительное усилие и действие.
Шестое. Реализация идей требует ресурсов команды, и тут может быть различная политика взаимодействия со стейкхолдерами: может быть договоренность о некоторой квоте на улучшения на каждый спринт, или политика, отличающая мелкие улучшения, которые может делать команда и крупные, о которых надо договариваться. Для взаимодействия со стейкхолдерами часто необходимо сформулировать идеи на их языке: в виде измеримого препятствия для скорости команды, или возможности повышения ее скорости, потенциальных рисков, которые несет ситуация.
В IT частным случаем работы с препятствиями является работа с техническим долгом. Очень часто при реализации принимаются решение о том, что необходимо быстрое частичное решение по ситуации (костыль), а полноценное будет сделано позднее. А потом сделать хорошо забывают. Об этом есть даже сленговая шутка «IT- единственное место, где на костылях быстрее, чем без них». И полноценные решения не делают, но скрытые в коде костыли несут риск. И важно уметь донести проблемы стейкхолдерам в том виде, в котором они покажутся нестерпимыми. То же относится и к другим идеям.
Ну и в заключении я хочу сказать, что ретро – внутреннее собрание команды. На нем не должно быть стейкхолдеров для открытого разговора. Однако, помимо внутреннего ретро можно проводить внешнее, со стейкхолдерами, оценивающими работу команды – я писал о нем ранее, рассказывая о дополнительных задачах демо.
Однако, несмотря на то, что на ретро есть только члены команды, не все вопросы могут быть подняты. Если какие-то претензии и препятствия носят личный характер, люди могут их не высказывать. И вот тут начинается ответственность скрам-мастера: поговорить с людьми индивидуально, выявить проблему, а потом решить, что делать – выносить ли в какой-либо форме на ретро, или работать через индивидуальную коммуникацию.
На этом я завершаю очередную статью про схему Scrum, продолжение следует…
Всё отлично, но этот жирны мелькающий шрифт. Ребят, кто вас этому научил? Неудобно читать, глаз начинает дергаться.
Где скриншоты, полотно текста.
Так хотел прочитать про Scrum, но это почти не реально.
Поставлю в закладки и создам задачу на понедельник.))
Жирный выделяет важное, но, наверное, его здесь действительно многовато получилось. Спасибо за обратную связь. Надеюсь, статья окажется полезной.
есть пара вопросов.
В целом я не пишу учебник, а рассказываю про Agile на практике. Учебников и так много, и они не удовлетворяют людей. Люди видят описание Sprint Review, повестку на 4-часовую встречу, понимают не реализуемость в их условиях и говорят «ну Scrum нам не подходит, и вообще он настолько жесткий, что убиться можно».