Если вы Скрам-мастер или Аджайл-коуч со стажем и работали с кросс-функциональными командами, то наверняка сталкивались с ситуациями, когда один или несколько участников команды в Спринте жалуются на нехватку работы по ключевой специальности. Считаю, это переломным моментом в Аджайл-трансформации, и то, как Скрам-мастер справляется с этой ситуацией, определяет, станет ли группа людей настоящей командой.
Рассмотрим типичную ситуацию. Команда выбрала три элемента Бэклога Продукта в Спринт. На третий день Спринта один из разработчиков сообщает о том, что сделал свои задачки по фронту и ему больше нечего делать.
Этот разработчик еще на старте Скрам-команды твердо обозначил, что ему неинтересно заниматься непрофильной работой. Его компетенция - писать фронт. И хотя сейчас задачи висят в тестировании, он не хочет помогать тестировать. Поэтому он смотрит в Бэклог Продукта и предлагает начать работу над верхним элементом. Ведь в этом элементе много фронтовой работы, как раз его основная компетенция. До планирования Спринта это был четвертый элемент. Теперь это верхний элемент Бэклога Продукта. Владелец Продукта и другие участники команды не против. Что же тут плохого? Человек не отлынивает от работы, а наоборот активно ее ищет!
Чего НЕ должен делать Скрам-мастер
Худшее, что может сделать Скрам-мастер в этой ситуации — способствовать включению новой работы в Спринт. Почему?
Есть несколько аргументов:
- Вы решаете не ту проблему. Скрам предполагает, что вся команда работает над одной целью и над самым важным. Как побочный эффект, отдельные разработчики ВСЕГДА будут загружены неравномерно. Примите это как данность. Достойная вашего внимания проблема — как из группы сделать настоящую команду, в которой люди помогают друг другу.
- Это замедлит скорость поставки на рынок. Бутылочное горлышко на этапе тестирования. Вы никак не расширяете его, начиная новую работу. Наоборот, загружаете еще больше. Если вы так будете поступать, то разработка будет хронически опережать тестирование. Но доставленной ценности на рынок больше не станет.
- Потенциальные потери и ненужная работа. Кто даст гарантию, что новая работа будет завершена в Спринт и будет соответствовать DoD? Скорее всего, нет. Незавершенная работа не обязательно пойдет в следующий Спринт, потому что приоритеты могут измениться.
- Снижается способность реагировать на возникающую работу. Это нормально, что отдельные участники команды простаивают некоторое время в Спринте. Зато команда способна реагировать на незапланированную работу. Пожарные большую часть времен не загружены. Поэтому и могут быстро приехать на вызов.
Чек-лист по “недозагрузке”
Итак, мы поняли, чего не должен делать Скрам-мастер. А вот какой может быть правильный алгоритм действий? Обычно я проговариваю и объясняю Скрам-команде пункты, описанные в предыдущей секции. Затем работаю с возражениями. А потом предлагаю создать чек-лист “недозагрузки”. Это стандартный протокол, который вступает в действие каждый раз, если кто-то считает, что ему не хватает работы в Спринте. Вот пример чек-листа, который я позаимствовал у одной из команд:
Что делать,если у меня нет работы в Спринте?
- Я ищу, чем помочь остальным с взятыми задачами (даже не по своей специальности), например, парное программирование.
- Если не могу п.1, то я помогаю с доведением до ready следующих задач Бэклога Продукта.
- Если не могу пп.1-2, то занимаюсь собственными делами:, рефакторингом, “уборкой”.
- Если у меня нет задач из п.3, то я жду окончания Спринта обучаясь: читаю книги, посещаю сообщества и т.д.
Основные мысли
- Цель Скрама — работа над самым важным и достижение общих целей. Утилизация и эффективность разработчиков не является целью Скрама.
- Быть не в полной мере загруженным в Спринте — норма.
- Скрам-мастер может предложить команде создать стандартный протокол “недозагрузки”.
