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

Минутка самокритики: Друзья, времени катастрофически стало не хватать на блог, но я стараюсь не забивать. Мыслей, событий, результатов очень много, буду стараться  сюда помещать это. Недавно, кстати, подумывала перевести его на 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

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

Главная заповедь scrum мастера

Всем привет! У меня появилась небольшое правило и я хочу им поделиться с вами.

“Каждый день приносить пользу команде, даже если она небольшая”

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

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

Если не делать каждый день маленькую пользу для команд и работать с ними только от ретро к ретро, ничего никуда не сдвинется. Очень быстро все съедут на старые рельсы отсутствия ответственности, не желания работать и двигаться самостоятельно. Люди опять скажут, что ваш Scrum не работает и вообще Agile у нас всегда был 🙂

cf7f964d-dd75-4433-8ebd-6aaaafac3fe2PS: Название заметки у меня родилось в самом ее конце, когда я вспомнила как на тренинге для одной из команд, мы рисовали метафору скрам мастера. Одна команда команда изобразила осьминога, у которого одно щупальце выходило их храма Agile

 

 

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

Очень вдохновилась тут заметками от Unusual Concept с интервью практикующих agile-коучей и scrum-мастеров. Особенно понравилось интервью с Лешей Пикулевым, и ответ на вопрос:

пикулев
Часть интервью с Лешей

Пытаюсь анализировать, как двигаюсь я. Многие шаги, которые они перечисляют в ответе на вопрос “Вас закинули к новой команде, ваши действия в первый месяц?“, я совершаю сама. Поэтому кажется, что на верном пути, ну и помню, что единственного верного пути нет 🙂

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

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

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

6f81eda2-f26f-4984-b74a-c875487f8d89

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

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

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

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

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

Часть 1.

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

И вводим профессионального скрам-мастера – это я, конечно же, про себя 🙂

6f81eda2-f26f-4984-b74a-c875487f8d89

Теперь:

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

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

Но об этом в следующих сериях…

Заходя в новую компанию

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

Если большинство современных компаний уже отошли от водопада и страдают больше code and fix, то здесь его можно наблюдать в полной мере. В силу некоторых обстоятельств, называть компанию я не буду, но намекну, что это ИТ и финтех, с большой и сложной структурой команд и продуктов. Ну а кто в финтехе простой? 🙂

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

Первые шаги

  1. Познакомиться
    • С компанией. И здесь я имею ввиду не только свои команды, с которыми буду работать, а вообще со всеми, от которых у тебя могут быть внешние зависимости. Важно на первом этапе понять, сколько их может быть, кто из них более непонятный, кто идет на контакт, а кто нет. Сколько вообще здесь уровней иерархии и как ходит информация. Scrum ведь это про общение и взаимодействие.
    • С командой. Буду проводить первое ретро для них. Пока ретроспективы у них были раз в месяц и не привязаны к спринтам. Мы это исправим. На этой встрече я расскажу им о себе и чем буду заниматься. Потому что пока никто не понимает, кто я, зачем я здесь, но все уже меня так долго ждали 🙂
  2. Договориться со всеми, кто хочет завести в компании Scrum и Agile. Пока ты человек снаружи, тебе не все говорят, как есть на самом деле. Когда ты становишься человеком изнутри, делятся более охотно. Эта работа поможет мне лучше понять полный объем работ и то, как действительно обстоят дела. Историю Agile и Scrum в организации, ведь я не в первый раз слышу, что мы это уже делали 3 раза..
  3. Обучить. Рассказать об Agile, из чего состоит Scrum и в чем тонкости.

Что ждет дальше?

Помимо этого, очень хочется собрать свою команду трансформации, которая будет помогать двигать процесс вперед. Этого я никогда не делала, но видимо пора.

Сразу после обучения соберемся, обсудим как кто видит этот процесс и все вместе сделаем Impact Mapping трансформации. Подумаем над стратегией изменения.

В завершении хочу сказать, что это не идеальный план. Что наверняка более крутые Agile-коучи мне бы кучу всего еще посоветовали, но это мой путь, он не менее запутанный чем у вас 🙂

3 условия применимости scrum

