Ретроспективы в командах: Артефакты ретроспектив

Это предпоследний пост в данном цикле.

Итак, вы провели ретроспективу, но радоваться рано.
Реально процесс встанет на (какие-то) рельсы когда вы будете делать в интервале между ретроспективами делать все те улучшения/изменения, которые захотели сделать.

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

Вернемся к артефактам.
Артефактов у вас будет (условно) три типа:

1. Список задач и/или карта их выполнения - это из предыдущего поста.
2. Конфликты и социальные игры в процессе ретроспективы - про них я первоначально писал тут.
   
   Социальные игры и конфликты являются для вас довольно ценным материалом. Вообще, наблюдение за людьми в процессе того, как они делают ретроспективу для фасилитатора этой самой ретроспективы является ценнейшим материалом, особнно если фасилитатор проводит ретроспективу с командой не в последний раз.
   
   Ретроспектива сама по себе является дополнительной нагрузкой. Люди, на уровне подсознания, довольно быстро запоминают что это труд, поэтому "внутренний лентяй" каждого человека старается максимально быстро и жестко уйти от вопросов и тем на ретроспективе которые могут нагрузить его, лентяя, какими-то улучшениями. Мне даже кажется что это один из отличных примером того как работает быстрое и медленное мышление описанное Каннеманом в Thinking Fast and Slow и Талебом в Черном Лебеде.
   
   Социальные игры и прессинг могут рассказать вам о том, как на самом деле обстоит рабочий процесс в команде (не сваливают ли разработчики недоделанные таски на тестирование ? все ли хорошо с требованиями и декомпозицией задач?).
   Процессные и организационные "дырки" и костыли, которые всплывают на ретроспективе безусловно нужно обсуждать и решать сразу - это и есть улучшения.
   Но вот игры и взаимоотношения порешать на ретроспективе не получится - это то, что должно выстраиваться в процессе ежедневной работы. И это вполне возможно может стать вашей работой за рамками ретроспективы.
   
   Еще один нюанс  - социальные игры происходят не только на ретроспективе, но и за ее пределами, поэтому не стоит удивляться что команда пришла к вам на ретроспективу "перейдя на следующий уровень игры". 
3. Нежданчики - задачи и мероприятия, проведение которых не планировалось на ретроспективе, однако в процессе проведения улучшений/изменений оказалось необходимым - это, пожалуй, самая интересная категория, особенно для тех кто только начинает.
   
   Неожиданно может всплыть все что угодно. Правда чаще всплывает то, что все старались забыть. но не исправить :).
   Краткая типология нежданчиков:
   
   Нежданчики-задачи.Плаинровали сделать А, но выяснилось что это блокируется B и С, которые  в свою очередь упираются в задачу D соседнего подразделения.  Или А увеличилась в размерах на порядок. Вывод: плохой анализ на ретроспективе, плохое понимание взаимосвязей в проекте.
   
   Нежданчики-люди. Таск поручили делать Васе, но Вася не понял что нужно делать, впряг в это Колю. Коля мог сделать или не сделать свои задачи по результатам ретроспективы, попутно выполнить Васины. В общем с точки зрения внешнего наблюдателя задачи могут быть выполненными или не выполненными, но явно не теми людьми, которыми планировалось. Такое вот неожиданное поведение от людей может сыграть как в лучшую так и в худшую сторону. Все, что оно дает вам как фасилитатору - лучшее знание о команде и способностях людей. Бывает так что самый молчаливый и забитый интроверт в команде является самым суровым "real fuckin do'er-ом" - это нужно знать и использовать во благо.
   
   Нежданчики-информация. Решили что-то улучшить, но нашли такое, что не знаем что делать дальше. Тут ве очень зависит от контекста. Встречал такую ситуацию пару раз в жизни когда приваливал проект который до этого делали другие люди и оставляли за собой "мины". Вообще, любой "угловое знание" о том, что вы делаете обычно идет в плюс нежели в минус. Другой вопрос - почему вы этим знанием не обладали ранее ?
