Comments 27
Если нет глупых вопросов и ответов — это серьёзно. А если это серьёзно, то это не уже игра.
Я имел в виду, что можно задавать глупые вопросы — хороший фасилитатор найдёт способ превратить их в умные.
Перед командой стоит цель закончить этот грёбаный проект. Но эта цель не стоит перед скрам-мастером и он не хочет о ней слышать. Он хочет тратить время команды на то, чтобы рисовать цветочки на доске и включать музыку из порно-роликов.
Если цель «закончить грёбаный проект» не стоит перед скрам-мастерм — это плохой скрам-мастер. Именно поэтому появляются плохие скучные ретро, когда скрам-мастер делает Agile ради аджайла. Целью скрам мастера должно быть: а) Помочь команде быстрее доделать «этот гребаный проект». б) Сделать это так, чтобы в процессе команда научилась доделывать эти гребаные проекты быстрее и качественне, чем раньше.
Иначе всё зря
— окончание проекта будет означать поиск нового проекта или сидение на скамейке запасных, в общем выход из зоны комфорта.
— проект в принципе не имеет конца в среднесрочной перспективе. Успешный продукт, например, фичи в котором пилить можно десяток лет только из текущего бэклога.
1) если команда не хочет ничего менять, внедрять Agile невозможно. Нужно либо сворачивать попытки, либо поставить команду в ситуацию, когда перемены неотвратимы — речь о более challenging KPIs
2) можно же и в этом "вечном" проекте улучшать свой перформанс постоянно — пилить фичи быстрее, пилить фичи надежнее и более оттестированные, креативить или, например, добавить "ВАУ-фактор".
Весь смысл чтобы команда увидела себя как отдельный стартап — пусть предложат что они могут делать для клиента лучше и что они хотят получить за это от менеджмента, сформулировать и вперёд — добиваться с помощью Agile.
Пока нет реальной потребности улучшаться, Agile не нужен
По книжкам, ретроспектива должна проходить каждый спринт, и иногда это слишком часто. За один спринт ничего особо не меняется, и сказать особо нечего, многие начинают повторяться ("нам нехватает тестовых окружений", "покрытие тестами недостаточное", и т.д.).
Для себя взял за правило записывать по ходу спринта любую свежую мелочь, которая всплывает, и которую можно будет потом обсудить на ретро.
Если за спринт ничего не меняется, значит работа выстроена неправильно. Если вы правильно определили цели саморазвития для каждого члена команды, то у него стояли задачи на эту неделю по улучшению. Если команда просто каждый спринт делает одно и то же, а именно рутинную работу, тем способом, которым они делалт её всегда то смысла в ретроспективах нет не то что в еженедельных, а вообще.
Ретроспектива уместна только там где у команды есть чёткие цели по непрерывному улучшению.
Если их нет то надо начать со стратегической ретро (необязательно называть её "ретроспективой"), определить, хочет ли команда развиваться, если да, то куда и как.
Если команда развиваться не хочет, значит надо сворачивать Agile и увольнять скрам-мастера, потому что тогда он не нужен
Это отличная возможность для скрам-мастера и продукт оунера начать "eliminate impediments" — устранять внешние препятствтя.
Тут может быть куча инструментов задействлвано, один из них — совместная ретроспектива
Было интересно, пока не предложили обсудить цвет стен. И кого-то удивляет, что разработчик, которого волнуют принципиальные проблемы, разочарован и не хочет?
Фтопку всё, что не приближает к цели, фтопку! Стен нет, я их не вижу, они не существуют!
P.s. но кресла я бы обсудил, да...
Стены, как пример)
Если стены пофиг, то нафиг стены! Можно их тупо снести, мы так делали на некоторых проектах — реально брали в руки молотки и крушили) ит воз фан)
Главное чтобы команда наконец захотела что-нибудь улучшить и начала улучшать. Смысл в том, что если трудно сразу определить, что нужно улучшить в работе, можно попрактиковаться на простых бытовых вещах.
А я ему на это: Вот что значит высшее образование!
Я это о чём: кто не хочет, тот и перфоратор сломает за полштуки баксов, а об улучшении процесса даже мысли не возникнет.
Как перестать фэйлить и начать проводить нормальные ретроспективы