Совсем недавно я сделала небольшой тренинг для одной команды. Как и везде, здесь есть явные евангелисты, благо хоть открытые 🙂 И на самой первой встрече, перед тем как рассказать про scrum, я собрала с них ожидания от тренинга. Одним из ожиданий у главного евангелиста было – “Какие 3 необходимых условия для внедрения/применимости scrum?”

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

Сразу оговорюсь, когда я упоминаю scrum, я за ним обязательно подразумеваю agile, а не голый фреймворк, поэтому все, что я скажу ниже, нужно воспринимать только через эту призму. Scrum без agile – деньги на ветер 🙂

Первое

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

Второе

Продукт, как мы знаем, невозможно сделать в одиночку. Нужна команда, но я здесь немного схитрю и в один пункт затолкаю два 🙂 Потому что просто команда условие необходимое, но недостаточное. Для настоящего успеха спец-операции нужна команда, разделяющая agile-принципы или хотя бы не сопротивляющаяся в 99% случаев, а готовая к изменениям.

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

Забегая немного вперед, все мы с рождения agile, просто со временем обрастаем кучей собственных убеждений, которые мешают нам это понимать 🙂

Третье

Вопрос: сколько нужно agile-коучей, чтобы вкрутить лампочку?

Ответ: ни одного, если нет поддержки сверху

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

Die_drei_Bogatyr

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

По итогам встречи

039

В результате встречи ребята сами сформулировали 3 пункта и у них получилось почти все то же самое. Первое – команда, второе – продукт. Третий пункт был сформулирован немного иначе, но по моему мнению, пересечение в нем почти на 80%.

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

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

Магия ответственности

На прошлой неделе проводила 4-ёх часовой тренинг про основы Agile и Scrum одной большой команде и начала выбиваться из тайминга. Последний час работы должен был быть посвящен игре LegoScrum для наглядной демонстрации процесса, но к этому моменту нам оставалась еще одна тема про оценку задач в story point. Это всегда воспринимается разработчиками в штыки, потому что они всю жизнь оценивают задачи в часах, и для этого хочется чуть подробней на этом остановиться. Мы договорились уделить этому побольше внимания и поиграть потом.

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

Тему для оценки я выбрала простую – уборка помещения после тренинга. Просто так, шутки ради, ведь мы все прекрасно представляем, как это делается, и здесь точно нет никаких подводных камней. Ребята нагенерили список необходимых работ ,чтобы выполнить эту “цель спринта” все вместе. Затем выбрали самую простую из них, сравнили с ней остальные, немного подискутировали при оценке и, в принципе, все остались довольны пройденным материалом.

IMG_0418

Потом я закончила тренинг. Мне все похлопали, сказали “спасибо” и тут как по волшебству никто не стал уходить, а все начали прибирать помещение! Я не просила, только и успела, что закинуть свои вещи в тренерский чемоданчик, как помещение было убрано 🙂 Это магия!

Вот что происходит, когда люди выбирают, как им работать. Происходит волшебство!

Daily Standup Quest

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

Мы долго думали с ними на ретро, как изменить отношение к этому процессу, что он полезный и нужно себя пересилить, и придумали:

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

CfjEzQNUEAAHIYJ[1]
Все уже, наверное, знают про такой способ 🙂
После ретро у меня мысль разогналась настолько, что я решила сама устроить ребятам веселые стендапы. Так как с командой я не сижу, а являюсь сторонним консультантом, то решено за несколько минут до события отправлять им стендап квесты. Они будут занимать от нескольких секунд до пары минут, но зато разбавят рутину и сделуют жизнь веселея! А главное, каждый раз будут разными 🙂

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

Понедельник: прийти на стендап с кофе/чаем, сказать крутой тост и поднять кружки за свой новый продукт

Вторник: хлопнуть-топнуть 3 раза, и крикнуть хором “Мы команда!”

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

Четверг: встать в круг и сказать человеку справа комплимент

Пятница: сыграть в крокодила -изобразить зебру и тому, кто угадал, выдать настольную игрушку маленькую зебру

Скоро мы с ними снова встречаемся и я получу от них обратную связь. Думаю что им понравится 🙂

Такой небольшой инструмент, а куча позитива и пользы!