Обо всем понемногу и об Agile-позитиве

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

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

Но теперь о новостях. Уже пара дней, как я на работе и все безумно и нещадно закрутилось. Для начала я очень обрадовалась, когда пришла, а здесь все в порядке: никто не поссорился, владелец продукта пашет как трактор, стейкхолдеры вели себя тоже нормально)) Одним словом, я очень рада, зрелость команд потихоньку тоже растет.

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

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

Мой руководитель, наконец понял, что SAFe нам никуда не уперся и стал почитывать Nexus. Не знаю почему, но LESS меня как-то больше зацепил, но в принципе и то, и другое примерно одинаковое. Было бы желание меняться 🙂 Можно же даже по водопаду довольно успешно работать, придерживаясь Agile-ценностей и принципов.

И в заключении – наш главный скептик, который препятствовал всякому Agile-движению, уходит. Это честно, груз с души, потому что работать со мной он не хотел. Когда стальные ребята уже побежали, организовались в команды, на daily собираются, в story point оценивают, он стоит сбоку и бухтит. Конечно, ему было тяжело быть одному. Но вылезти из своей этой роли ему не позволяло, видимо, собственное достоинство. Поэтому уходит. Сейчас на последнем планировании сидел молчал, уже даже не троллил и что-то рисовал в своей тетрадочке.

С одной стороны грустно терять члена команды, который очень шарит в нашей очень сложной системе, но с другой я всегда вспоминаю фразу “не работайте с мудаками“. Есть скиллы, но нет ценностей – пора прощаться.

Позитивный Agile научил меня с позитивом относиться ко всему и искать хорошее даже в каких-то негативных моментах. Впереди меня ждет AgileConf 2017, встреча с прошлыми коллегами, Agile-митапы в Новосибирске, выступление на продуктовой тусе Сибири, обучение команд и еще много всего интересного. Это ли не прелесть 🙂

photo5393400543843559468
А это нас вчера выперли из всех переговорок и нам пришлось планироваться прямо в нашем open space))

 

 

 

Advertisements

Чтиво для отпуска

Наконец куплены билеты и 2.5 недели меня ждут райские уголки нашей планеты. Уже даже нашла себе книженцию на отпуск и хочу с вами поделиться.

Это новая книга, переведенная вот только что

Постигая Agile

postigaya-agile-big

Она рассказывает о самых популярных agile-подходах – #Scrum, #XP(экстремальное программирование), #Lean (бережливое программирование) и #Kanban. Она познакомит вас с методами, работающими в повседневной жизни, а также с базовыми ценностями и принципами, которые помогут вашей команде полностью изменить свой подход к работе над проектами. Вы начнете лучше разбираться в конкретных agile-подходах и сможете сразу внедрить их на практике. А главное, вы поймете, как превратить группу сотрудников, добавляющих в свою работу #Agile, в настоящую команду, которая действительно улучшает способ создания продукта и добивается выдающихся результатов.

По ссылке выложены форматы fb2, epub, pdf. 

До скорых встреч!

Снова на тренинг для владельцев продуктов

Неделю назад мы учились с воскресенья по вторник. К нам приезжала Даша Рыжкова и читала тренинг Lean Product Management. Даша рассказывала о роли владельца продуктов, об инструментах этого человека, о запусках команд и делилась своим практическим опытом. Было очень круто, особенно на третий день. Как и обещала, в режиме дневника поделюсь о том, что для меня открылось с новой стороны.

photo5298693487014815775

#Воскресенье

Прошёл первый день тренинга. Из интересного эволюционный цикл владельца продукта.

Самая первая ступень – junior

  • Он способен приоритезировать backlog
  • Взять продуктовую гипотезу и проверить ее
  • Может общаться с командой
  • Переход на следующую ступень занимает, как правило, 3-6 месяцев

Следующая ступень – эксперт 

  • Он способен формулировать гипотезы и проверять их
  • Может сформировать набор экспериментов
  • Общается со стейкхолдерами (заинтересованными лицами)
  • Способен построить роадмап развития продукта
  • У него есть видение продукта
  • Получает бюджет по запросу
  • Переход в самый верх может занять больше 1 года 

