Что такое ретроспектива в scrum
«Василий не сделал свою задачу, мы завалили спринт!»: как не повторить старые ошибки в новом проекте
Менеджер проектов в 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-мастера – знать весь арсенал инструментов, но использовать только те, что полезны и подходят конкретному проекту и команде.
Этот материал – не редакционный 
Это – личное мнение его автора. Редакция может не разделять это мнение.
Ретроспектива: как и зачем ее проводить?
Проведение ретроспектив – это активность, которую каждая agile-команда проводит для того, чтобы решать свои проблемы. Что такое ретроспектива? Это регулярная встреча, на которой команда обсуждает свой рабочий процесс и что-то в нем меняет.
Зачем нужна ретроспектива?
Это не праздный вопрос, его часто задают начальники, когда им предлагают провести ретроспективу. Они спрашивают: «Зачем? Мы можем сами все решить». Почему же нельзя сделать так, чтобы какой-то начальник или эксперт пришел, посмотрел и сказал, что команде надо делать, а что в рабочем процессе стоит изменить?
Основных причин две. Во-первых, если мы приходим к команде с готовыми решениями, возникает феномен, который называется «not invented here». Даже если члены команды понимают, что это правильное решение и его нужно выполнять, у них нет чувства собственности по отношению к нему. Такие решения, не «выстраданные» самим коллективом, а «навязанные» или предложенные сверху, имеют меньше шансов на реализацию.
Во-вторых, сейчас разработка ПО – настолько сложная и запутанная вещь, что вряд ли найдется специалист, который сможет, не зная контекста, расписать, как на самом деле должны работать процессы в конкретной команде при решении определенной задачи. Чтобы это выяснить, надо что-то пробовать, проводить эксперименты, смотреть, к чему приводят те или иные решения. Только попробовав, можно понять, хороша или не очень та или иная практика в контексте данной команды.
Тем не менее, существуют такие вещи как good practice или best practice. Это практики, которые многие используют и которые многим помогают. Возьмем, например, code review: хорошая это практика или плохая? Одним командам она помогает. Другие пытаются ее использовать, и ничего хорошего из этого не выходит. Так происходит потому, что эта конкретная практика, не хороша и не плоха как таковая: ее можно оценить только в контексте конкретной команды и ситуации.
Хотя бы поэтому невозможно сказать заранее, даст она какое-то преимущество или нет. Сode review – это один пример. На самом деле этот эффект характерен для любой практики – никогда нельзя знать заранее, насколько она будет эффективна в той или иной ситуации.
Цели и результаты
В основе ретроспективы лежит концепция цикла Деминга, PDCA (англ. Plan-Do-Check-Act). Цель ретроспективы – к ее окончанию получить план изменений. Но важно понимать, что это не план окончательных изменений в процессе – это план эксперимента на ближайший период. Мы что-то пробуем, а потом смотрим, что из этого вышло, и на основании этого принимаем решение.
Цикл Деминга: Plan – запланируй, Do – выполни, Check – посмотри, что получилось, Act – прими какие-то дальнейшие решения, реши, что дальше делать. Ретроспектива должна проходить именно по этому циклу. Собственно, сама ретроспектива – это стадия Plan.
Ретроспектива, как и любая командная встреча, должна иметь какую-то цель. Цель ретроспективы – получить план процессного эксперимента. Однако многие команды этого не понимают. Например, на ретроспективе команды порой пытаются придумать какие-то глобальные решения своей проблемы, и упираются в то, что у них не получается этого сделать. Они застревают и в итоге вообще ничего не делают. Если команда с такой проблемой сталкивается, то надо ей объяснить, что двигаться надо маленькими шагами, пробуя разные вещи и проверяя, что из этого выходит.
Если команда просто считает, что ретроспектива – это встреча для того, чтобы обсудить свой рабочий процесс и как-то его улучшить, то, как правило, все сводится к тому, что люди приходят, о чем-то разговаривают, выливают свою боль, облегчают душу – в итоге это ни к чему это не приводит. Так происходит потому, что цель не достигнута, план не получен.
Задача ведущего – привести команду в процессе ретроспективы к конкретному плану. План – это одно из двух: либо действия, либо новая договоренность. Все, к чему ретроспектива сводится – это список из действий, которые надо совершить, и договоренностей, которых отныне нужно придерживаться.
Что такое действия? Это конкретные задачи с известными исполнителями. Причем если выполнить действие должен тот, кого нет сейчас в комнате, из присутствующих выбирается человек, который берет на себя ответственность объяснить отсутствующему, что и как нужно сделать, а также проконтролировать результат. В итоге за каждое действие отвечает кто-то из присутствующих на ретроспективе.
Какие бывают ретроспективы?
Вообще ретроспективы разумно подразделять на несколько типов:
Ретроспектива по качеству обычно сводится к тому, что на ней обсуждаются либо недавно произошедшие инциденты, либо дефекты. Ретроспективу посвящают тому, что обсуждают эти дефекты и анализируют, почему они возникли, то есть строят диаграмму глубинных причин дефектов. Так или иначе, в этом случае работу ведут с конкретными проблемами с качеством.
Есть ретроспективы, на которых работа ведется с проблемами, возникающими у заказчика или у владельца продукта. Это третий тип ретроспективы. Четвертый тип – когда есть конкретная специфическая проблема, и ретроспектива посвящается ее решению.
В чем проблема?
Какие в процессе ретроспективы могут возникнуть дисфункции, и как с ними бороться? Вот одна из дисфункций: команда считает, что у нее нет проблем, ее рабочий процесс достаточно хорош, и не видит смысла в его улучшении. Как правило, это не так. Но команде этого просто так не объяснить.
Для того, чтобы сдвинуть коллектив с этой позиции, полезно пригласить на ретроспективу кого-то из стейкхолдеров – заказчика или пользователей, которые знают, что с командой не все в порядке (заказчики вообще очень редко полностью удовлетворены работой команды). Они могут быть удовлетворены до определенной степени, но, как правило, у них все равно есть какие-то мысли на тему того, «что команда могла бы сделать лучше». Если такой заказчик приходит на ретроспективу и рассказывает это команде, ей уже некуда отступать, она начинает обсуждать направления для дальнейшего роста.
Еще одна дисфункция – когда на ретроспективе говорит в основном кто-то один или 2-3 человека, а все остальные сидят и молчат. На самом деле этим людям есть, что сказать. Просто, если все внимание на себя забирает, к примеру, лидер команды, он начинает доминировать, а остальные просто слушают.
Почему это плохо? Если каждый будет открыто высказывать свои мысли, то вероятность найти лучшие решения намного возрастет. Когда мы участвуем в групповой дискуссии, мы друг друга подстегиваем. Это и помогает придумать лучшее решение.
Часто справиться с этой проблемой помогает ведущий (фасилитатор) ретроспективы, который будет следить за тем, чтобы каждый из присутствующих высказал свою точку зрения. Иногда для того, чтобы участники ретроспективы более свободно выражали свое мнение, полезно давать им возможность не высказывать свои соображения вслух, а записывать их на клейких листках (их обычно прикрепляют на стену или специальную доску, причем это могут сделать как сами участники, так и – для пущей «анонимности» – фасилитатор).
Формат ретроспективы: наши предложения
В литературе описываются различные форматы проведения ретроспективы – от простых до крайне специфических. В одном из материалов в нашем блоге мы предложили свой вариант: его отличительные особенности – простота и эффективность. В основном именно это и требуется от подобных мероприятий.
Вместо того, чтобы выставлять жесткий тайминг и последовательность действий, мы предлагаем просто расчертить доску на 4 основные области и заполнять ее по ходу обсуждения:
Как правило, новые идеи рождаются в процессе обсуждения минусов прошлой итерации, однако ими не ограничиваются: такой формат ретроспективы не препятствует свободному обсуждению. При этом фасилитатор или скрам-мастер должен следить за тем, чтобы обсуждения не перерастали в поиск виноватых: для достижения цели важно не столько то, «кто виноват», сколько то, «что с этим делать дальше». Споры по поводу той или иной идеи на данном этапе тоже бесполезны: в план все равно попадут только те идеи, с которыми согласны все участники ретроспективы.
После обсуждения плюсов, минусов и идей команда переходит к составлению плана, куда попадают не просто результаты обсуждения, а (как уже было отмечено) конкретные действия («Выполнить…», «Обсудить…», «Сформировать…») или правила («Задачу Х выполнять с использованием подхода Y»). Не стоит при этом пытаться выработать пути решения всех возможных проблем команды – для эффективной работы на следующей итерации достаточно плана из 3-6 пунктов. Слишком объемный план может в итоге оказаться невыполним и только демотивирует команду.
Стоит еще раз отметить, что форматы проведения ретроспективы могут быть различными. Важно одно: ретроспективы – это не единичное мероприятие, они проводятся регулярно, и по результатам каждого такого собрания выполняется основная цель – создается план на ближайшую итерацию. Если отнестись к этой процедуре не «формально», понимать ее цели и задачи, заранее знать наиболее типичные проблемы, возникающие в ходе ретроспективы, можно создать благоприятные условия развития настоящей самоорганизующейся команды.
Ретроспектива Спринта (Sprint Retrospective)
Ретроспектива Спринта — это одно из 5 Мероприятий Скрама, дающее Скрам-команде возможность провести инспекцию своей работы и создать план улучшений на следующий Спринт. Ретроспектива проходит после Обзора Спринта, перед Планированием следующего спринта. В нем принимает участие вся Скрам-команда.
Руководство по Scrum 2020 следующим образом описывает цель и содержание Ретроспективы:
Для Спринта длиной в месяц эта встреча ограничивается 3 часами. Для более коротких Спринтов она обычно короче.
Ретроспектива Спринта — командообразующая встреча, весьма непростая для проведения. Поэтому ее обычно фасилитирует Скрам-мастер. На Ретроспективе ведутся откровенные разговоры, в том числе, о неприятных вещах; проходят сложные мозговые штурмы. Если из раза в раз встреча будет оставлять чувство неудовлетворенности у команды, а ее результаты не будут реализовываться в следующих Спринтах, команда будет демотивироваться.
Типичная Ретроспектива включает ответы участников Скрам-команды на следующие вопросы:
Эти ответы так или иначе визуализируются, а далее служат основой для генерации новых практик и правил, влияющих на процесс работы команды.
Однако если каждый раз Ретроспектива будет проходить в одном и том же формате, это быстро наскучит людям. Кроме того, далеко не всегда такие прямолинейные вопросы позволяют получать откровенные ответы и вскрывать реальные проблемы. По этим причинам Скрам-мастера стараются разнообразить формат обсуждений на Ретроспективе, используя десятки различных техник.
Варианты проведения каждого из 5 этапов ретроспективы вы можете посмотреть в этих видео:
Одно из 5 Мероприятий Скрама. Эта встреча длится не более пятнадцати минут и проводится каждый рабочий день в одном и том же месте в одно и то же время. В нем принимают участие все разработчики. На нем озвучивается информация для оценки прогресса и отмечаются препятствия. В результате разработчики могут прийти к необходимости перепланирования работы внутри Спринта.
Одно из 5 Мероприятий Скрама. Проводится в конце Спринта, чтобы клиенты и заинтересованные лица провели инспекцию Инкремента и дали обратную связь по нему, а Скрам-команда, при необходимости, сделала адаптацию Бэклога Продукта. Для Спринта длиной в месяц Обзор Спринта длится не более 4 часов.
Одно из 5 Мероприятий Скрама. На этой встрече Скрам-команды происходит планирование работы на следующий Спринт. Для Спринта длиной в месяц встреча длится не более 8 часов. Она завершается созданием Бэклога Спринта и включает обсуждение 3-х тем:
Одно из 5 Мероприятий Скрама, которое является контейнером для других мероприятий. Спринты — это короткие регулярные циклы длиной не более четырех недель. Итерации работы должны быть достаточно короткими, чтобы команда не теряла концентрацию, и при этом достаточно длинными, чтобы поставлять значимый инкремент работы. Все остальные Мероприятия Скрама проводятся в рамках Спринта. Следующий Спринт начинается сразу же по окончании предыдущего.
Активность, которая проводится Владельцем Продукта при участии всех членов команды. Включает добавление деталей, оценку и упорядочивание элементов в Бэклоге Продукта.
Не относится к официальным Мероприятиям Скрама, однако зачастую проходит в виде мероприятия (встречи).
Уточнение бэклога обычно занимает не более 10% времени Скрам-команды в Спринте.
Мы хотим, чтобы компании были крутыми, а люди в них — счастливыми
Ретроспективы agile
Ретроспектива — это любое время, когда команда размышляет о прошлом, чтобы улучшить будущее. Помимо рабочих вопросов в технических и нетехнических командах, ретроспективы можно устраивать практически по любым темам. В настоящий момент мы проводим публичную ретроспективу по методам agile в разработке программного обеспечения. Помогите определить будущее методологии agile, добавив свои идеи на нашу доску.
Подключайтесь к обсуждению #RetroOnAgile
Поразмышляйте о своем опыте разработки программного обеспечения и напишите в Твиттере сообщение с хэштегом #RetroOnAgile. Расскажите нам о том, что вам нравится, под хэштегом #ILike, что вам хотелось бы улучшить — с хэштегом #IWish, что вы бы хотели увидеть в будущем — с хэштегом #WhatIf. Для вдохновения используйте тысячи ответов, представленных ниже. Ваш отзыв отобразится здесь в течение 24 часов.
Совет. ^^^ Подставьте в вопрос свой ответ, сохранив хэштеги 😉
#ILike the conversations that we have as a result of our agile process, which help us clarify assumptions and gaps in reasoning #RetroOnAgile
#ILike working smarter and seeing solutions evolve through collaboration #RetroOnAgile
If nothing else, I feel like I waste less time, using the agile process. I know within a few weeks, I’ll get feedback on the direction I’m headed with a project. #RetroOnAgile
#ILike to help people grow and to watch teams develop from a bunch of individuals into a team that takes over responsibility #RetroOnAgile
#Ilike to work in a truly agile way. Enabling and empowering the teams is a powerful way to get your projects rolling. #RetroOnAgile
— Aishwary Shrivastava (@toxicaishwary) April 13, 2018
#ILike to work in a interdisciplinary team. Working together with people from other fields toward a common business goal is an amazing experience. #RetroOnAgile
#ILike that the focus of software development has changed from deliver software to deliver value. #RetroOnAgile #agile
#RetroOnAgile is a way for my #clockit team to unwind and make the next sprint better. Works amazingly well and puts down everyone’s guard. #Jira #ILike
#ILike The way agile pushes you to question the way yo do things an helps you improve constantly #RetroOnAgile
#ILike that our agile process involves hypotheses, experimentation, measurement, and outcomes other than «we’ve shipped it». #RetroOnAgile
#ILike ability to change the direction, whenever it is reasonably justified #RetroOnAgile
#ILike the attitude that we never settle. In the spirit of Continuous Improvement we always look for ways to surpass our past achievements. #RetroOnAgile
#ILike that agile allows us to quickly react to changes in the SEO environment. SEO is always unpredictable to a degree. Agile comes with the necessary flexibility to adapt.#RetroOnAgile
#ILike that agile encourages teams to focus more on collaboration and outcomes, rather than tools and process #RetroOnAgile
#ILike that we have people from different knowledge areas working together, in one team, towards a shared outcome #RetroOnAgile
#ILike Our software team is starting to deliver software by working together #RetroOnAgile
#ILike deep involvement and awareness of the team that gives unexpected valuable insights #RetroOnAgile
#ILike that I can configure Jira to influence how are team runs agile, not just configure it to reflect how we already work. #RetroOnAgile
#ILike that agile provides a means for saying «no» to the urgent, and empowers a team to focus on the important. We are an #agilemarketing team that runs scrum in #jira not a software dev team, for what that’s worth. #RetroOnAgile
#ILike transparency, united team and shared expectations #RetroOnAgile
#ILike it when my team doesn’t finish the #Agile Sprint objectives and I make them demo broken shit to all the stakeholders anyway, because of course, public shaming is a powerful motivator. Wait, did I say that out loud? #RetroOnAgile
#ILike that DevOps is a thing, just not the watered down “devs do ops” version many teams and companies adopt.#RetroOnAgile https://t.co/Twr8daFj3E
#ILike potential to set sprint goals small enough to present them on Sprint demo #RetroOnAgile
#ILike #noestimates and concentration on flow maximizing instead of resource efficiency. #RetroOnAgile
#ILike how Agile keeps my brother and I developing as fast we can #RetroOnAgile
#ILike how we’ve embraced a mindset of solving customer problems to shape how we work over just shipping features. #RetroOnAgile
Retrospectives, not just on sprints and projects, but all that we do, are very valuable #justdoit #retroonagile https://t.co/BWJE1FLSUn
#ILike we pull up our Jira board during standups to make sure we stay on topic and talk about what we are actually working on. Makes it go faster as opposed to people trying to remember what they are working on #RetroOnAgile
#ILike it when we have a StandUp meeting and when the thing you say you are trying to finish today is already a JIRA ticket. #RetroOnAgile pic.twitter.com/0F1fDHeNpN
#ilike if my team was a little less, delivery focused; and a little more sprint focused. #RetroOnAgile
I like how scrum turns agile back into a heavyweight process with lots and lots of meetings, even when those meetings take place in Jira itself.
#ILike it when tasks in a sprint can be completely done by a single person in less than 3 days. #RetroOnAgile
#IWish Agile was re-branded/re-named so people don’t assume it means «work really fast without thinking». #RetroOnAgile
#iwish people would realise agile is not a switch you can turn on overnight #retroOnagile
#IWish more companies and people understood that Agile can be other methodologies besides Scrum #RetroOnAgile
#IWish we could bring the whole company onto the agile practice #RetroOnAgile
#IWish for Agile we had interactive digital wall boards to use across sites and with people working remotely #RetroOnAgile
#IWish it would be easier to fuel the agile spirit from inside the teams to invest the energy from that better in good practices and software instead of having to discuss processes. #RetroOnAgile
#Iwish for Enterprises to embrace change and and allow agile ways of working without fearing loss of power and control. #RetroOnAgile
#Iwish agile wasn’t used for micro-management and witch-hunting in the work place #RetroOnAgile
#IWish we were beyond wondering «how to do Agile the right-way»… it’s an idea to work towards vs something to attain quickly & easily #RetroOnAgile
#IWish for processes to work for the people, rather than the people working for the processes https://t.co/cdM03j1mZ6 #RetroOnAgile
#IWish companies would not only use the buzzword agile to make the company more interesting to applicants but instead would really support the agile principles. #RetroOnAgile
#IWish more folks followed the Agile principles and values rather than trying to hammer away on process and methodology. #RetroOnAgile
Redraft those ridiculous, self-contradictory 12 commandments so they actually mean something useful
#RetroOnAgile #IWish there was more management-focused material available on the transition from waterfall to Agile.
#IWish companies were more aware of the kind of autonomy and discipline #agile requires #RetroOnAgile
#IWish Agile could be accepted company-wise, and not only in dev teams. #RetroOnAgile
#RetroOnAgile #IWish team members could accept the mindset of Agile more than the method argument.
#iwish to spend less time on Jira to get the desired information and more time doing my job. #RetroOnAgile
#IWish companies, teams, evangelisers, etc. would not use Agile as #buzz and #MagicWand, but indeed maintain culture #RetroOnAgile
#IWish it would be easier to sell #agile development. There’s still too much upfront planning and too little adapting to new information. #RetroOnAgile
#IWish more SEOs in the industry would embrace the agile methodology and step away from the waterfall model.#RetroOnAgile
#IWish «agile» wasn’t such a scary word to teams and companies that haven’t embraced it #RetroOnAgile
Ok #IWish that we would focus less on tools and more on interactions and communication #RetroOnAgile 😀
#IWish there was another kind of Agile besides just Scrum and Kanban. #RetroOnAgile
#IWish there was a shared, ethical definition of “done done” for ML/AI features in agile projects.#RetroOnAgile https://t.co/Twr8daFj3E
#IWish my past experience of Agile had not made me wary of self-proclaimed «Agile Advocates» #RetroOnAgile
#IWish Jira could make customizing release notes simpler #RetroOnAgile
#iwish I could have a better view of all projects, including sorting, prioritisation, labeling, and client assigning. #RetroOnAgile
#IWish JIRA tied usability defects to their originating story, and easily graphed it, so Agile teams could focus on usability. #RetroOnAgile pic.twitter.com/It0NAcb9Bo
#IWish the assignee could be shared among team members, so that pair programming can be planned in advance 😀 #RetroOnAgile
— #IWish Retrospective would magically appear linked to related issues in the new sprint and help overcome scope creep! #RetroOnAgile https://t.co/w6c4gOddfk
#IWish we could keep TLMs from degenerating into program managers. #RetroOnAgile
«When agile shops were first being established, an important consideration was to keep TLMs from having full visibility into any one agile team.» https://t.co/32eiK5ih9a
#IWish @JIRA would let me story point my sub-tasks and roll up the points. Purist is not always pragmatic. #RetroOnAgile
#IWish Consensus would work always. Sadly, the voting environment could get polluted. #RetroOnAgile
«Even though agile rests on collaboration, the ‘agreement by consensus’ model has it’s share of flaws, depending on the who, the what, and the when.» https://t.co/32eiK5ih9a pic.twitter.com/9X7dFon0RV
#IWish people would move their sub-tasks along the Agile board without having to be reminded #RetroOnAgile
#IWish Teams won’t declare agile victory prematurely by merely doing stand-ups.
Unless we invest in:
a) a single prioritized backlog
b) KPIs and a DoD that we can get behind, and
c) feel empowered,
standing up won’t help. We might as well sit and do some work. #RetroOnAgile pic.twitter.com/3ou448YLbw
#IWish that stakeholders, peer-reviewers, & quality team-members could star an assignee’s work on a ticket. #RetroOnAgile pic.twitter.com/9tqkpSGgyP
#iwish @jira has «hide fields» option. It is issue-secured now but not field-secured. #RetroOnAgile
It would be super awesome to allow my customers to vote on JIRAs without eating up a license for login #RetroOnAgile @JIRA #JiraOnDemand https://t.co/Yj2fwz7DQq
#retroonagile I wish people played as a team. No aggressive jira Tix allowed
#IWish there was out-of-the-box integration between my automated unit tests and the columns of my scrum board. #RetroOnAgile
#IWish we are not surprised that the feature does not work during demo and be more in control #RetroOnAgile
#WhatIf we could make our agile board three dimensional? What other dimension would we add? #RetroOnAgile
#WhatIf The whole company practiced Agile, not just the developers? What would our teams look like? What could our teams accomplish? #RetroOnAgile
#Whatif we dare to trust and take the prime directive seriously not only for retro but for every day live #RetroOnAgile
#Whatif the agile way of getting things done would be taught very early on and would be the core of the way we get things done? #RetroOnAgile
#whatif, The way I seek Agile working in the next few years is having to accommodate BOT coders as part of the squad and dealing with BOT communication too #RetroOnAgile
#WhatIf Some agile techniques were taught early in schools so kids could benefit from them and learn how to plan their homework efficiently #RetroOnAgile
#whatIf certifications weren’t the criteria for hiring #agile practitioners #RetroOnAgile
I’d replace the word software with product in the manifesto #RetroOnAgile
#WhatIf we didn’t try to manage multiple products at once on multiple boards with a single #Agile team? #RetroOnAgile
— le Violon Chocolat (@ViolonChocolat) April 12, 2018
#WhatIf there was one menu where you could easily navigate between boards in JIRA? #RetroOnAgile
#WhatIf we ran daily sprints? would we have daily retros? #RetroOnAgile
#WhatIf the software industry moved from delivery of projects to delivery of outcomes? https://t.co/btLBb3fhU4 #RetroOnAgile @Atlassian
#WhatIf every user story was treated as an experiment and it’s impact easily measured #RetroOnAgile
#WhatIf we would keep agility rather that DO Agile? Plus we should mind that it require a lot of self-discipline. #RetroOnAgile
#WhatIf Scrum and Kanban weren’t the only ways to be agile? #RetroOnAgile
#WhatIf SEOs would work in agile sprints like developers?#RetroOnAgile
#WhatIf humans just be humans and bots did all the technical (or remaining) stuff (or vice-versa?) #RetroOnAgile
#WhatIf we stopped worrying about whether tools, practices, or people are Agile or not, and instead kept an open mind about new ideas that can help us work better together. #RetroOnAgile
#Whatif we could say in 12 months from know that 2018 was the year when #agile was eventually applied to business at large – on all levels, beyond software projects? #RetroOnAgile https://t.co/lyylkPgNeV
#WhatIf the agile community treated security and privacy as seriously as they treat daily stand-ups?#RetroOnAgile https://t.co/Twr8daFj3E
#WhatIf we stopped trying to make Agile fit with top-down management, budget-driven planning, and feature-bloated products? #RetroOnAgile
#WhatIf(Companies stopped investing on precise projects scope and rather invested in trusting capable agile teams who will deliver value continuously?) #RetroOnAgile
#WhatIf a user could report a ticket in one language and @Atlassian’s Jira could show it to the team in a second language? #RetroOnAgile pic.twitter.com/qPWDfpgcMG
#WhatIf @Atlassian’s JIRA could use estimate the probability that a checked in block of code would get reopened based on machine-learned, correlated factors. #RetroOnAgile pic.twitter.com/vQ8DTrzrWm
Зачем проводить ретроспективу?
Agile-ретроспектива была изобретена в 2001 году одним росчерком пера. Последний из двенадцати принципов agile-разработки гласит:
«Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы».
Манифест методики agile со всей ясностью заявляет: для лучшего соответствия ценностям гибкой методологии разработки команды должны регулярно встречаться для проведения проверок и внесения поправок. Обычно команды разработчиков следуют этому принципу, проводя регулярные ретроспективные встречи, и хотя эта страница посвящена именно таким встречам, это не единственный способ проведения ретроспективы.
Позже концепция ретроспективы вышла за рамки групп разработчиков и распространилась на все аспекты бизнеса и командной работы.
Мне знакомы маркетинговые команды, использующие ретроспективу при проведении кампаний, и команды менеджеров, которые применяют ретроспективу в больших презентациях — более того, компания Atlassian проводит ретроспективу в рамках всей своей отрасли. Такое принятие ретроспективы и ее распространение на все аспекты бизнеса очень воодушевляет.
Причина, по которой ретроспектива вызывает столько интереса, заключается в том, что именно сейчас начинается реальное активное испытание методологии agile. Многие ключевые концепции манифеста гибкой разработки укрепляются благодаря этим ретроспективным встречам. Обдумайте следующие ценности.
Суть ретроспективы заключается именно в работе с реальными людьми для внесения изменений и улучшений. Мало что может лучше подкрепить принципы agile-разработки. Теперь, когда мы разобрались, почему ретроспектива так важна, ознакомьтесь с информацией о том, как самим организовать такое совещание.
Помните, что мы проводим ретроспективу для улучшения текущего положения дел, поэтому если вы увлеклись методологией agile, участвуйте в нашей ретроспективе #RetroOnAgile и помогите определить будущее разработки программного обеспечения.
Подписаться
Оставайтесь в курсе ретроспективы #RetroOnAgile и других тенденций agile
Thanks for signing up!
Лучший продукт для agile-команд
Ретроспективное совещания
Ретроспективы — это отличная возможность для agile-команды оценить самих себя и составить план улучшений на будущее. Ретроспектива поддерживает идею постоянного усовершенствования и защищает от ловушек самонадеянности, заставляя выходить за рамки рабочего цикла, чтобы поразмыслить о прошлом.
Цель ретроспективного совещания заключается в следующем.
Ретроспектива предоставляет безопасное место, где можно сфокусироваться на самоанализе и адаптации. Для успешного проведения ретроспективы необходима атмосфера поддержки, которая поощряет вклад всех участников команды (но не принуждает вносить предложения).
Ретроспектива должна давать вашей команде положительный опыт и заряжать ее энергией. Она помогает участникам команды делиться важными отзывами, смиряться с разочарованиями и сообща находить решения. Организаторы тоже могут многое узнать для себя, в том числе лучше понять, как работает команда и какие трудности (и успехи) она пережила в последнем спринте. Результатом успешной ретроспективы становится список улучшений, за которые участники команды берут ответственность и к которым стремятся в следующем спринте.
Как провести вашу первую ретроспективу
Хотя бывает полезно изменять формат ретроспективы (подробнее об этом ниже), некоторые аспекты, такие как хронометраж, участники и общая форма, должны по возможности оставаться неизменными.
Когда
Для agile-команд, работающих по традиционному двухнедельному спринту, ретроспектива должна проводиться в конце каждого спринта. Для команд, где рабочий процесс находится ближе к методу Kanban, более целесообразной может оказаться ежемесячная или ежеквартальная ретроспектива. После развертывания крупных инициатив полезно также привлекать к участию представителей вышестоящего руководства; старайтесь обсуждать не конечный продукт, а совместную работу команды над ним.
Выделите на это от тридцати минут до часа в зависимости от того, сколько длился спринт и какой объем работы нужно охватить в обсуждении.
На ретроспективе должен присутствовать каждый участник команды. Руководит дискуссией организатор совещания: это может быть scrum-мастер, владелец продукта, или же можно передавать эту обязанность по всей команде. Смело привлекайте к обсуждению дизайнеров, маркетологов или других сотрудников, которые участвовали в текущем спринте или итерации.
Существует несколько способов разнообразить ретроспективу (о них мы поговорим позднее), но стандартный шаблон встречи выглядит следующим образом.
Разнообразие придает вкус жизни
Стандартизация ретроспективы — хорошая идея для постепенного укрепления стабильности и доверия со стороны команды. Однако организаторы могут попробовать несколько приемов, чтобы раскрыть дополнительные идеи, привлечь к участию новых участников команды или просто поддержать интерес.
Привлеките организатора со стороны. Обычно ретроспективу проводит Scrum-мастер или руководитель проекта, но вы можете пригласить гостя, который поможет провести следующую ретроспективу. Динамика может показать положительные изменения, если у человека, ведущего дискуссию, не будет личной заинтересованности. Более того, эта стратегия позволяет сотрудникам в организации понаблюдать за тем, как работают другие agile-команды, и позаимствовать полезный опыт для использования в своей команде.
Измените список подсказок. В конце концов, ретроспектива призвана выявить, что работает, а что нет. Но достижение этих хххх может означать хххх. Можете использовать для подсказки следующие варианты.
Пригласите руководство. После запуска крупного проекта пригласите на час представителя руководящей команды и сфокусируйтесь на обсуждении совместной работы команды (а не подробностей выполнения этой инициативы).
Существует множество способов внести улучшения, поэтому не стесняйтесь искать новые приемы самостоятельно. Независимо от того, пытаетесь вы наладить взаимодействие распределенной команды или улучшить недостаточно эффективный процесс проведения ретроспективы, главное — это сохранить вовлеченность команды и получить реальный план действий.
Подключайтесь к обсуждению!
Теперь, когда вы узнали основные положения о проведении ретроспективы, мы бы хотели услышать о ретроспективах вашей команды. Напишите в Twitter, начав сообщение с хэштегов #IWish или #WhatIf, и вы сможете увидеть свой отзыв на нашей виртуальной доске выше! Подключайтесь к обсуждению →
Изучите scrum с помощью Jira Software
Пошаговое руководство по ведению scrum-проекта, расстановке приоритетов в бэклоге, упорядочиванию работы в спринты, проведению scrum-собраний, другим вопросам — и все это в Jira.
Как провести agile-ретроспективу (с примерами)
Инструкции по проведению классических командных ретроспектив и возможные варианты таких совещаний. Техника, распространенная среди agile-команд разработчиков, которую теперь используют не только в сфере разработки ПО.