Пассивная реакция какая-то. Так и до выученной беспомощности недалеко :(

Тут скорее про то, что изначально они были против, а оно сработало. Непросто признавать свои ошибки

Значит есть куда расти... не проговаривал им это на ретроспективе?)

Интересно как DoD стал причиной:
- уменьшения количества багов
- упрощения тестирования
- появления практики фича-флагов
- повышения прозрачности качества фичей для продактов

Еще не доводилось сталкиваться с таким применением этого элемента фреймворка. Можешь подробнее рассказать?

Родился анекдот:

Однажды Рузвельта, Черчилля и скрам-мастера попросили накормить кошку горчицей.
Рузвельт схватил кошку за шкирку одной рукой, а другой - взял ложку,
набрал горчицы и стал запихивать ее кошке в рот. Огромными трудами ему
удалось запихать кошке в рот небольшую толику горчицы. "Нет, - сказал
Черчилль, - это нецивилизованный метод".
Он налил горчицу в блюдце и с размаху ткнул кошку туда мордой. Кошка
морщась и отфыркиваясь начала слизывать горчицу с морды. Скрам-мастер схватил
кошку и намазал ее горчицей задницу. Кошка дико завопила и начала слизывать
горчицу. "Видите, - сказал скрам-мастер, - добровольно и с песнями!"

:)

Опционально можно на эджайл коуч заменить )))

Ну...
Команда, которая сопротивлялась была поделена на две и тема ДоДа более не поднималась. На ретрухе я упомянутую реакцию и зафиксировал.

Пока звучит страшно, сорян.

Любая команда, которая посмеет мне сопротивляться - будет помножена на ноль)

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

Первое и второе было достигнуто юнит-тестами. Да, их у нас не было.
Фича-флаги поместили в ДоД по той причине, что каждая серьезная бага может стопнуть нам прод. Прецеденты были. А стопнуть прод для нас - это очень страшно. Потому флаги просто добавили
Не все продукты знали, что нужно сделать и в каких объемах, чтобы фича была нормального качества. ДоД опрозрачил это дело и вопросов стало меньше.

Разделение было по причине того, что команда была большой. Этот кейс не имеет к разделению никакого отношения.

Спасибо, стало понятнее, а то начало складываться впечатление, что DoD какой-то магической силой обладает)

Не кажется ли тебе, что причиной:
- уменьшения количества багов
- упрощения тестирования
- появления практики фича-флагов

стало на самом деле введение инженерных практик:
- юнит-тестов
- фича-флагов

Почему ты приписываешь суть причинности в этом случае DoD?

Потому, что фича не считается готовой, если у нее нет фиче-флага.

Тимур, давай шаг назад сделаем и проговорим в чем суть (common) Definiton of Done в Scrum.

Чтобы не тратить время на открытие новых вкладок, скопирую референс сюда:

If the definition of "Done" for an increment is part of the conventions, standards or guidelines of the development organization, all Scrum Teams must follow it as a minimum.

If "Done" for an increment is not a convention of the development organization, the Development Team of the Scrum Team must define a definition of "Done" appropriate for the product. If there are multiple Scrum Teams working on the system or product release, the Development Teams on all the Scrum Teams must mutually define the definition of "Done".

Всем добрый вечер! Возник вопрос:какие встречи вы регулярно проводите с командой? Какие считаете наиболее эффективными из стандартных видов встреч?

Давай сделаем. Но для чего?

Что ты пытаешься до меня донести?

Чтобы прояснить в твоей истории в чем заслуга конкретно DoD, а в чем введения практик юнит-тестов и фича-флагов. И можно было бы также поговорить о том кто в Scrum формулирует DoD.

Зачем ты пытаешься разделить влияние фича-флагов и ДоД в моем контексте? Не могу понять.

Я ж написал. Мы не считаем фичу готовой, пока нет фиче-флага. И это закреплено в ДоДе.

1. DoD в Scrum - суть общее восприятие сделанного теми кто выполняет работу и теми кто инспектирует результат. Ничего более. DoD ничего кроме прозрачности не привносит. Ни новых практик ни требований по их соблюдению.

2. Согласно Scrum guide формированием DoD занимается DevTeam(s). За основу могут быть взяты принятые в компании стандарты. Например, если в вашей компании принято писать юнит-тесты, а DoD вашего продукта опирается на принятые стандарты, то юнит-тесты должны быть объявлены в DoD. Если юнит-тестов не было до введения DoD, а с введением DoD они появились, то не DoD привнёс юнит-тесты - вы изменили стандарты компании одновременно с введением DoD. И именно введение практики юнит-тестов повлияло на баги, тестирование и т.п. DoD тут нипричем

3. Если вы используете DoD чтобы огнем и мечем приносить стандарты в команды, которые считаете DevTeam в составе Scrum команд, то кажется вы что-то делаете не так, хотя бы с точки зрения Scrum. IMHO

Та самая статья про структуры - https://aftershock.news/?q=node/914716

Наконец-то дописал. Для меня описанная в статье схема объясняет перспективы Scrum of Scrums, Agile трансформации сверху и прочего и прочего. Замечания и критика в личку, тут - приветствуются.