Думайте, а не проводите спринты

Статья разработчика Джона Катлера о том, как бороться с превращением Agile-методик в необдуманный набор ритуалов.

Окей, у вашей команды есть выбор. У вас есть список задач с приоритетами, который нужно реализовать…

1. Вы можете выбрать то, что вы способны сделать за две недели, встретиться после этого времени и посмотреть, что сделано.
2. Вы можете пойти от наиболее приоритетной задачи к концу списка., встретиться через две недели и посмотреть, что сделано.

Какие аргументы обычно учитывают при выборе первого варианта:

1. При варианте №1 команда будет мотивирована выполнить свои обязательства по спринту.
2. Всегда хорошо к чему-то стремиться. № 1 позволяет это сделать.
3. Разработчики должны научиться выполнять свои обещания. Снова №1.
4. №1 показывает, что разработчики могут работать предсказуемо.
5. Как мы можем прогнозировать проект без №1?
6. С №1 мы создадим подходящую для получения обратной связи вещь.

Я могу поспорить, что с вариантом №2 вы можете создавать продукты не менее хорошо.

1. Вы хотите, чтобы ваша команда работала максимально хорошо. Реализация предопределенного набор функций — это не показатель того, что вы работаете наилучшим образом. Например, вы можете быть вынуждены начать рефакторинг. Это сложно. С №1 вы не выполните свое обещание, работая наилучшим образом.
2. Вариант номер 2 не отменяет постановку целей. Но этот вариант дает вам гибкость в постановке целей разных типов — создании циклов обратной связи и обучения, циклов поставки и т.д.
3. Многие команды “придерживаются №2, но с оценками и целями спринта…Мы не относимся к функциям, как к обязательству”. Хмм, ок.
4. Простой способ выполнять свои обязательства — обещать меньше. Мы этого не хотим.
5. Предсказуемость и определенность требуют времени. Вариант №2 может стать предсказуемым потоком спустя какое-то время.
6. На способность делать прогноз сильно влияют факторы, не связанные с временем работы: объем работы, количество незавершенной работы, постоянство среды, мультизадачность, обзоры, коэффициенты полезности и т.д. Эти факторы можно учесть в обоих способах работы, но с помощью №2 это можно сделать с меньшим количеством отвлечений и затрат.

И что?

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

Ничто не останавливает вашу команду от рефлексии по поводу процесса. Ничто не останавливает вашу команду от постановки значимых целей. Поэтому мой совет — не нужно устраивать спринты, начните думать (даже если в итоге вы будете проводить спринты обдуманно). Знайте причины определенных ритуалов. И сделайте экспериментирование и обучение безопасными.