Я призываю мою нынешнюю команду принять изменения процессов и рабочих процессов, чтобы быть более гибкими. У нас приближается наша первая ретроспектива, и я ищу несколько советов о том, как провести ретроспективу воодушевляющим образом, который побудит людей принять хотя бы некоторые изменения.
Я поговорил с другими разработчиками, нашим QA-парнем и менеджером команды об их мыслях и опыте. На данный момент, кажется, есть некоторое общее мнение о положительных изменениях, но также не так много опыта работы с Agile-процессами или рабочими процессами.
Среди предложений, которые, по моему мнению, имеют точки соприкосновения с несколькими товарищами по команде, следующие:
Помимо разговора с товарищами по команде об общих принципах, их проблемах и опыте, как мне провести настоящую ретроспективу с остальной частью команды?
Предполагая, что мы можем продолжать проводить периодические ретроспективы, что можно посоветовать, чтобы наилучшим образом использовать ретроспективы для внесения даже постепенных изменений в наш процесс?
Не обращая внимания на тот факт, что по крайней мере некоторые из ваших пунктов повестки дня кажутся по своей сути анти-паттернами Scrum (пожалуйста, спросите, почему в отдельном, но связанном вопросе, если вы действительно хотите знать), вы и ваша команда приближаетесь к Ретроспективе Спринта . событие неправильно, рассматривая его в первую очередь как упражнение по совершенствованию процедур или инструментов. Хотя иногда это и является конечным результатом, это не совсем суть мероприятия.
Руководство по скраму 2021 довольно четко объясняет цель ретроспективы, но я выделил некоторые элементы жирным шрифтом для акцента:
Скрам-команда проверяет, как прошел последний спринт в отношении отдельных лиц, взаимодействий, процессов, инструментов и их определения готовности. ... Предположения , которые сбили их с пути, выявляются и исследуются их истоки . Скрам-команда обсуждает , что было хорошо во время Спринта, с какими проблемами она столкнулась и как эти проблемы были (или не были) решены .
Другими словами, цель улучшения процесса не начинается с маркированного списка исправлений. Наоборот, это исследование всего командного процесса, когда команда стремится определить, что прошло хорошо (чтобы они могли делать больше таких вещей), а что не очень хорошо , чтобы вся команда могла сотрудничать в процессе. решения, которые могут быть согласованы, проверены и измерены.
Хотя это, безусловно, хорошая идея — попытаться определить что-то действенное в ретроспективе, что, вероятно, приведет к ощутимому улучшению процесса, на самом деле именно общение и сотрудничество внутри команды создают возможность учиться, расти и постоянно совершенствоваться как команда. Отправляясь на Ретроспективу Спринта со списком потенциальных решений, а не с форматом, в котором команда чувствует себя в безопасности, честно и коллективно определяя muda , mura и muri , вы уже украли реальную ценность мероприятия (всей команды). сотрудничество и готовность вместе проверять и адаптироваться) и заменил его заранее подготовленным упражнением по поиску решения. Не делай этого!
Я предполагаю, что вы используете Scrum.
Для команды, которая относительно плохо знакома со Scrum, первые несколько ретроспектив больше направлены на то, чтобы научиться решать проблемы самостоятельно , чем на реальное решение множества проблем.
Вы играете роль скрам-мастера? Если да, то вы могли бы исследовать некоторые потенциальные ретроспективные форматы. Вероятно, наиболее распространенным из них является сбор отзывов о спринте от команды, группировка похожих отзывов, а затем голосование команды по темам, которые они хотят обсудить в первую очередь.
Ключевым моментом здесь является то, что команда должна разработать шаблон выявления своих проблем, а затем предлагать решения для них. В роли Scrum Master вы часто можете помочь в этом, предоставив им информацию. Например, вы можете сказать что-то вроде:
«У нас было довольно много проблем с промежуточной средой в этом спринте, я насчитал 4, и они были разрушительными. Возможно, стоит рассмотреть это с учетом ваших отзывов».
Чтобы было ясно, вы не устанавливаете повестку дня собрания. Вместо этого вы предоставляете информацию для рассмотрения командой. Важно, чтобы команда научилась хорошо распознавать проблемы , поэтому скармливать им проблемы с ложечки — не лучший вариант.
ДэйвГ
Робомедведь
Тодд А. Джейкобс
Богдан
ДэйвГ