• По окончании спринта команда проводит ретроспективу (чтобы понять, как улучшить свою работу), где присутствует и scrum-мастер, и, при необходимости, владелец продукта. Каждый участник отвечает на два вопроса: что было сделано хорошо во время спринта? Что можно улучшить? Scrum-мастер отмечает любые улучшения, а также отдельные пункты (монтаж нового сервера сборки, внедрение нового метода программирования или перепланировка офиса и т. д.) и добавляет их в список продуктового бэклога как нефункциональные элементы.
Вот и все! Ничего сложного.
Но если это так просто, то почему все мы не используем Scrum?
Почему же такой значительной части нашей команды, работающей со Scrum и соблюдающей все правила, кажется, что получаемый ими результат – это всего лишь немногим лучше, чем ничего? Чего не хватает?
Акт I. Я могу использовать Scrum?
Hover Puppy Software – небольшая компания, создающая сайты и приложения для мобильных телефонов. Она пользуется популярностью. Шесть месяцев назад выпущенное ими приложение для мобильного телефона принесло огромную выручку, и CEO решил вложить деньги в запуск нового сайта Lolleaderz.com, который позволяет пользователям создавать рейтинги любимых видеороликов.
В начале проекта его руководитель Роджер хотел использовать Agile. Он был по-настоящему счастлив, когда узнал, что команда рада такой перспективе. Разработчики мобильных телефонов в другой компании уже использовали Scrum для создания очень популярного приложения, и идея получила там широкое распространение. Один из членов команды стал называть Роджера scrum-мастером, и эта роль закрепилась за ним.
Первым делом Роджер начал искать владельца продукта, но нашел его не сразу. К счастью, Hover Puppy – небольшая компания, где сотрудники называют директора по имени. Роджер просто подошел к нему и объяснил ситуацию, описывая владельца продукта как «короля заинтересованных сторон» проекта. Примерно в то же время один из менеджеров, Ави, только что закончил проект. CEO познакомил его с Роджером, объяснил, что полностью поддерживает Scrum, и оставил их вдвоем – выяснять, как лучше организовать работу над проектом.
Поначалу все шло хорошо. Роджер установил продолжительность каждого спринта в один месяц, а Ави придумал бэклог задач для разработки. Роджер организовал ежедневные scrum-митинги, Ави занес их в свой календарь, чтобы видеть их каждый день. Первый спринт прошел отлично: все двигались вперед вместе, и команда добилась определенных успехов. В конце спринта команда предоставила Ави демоверсию сайта с несколькими функциями, которые они вместе планировали. Казалось, что эксперимент со Scrum удался.
В течение следующих нескольких недель в проекте начали появляться трещины, но он все еще держался на плаву. Один менеджер по обслуживанию клиентов настраивал показ рекламы нового блокбастера своего клиента, кинокомпании, чтобы он происходил при каждом наведении мышки на сайт Hover Puppy. Команда пообещала Ави, что предоставит ему демоверсию этой функции в конце спринта. Но на раннем этапе разработки возникли технические проблемы, и пришлось перенести эту задачу на следующий спринт. Роджер объяснил, что scrum-команды всегда поставляют работающее ПО, а если создание функции еще не закончено, то задача переносится на следующий спринт. Но они не были уверены, что именно так должен работать Scrum.
Работоспособность команды снижалась с каждым спринтом. К концу третьего спринта Ави почувствовал, что в основном занимается командой, поэтому на клиентов у него остается совсем мало времени. В начале проекта ему казалось, что он контролирует работу команды. Теперь же он начал понимать, что поторопился, согласившись стать владельцем продукта в проекте Lolleaderz.com. Роджер расстроился, услышав жалобы Ави, что команде тяжело работать с другими аккаунт-менеджерами.
Но хуже всего было то, что команде на самом деле надоела вся эта scrum-возня. Прежде чем Роджер и Ави получили возможность разобраться в этой проблеме, случилась еще одна неприятность. Три разработчика высказали Роджеру свое недовольство, что им приходится ходить на ежедневные scrum-митинги. Один из них сказал: «У меня и так много работы, а эти совещания просто пожирают мое время. Почему я должен сидеть и смотреть, как вы раздаете всем задания на ближайшие дни? Разве нельзя отправить их нам по электронной почте?» Роджер пробормотал, что таковы правила Scrum, поэтому разработчики должны продолжать ходить на собрания. Такой невнятный ответ никого не удовлетворил, и Роджер уже начал задумываться, не стоит ли прислушаться к мнению разработчиков.