Мини CEO 🤘

  • Распоряжается бюджетом самостоятельно
  • Нанимает себе людей 

photo5298693487014815774

И беда в том, что на рынке почти нет мини CEO. А если есть, то таких людей очень сложно удержать в рамках компании, чтобы они не ушли запускать что-нибудь своё. Компаниям приходится набирать junior и обучают их.

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

Если продукт большой и сложный, тем более не допускайте комитеты. Дробите его на кусочки и команды. Хорошее правило 1 владелец продукта – не более 3 команд. Иначе происходит расфокусировка.

#Понедельник

Во второй день обсуждали стейкхолдеров (заинтересованных лиц).

Нужно знать своих и учиться работать с ними. Выпишите всех, кто имеет влияние на ваш продукт и попробуйте поместить в матрицу 2*2. Это будут и внешние и внутренние люди/организации.

  • Будут те, кому ваш бизнес и продукт не все равно, а так же они могут оказать на него достаточное влияние. Выстраивайте с ними партнёрство. Помогайте друг другу, ведь это взаимовыгодно.
  • Есть те, кто оказывает высокое влияние, но вы им не интересны. Старайтесь перевести в предыдущий квадрант, особенно хорошо работает для внутренних стейкхолдеров, либо просто удовлетворять их потребности с наименьшими затратами. Пример внешнего такого стейкхолдера может быть ЦБ. 
  • Кто искренне интересуется, но не оказывает влияние – просто информируйте о ваших делах. 
  • Последний квадрант – не работайте с ними. Трата времени. 

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

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

#Вторник

Вчера был последний день обучения и он был огонь! 🔥🔥🔥

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

До этого мы узнали, что владельцы продуктов бывают трёх степеней крутости:

  1. Jinior
  2. Expert
  3. mini-CEO

Так как же запустить большой продукт по #Agile, чтобы было комфортно и командам, и владельцам, и в прозрачности не потерять? Пойдём от обратного, раскручивая всю цепочку сверху вниз, потому что продукт это следствие 🙂

Для начала, компания понимает, куда она плывёт и зачем. То есть, у неё есть цель, которую она преследует. Для того, чтобы ее достичь, мы формируем value streams, то есть определяем продукты, которые все вместе позволят достичь эту цель. А перед каждым продуктом, соответственно, ставим определенную задачу.

Дальше мы закрепляем за каждым продуктом человека, который будет его двигать вперёд – CPO (chief product officer).
Прорабатываем, сколько нам надо команд, чтобы этот продукт построить. Например, как на картинке, 3 штуки. За каждой командой, в данном случае, закреплён свой владелец продукта и у каждого свой #Backlog.
Если вспомнить эволюцию, то обязанности CPO стоит доверить владельцу уровня mini-CEO, потому что с командами ему будет скучно.

Scrum мастер может быть как один на value stream, так и несколько. Важно не забыть этого человека, потому что именно он будет помогать вашим командам выплывать из болота хаоса.

Чтобы наши владельцы гребли в одном направлении, с определённой периодичностью устраиваем им совместную с CPO встречу по синхронизации – PO synchronize.

Помимо этого, мы хотим, чтобы наши команды и люди в них развивались, поэтому ребята одной специализации образуют chapters. Например, iOS chapter или PO chapter. Здесь тот же CPO помогает расти своим PO, делится знаниями и выращивает из них себе крутых специалистов.

Подобная организация работы очень популярна сейчас и многие знают ее под названием #Spotify фреймворк. Это проще, чем #SAFe, здесь команды могут работать не только по #Scrum, но и по #Kanban и т.д. Можно отдать выбор инструментария самим командам.

Советую к просмотру видео про инженерную культуру Spotify 🙂

Но как запустить это все безболезненно для компании? Есть несколько шагов:

  1. Запускаем пилотную команду с владельцем продукта и скрам мастером
    • обычно делаем эксперимент 3-4 месяцев
    • ставим амбициозную бизнес цель перед командой, но это не KPI, как правило, она недостижима, а команду мотивируют маленькие победы (успешные спринты, проверенные продуктовые гипотезы)
    • договариваемся о правилах игры на период пилота, как минимум, что никто не может быть уволен, потому будут взлеты и падения
  2. Строим вокруг команды value stream и собираем все косяки, которые могут быть в компании по межкомандному взаимодействию
  3. Масштабируем в рамках компании и достраиваем остальные value streams

