Инкрементальность и прозрачность

Мы не успели. Мы хотели реализовать фичу с межведом и не успели.

Какие есть факты?

1. Команда А потратила в совокупности примерно 2 месяца на фичу межведомственного взаимодействия.
2. После этого была полная уверенность что все хорошо. Мы видели запросы - они создавали ощущение что все OK 
3. Комнада Б получила неделю чтобы показать свою часть и общее демо по задаче при сильно уменьшенном scope.
4. В результате продемонстрировать фичу в полном объеме не смогли.
5. Не смогли показать - значит все потраченное время это waste.

Знакомо?

Сейчас когда все видят fail, лучше всего пытаться что-то изменить. Мы все делали как раньше - это привело к fail, наверное есть что можно поменять.

Я вижу 2 проблемы.

Инкрементальность 

"Scrum employs an iterative, incremental approach to optimize predictability and control risk." Из Scrum Guide.

Как было в нашем случае. 

Мы разбили фичу на отдельные US, которые можно было делать параллельно. Потратили неделю. За день до демонстрации стали соединять куски в общую фичу. Вылезли проблемы. В результате ошиблись в сроках где-то на день, и как результат - фичу не показали. Это не единичный случай - большинство fail спринта имеют эту проблему в основе.

Как можно было сделать в рамках инкрементального подхода. 

Сделать маленькую сквозную задачу чтобы получить результат в самом минимальном объеме:

1. На форме ввода данных запроса есть только кнопка отправить запрос.
2. На клиентской части показываем лишь номер запроса и кнопка "Ответить".

Получить работающий прототип. На основе него принять следующие решения что и куда инкрементально развивать.

В рамках этого подхода через 2 дня была бы работающая фича в MVP виде. Риски по интеграции были бы удалены. Можно было бы параллельно развивать любые части, и в любой день иметь работающую фичу и тем функционалом, который был бы возможен с учетом сроков. Не нужно было бы сидеть по ночам.

Если бы это было бы не специальное демо, а просто обычный спринт - мы так же увидели бы фичу в конце спринта возможно с неполным АС. Но фича бы была. По ней можно было бы узнать больше и принимать следующие решения. Это крайне важно.

Какие варианты решения я вижу? 

Shift

Нужен shift мышления самих разработчиков. Его сейчас нет ни в одной из команд. Более того сейчас у разработчиков позиция что это нельзя делать, так как в инкрементальном подходе стоимость фичи выходит дороже. Нет - это не так. Это такое же заблуждение как с парной разработкой. "2 разработчика отдельно сделают всегда больше чем в паре." 

Эта смена мышления решит все проблемы с инкрементом продукта, но это сложно. Каждому в голову не залезешь.

Backlog 

Сверхспособный РО умеет так бить User Stories заранее что вынуждает команды из-за WIP ограничения поставлять продукт в рамках спринта инкрементально. Но фактически это означает что РО будет думать не над тем как быстрее и эффективнее сделать продукт. Его мысли направлены на то, чтобы вместо Scrum Master сформировать такие ограничения чтобы команда самоорганизовалась в сторону инкремента продукта. Это возможно, но это печально. 

Scrum Master 

SM может добиваться постепенной смены мышления в команде обсуждая реализацию каждую фичу и сподвигать их на инкрементальную разработку внутри монолитной единой крупной story как фичи. 

Прозрачность 

Второй факт что усугубляет проблему - это отсутствие прозрачности. Мы используем следующие утверждения:

1. Команда самоорганизована и отвечает только за финальный результат спринта. За промежуточные результаты в спринте никто не отвечает. То есть команде можно сказать что "у вас есть проблемы" только в самом конце спринта уже на демо. Когда все что могло случится - уже случилось и изменить ничего нельзя.
2. Burn-down chart ни о чем не говорит. Это мое любимое! Не важно что прошло пол-спринта и мы не съели ни одного point! Это не твои проблемы, Чувак! Ты нам мешаешь. Еще полчаса и мы сразу закроем 2 задачи на 5 и на 8, и все сразу станет OK.

В результате burn-down chart не используется, перетаскивание задач по статусам используется только чтобы видеть статус конкретной истории. То есть НЕТ НИКОГО прозрачного механизма, который бы мог показать как идет дела в любой момент времени. 

А его нет потому что он и не нужен. Подход прост - мы как Команда делаем что можем и в конце просто смотрим успели мы закрыть спринт или нет.

И все управления процессом поставки продукта у нас сводится к тому чтобы прийти за пару дней до демо и сказать - Чувак, нижних 3-х задач не будет, не жди. Давай выкинем их из спринта.

Chart - это один из механизмов перехода с Push управления на Pull на управление через  сигналы и прозрачности. РО должен не присутствовать на daily, и просто проходя мимо доски глядя на chart понять если ли риски на fail спринта и какие. Смысл chart-а в том что он убирает все эти эмоции и ощущения членов команд (Да, эта фича уже готова. Там пара тестов написать, залить в develop и перенесем в "Done"), и показывать просто цифры. Chart показывает факт - остальное ему не важно. В этом и смысл.

Для РО гораздо лучшей стратегией будет сократить scope ряда историй чтобы успеть сделать все запланированые фичи, чем выкинуть нижние фичи. Но он должен своевременно это увидеть. 

Что делать?

Я изменю процесс определения scope истории на более формальный и более определенный. Должно быть лучше видно как можно вырезать scope в случае проблем. Но это не решение.

Что делать командам А и Б?

Проведите ретроспективы и найдите решения по инкременту и прозрачности, которые будут работать у вас.