Стратегия изменений. Часть 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В будущем хочется сделать мобильные команды кроссфункциональными тоже и прийти к одному баклогу. Но это реальность будет проверять мой план на прочность 🙂

 

Advertisements

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

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

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

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

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

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

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

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

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

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

6f81eda2-f26f-4984-b74a-c875487f8d89

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

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

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

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

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

Часть 1.

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

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

6f81eda2-f26f-4984-b74a-c875487f8d89

Теперь:

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

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

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

7 дней спустя

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

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

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

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

И кстати да, я понимаю, что как коучу мне еще расти и расти!