Затем пришло время ежегодных отчетов. Его сосед по офису вернулся с отчетной встречи, хлопнул дверью и ударил головой по их общему столу. В начале года команде поручили огромный и важный проект, который за все это время не сдвинулся ни на йоту. Поскольку он был ведущим разработчиком, руководитель отчитал его и сказал, что в этом году они «эффективно добились ничего». Для Алекса самым странным в ситуации было то, что они трудились вместе, в одной комнате, в одной команде, полгода, все время говорили о работе, жаловались на нее, но он ни разу не слышал об этом проекте. Они усердно трудились и делали то, что их просили. Никто из партнеров не хотел саботировать проект; они просто не понимали, что, отвлекая их важными запросами, они создали условия, в которых команда не смогла даже сфокусироваться на проекте, не говоря уже о том, чтобы закончить его. Взяли ли они на себя ответственность за свои действия? Нет. В фиаско они винили ведущего разработчика.
Я слишком часто вижу такие ситуации. Менеджмент, продажи, поддержка постоянно отвлекают команды и просят их бросить все, чтобы выполнить одну важную задачу, которая только что появилась. Затем, когда они отправляются на обзор спринта, конечно, ничего не сделано. И менеджеры думают,
Решение этой и многих других проблем в Scrum – сделать стоимость решений наглядной. Иногда и правда возникают чрезвычайные ситуации, с которыми нужно справляться немедленно. Но не все ситуации такие. Именно поэтому команде не нужно загружать себя полностью, лучше выделить часть времени на формирование буфера на отвлечения. Допустим, обычно команда доводит до готовности 20 элементов бэклога за спринт. Значит, в следующем спринте им нужно взять 15 элементов, оставив резерв для подстраховки.
Все запросы, поступающие команде, проходят через владельца продукта. Только он решает, нужно ли отвлекать команду, поскольку это замедлит ее работу. По этой причине он может сказать: «Да, это важно, но не важнее тех элементов, которые есть в бэклоге этого спринта, поэтому мы выполним эту задачу в следующем спринте. Или через один спринт». Есть задачи, которые на самом деле неважны, и, поскольку владелец продукта управляет бэклогом, он может сказать: «Да, конечно, я помещу это в бэклог! В самый низ списка». Но есть задачи, ради которых стоит отвлечь команду, и на них можно задействовать часть зарезервированного времени.
Вот в чем загвоздка: когда срочные задачи переполняют буфер, нужно отменить спринт. Немедленно прекратите работу и измените планы, касающиеся того, что вы можете сделать в оставшееся время спринта, и ваших приоритетов. Поскольку, если буфер переполняется, часть работы, которую команда обязалась выполнить за спринт,
Косвенный результат отмены спринта – то, что лидеры ненавидят это. И на собрании отдела продаж в понедельник Салли может обратиться к Рею: «Почему ты сорвал спринт, Рей? Теперь то, что я обещала клиентам, не будет сделано. В этом
Другой косвенный результат отмены спринта заключается в том, что, когда чей-то менеджер просит что-то сделать, можно ответить: «Это не от меня зависит. Я бы хотел помочь, но есть новые правила – нужно поговорить с владельцем продукта. Если бы я решал, то, конечно, я бы помог, но не я придумываю правила».
Представим, что команда учится использовать Scrum и первый же ее спринт нужно отменить из-за того, что один из семи партнеров ее отвлекает. Так результаты того, что их отвлекают, становятся
Важно сделать так, чтобы цена решений была наглядной. Внешние, не зависящие от команды силы часто сдерживают ее процессы. Запомните: настоящая цель – скорость. Измерьте ее и найдите то, что мешает команде ускоряться.
Практика буфера на отвлечения позволила 3M HIS перейти от традиционной организации к гибкой. Вначале около 60 % усилий команды уходили на побочные задачи. Но с годами они смогли сфокусироваться на том, чтобы снизить этот показатель. Теперь он составляет около 20 %. И они всерьез задумались об этом. Они работают над разными изменениями, которые позволят им выйти на следующий уровень.
Соблюдение чистоты