Advanced Scrum: проблемный вопрос

Конечно, на этот вопрос приятно ответчать именно отрицательно. Мы ведь все герои! Намного сложнее признаться в наличии проблем, а тем более ещё и попросить о помощи. Это же прозвучит как громогласное заявление в своей некомпетентности перед всей командой! А если такое заявлять ежедневно — о, ужас!

Интересно, как может не быть проблем в команде, которая в крайне сжатые сроки пытается выпустить рабочую версию продукта, требования которой уточняются по ходу реализации, тестирование проводится параллельно с разработкой, а заказчик накидывает пожелания по улучшению фич на каждой промежуточной приёмке?

У вас должны быть проблемы! Ежедневно. Если их у вас нет — вы делаете что-то неверно.

Что же делать, если команда морозится?

Я думаю, стоит изменить формат третьего вопроса.

Вместо закрытого вопроса (со всеми вытекающими): «Есть ли проблемы?», — или его открытого варианта (чуть лучше, но всё равно не то): «Какие у тебя есть проблемы?» , — я предлагаю использовать такой:

«ЧТО БЫ ТЕБЕ МОГЛО ПОМОЧЬ ЗАВЕРШИТЬ ТО, НАД ЧЕМ ТЫ СЕЙЧАС РАБОТАЕШЬ?»

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

Подумайте, чего вы хотите как Скрам-мастер на самом деле?

а) Получить список проблем?

б) Сделать так, чтобы все задачи были сделаны?

Представьте себе такой утренний митинг:

— «Я вчера закончил часть фичи, связанной с аутентификацией админов. Сегодня я планирую прикрутить простой админский интерфейс для управления учётными записями пользователей», — говорит член команды Федя.

 — «Федя, что бы тебе могло помочь сделать это?», — голос Скрам-мастера.

 — «Ну… (пауза — признак хорошего вопроса), мне бы помогло, если бы у меня был набросок интерфейса админки, чтобы я потом по сто раз не переделывал».

Мы говорили о проблемах? Нет.

Мы их нашли? Да!

У нас нет наброска дизайна.

Признался бы Федя в том, что это для него проблема? Не факт.

Скорее всего ответил бы свое: «Проблем нет. Разберемся!».

Скрам менять можно и нужно. Особенно, если вы понимаете, как и зачем вы это делаете.

По словам его со-автора Кена Шуэйбера, Скрам 2.0 никогда не будет описан, но это не должно останавливать нас от улучшения вещей, которые были описаны 10 лет назад.

С тех пор мы многому научились!

Кстати, я предлагаю также ввести четвёртый вопрос: «Какими новостями ты бы хотел поделиться с командой?».

Статья от 12/2011

Больше о митингах.