Спасибо нашим тренерам за их терпение 🙂

Ретро на пляже

Я тут немного упоролась и, пока тепло у нас в Сибири, решила провести ретроспективу на пляже. Всё с теми же 4-мя командами и сделать это во время рабочего дня. Неформальная обстановка, свежий воздух и обсуждение волнующих всех вопросов. Было круто!

Дальше хочется поделиться, как одновременно вывезти почти 30 человек вне офиса в рабочий день для плодотворной работы? Все-таки такие большие мероприятия я провожу не каждый день 🙂

  1. Определиться с целью мероприятия, ведь не все вопросы можно решить на свежем воздухе без возможности визуализации.
  2. Определиться с местом, убедиться, что погода будет благоволить. Мы выбрали пляж, потому что давно не выбирались туда всей командой. Неплохо съездить на местность перед окончательным выбором, понять, как сможем расположиться.
  3. Продумать как добираться, хватит ли машин или понадобится такси. Нам повезло, половина была на машинах, которая забрала вторую половину 🙂
  4. Выбрать день и время. Как показала практика, лучше проводить во второй половине дня, чтобы после мероприятия не пришлось возвращаться в офис. 
  5. Организовать перекус, особенно, если работаете больше 2-ух часов. У нас получилось 3 часа, закупили фрукты, печенье, взяли питье. Обязательно мешок под мусор, одноразовую посуду, салфетки не забыть!
  6. Организовать рабочие места. Сюда входят и письменные принадлежности, и пледы. У нас так получилось, что планшетов в офисе совсем не нашли, пришлось импровизировать и брать из дома детские книги формата А4, чтобы было удобно писать. А коллеги из продуктовой команды поделились 2-мя биванами 🙂
  7. Продумать agenda встречи. Это самое важное для продуктивной работы. Ведь ретроспектива – главная встреча скрам мастера, которую он должен организовать хорошо и чтобы был выхлоп.

О структуре ретро

У нас была тема киносценария на прошедший спринт. Команде надо было отрефлексировать все, что с ними происходило и зафиксировать это в небольшой тетради. А в конце заполнить отчет на прошедший спринт. 

Для киносценария надо заполнить:

  1. жанр фильма
  2. название фильма
  3. кто главный герой
  4. с какими трудностями сталкивается главный герой
  5. как он их решал или будет решать

Для отчета:

  • сколько из бюджета потрачено story point на фильм
  • сколько киноляпов (багов) допущено в результате
  • сколько было незапланированных сюжетных линий (задач)
  • удалось ли достичь целей съемки фильма (спринта)?

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

Снова на тренинг для скрам мастеров

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

#Пятница

Сегодня прошёл первый день тренинга для #Scrum мастеров. Полезно было ещё раз вспомнить все основы, зарядиться и задать вопросы. Но и новая информация тоже была.

IMG_02771
Так Саша рассказал про хитрости планирования и зачем декомпозировать задачи на более мелкие, чтобы влезали примерно в 1 человеко-день. Это делается не ради бюрократии или потому что кому-то так хочется. А ради следующего профита:

  1. Можно отдать в тестирование намного раньше и не грузить тестировщиков под конец спринта. Чем раньше мы обнаружим ошибку, тем дешевле ее исправлять.
  2. Можно работать над большой задачей вдвоём, а это ускорит разработку и проучите опыт командной работы 
  3. На #Dailyscrum есть что рассказывать
  4. Видя полную декомпозицию, понимаешь, где в задаче может что-то пойти не так и даёшь более полную оценку
  5. Можешь раньше доставлять кусочек фичи и уже давать ей пользоваться
    🙂

Кстати, было очень крутое задание на принципы #Agile. Угадайте, какие принципы #Agile нарушены в каждом кейсе? 1 кейс – 1 нарушенный принцип. Они везде разные 😉