4. Любые рисунки, схемы, описания процессов - все что создается на ретроспективе руками участников - должно быть тщательно (но не навязчиво!!!) задокументировано и сохранено. Я обычно использую для этого телефон и забираю с собой листы флипчарта. Результаты любой из ретроспектив могут пригодитя вам при проведении следующей. поэтому лушче хранить их в электронном виде и структурировано.  

Данный список и классификация никоим образом не претендуют на истину в какой бы то ни было инстанции - дополняйте, расширяйте , переделывайте под себя.

Буду рад ответить на вопросы.

Ретроспективы в командах: Отбор проблем и анализ

Проолжаем начатое тут и продолженное тут.

Отбор проблем.

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

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

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

Второе - не кидайтесь сразу что-то с ней делать, остановитесь, посмотрите на нее, прочитайте все пункты/стикеры еще раз, убедитесь, что все что там написано вам и всем остальным понятно.

Второе с плюсом (только для фасилитатора) - попробуйте проанализировать есть ли или могут ли быть связи между проблемами.
Если есть хоть малейшее подозрение что да - надо привлекать весь коллектив к анализу.
Даже если описанные проблемы кажутся независимыми - то лучше все равно задать вопрос всем.
Тут можно просто прямо послать вас читать замечательную статью Хенрика Книберга про Root-Cause Analysis, и я конечно это сделаю, но надо дополнить.
В любой команде есть определенная емкость терпения/сил/времени/бюджетов для решения любых проблем. И эти бюджеты очень плохо переносят дефициты.
С одной стороный эта емкость ограничивается заказчиком/владельцем продукта который вряд ли одобрит улучшайзинг на политерации, а с другой отсутствие поставки ценности для заказчика - это очень сильный демотиватор для команды.
Поэтому выявление корневой причины и анализ причинно-следственных связей - важен, потому что точное и точечное улучшение лучше чем генеральная уборка во всех углах.

Окей, для простоты картины представим, что взаимосвязей между проблемами у вас нет и они изолированы.

Третье - выбираем проблемы. Тут опять же есть место для социальных игр, про которые я писал ранее.
Я предпочитаю голосование точечками - каждый участник ретроспективы ставит точку (или магнитную точку, такие тоже есть в канцелярских магазинах) напротив той проблемы, которую считаает самой важной для решения.
У каждого члена команды есть право поставить три точки. Почему три ? Опять же правило по-умолчанию.
Если ваша команда настолько крута в области улучшений своего собственного процесса - то можете взять хоть 7.
Только аккуратно - предпочтительно внедрять улучшения по-одному, чтобы понимать какое улучшение какой эффект дает. Если у вас три улучшения в разных областях или даже два из них пересекаются, то отделить эффект одного от другого довольно просто. Если у вас их 7 - то уже сложно.

Второй аспект который касается количества отбираемых проблем для решения состоит в том что это только те проблемы которые вы ХОТИТЕ решить, но не факт что решите. и что еще
хуже не факт, что решите ДО КОНЦА. Это ваши эксперименты с вашим собственным процессом работы, которые вы сами над собой, коллегами и процессом будете ставить. И не факт, что эксперименты будут успешными. Вполне возможно что их придется откатывать, при том делать это не после следующей ретроспективы, а "на горячую", в процессе основной деятельности.

Процесс голосования довольно важный момент - на нем можно увидеть есть ли у команды единодушное мнение о главных проблемах, или это мнение размыто.
Опять же, это отличный момент для фасилитатора "попробовать продавить" решение "главной" проблемы команде  - только помните что делать это нужно не на первой ретроспективе и ОЧЕНЬ аккуратно.

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

Итак, голосование завершено, топ-3 проблем собран, переходим к следующему этапу, предварительно сделав фото доски.

Анализ проблем.

Берем проблему с наибольшим количеством голосов и пишем в верхней части доски/флипчарта.
Дальше начинаем анализ проблемы любым удобным вам способом.
Тут я хочу сослаться на книгу Дэвида Стрейкера - она будет являться отличным методическим пособием для вас на этой стадии - в ней есть кусочек методологии в связке с инструментом (стикерами).

