С — самоорганизация

6 min readSep 24, 2018

В прошлых сериях

Мы решили организовать кроссфункциональные кроссплатформенные команды
Нас покинул наш руководитель

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

Конец 2017 года

6 команд разрабатывают 1 продукт
разные владельцы продукта
разные бэклоги продукта
разное расписание спринтов

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

Уходило довольно много времени, чтобы спланировать большую фичу, которую нужно было разрабатывать для всех каналов сразу.
Было 2 владельца и 2 бэклога, хотя продукт один. Требовалось больше общаться, больше договариваться. Нет, это не плохо, но на это надо было время, а это наш самый ценный ресурс!
Обе команды не понимали, что происходит в другой, не интересовались. Каждая жила своей жизнью.
Ни разу фича не была выпущена всеми каналами за один спринт. Обычно уходило 2–3 спринта.
Mobile команды всегда отставали на 1 спринт, ожидая разработки Backend. Иногда и дольше, потому что доделывали свои очереди задач.
Backend допиливали, когда Mobile интегрировался, потому что нельзя было учесть сразу все для них.

Начало 2018 года

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

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

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

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

Середина 2018

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

Темная сторона

Фича очень быстро кончилась. Выпустили MPV, доделали до более-менее вразумительного решения и… статистика показала, что больше и не надо. С точки зрения продукта это круто — мы сфокусировались на чем-то другом более важном и не тратили ресурсы на ненужное пользователям. Это и есть настоящий Agile. А вот команда смотрела на это с другой точки зрения, с той, когда у них пропала общая цель, сплачивающая и делающая их командой. И тут я их тоже могу понять.
Оторванность от своей платформенной команды, нахождение в изоляции.
Плохая идея проводить двойной эксперимент сразу: и из менеджеров в скрам мастера, и первая фичетима продукта.. Нужно исследовать сначала что-то одно.

Мы собрались на очередную большую ретроспективу на пляже и ребята из фичетимы высказались, что хотят ее покинуть в связи с причинами выше. “Интересно!” - подумали мы и уточнили, ну неужели и правда все так плохо? Есть ли положительные моменты?

Светлая сторона

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

Внезапно..

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

Август-сентябрь 2018

Решили реорганизовать все команды в фиче-команды.

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

Нехватка скрам-мастеров и web-разработчиков
Bus-фактор, когда в команде каждой компетенции по 1шт.
+1 новый продукт, итого нам надо делать этой командой целых 3 продукта!
Есть backend-разработчики, которые будут делать крутые технические решения, и нужен тот, кто будет выдавать API платформам

Мы провели ретроспективу и, опять же, у команд появилась идея о том, как все исправить.

Укрупнение команд

Идея укрупнить команды пришла от самих же команд. Это идет в разрез со всеми рекомендациями Agile, но нам показалось это спасением.. По крайней мере, как отвественная за Agile и Scrum, я не стала сильно сопротивляться и решила довериться командам. Да, местами будет сложно, потому что в зелененьких командах от 11 до 15 человек!

Так сейчас это выглядит, уже запущено.

Переломная неделя

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

Уход руководителя, который по сути и был связующим звеном команд backend+web с mobile, нам надо было учиться договариваться друг с другом теперь самостоятельно
Новые команды, которые не все принимали — зачем все менять, если и до этого мобильные команды не испытывали проблем?!
Полу-канбан процесс в мобильной разработке и тестировании, который надо перестраивать на рельсы скрама

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

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

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

Третий пункт пока в стадии разработки. Здесь никто не мог предугадать такого айсберга, пока не запустили изменение..

Суть в том, что мобильные команды заявляют, что живут по скраму, но планировать они совершенно не умеют и живут по принципу: все решает один человек. Иными словами, вот берет команда на спринт несколько задач, но гарантировать, что она их выпустит, не может. Как только начинаются какие-то изменения беклога спринта, это надо утверждать у этого одного конкретного человека. Человек чувствует себя супер нужным и незаменимым. А по факту, он бутылочное горлышко, которое не дает командам самостоятельно принимать решения.
Дополнительно к этому “счастью” мы узнали, что мобильные тестировщики занимаются проверкой не только наших продуктов, но и еще пары-тройки других. Дальше, чем на неделю, они планировать не могут, потому что не знают, что будет дальше происходить в этих других продуктах. Приоритет, конечно, за нашим.
Еще мобильные тестировщики придумали себе кучу разных ограничений, почему брать и тут же тестировать за разработчиком не стоит. Мобильные тестировщики, находящиеся в командах, по факту их тестировщиками не являются и могут весь спринт проверять функционал другой команды.

Ладно, дальше будет только лучше :)

Надо отдать должное, что ребята из бывших backend-команд начали помогать и тоже пытаются объяснять вновь добавленным к ним мобильным разработчикам, что ничего страшного не произошло. Что это удобно и нормально. Хорошо, что появляются общие темы для работы, которые будут показывать, что их совместная работа куда важнее небольшого дискомфорта при реорганизации состава команд.

Выводы

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