Гибкость в Scrum — это не возможность произвольно менять объем работ спринта, как некоторые могут предполагать. Это о возможности команды доставлять ценность каждые две недели и менять курс действий с такой же периодичностью.
Наверняка некоторые из вас сталкивались с ситуациями, когда в середине спринта добавляются задачи, не являющиеся критическими. В идеале, следует пересмотреть цель спринта и, при необходимости, начать новый спринт с обновленной целью. Такой подход может быть не самым удобным, но в определенных ситуациях он хотя бы позволяет команде сохранять фокус на чем-то одном.
Однако, особенно когда вы новичок в компании и не полностью осведомлены о продукте, менеджмент может попытаться воздействовать на ваше решение:
- «Это небольшая задача, может быть на день».
- "Разве у вас не запланировано 20% времени спринта на срочные ад-хоки?"
- «Это решение высшего руководства».
Перейдем к анализу каждого из этих доводов:
Это небольшая задача, может быть на день.
Менеджмент и руководители могут не обладать глубокими техническими знаниями. Задачи, которые могут казаться простыми, часто требуют детального анализа и планирования. Даже если задача действительно займет один день разработки, не стоит забывать о всех этапах ее выполнения:
- прояснить требования;
- обсудить бизнес логику со стейкхолдерами;
- учесть краевые сценарии;
- сформировать и выбрать наилучшее решение;
- запланировать в спринт, поменять задачи местами, передоговориться с командой о разных вещах;
- разработать (допустим, 1 день, как и предполагал стейкхолдер);
- протестировать;
- потестировать самому и показать стейкхолдерам, чтобы скорректировать ожидания;
- подготовить к релизу.
И сколько по времени и ментальным ресурсам занимает всё кроме разработки? Может быть и гораздо больше. А если делать это очень много и очень быстро — это неблагоприятно повлияет на процессы в других отделах.
Разве у вас не запланировано 20% времени спринта на срочные ад-хоки?
Не все команды могут позволить себе резервировать 20% времени на ад-хоки. Для начинающих команд даже основная цель спринта может стать вызовом.
Сработавшиеся команды может и могут себе позволить такую роскошь, конечно, но в любом случае на процессы внутри команды это влияет негативно.
В молодых командах нет и не должно быть никаких 20% в спринте на ад-хоки. В большинстве случаев только что сформировавшаяся команда не знает, что такое Story Points, как оценивать комплексность задач, как действительно эффективно участвовать в ритуалах, чтобы они по-настоящему имели ценность для команды и помогали достичь цель спринта.
Ну и в целом, разработка софта связана с большой долей неопределенности, и это стоит учитывать.
Это решение высшего руководства.
Важно помнить, что продукт разрабатывается для пользователей, а не для руководства. Роль руководителя — определять стратегическое направление, а не участвовать в микроменеджменте.
И не поймите меня неправильно, я понимаю, что, например, в случае изменения регуляторных требований, от которых зависит судьба компании, действительно есть смысл поднапрячься.
Только чаще всего, приходят с ад-хоками другого типа — такого, без которого можно пожить недельку-полторы до следующего спринта и ничего плохого не случится.
В завершение хочется еще раз подчеркнуть: гибкость в Scrum не заключается в способности менять объем работ спринта на лету. Это о способности команды эффективно адаптироваться и предоставлять результаты в установленные сроки.