потому как люди все равно будут управлять проектом как умеют :D

Или вот: 1. ты приходишь к тимлиду и объясняешь что он теперь отвечает за то, чтобы команда принимала решения по сложности PBI 2. ты приходишь к тимлиду и говоришь, что он теперь называется scrum master

Собственно тим лида делатб скоам мастером уже ошибка

СМ не обязан быть технически подкован, у него совершенно другого рода задачи

СМ не обязан быть технически подкован, у него совершенно другого рода задачи

Не спорю, но было бы хорошо если бы этого тим лида уведомили что отныне он сервант, а не лид))

Можно пример?

Да, пожалуйста. 1. Запустили спринт как обычно, планирование прошло успешно. На 2-3-4 день заметили что ни одна из историй не прошла стадию кодирования. От волнения перешли плавно к конструктиву, построили гипотезы в отношение PO, устроили на час собрание devteam + PO, обсудили, выработали план и конкретные действия. Проблема была в том, что программистам нужна была консультация с PO по вопросам, которые всплыли по ходу решения задачи, а PO не был на связи. Решение - приняли стратегию согласно которой PO был по умолчанию приглашен на Daily и присоединялся либо когда мог либо когда команда явно обозначала такую потребность. В случае недоступности PO договорились о делегации, если не работало и это PO согласился с принятием выбора команды. Обсуждение до ретро в конце спринта позволило не зафакапить весь скоуп. Это пример проблемы. Теперь реальный пример идеи на улучшение. 2. Один из разработчиков обратил внимание на то, что истории часто возвращаются на доработку из-за большого количества явно обнаруживаемых дефектов, пару дней он обсуждал это только со мной, потом вынесли на обсуждение с командой. Договорились до коммита в ветку программист будет в паре с тестером проводить sanity check. Это сократило число возвратов уже в текущем спринте и соответственно всю цепочку разработки истории. В итоге скоуп закрыли раньше на 2 дня и повысили производительность на будущее. Сами представьте, что бы было отложи мы обсуждение/решения на конец спринта. И главное - в чем плюс?

Да, пожалуйста. 1. Запустили спринт как обычно, планирование прошло успешно. На 2-3-4 день заметили что ни одна из историй не прошла стадию кодирования. От волнения перешли плавно к конструктиву, построили гипотезы в отношение PO, устроили на час собрание devteam + PO, обсудили, выработали план и конкретные действия. Проблема была в том, что программистам нужна была консультация с PO по вопросам, которые всплыли по ходу решения задачи, а PO не был на связи. Решение - приняли стратегию согласно которой PO был по умолчанию приглашен на Daily и присоединялся либо когда мог либо когда команда явно обозначала такую потребность. В случае недоступности PO договорились о делегации, если не работало и это PO согласился с принятием выбора команды. Обсуждение до ретро в конце спринта позволило не зафакапить весь скоуп. Это пример проблемы. Теперь реальный пример идеи на улучшение. 2. Один из разработчиков обратил внимание на то, что истории часто возвращаются на доработку из-за большого количества явно обнаруживаемых дефектов, пару дней он обсуждал это только со мной, потом вынесли на обсуждение с командой. Договорились до коммита в ветку программист будет в паре с тестером проводить sanity check. Это сократило число возвратов уже в текущем спринте и соответственно всю цепочку разработки истории. В итоге скоуп закрыли раньше на 2 дня и повысили производительность на будущее. Сами представьте, что бы было отложи мы обсуждение/решения на конец спринта. И главное - в чем плюс?

а где у вас в этих кейсах DoD?

На ретро просто отметили что добавили пунктик в дод, не вижу противоречий

На ретро просто отметили что добавили пунктик в дод, не вижу противоречий

проблемы начинаются когда ретро в конце спринта а спринт месячный :DDDD

Вы DoD расширяете по каждой проблеме?

На экзаменах по скраму, замечу. Не по внедрению.

На мой взгляд на ретро обсуждвют не одну, а целый пепечень проблем

вам скорее всего реально не нужен спринт в месяц

Так у вас же много улучшений за спринт?

не упрощайте себе работу. Давайте исходит из того что нужен

да в том то и дело что спринт в неделю это не упращение :D вообще нигде не сказано что вы не можете делать улучшения на спринте. просто на ретроспективе обсудите как эти улучшения прошли/внедрились

зачем? ради традиции? Что если у нас прозрачность в команде такова что вот эти "обсудите как эти улучшения прошли/внедрились" будет выступлением капитанов очевидность?

зачем? ради традиции? Что если у нас прозрачность в команде такова что вот эти "обсудите как эти улучшения прошли/внедрились" будет выступлением капитанов очевидность?

чтобы понять были ли эти улучшения полезны :D это не всегда всем очевидно

А вы уверены что у членов команды не появятся другие предложения?

не всегда и всем - да. Но мы, возможно, даже перебарщиваем местами с прозрачностью, поэтому в данном примере всем и всегда

у улучшений тоже должен быть предел, нельзя всё время убирать и добавлять ластик на конец карандаша. В нашем случае схема накопления идей/проблем для ретро в конце показала себя хуже чем 1-4 улучшения внутри. Также такая схема дала больший рост производительности команды

Думается мне вы могли бы статью написать по этому поводу)

у улучшений тоже должен быть предел, нельзя всё время убирать и добавлять ластик на конец карандаша. В нашем случае схема накопления идей/проблем для ретро в конце показала себя хуже чем 1-4 улучшения внутри. Также такая схема дала больший рост производительности команды

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

Наши небольшие ретро выполнялись в том же в формате что и одно большое

скорее всего у вас был очень не эффективный для этого формат и стоит поискать другой.