10 признаков того, что ваш Scrum пора масштабировать

Представьте, приходит к вам в гости очень грустный товарищ по имени Василий. Василий в команде — человек многофункциональный: немного PM, местами Scrum Master и самую малость Product Owner (когда помогает заказчику с требованиями). Как такое может быть? Очень просто, Василий работает в СНГ. Так что все артефакты Scrum внедрили, но получилось не совсем по учебнику.

Scrum Master Василий

У Василия Scrum Team из 8 человек и он прямо чувствует, как что-то идет не так. Что именно — понять пока не может. Вася читал Scrum Guide и знает, что это почти предельная по размеру команда и, теоретически, можно масштабироваться и разделиться на 2 подкоманды, перейдя со скрама на LeSS или Scrum of Scrums. Одна беда: Вася совсем не уверен, что это как-то решит его проблемы на проекте. Ниже мы расскажем, как помочь Василию оценить ситуацию, и при каких обстоятельствах самое время масштабировать команду из восьми человек, а когда даже с десятью людьми стоит еще подумать.

Оглавление:

1. Что важно знать, прежде чем задумываться о масштабировании
2. 10 признаков того, что ваш Scrum пора масштабировать
3. Масштабирование небольших команд

Что важно знать, прежде чем задумываться о масштабировании

Когда у Scrum Master-a возникают мысли о масштабировании, это говорит о том, что команда столкнулась с тремя ключевыми проблемами, которые нужно как можно скорее решить.

1. Стало сложно планировать спринт: Product Owner не справляется с составлением требований для всех, поскольку команда слишком большая.
2. Ретроспектива теперь больше похожа на зомби-апокалипсис: одна половина команды пытается перекричать другую, а Scrum Master изо всех сил старается контролировать ситуацию, но получается плохо.
3. Постоянно что-то «впихивается» в текущий спринт, хотя, на самом деле, с дополнительным объемом задач справиться невозможно.

Если вы наблюдаете все три симптома у себя на проекте, но у вас пока 8-10 человек, не спешите выбирать фреймворк «на вырост». Возможно, вы просто плохо внедрили Scrum, и команда так и не стала командой.

Прежде, чем планировать масштабирование, убедитесь, что команда слаженно работает в классическом Scrum. Если вы масштабируете то, что не работает, получаете еще больший хаос, чем есть сейчас.

10 признаков того, что ваш Scrum пора масштабировать

«Люди и взаимодействие важнее процессов и инструментов», — гласит первая заповедь Agile-манифеста.

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

1. Слишком длинный Sprint Planning

Scrum Guide о планировании спринта

Точных цифр, сколько времени должно занимать Планирование в конкретной команде, нет. Все относительно. Но если раньше вы как-то справлялись за два часа, а теперь сидите все шесть — стоит задуматься.

Причин может быть несколько:

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

В таком случае стоит попробовать внедрить масштабирование путем разделения команды на 2 или 3 подкоманды. При этом нужно заранее продумать, что именно каждая из подкоманд будет показывать в качестве демо.

2. Тихая ретроспектива

Скрам команда не понимает, что происходит

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

3. Ретроспектива без действий

Как часто вы начинаете следующий спринт с тех улучшений, которые обсуждали на ретро?

Зачем нужна ретроспектива

Если ретроспектива в вашей команде не заканчивается планированием конкретных улучшений, с которых вы будете начинать следующий спринт — это может быть одним из симптомов «болезни роста». Хотя, возможно, вам просто стоит прокачаться в проведении ретроспектив.

4. Product Owner говорит «я устал»

Типичный портрет Product Owner-a в Scrum

Под «я устал» будем понимать те случаи, когда Product Owner уже не в силах создавать требования и задачи в полном объеме сразу на всю многофункциональную Scrum Team. Отличный выход: разделить команду на несколько и в первые четыре дня прописывать общие требования для всех команд, а потом приступать к работе над конкретными запросами. Разделение команд также позволяет Product Owner-у работать с разной продолжительностью спринтов для каждой команды: одна неделя, две недели, месяц.