#Суббота

Закончился второй день тренинга. Из инсайтов, о роли #Scrum мастера – это не только человек, который:

  1. Следит за соблюдением фреймворка
  2. Насаждает #Agile культуру
  3. Создаёт крутую команду

Так же важным аспектом его работы, особенно на первых этапах запуска нового фреймворка, является создание прозрачности. Именно она даст понимание не только бизнесу, но и самим участникам scrum команды, что происходит, вовремя отреагировать и сделать процесс лучше. А значит стать эффективней 🙂
Помимо этого начнёт культивировать атмосферу доверия, которой раньше не было. Это не маловажный аспект командной работы, о котором стоит поговорить отдельно.

К инструментам, которые добавляют #Прозрачность, можно отнести:

  • sprint planning с декомпозированными задачами (об этом писала вчера)
  • daily scrum meeting, который позволяет составить всем вместе план на день и решить, как справляться с трудностями
  • burn down chart и kanban доска визуализируют процесс движения к цели спринта
  • #Velocity очень хитрая штука. Считаем по реально сделанным задачам. Не важно сколько ты набрал и запустил в прогресс. Важно, сколько ты реально можешь довести до конца, ведь только то, что готово ценно и можно использовать. Несделанные задачи отправляем на следующий спринт без переоценки! Наша задача в дальнейшем выравнивать скорость спринтов, чтобы не было перекосов. 
  • definition of done, дающий понимание что значит задача готова 
  • sprint goal, которую формулируем в виде ценности, а не в количестве разработанных фич 
  • И т.д.

А какие инструменты, из перечисленных выше, используете вы?

Кстати, на следующих выходных тоже буду учиться 🙂

Стратегия изменений. Часть 2.

Или как мы хотели разделиться на команды

Я напомню, что мы активно меняем подразделение одной организации изнутри.

Было: куча заказчиков, куча менеджеров, одна большая команда

Стало: 2 владелец продукта, 2 скрам мастера, одна большая команда

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

Мы начали задаваться этим вопросом уже давно, вариантов, предложенных самой командой, было много, но это все были разновидности component team. Я знала только то, что команда должна быть кроссфункциональной, а это значит, что она должна обладать всеми компетенциями, чтобы создавать продукт.

В поисках лучших решений мы стали прибегать к поиску успешных кейсов у коллег по цеху, понятное дело нам надо масштабироваться. Конечно, если смотреть на них, как на одну большую команду из почти 59 человек, они обладают всеми компетенциями, чтобы сделать продукт. Но это мало управляемая толпа, получасовые daily scrum, шестичасовые планирования и неэффективные ретроспективы. Scrum of scrum не спасает, Nexus выглядит непривлекательно. Пока очень круто все учтено у Spotify, но их опыт неповторим, нужно строить что-то свое. Очевидным решением просятся feature teams, а дальше посмотрим.

component-vs-feature-teams.png.pagespeed.ce.NKNnxhQVFQ
Подробнее здесь

Как мы живем сейчас

1

Команды мобильной разработки и тестирования я пока не трогаю. У них там более или менее есть скрам-мастер, владелец продукта, кое-какой scrumbut и отдельный баклог. Единственное, посоветовала им тестировщиков включить все-таки в скрам-команды.

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

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

Еще очень интересное наблюдение, видите большой Component A?  По сути, даже если мы разделимся на кроссфункциональные команды, радости особой не получим, потому что монолит невозможно будет разрабатывать независимо. Все-равно будет общий регресс и интеграция. Приходим к тому, что надо провести большую техническую работу по дроблению монолита на мелкие независимые друг от друга кусочки.

Как будет

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

Во втором приближении мы планируем начать дербанить Component A на независимые кусочки, которые смогут жить самостоятельно. У нас появится архитектураная команда, которая этим будет заниматься.

3В будущем хочется сделать мобильные команды кроссфункциональными тоже и прийти к одному баклогу. Но это реальность будет проверять мой план на прочность 🙂

 

Перезагрузка ретроспектив