Достаточно часто бывает так, что проблема "проседает" под тяжелым взором всех участников команды - это значит что все чего им не хватало для решения этой проблемы - это собраться вместе и поговорить. Радуйтесь - вы только что получили +1 в карму фасилитатора. Эту "просевшую" проблему нужно разложить на таски и впихнуть в бэклог.

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

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

Ваша задача в таком случае - за минимальное количество времени и ресурсов максимально достоверным способом отсечь ветви не достойные дальнейшего внимания.

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

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

Итого по результатам анализа вы должны получить:
1) список задач которые прольют свет  на непонятные вам моменты (гипотезы и предположения), либо напрямую  улучшат ваш процесс
2) схему увязки этих задач в единое целое, как путь от частных задач к большому улучшению.

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

Сформированные задачи вам нужно будет воткнуть в бэклог, но тут уже у каждого все по-своему.

Оформленные результаты ретроспективы (карту, блок-схему, список задач, прочее) нужно разослать на всех участников ретроспективы.
Опять же полезная практика - в отправляемом письме обозначить список задач и кто за них ответственный.


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

Продолжать повествование относительно данного этапа ретроспективы считаю непродуктивным, если какие-то вопросы остались неосвещенными - добро пожаловать в комменты.

Ретроспективы в командах: Начало и сбор данных

Продолжу начатое.
Про общие моменты я рассказал в прошлом посте, теперь ближе к конкретике.
Сегодня поговорим про то как начинать ретроспективу и собирать данные.
Я приведу картинку из презентации Бориса Вольфсона на которую ссылался раньше - самому рисовать лень.

Итак вы собрали своих коллег или подчиненных в одной комнате, отрезали им путь к отступлению и вот-вот начнете ретроспективу.

С чего начать это действо?
Я рекомендую с подготовки самого себя и мероприятия.
Что нужно сделать:

1. Забронировать переговорку
2. Листы А3 и больше, маркерная доска или флипчарт тоже подойдет.
3. Маркеры
4. Можно стикеры, можно без них.
5. Если есть возможность - вода в бутылках 
6. Пара явных проблем или хороших моментов, которые уже можно повесить на доску
7. Результаты улучшений с предыдущей ретроспективы (если они есть и если положительные)

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

Начало.

Вот теперь точно все - все кто нужен все в комнате, доска или листы на которых можно визуализировать подготовлены, можно начинать. А с чего начать? Этот вопрос стоит еще более остро если вы делаете ЭТО в первый раз.

Лично я задумался над этим вопросом тогда, когда пригласил на ретроспективу  команды сторонних людей.
И вот тут встала задача: с одной стороны у меня есть команда которая уже знает и понимает что к чему, с другой - люди которые вообще в этом вот первый раз, и надо быстро привести мозги вторых к состоянию мозгов первых - вопрос как ?

В таком случае я рекомендую начать с мантры.

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

Это очень вольная трактовка, дословно в оригинале звучит так "В независимости от того, что удастся выяснить в результате ретроспективы, каждый член команды сделал всё, чтобы добиться успеха".

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

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

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

Один знакомый рассказывал что команда которая делала ретроспективы три года практически одним и тем же составом. Для того чтобы попасть в комнату где проводилась ретроспектива им всем нужно было пройти через длиннющий коридор между зданиями. Так вот по наблюдениям моего знакомого после полутора лет проведения ретроспектив  у членов команды чуть ли не автоматически врубался ретроспективный режим при прохождении коридора (привет Павлову и сигнальной системе).

Сбор  данных.

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

У нас она выглядит так.

Названия колонок мы обычно не пишем, а рисуем смайлики.
Почему именно такие колоки? Выработано методом проб и ошибок. В настоящий момент команда является географически распределенной, поэтому есть специальная колонка "Просто  было" которая позволяет свести  воедино видение всех членов команды о самых значимых событиях за рассматриваемый период. Иногда из этой колонки удается узнать что-то интересное.

Про колонку "Хорошо" рассказывать особо нечего. Если команда не видит у себя ничего хорошего - то это с одной стороны проблема которую уже надо решать, а с другой стороны у нормальной команды эта колонка всегда самая "худая" - в колонке "Плохо/Улучшить" всегда больше.

