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

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

Я не знаю, почему самоорганизация в скраме работает так здорово, но это вряд ли имеет значение. В конце концов, мне известны сотни успешных скрам-проектов на тысячи спринтов.

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

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

Я провел с командой упражнение «Быстрый старт». Это интенсивная двухдневная сессия, в которой участники изучают практики скрама и готовятся к запуску своего первого спринта. Учебная часть сессии прошла хорошо, но, когда я добрался до первой части планирования спринта, все начало рассыпаться. Комната была переполнена: 17 участников команды разработки плотно расположились вокруг небольшого стола, а заинтересованные лица сформировали кольцо за ними. Более активные участники команды расспрашивали и общались с владельцем продукта, а более пассивные – выпали из процесса. К началу второй части планирования спринта, когда команда разработки определяет свой бэклог спринта, по-прежнему участвовали только самые бойкие. Прерывая их, я несколько раз старался вовлечь молчунов и спрашивал, над чем они будут работать. Я уточнил, понимают ли они, что нет ничего хуже, чем во время ежедневного скрама сознаваться, что они ничего не делали и вообще не сильно вовлечены в проект. Имея благие намерения, этим своим замечанием я добился лишь того, что пассивным участникам стало только хуже.

Команда разработки была слишком большой, поэтому вовлечь всех не удалось. Оптимальный размер команды – от трех до девяти человек, чтобы во время планирования спринта они могли общаться, глядя друг другу в глаза, взаимодействовать и формировать общий план действий. Команда из 17 человек сделала фактически то же самое: 7 активных участников планировали спринт, а 10 пассивных сотрудников не участвовали в процессе. Что мог сделать я? Понимая, что пересобирать команду уже поздно, я решил оставить все как есть и посмотреть, что произойдет. Несколько дней спустя я присутствовал на ежедневном скраме этой команды разработки. К моему большому удивлению, о выполненной и планируемой работе рассказывали все. Конечно, с таким количеством людей ежедневный скрам длился 20 минут вместо 15, но это была активная, оживленная сессия, и все участники команды, казалось, были увлечены работой. После встречи они поделились со мной своими соображениями. Они решили, что менеджмент сформировал такую большую команду разработки по ошибке, однако не хотели перечить ему, полагая, что мудрое руководство знает о причинах, по которым команда должна быть настолько многочисленной. Но большая команда разработки не функционировала – прогресса в работе над задачами спринта почти не было. Команда решила разделиться на четыре подгруппы численностью от трех до пяти участников каждая. Руководители программистов и тестировщиков помогли сформировать эти подгруппы и разделить работу так, чтобы сложносоставные задачи выполнялись внутри подгрупп, а коммуникации между ними свелись к минимуму. Также они взяли на себя ответственность за устранение зависимостей, возникающих между участниками команды в ходе работы. Эти руководители были частью команды разработки, они были преданы работе и общей цели, поэтому их действия являлись проявлением самоорганизации.

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

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