что такое ретро в agile
Ретроспектива Agile. Взгляд с точки зрения Lean
Ретроспектива является одной из священных традиций Agile в разработке программного обеспечения. Ретроспектива – один из двенадцати принципов в Манифесте Agile. Наконец, ретроспектива – одно из четырех регулярных занятий, описанных в руководстве по scrum (скрам). У каждой Agile команды, с которыми я когда-либо сталкивался, была ретроспектива. И все знают, для чего все это? Непрерывное улучшение! Это Святой Грааль, верно? Кайдзен! Истинное сердце Lean и Agile. Кайдзен означает «улучшения». И это изменения, улучшения, рост и обучение, верно?
Все это хорошо. Но никто не говорит вот о чем: ретроспективы – это не постоянное улучшение.
Медиапособие Виктора Вальчука «Конфликт сторон»
На предприятиях нередко возникают ситуации, когда интересы сторон расходятся. Одна сторона предпочитает одни действия и решения, а другая сторона — другие. Для таких ситуаций всегда можно построить диаграмму разрешения конфликта. Как всегда, конфликт имеет место быть вследствие того, что у одной или у обеих сторон имеются ошибочные убеждения. Их обнаружение позволяет найти прорывное решение.
Медиапособие для тех, кто хочет развить свои управленческие навыки и вывести карьеру на новый уровень, но не хватает времени. Включает полный разбор инструмента ТОС «Грозовая туча» для верного решения конфликта сторон (в т.ч. 2,5 часа видеолекций курса «Директор по трансформации»).
Что такое ретроспективы?
Ретроспективы – это регулярные действия, когда команда берет паузу и размышляет о том, как она работает, и находит способы работать лучше. Манифест Agile гласит:
Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.
Это довольно хорошее описание ретроспектив. Так в чем проблема? На самом деле их две. Во-первых, они не являются непрерывными. Во-вторых, они часто не имеют отношения к улучшениям.
Регулярные интервалы не являются непрерывными
Если вы делаете что-то раз в неделю, раз в месяц или раз в две недели, это не является непрерывным действием. На самом деле это называется «дискретным», что на самом деле является противоположностью непрерывного. Непрерывный означает «все время». Не какое-то время, не часть времени, не один раз время от времени, но все это чертово время. Ты никогда не перестаешь это делать. Это Кайдзен.
Ретроспективы часто не имеют отношения к улучшениям
Многие ретроспективы просто заканчиваются нытьем и жалобами. Что на самом деле неплохо. Иногда людям просто нужно дать волю чувствам. Но способ заставить людей клеить стикеры на доску, жаловаться на коллег, процессы или инструменты, а затем забывать про это или превращать в какое-то действие, которое ни к чему не приводит, не заслуживает термина «улучшение». (Помните, если вы не придумали конкретные действия с привязкой ко времени, назначенные реальным людям и отслеженные, вы делаете это неправильно).
Но это просто означает, что мы плохо проводим ретроспективы, верно?
Вы можете считать, что кто-то не умеет проводить ретроспективы. Конечно, можно делать их лучше или хуже. Некоторые команды суетятся и кричат друг на друга, не придумывают действия и / или не отслеживают их, и / или не реализуют их. Но на самом деле проблема глубже, и она связана с фундаментальной структурой и форматом ретроспектив. Они далеко отстают от проблем в пространстве и во времени. И это резко снижает эффективность ретроспектив. Непрерывное улучшение происходит везде, со всеми, все время. Это улучшение того, как люди работают в организации. Но это не специально организованная встреча один раз в две недели.
Непрерывное улучшение – не то, что вы думаете
Непрерывное улучшение – это старая концепция Lean, а не Agile, и это не эквивалент ретроспективы. Это фундаментальное изменение в структуре и культуре работы в организации.
Это ответственность всей организации
Это не то, что команды Scrum делают один раз спринт. Это то, что каждый практикует все время. Каждый в организации обязан постоянно исправлять и улучшать свою работу, устранять препятствия. Это должен делать каждый, начиная с рядового сотрудника и заканчивая генеральным директором. Технологии, маркетинг, закупки, все, везде, всегда.
Это происходит (в значительной степени) все время
Постоянное улучшение не означает, что время от времени вы перестаете делать то, что делали, и думаете о том, как все было раньше. Это не непрерывно. Думайте об этом так: почему люди поднимают проблемы на ретроспективе? Исправление проблем в том месте и времени, где и когда они происходят, является лучшим из возможных способов. Почему эти проблемы не были подняты тогда, а только теперь – на ретроспективе?
Если кто-то на ретроспективе говорит, что «программа сломалась в прошлую среду, остановив наше тестирование», почему это не было поднято, обсуждено, исправлено и навсегда устранено в прошлую среду? Если кто-то говорит «новая процедура утверждения замедлила мою работу», почему эта процедура не была сразу оспорена, улучшена или удалена?
Потому что это сложно. Действительно сложно. Большинство организаций не готовы поддержать такой подход к работе. Это настоящий кайдзен, Lean кайдзен, который я люблю переводить так: «остановись и исправь». Если вы видите что-то плохое, или неисправное, или медленное, или ненужное, или неправильное, тогда вы все останавливаетесь и сразу исправляете это, в том месте и в тот момент. Не через неделю, не через месяц, не в виде стикера на доске через три недели, прямо там и тогда.
Andon (андон)
На заводах Тойоты такие штуки называются «андон». Если кто-то обнаруживает проблему на конвейере, он сразу же тянет за шнур-андон. Вся линия останавливается. Каждый перестает выполнять свою работу, исследует и устраняет проблему. И следит за тем, чтобы она больше не повторилась.
Подумайте минуту о своей работе. Представьте, что каждый раз, когда кто-то сталкивался бы с глупым правилом, ненужным процессом, плохим инструментом, медленным или ошибочным программным обеспечением, он не мирился бы с этим. Он тянул бы за шнур, звал свою команду и менеджера и говорил: «вот это неправильно, мы должны это исправить». И все бросили бы все, что они делали, и исправили проблему навсегда. (Кстати, вы знаете, что не делают в Toyota? Ретроспективу спринта).
Вы, наверное, думаете: «Это безумие, так нельзя работать! Тогда ничего не будет сделано!». В этом весь смысл, и именно поэтому никто так не работает, и именно поэтому все плохо. Это трудно. И какое-то время (ненадолго) ничего не будет сделано. Но все начнет улучшаться по мере того, как давние проблемы будут исправлены навсегда. И люди смогут вернуться к своей работе, но они будут действовать по-другому: это кайдзен.
Это инструмент Lean, а не Agile
Непрерывное улучшение основано на кайдзен, то есть Lean. И это старый японский производственный подход, а не модный американский подход к разработке программного обеспечения. Это также подход для управления организацией, а не для управления проектом или разработкой продукта. Это не просто проведение традиционного для «водопада» обзора после внедрения (PIR), только в каждом спринте. Конечно, ретроспектива в конце спринта – это огромное улучшение по сравнению с обзором в самом конце проекта. Но одной ретроспективы и поддержки Манифеста Agile на их сайте недостаточно, чтобы даже заикнуться о непрерывном совершенствовании.
В одной из организаций, где я работал, был отдельный скрам для кайдзен, и еженедельный стендап вокруг доски с задачами кайдзен. Это не были проблемы, поднятые конкретной командой, а общие организационные улучшения. Очевидно, что делать кайдзен раз в неделю со стикерами – это не круто, но это был шаг в правильном направлении.
Я все еще считаю, что проводить ретроспективы нужно
Я не говорю, что всем нужно прекратить проводить ретроспективы. Они полезны и имеют свое предназначение даже в организации, которая пытается непрерывно совершенствоваться. И они могут дать возможность подумать о том, как преуспевает команда, пересмотреть показатели, сформулировать эксперименты и выявить неявные давние проблемы, которые никогда не проявлялись, потому что никогда не были острой и неотложной проблемой.
Они также являются важным первым шагом на трудном пути к непрерывному совершенствованию. И большинство компаний в мире не сделали даже этот первый шаг.
Но давайте не будем обманывать себя
Ретроспективы могут быть полезными и хорошим первым шагом, но они не являются непрерывным улучшением и не являются кайдзен. Всем, кто не понимает, откуда пришли эти идеи, я бы порекомендовал прочесть «Тойота Ката. Лидерство, менеджмент и развитие сотрудников для достижения выдающихся результатов» Майка Ротера.
Что такое ретро в agile
Agile-коуч Марк Лоффлер уверен: ретроспектива — отличный инструмент для начала положительных изменений в команде или во всей компании. Эта практика учит смотреть в прошлое, чтобы извлекать уроки, не цепляться за старые решения и вовремя корректировать курс. Но как провести ее впервые? Вот детальный план из книги «Ретроспектива в Agile».
Подготовка
Определите агенду ретроспективы. Она может выглядеть так:
Обратите внимание: здесь нет одного из этапов — проверки гипотез. Дело в том, что наша агенда рассчитана на команды, которые используют практику впервые или не определили гипотезы в прошлый раз.
Так выглядит полная модель ретроспективы
Когда агенда будет готова, отправьте приглашение всем участникам. Запаситесь флипчартом, маркерами, ручками, стикерами. Не забудьте забронировать комнату, и прийти за 15-30 минут до начала, чтобы успеть подготовить пространство.
Открытие: сравнение с автомобилем
В начале ретроспективы поприветствуйте участников и кратко объясните агенду. Если у команды есть устав, напомните всем о правилах. При отсутствии устава пропустите этот шаг, но в будущем организуйте воркшоп по его созданию.
Попросите участников сравнить период, который обсуждаете, с автомобилем. Каждый должен в нескольких словах описать машину, о которой он подумал. Приведите пару примеров: «ржавый старый фольксваген пассат» или «первоклассный ламборджини мурселаго». Участникам не обязательно следовать фиксированному порядку, но высказаться должны все. Не комментируйте ответы. Поприветствуйте каждый вклад.
Сбор данных
Объясните участникам суть работы. Пусть каждый использует стикеры, чтобы записать все, что делало его раздраженным, грустным или довольным в течение рассматриваемого времени. Оставьте специальное поле, чтобы присутствующие могли сказать спасибо одному или нескольким членам команды.
Нарисуйте большой крест на доске или флипчарте и пометьте четыре области
Совет: пока участники пишут на стикерах, ваша задача — задавать вопросы о четырех категориях, чтобы предложить несколько идей. Это мотивирует других продолжать записи, когда вы почувствуете, что команда остановилась. Например:
Используйте последние 5 минут, чтобы прочитать заметки и получить разъяснения от авторов. Прекратить писать можно именно в это время. По мере чтения стикеров группируйте их по темам. В большинстве случаев это дает представление о насущных проблемах. Выбрать пару тем, которые будут в фокусе на оставшуюся часть ретроспективы, можно двумя способами:
Голосование стикерами или точками
Генерация идей: «5 почему»
Методу «5 почему» исполнилось более 100 лет. Его идея заключается в том, что большинство очевидных на первый взгляд причин проблем — лишь симптомы, а корень зла лежит гораздо глубже. Простой пример: предположим, вы разрабатываете автомобили, но их никто не покупает. Вот ряд вопросов, которые в связи с этим вы можете задать, и возможные ответы на них.
Найти единственный ответ на вопрос «Почему?» не всегда возможно. Иногда существует несколько причин, которые, в свою очередь, могут иметь свои основания. Это нормально.
Определение следующих экспериментов: мозговой штурм
На этом этапе у каждого участника есть 5 минут, чтобы придумать максимум три идеи, которые, по его мнению, имеют самый высокий потенциал для положительных изменений. Участники пишут свои идеи, придерживаясь правила «Один эксперимент на один стикер». Затем стикеры размещаются на открытом участке стены.
Когда время истекает, каждый кратко объясняет свою идею. Требуется рассказать, каким, по его мнению, будет эффект эксперимента. Участники должны попытаться сгруппировать идеи по мере их публикации. Используйте круглые стикеры, чтобы выбрать идею, которая имеет наибольший потенциал для успеха. Соглашайтесь лишь на одну идею. Это может показаться странным, учитывая, что теперь команда готова попробовать множество вариантов. Но если хотите убедиться, что работа действительно выполнена, важно выбрать что-то одно.
Дайте участникам понять, что идея, которую они выбрали, — это эксперимент. Вы способны лишь предположить, каким будет эффект, но никто не может быть в этом уверен. Сейчас важно добавить к выбранному эксперименту гипотезу. Убедитесь, что она поддается проверке. Так вы закладываете основу для следующей ретроспективы, где будете сравнивать исходную гипотезу с тем, что на самом деле произошло в эксперименте.
Совет: выбранные эксперименты должны быть конкретными, исполнимыми, измеримыми и достижимыми (выполняться в течение нескольких дней или недель). Убедитесь, что группа имеет право проводить их. Наконец, эксперимент должен быть ограничен по времени.
Теперь осталось определить, кто отвечает за проведение эксперимента и когда это произойдет. Объясните другим, что ответственный не обязательно должен делать все самостоятельно.
Закрытие: возврат на вложенное время (ROTI)
График, который поможет дать оценку ретроспективе
А теперь проведите ретроспективу о ретроспективе. Для этого часто используется график ROTI. Чтобы создать его, нарисуйте оси x и y, а затем диагональную линию, пронумерованную от одного до пяти. Единица означает: «эта встреча — пустая трата времени», тройка — «встреча стоила того времени, которое я на нее потратил», пятерка — «встреча замечательная, потраченное время полностью окупилось». Чтобы график принял завершенный вид, каждый участник ставит на нем крестик, отражающий его мнение. На рисунке выше видно, что команда довольна своей ретроспективой.
Поздравляем, вы провели свою первую ретроспективу! Пусть такие мероприятия станут регулярными, помогают учиться как на успехах, так и на неудачах, а хорошее делают еще лучше.
Ретроспектива спринта. Как сделать её интересной и продуктивной?
Для чего проводится ретроспектива в команде? Какова её цель? Прежде всего ретроспектива нужна для инспекции прошедшего спринта применительно к людям, отношениям, процессам и инструментам, а также для адаптации рабочего процесса или продукта.
В процессе проведения ретроспективы команда должна выявить и понять, что в спринте прошло хорошо, а что не очень и по результатам общения попробовать выработать план по улучшению продуктивности и сплочённости.
Каждая команда проводит ретроспективу по-разному и по разным причинам: кто-то для поддержания командного духа, а кто-то для определения недовольства или выявления причин провального спринта. Важно, чтобы ретроспектива, прежде всего, была живым мероприятием. Проведение ретро по стандартным шаблонам, скорее всего, приведет это мероприятие в разряд формальных и, со временем, команда потеряет к ней интерес. Члены команды будут с неохотой участвовать или вообще стараться под различными предлогами избегать ретро.
Для поддержания командного духа и привлечения интереса к данному мероприятию часто приходится придумывать различные форматы, вносить новые идеи и делать ретроспективу интересней и необычней. В этой статье хочу рассказать о тех инструментах, которые я использую и, возможно, вы сможете использовать их у себя в командах. Итак, приступим.
Классическая структура ретроспективы состоит из 5 шагов:
Важно отметить, что проценты могут варьироваться исходя из специфики вашей команды. Рекомендованная длительность проведение ретроспективы — не более 3 часов. Как правило, для двухнедельного спринта команды из 9–12 человек ретроспектива проводится за 1–2 часа.
Перед проведением ретроспективы очень важно подготовить команду к этому мероприятию. Постарайтесь немного отвлечь команду от текущих работ – проведите небольшую разминку. Поверьте, это поможет каждому члену команды “переключиться”, выйти из своего кокона и быть более открытым для общения.
Можно использовать огромное количество разминок. В интернете их довольно много. Но я бы хотел рассказать о тех, которые мне нравятся больше всего.
Необходимо взять стакан / кружку и поместить туда m&m’s или skittles. По очереди каждый член команды вытягивает из стакана по 1 конфете и отвечает на вопрос:
Цвет конфет и вопросы могут быть совершенно любыми.
Если команда собирается в чате / конференции, вместо конфет можно использовать рандомайзер (генератор чисел). Например, вы можете включить демонстрацию экрана в приложении, например: discord, zoom. Называете члена команды и на сайте генерируете случайное число (от 1 до N, где N – максимальное число вопросов). Задаёте вопрос исходя из полученного номера.
Отличная разминка, позволяющая членам команды выражать признательность друг другу. Большинство из нас настолько заняты работой, что забывают благодарить членов команд за помощь или поддержку. Каждому члену команды очень важно чувствовать, что его ценят.
Если вы проводите встречу вживую, то рекомендую заранее распечатать карточки. Если нет времени – можно написать на стикерах какой цвет отвечает за ту или иную карточку.
Шаблоны cudo cards можно скачать тут.
Раздайте каждому члену команды стикеры / карточки. Дайте несколько минут на заполнение. После чего каждый член команды рассказывает что он написал и клеит свои карточки на доску благодарности. Оставьте доску висеть в помещении на некоторое время. Пусть она радует коллег!
Это мероприятие прекрасно подходит как для спринтов, где все прошло хорошо, так и тех, в которых все пошло наперекосяк. В первом случае разминка послужит отличным стимулом для мотивации команды, во втором – напомнит всем, что даже в трудные времена члены команды ценят друг друга.
Хотите провести разминку удалённо? Не вопрос. Можете сделать это, например, в Miro.
Сверху укажите карточки определённого цвета с формулировкой. Дайте команде 10 – 15 минут на заполнение карточек. После чего попросите перенести карточки на доску.
Многие члены команды могут умалчивать о некоторых проблемах во время проведения ретро. Сбор обратной связи (анонимной) поможет разобраться в проблемах, которые видно со стороны, но не “подсвечиваются” при обсуждении.
В качестве сбора обратной связи можно использовать различные опросы или тесты, например:
Быстрый способ собрать обратную связь по спринту.
Запишите полученные результаты в таблицу:
Используйте данные, полученные по результатам опроса, для ретроспективы. Постарайтесь направить команду на обсуждение проблемных зон, а также не забывайте подчёркивать успехи команды.
Тест позволяет оценить взаимоотношения в коллективе, заинтересованность сотрудников в получении результатов и их мотивацию.
Принцип тестирования не сложен. Каждый член команды независимо от должности заполняет вопросник в который входит 84 утверждения. Затем по специальной таблице выполняется подсчет результатов и их анализ.
В данном тесте вопросы могут быть совершенно любые. Постарайтесь вспомнить те моменты, которые не понравились команде на предыдущих planning. Тест позволит понять смогли ли вы решить часть проблем, которые обсуждала команда.
Собирайте статистику для понимания проблем, сильных и слабых сторон команды. Через некоторое время запустите этот же опросник и сравните результаты.
(Начать / Прекращать / Продолжать)
Это метод систематизации мнений позволит команде понять текущие проблемы и предложить варианты их решений.
Каждый член команды должен за отведенное время ответить на следующие вопросы:
(Расстроило / Разозлило / Порадовало)
Это метод хорош тем, что позволяет каждому члену команды выпустить пар и рассказать о наболевшем. Быть выслушанным уже само по себе немаловажно. Но не забывайте, что конструктивный негатив должен быть уравновешен позитивом. Не допускайте “токсичности” в команде.
Базовый ретроспективный метод, который фокусируется на сильных и слабых сторонах вашей команды.
Этот метод хорошо подходит для ретроспективы, когда команда уже давно работает над одним проектом / продуктом.
Простой и понятный метод, которых отлично подойдет, если вам необходимо выделить как положительные, так и отрицательные моменты.
Как вы могли уже заметить, способы сбора данных примерно одинаковы. Разница лишь в задаваемых вопросах. Если вашей команде наскучило проведение классических ретро, попробуйте придумать свои вопросы. Например, вашей команде выделили бюджет на обучение, можно выяснить, какое из направлений обучения интересует каждого члена команды. Создайте 2 колонки с вопросами: «Что я хочу изучить для повышения компетенции?», «Что я хочу изучить для личностного роста?»
После получения ответов на вопросы, каждый член команды должен выбрать до 3 вопросов (стикеров), которые, по его мнению, он считает важными. Если встретились вживую, можно провести голосование точками, отлично подойдут маркеры разного цвета. Каждому члену команды можно оставить по 1 точке на стикер (Заранее решите командой лимит голосов). После того, как вся команда проголосует, необходимо выделить от 3 тем, за которые отдали большинство голосов. Обсудите их с командой, попробуйте найти способы решения, если это проблема или поговорите о том, как улучшить то, что уже имеется. В случае, если команда нашла вариант способа решения проблемы, зафиксируйте ваши решения как «Action point» и назначьте по одному ответственному на каждый стикер. Можно составить «Action Plan» (Who, What, When), если это необходимо.
В начале следующей ретроспективы обязательно пройдитесь по предыдущим Action points. Узнайте у ответственных, получилось ли решить проблему.
P.S. Очень часто бывают action points на проблемах, которые невозможно решить на уровне команды. Просто запишите эту проблему — пусть она хранится в вашей wiki системе.
Цель закрытия – подвести итоги, высказать коллегам благодарность за терпение и похвалить за продуктивную работу. Попробуйте получить обратную связь:
Или просто расскажите анекдот, поздравьте коллегу с прошедшим днём рождения.
В общем, завершите ретроспективу на позитиве!
One to one – это мероприятие, позволяющее узнать членов команды получше. Узнайте, что движет человеком, что его мотивирует, какие у него интересы, чем человек занимается в свободное время и какое направление он хочет развивать. Узнайте мнение собеседника об атмосфере в команде, получите обратную связь.
Кто должен проводить? Желательно, teamlead, но можно и PO/PM/SM.
Как проводить? Желательно проводить one to one вместо ретроспективы в формате конфиденциального дружеского разговора, а не начальника и подчинённого. В течение спринта teamlead (PO/PM/SM) назначает встречу с каждым членом команды на 30 минут.
Очень важно, чтобы организатор грамотно подходил к собеседнику и находил к каждому индивидуальный подход. Некоторые члены команды могут быть скептически настроены, поэтому перед началом разговора объясните коллеге цель встречи.
Можно использовать множество различных инструментов. Перечисляю те, которыми пользуюсь сам:
1. Google forms – для тестов и опросов;
2. Retrium – проведение классических ретроспектив + Team radar;
3. EasyRetro – проведение классических ретроспектив;
4. Miro – для разминок и не только. При должном желании и подходе можно проводить ретроспективы.
Ретроспективы 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-команд разработчиков, которую теперь используют не только в сфере разработки ПО.