Нужна ли команде Цель спринта в Scrum?
Вспомним, что о Цели спринта (Sprint Goal) говорится в официальном руководстве по Scrum:
Sprint Goal — единственная цель на Sprint. Несмотря на то, что Developers привержены Sprint Goal, она обеспечивает гибкость с точки зрения выбора конкретной работы, необходимой для ее достижения. Sprint Goal также обеспечивает связность и сфокусированность, побуждая Scrum Team работать совместно, а не над отдельными инициативами.
Sprint Goal создается во время Sprint Planning, а затем добавляется в Sprint Backlog. Developers помнят о Sprint Goal в ходе работы над задачами Sprint. Если работа не соответствует ожиданиям, они взаимодействуют с Product Owner, чтобы пересмотреть содержание Sprint Backlog в рамках Sprint, не изменяя Sprint Goal.
...В ходе Sprint Planning ... вся Scrum Team совместно определяет Sprint Goal, которая объясняет, почему Sprint ценен для заинтересованных лиц. Sprint Goal должна быть сформулирована до окончания Sprint Planning.
Таким образом, можно определить несколько преимуществ от использования Цели спринта - четкий фокус команды во время работы на достижении цели; критерий для внесения изменений в работу (помогут ли они достижению цели или наоборот помешают); мотивирующий фактор в работе, побуждающий в том числе к взаимопомощи и командной работе; прозрачность работы команды для заинтересованных лиц (stakeholders).
Но определение цели на спринт может быть достаточно сложным для команды, многие команды испытывают трудности с этим. А ведь это регулярный процесс, на каждом планировании спринта приходится это делать (в среднем плюс-минус раз в две недели). Если сама команда не видит пользы от этого артефакта и считает формулировку цели пустой тратой времени, делать они это, скорее всего, не будут. В итоге, после нескольких начальных спринтов в проекте (по опыту, первоначального запала хватает от 1-2 мес до полугода) либо на это все забивают с аргументацией: "Мы не можем брать на себя такое обязательство, все эти строгие цели и дедлайны это не Agile", "В нашей команде это не работает", "Клиенту на эти цели пофиг, значит нечего тратить на них время"и т.п. Либо цель определяет владелец продукта / менеджер в приказном порядке (в командах, работающих на "ручном управлении").
Иногда цель спринта становится мульти-целью, когда команда не может определить что главное для клиента, какую пользу ему принесет этот инкремент, и включает в Sprint goal несколько пунктов. Не говоря уже о Цели 80-го Уровня: "Закрыть все эти чертовы таски за этот спринт!"
Отсутствие четкой цели на спринт может привести к тому, что команда потеряет фокус, что же важно сделать за спринт, каждый будет делать те задачи, которые ему кажутся сейчас приоритетными ("кто в багфиксинг, кто за техдолгом"). В итоге на спринт ревью и ретроспективе вместо обсуждения прогресса в достижении Цели спринта, члены команды откупаются ничего не значащими фразами "вроде всё норм, всё как всегда, замечаний нет". Про предлагаемые улучшения, которые в идеале должны быть по итогам ретро-сесии добавлены в бэклог, и говорить не приходится.
Встречал такие проекты и команды на практике, итог практически всегда предсказуем - расфокусировка команды, быстрая потеря мотивации у разработчиков, отсутствие улучшений в работе, постоянный перенос незавершенных задач на следующий спринт, поставка нового релиза раз в 2-3-4 месяца. И вот уже у вас вместо Скрама лишь пустой по сути карго-культ, и руководство ищет на замену нового менеджера или Скрам-мастера, потому что этот "поломался"...
Между тем, вместо того чтобы убеждать команду "старайтесь получше, чтобы сформулировать хорошую Цель спринта", можно обратить внимание, какие есть препятствия в формулировке релевантной Sprint Goal. Команда опасается негативных последствий в случае не достижения цели. Слишком короткие спринты. Владельцу продукта не хватает полномочий. Слишком много внешних зависимостей. Склонность высшего руководства или клиентов набрасывать "срочные очень приоритетные" задачи.
Не игнорируйте постановку цели на предстоящий спринт, это может быть очень полезным инструментом если использовать правильно. Вспомните, с чего начинается официальное руководство по Scrum:
Каждый элемент фреймворка служит определенной цели, необходимой для достижения общей ценности и результатов от применения Scrum. Изменение ключевых идей или структуры Scrum, исключение каких-либо элементов или не следование правилам Scrum приводит к сокрытию проблем, ограничивает преимущества Scrum и потенциально даже делает его бесполезным.
Не старайтесь убедить или заставить людей формулировать цель - лучше обратите внимание на выяснение и устранение препятствий на пути к этому.
В заключение - цитата из гениального поста на Хабре о имитации Agile:
***
Не достигаются цели спринта
Коучи могли вам сказать, что у каждого спринта должна быть цель. Может они даже они упоминали, что цель спринта придумывается в ритуале Планирование Спринта (он же грумминг), а ее достижение потом проверяется в ритуале Ревью Спринта (почти как ретро). И может быть ваш неопытный владелец продукта (или это был скрам-мастер?) это запомнил и даже решил применять.
Это было ошибкой. В имитации Agile нет и не может быть такой формальной штуки, как цель спринта, потому что команды работают на куда более осязаемые вещи, как-то выпуск первой версии, то бишь MVP, в конце следующего года, а в ближайшей перспективе у них есть закрытие задач, решение проблем и т.д.
А когда у команды появляются цели спринта, то надо каждые две недели придумывать новые цели, а через две недели как-то объяснять, почему не достигаются. Хорошо, хоть объяснения эти происходят только внутри команды и больше никому не нужны.
На эту проблему есть два способа решения - простой и радикальный. Первый - просто перестать ставить цели. В конце концов, команда профессионалов и так знает, чем ей заниматься, нужная сторя заведена и всегда стоит в спринте, как она же стояла в прошлом спринте, так и будет стоять в следующем, и далее. А у ВП есть дейли, на котором он держит руку на пульсе команды и всегда может направить ее в нужную сторону. Каждый день в новом направлении.
Второй способ чуть более радикальный, но тоже достаточно простой - перейти на Канбан. Я выше упоминал, что есть несколько конфессий Agile, так вот Kanban - это еще одна. Она гораздо, значительно проще Scrum-а - в ней весь процесс сводится к одной доске, на которой задачки идут по этапам. Доска расчерчена на колонки, каждая колонка - этап. Новая задача появляется слева, идет по колонкам слева направо, потом убирается с доски. Всё! Это весь процесс. Ни ритуалов, ни спринтов, ни целей. Двигаем задачи и радуемся Agile. Слава разработчикам Атлассиана, в джире переход со Scrum на Kanban делается легким мановением руки.
Но не рекомендую внедрять с самого начала Kanban вместо Scrum. Именно из-за его простоты продать топ-менеджменту в качестве современной, совершенной, блестящей методологии всего одну доску будет сложновато. Там и обучения всего на день, ну два, а не на месяц, и ритуалов практически нет. Лучше "внедрить" Scrum, потом тихонько переползти на Kanban. И то, и то Agile, так что подмены никто не заметит.
Интересная мысль! Нам кажется, что у всего есть своя цель. Может даже не такая очевидная на первый взгляд :)
Скажу так, жестко держаться за методологию эт обрекать себя на провал. Всегда допустимо видоизменять правила и быть гибче. Поэтому, само собой, можно ставить цели, почему б и нет?
Как мне кажется, в данном случае подход должен быть таким - методология (строго говоря Скрам это фреймворк) создана вот такой, почему она такая подробно объяснено, и проверено практикой. Если вы что-то изменили / отбросили и у вас всё отлично работает - ну отлично, почему нет.
Если же такой подход "не взлетел" - вас предупреждали, вы должны были понимать риски. Возможно стоит не искать причину провала в методологии как таковой, а понять почему она такая какая есть и в чем смысл.
Как вообще может помочь цель сприна, если в большинстве случаев у самой компании нети никакой цели?