Вот тут вот Денис Миллер пишет что колонка Плохо - она для нытиков, у настоящих джедаев колонка называется "Улучшить".  Мне такая мысль не нравится по той причине, что получается так, что настоящие джедаи приходят на ретроспективу с уже проанализированной проблемой, и точно знают что надо улучшать. В моей практике я чаще вижу обратное - люди могут формулировать несколько проблем, которые имеют одну общую корневую причину, но не догадываться об их взаимосвязях.

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

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

При сборе данных нужно соблюдать несколько рекомендаций:

1. Каждый может написать то, что считает нужным в любую колонку
2. Мнения могут расходится и это нормально (такая халява для фасилитатора бывает, но редко :)). Расхождение мнений как раз отличный материал для дальнейших обсуждений. 
3. Каждая записанная мысль должна быть понятна всем участникам (и переформулирована так чтобы была понятна )
4. На ретроспективе нет никаких "Они плохие", есть только "Что мы можем с этим сделать?"

После определенной степени зрелости может наблюдаться следующий эффект - один из учатсников ретроспективы формулирует проблему, описывает ее окружающим, завязывается обсуждение в результате которого проблема трансформируется в конкретную последовательность шагов для ее решения. Эти шаги нужно сразу же записать в список улучшений. Помещать ли в этом случае проблему на доску ? Я думаю нет. Но вот подумать почему проблема, которая решается банальным обсуждением и составлением списка задач, доживает до ретроспективы - я бы подумал. Это может быть следствие другой проблемы.

Теперь хочется рассказать немного о том чего следует избегать при сборе данных.

Социальные моменты при сборе данных.

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

1. Конфликт между двумя и более участниками команды. Обостряется когда один из конфликтующих вывешивает проблему на доску, а оппонент(-ы) начинают "запинывать" проблему в обсуждении пытаясь убедить всех что это не проблема.
2. Решение проблемы большинства. Ситуация: в команде 5 разрабов и 1 тестировщик. Вполне естественно что 5 разрабов видят может быть в 5 раз больше проблем в разработке, чем один тестировщик в тестировании. Но это совершенно не повод не обсуждать и не решать проблемы связанные с тестированием.
3. Проблема-беспризорник. Вся команда знает что существует проблема, но никто не хочет вешать ее на доску чтобы потом самому же ее не решать.  Обычно это признак глубокого технического долга и не первой стадии морального разложения коллектива. Частный случай данного паттерна - решение только "удобных" проблем или переформулирование проблемы тактм образом чтобы не касаться ее действительного решения.  
4. Проблема не на нашей стороне. С наличием проблемы все согласны в ходе сбора данных, но она вдруг становится "не нашей" проблемой, в ходе ее более глубокого рассмотрения.
5. Нытье. К сожалению это так -  если вам удалось внести людям в голову ощущение безопасного места для анализа происходящего, то они могут начать ныть. Это бывает, можно даже сказать что бывает со всеми время от времени. Мой рецепт тут прост - дать время наныться, а потом методично загонять в сторону решения проблем. Просто "нажать" на одного конкретного "нытика" или "нытиков" нельзя - таким простым движением вы показываете внутренним нытикам каждого человека  (а они есть у каждого в той или иной степени)  что здесь ему - нытику - не безопасно.
     

Это те социальные моменты которые встречались мне, список естественно может меняться.

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

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

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

Писать далее общие мысли на тему сбора информации лень, с удовольствием отвечу на вопросы.

Ретроспективы в командах: Общие моменты

А еще вчера вечером я был на CodeFreeze с Борисом Вольфсоном про ретроспективы и думаю что я напишу ряд постов про эту практику.

То что я когда-то пообещал начинаю претворят в жизнь.
Почему я об этом пишу?
Потому что за 7 лет работы в отрасли я убедился в эффективности этой практики и честно считаю, что данная практика должна использоваться шире.
Потому что каждый год я провожу порядка 10 ретроспектив и накопился кое-какой опыт.

Здесь не будет теории на тему ретроспективы, здесь будут мои мысли и опыт на тему ретроспектив. Хотите теории - смотрите выступление Бориса Вольфсона и презентацию.
Это первая часть, здесь я расскажу про общие моменты - те моменты про которые лучше знать до того как вы начнете этим заниматься.