Минутка самокритики: Друзья, времени катастрофически стало не хватать на блог, но я стараюсь не забивать. Мыслей, событий, результатов очень много, буду стараться  сюда помещать это. Недавно, кстати, подумывала перевести его на medium, чтобы осовремениться, но пока руки не доходят.

Ладно, сегодняшняя тема довольно банальная. Поговорим о перезагрузке ретроспектив. Как и водится – это главная встреча scrum мастера и он должен проводить их хорошо. Часто эти встречи не любят, проводят раз в полугодие и все такое.

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

  • большая команда 30 человек собиралась в одном помещении, а так же все, кто хотят поприсутствовать
  • приносили коробочку, куда за целый месяц люди скидывали бумаженьки со своими мыслями
  • вскрывали коробочку и обсуждали
  • формировали командные договоренности
  • затем оцифровывали и рассылали на всех лог общей встречи

Надо признать, что по-началу это у них работало, я про совсем давние времена, когда ребята только задумывались об Agile и Scrum. Работало, потому что это было новой практикой, раньше никто и никогда не спрашивал твоего мнения и наконец-то появилось такое место.

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

Первая ретроспектива

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

Затем попыталась собрать мысли и идеи о прошедшем месяце у людей прямо там, раздав цветные стикеры и ручки, но люди оказались не готовы. Скривив лица, они указали мне на красную коробочку. В ней было не очень густо, в основном негатив. Обсуждая его у нас рождался список командных договоренностей. Это было больше похоже на свод правил, которые они пересматривают от встречи к встрече. Где нет того, кто берет ответственность на себя, потому что может, и проминает одну тему. Где нет устранения причин, а есть устранение симптомов.

Обычная фраза с командного ретро:

Команда не должна брать в работу непонятные и неполные задачи.

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

22955_regenbogenballНадо ли говорить, что я была не довольна такой ретроспективой? Сама ведь выбрала старый формат 🙂 Остальным вроде понравилось, потому что хоть кто-то начал фасилитировать встречи, не давать гудеть одновременно всем и передавать токен..

Следующие встречи

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

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

Люди пришли, расселись по 4-ём столам. Я выдала им флипчарты, маркеры, стикеры, клей, распечатанные задачи из Jira.

  • Попросила вспомнить цель своего спринта и зафиксировать на бумаге. Было интересно, вспомнят ли. Но все прекрасно держали ее в голове! Это была приятная неожиданность.
  • Попросила разделить все задачи на 2 кучки:
    1. Мы завершили задачу и она идет в релиз
    2. Что-то пошло не так и с задачей не справились
  • Посчитать количество выполненных story point по кучке #1 и зафиксировать на флипчарте. Это их командный маячок, сколько они реально доводят до конца и делают прироста к будущему продукту.
  • Попросила проанализировать, что помешало им выполнить задачки из кучки #2. Люди реально видели то, что им мешает и здраво формулировали. Фраз типа “луна была в тельце” нигде не появилось, что не может не радовать 🙂
    • Кстати, на этом этапе выяснилось, что у меня есть команда, которая абсолютно перевыполнила план и у нее не было этой кучки. Пришлось на ходу переориентироваться и просить ребят подумать над тем, а что им помогло в этом.
  • Когда все справились с вышеперечисленными задачами я попросила придумать, как они будут в следующий раз справляться с подобными проблемами. И… люди впали в ступор. Реально, они сидели и говорили мне с честными глазами, что ничего нельзя сделать, что проблема не на их стороне, что мы заложники ситуации и прочее прочее. Ведь к такому повороту событий жизнь их не готовила, а раньше они обсуждали только командные правила..

Подходя к каждой команде по очереди, слыша “мы не можем”, я просила озвучить проблему? На каждую мне удавалось придумать решение или подкинуть идею, куда копать. Уловив способ поиска решений, они начали генерировать их дальше сами, а я уходила к другой команде. Так за несколько циклов ребята справились.

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

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

0_ab98c_5010f11d_XXL

И кстати, я прошла испытательный срок досрочно. Мне его закрывали со словами: “Чтобы ты от нас не сбежала”. Я считаю это довольно неплохим результатом и даже немного горжусь собой 🙂