5. Команда не общается со Scrum Master-ом

Проблемы в коммуникациях команды и Scrum Master-a

Чаще всего со Scrum Master-ом не общается Team Lead. Погодите, какой такой Team Lead? Этой роли в Scrum нет, есть Scrum Team и все! Конечно, теоретически это так, но в реалиях СНГ почти всегда есть один выделенный разработчик, который представляет команду и активно коммуницирует со Scrum Master-ом. Этим разработчиком выступает либо самый синьористый синьор, либо Team Lead (что не всегда одно и тоже).

Почему представитель команды может не общаться со Scrum Master-ом? Здесь есть два варианта: либо Team Lead перегружен, либо у Scrum Master-а столько задач, что не хватает времени на дополнительную коммуникацию. Задача Scrum Master-а — обучать и направлять команду, предлагать решения и проводить эксперименты. Когда прекращаются эксперименты, это значит — команда вошла в состояние плато, что в рамках Agile уже деградация.

6. Scrum Master не проводит встречи один на один

Нет времени для встреч 1+1

Да, в Scrum есть ретроспектива и еще куча хороших и полезных встреч, но «1+1» никто не отменял. Scrum Master должен видеть команду, и понимать, кто чем живет, совпадают ли цели сотрудников с тем, куда идет проект, все ли счастливы, есть ли рост.

Ниже 5 правил, которым вы должны следовать в проектах любого размера.

1. Проводите «1+1» регулярно, только в этом случае они принесут максимум пользы.
2. Сотрудник должен знать, какие вопросы будут обсуждаться на встрече,понимать ее цель и формат.
3. На встрече «1+1» Scrum Master должен определить состояние своего собеседника, оценить, все ли ему понятно и нравится в текущей работе.
4. Важно дать сотруднику высказаться и записать все пункты, которые сейчас считаются проблемными.
5. На следующей встрече нужно сделать анализ вопросов, затронутых на предыдущем митинге, и понять, решились ли проблемы.

А вот 4 вопроса для интервью «1+1», которые помогут Scrum Master-у разобраться, нужно ли команде масштабирование.

1. Понимает ли сотрудник ценность своего личного вклада в проект?
2. Насколько одиноко он чувствует себя в команде? Если это так, риск профессионального выгорания крайне высок.
3. Какие задачи сотрудник хотел бы выполнять чаще?
4. Чем вы можете помочь?

7. Команда не готовится к Product Backlog refinement (бывший Backlog grooming)

Никто не готовится к грумингу

Подготовка к Product Backlog refinement — процесс или встреча, когда команда, какой бы она не была, ознакамливается с задачами, которые будут выноситься на Backlog refinement, а потом и на Sprint Planning. Подготовка к Product Backlog refinement может отсутствовать в 2 случаях: либо все задачи из спринта в спринт одинаковые, либо у сотрудников нет времени и / или понимания, зачем эта встреча нужна. Факты говорят о том, что если к Product Backlog refinement не готовиться заранее, эта встреча занимает неоправданно большее количество времени.

8. На Product Backlog refinement не приходит Product Owner

Backlog refinement — обязательный митинг для Product Owner-a

Цель такой встречи: определить и предложить действия по оптимизации бэклога.

На Product Backlog refinement обязательно должны присутствовать Product Owner (так как именно он понимает, что сейчас в приоритете) и команда (чтобы оценить сроки и то, насколько понятны user stories).

Результат хорошего Product Backlog refinement:

• Задач вверху backlog-а достаточно для 2-3 спринтов.
• User Stories понятно описаны и оценены всеми членами команды.
• Размер user stories позволяет реализовать несколько из них за один спринт.

Выходит, PO — тот человек, без которого этот митинг не имеет смысла. Команда, в ходе оценки и декомпозиции задач, должна задавать вопросы и договариваться с Product Owner-ом, что для этого блока задач будет определением состояния готовности. Если PO не пришел, с кем разговаривать? Отсутствие Product Owner-а на Product Backlog refinement совсем не значит, что его нужно менять, возможно продакт настолько загружен, что действительно не успевает посещать эту встречу.

