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