0. Все идет от тебя.
Очень редко звезды становятся в такое положение, что все участники ретроспективы настроены именно на ретроспективу и будут конструктивно обсуждать проблемы, искать пути их решения. Бывает, но редко. Поэтому ретроспективе нужен ведущий или фасилитатор.
Это вы - менеджер, лидер, или просто человек заинтересованный в том чтобы что-то стало лучше. Без вас и вашей готовности - не будет ничего.


1. К ретроспективам нужно относится как к капитальной инвестиции.
Ретроспектива помогает вам и вашей команде учится у самих себя.
На это нельзя забивать, это нельзя переносить и тем более пропускать.
И ваша задача как руководителя, тимлидера или просто человека заинтересованного в том чтобы процесс ретроспектив был обязательным, эффективным и регулярным.
Этот процесс не построит сам себя, его никто не построит у вас под заказ.
Это можете сделать только вы. И вы же должны будете его поддерживать.
Это произойдет не быстро, с муками и проблемами, но другого пути я пока не видел.


2. Про регулярность.
Рекомендую как минимум для начала пользоваться простым правилом:

конец итерации = ретроспектива.

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

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

Ретроспектива, которая делается в конце проекта называется Post Mortem и помогает как вскрытие грудной клетке при насморке.

3. Ретроспективы, скоупы, бэклоги и как оно друг с другом связано.
Результатом каждой ретроспективы для команды является список задач по улучшению их собственного процесса разработки.  Список задач составляется с использованием мантры Кто-Что-Когда, но вот про Когда - есть один нюанс.
Сроки могут быть не очень жесткими. По умолчанию - точно должно быть сделано до следующей ретроспективы и проверено что улучшение работает как и ожидалось. Или не как ожидалось и надо думать что делать.

Если вы практикуете любое из течений Agile, то список задач по улучшению становится частью вашего бэклога на следующую итерацию. Обязательно становится. Тут никаких отмазок быть не может. Ввиду этого в вашем маленьком уютненьком agile мирке все должно быть устроено так : итерация - демо - ретроспектива - планирование  - и никак иначе. Ретроспективы до демо быть не может - все надеюсь понимают почему.
Планирования до ретроспективы быть не может - потому что вы еще не подумали как вы на следующей итерации будете делать свою работу лучше.

Тут можно попробовать возразить, сказав что заказчик или его product owner порежет любые таски которые не входят в скоуп разработки. И, да - порежет если вы ему такую возможность дадите. То как вы выпускаете ему софт  - это зона вашей компетенции. То как вы планируете объем задач на итерацию - это тоже зона вашей компетенции. Если не вы его планируете, а заказчик/менеджер/владелец продукта - то у вас уже есть серьезная проблема, которая заключается в доверии между вами и заказчиком.
Я не призываю  вас делать улучшения партизанскими методами, хотя и про такие случаи я слышал, я призываю вас договариваться.  И договоренность эта очень проста: "каждую итерацию мы тратим 1/5/10/20% времени на улучшение процесса".

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

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


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

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

По той же инерции мышления ретроспектива не бывает менее чем на 1,5-2 часа  - люди приходят на нее с какими-то своими мыслями в головах и им нужно их аккуратно сложить, включить "режим ретроспективы", вспомнить и подумать.
Моя рекомендация  - планировать не меньше двух часов - больше можно.
Вполне себе допустимо что после того как вы провели ретроспективу в офисе вы полным составом отправитесь пить чай-кофе/пиво/ужинать все вместе и там она продолжиться в более неформальной обстановке.  Это нормально и даже хорошо, главное не забыть с собой ручку и бумагу :).

Ретроспективу лучше проводить не в том помещении в котором вы постоянно находитесь, и уж точно не сидя за компьютером.
Лучше переместиться в другое помещение - переговорку, комнату - это выводит людей из зоны комфорта зато позволяет вам быстрее перевести их в нужный режим работы.
Никаких ноутбуков, планшетов, телефонов.
Телефоны на время ретроспективы на беззвучный режим и в дальний угол комнаты - потеря внимания для любого участника ретроспективы  - это продолбанная ретроспектива.

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

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