9. Не хочется показывать Increment продукта во время Sprint Review

Scrum Guide о Sprint Review

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

Казалось бы, что может быть непонятного с Демо — взяли, показали. Но если вся работа — это бекенд и логика, и тут не то, что показать — представить сложно? А если такое решение пилят пять подкоманд? Над проектом трудится 50 человек, и в конце спринта никто не может посмотреть, что же они сделали. Демотивирует.

В данном случае, визуализация результатов работы — личный челлендж для любого уважающего себя Scrum Master-a. Как вариант, можно подготовить презентацию, на которой видны изменения в продукте и понятно, что именно команда сделала для проекта и как Инкремент повлиял на его развитие. Даже схема на доске с пояснениями, почему разработчики молодцы, лучше, чем ничего. Так что Демо — еще и отличный способ отпраздновать успех в тех случаях, когда команда весь спринт что-то рефакторила. Scrum Master должен понимать, что мотивация делать что-то лучше возникает только тогда, когда люди видят и понимают свой личный вклад в продукт.

10. Development Team больше 10 человек

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

Scrum Guide о максимальных размерах команды разработчиков.

Несмотря на то, что разделение команды, в которой больше девяти разработчиков, кажется самым очевидным вариантом, истории известны случаи, когда в Development Team было больше 10 человек, и качество работы от этого только выигрывало. Если ваша команда разработки больше 9 человек и все предыдущие проблемы вас не коснулись — не стоит слепо следовать Scrum Guide.

Масштабирование небольших команд

Если речь идет масштабировании команд в рамках больших проектов, не хватит и десятка статей, чтобы разобраться. Agile фреймворков для больших проектов не мало, есть что внедрять. Поэтому тема «Scrum на больших масштабах» вынесена отдельным блоком нашего курса Middle PM.

Но не все работают на проектах-великанах. Тем, кто задумывается над масштабированием пока еще небольшой Scrum Team, прежде чем что-либо менять, будет полезно ответить на 5 вопросов.

1. Что именно вы хотите изменить?
2. Что вы планируете получить в результате?
3. С чего будете начинать?
4. Почему вы хотите внедрить изменения?
5. Как определите, чтобы новое решение заработало?

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

6 советов по масштабированию небольших команд.

1. Разбить Scrum Team на маленькие команды с полным набором скиллов (минимальная команда может состоять из двух человек, хоть Scrum Guide и советует начинать с трех).
2. Настроить полностью автоматизированный workflow в Jira (или любом другом трекере).
3. Команда должна слаженно работать даже в отсутствие Scrum Master-a. Главная цель любого Scrum Master-a — сделать так, чтобы команда отлично работала без его активного участия в процессе, особенно когда дело касается масштабируемых проектов.
4. Обратить внимание на Self Selection process — процесс, когда участники команд сами выбирают, в какой части продукта они хотят работать. Эта практика хороша для поднятия боевого духа и мотивации сотрудников.
5. Разделить команду на самодостаточные блоки, по которым они закрывают те или иные проблемы. Можете разбить большой продукт на функциональные куски и сформировать команды, которые будут работать в разном окружении. Здесь как раз и пригодится Self Selection process.
6. Не давайте сотрудникам потерять ощущение, что без их работы мир рухнет! Нет более или менее важных команд. Все крутые и все равны!

Что можно попробовать уже завтра

Конечно, решение о масштабировании не принимается за 7 минут чтения статьи. В то же время, Agile и Scrum проповедуют гибкость и эксперименты, которые, при наличии более 6 симптомов из 10, лучше проводить как можно скорее.

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

• разделить команду на несколько подкоманд;
• оценить скиллы сотрудников и постараться усилить то, что уже сильно;
• провести «1+1» с каждым членом команды;
• выделить время на подготовку к Product Backlog refinement;
• демонстрировать Инкремент Продукта не только для заказчика, но и внутри команды;
• автоматизировать workflow в Jira.

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