А как прозрачность достигается? Как ребята понимают какую именно сейчас задачу брать и т.д.?

А как прозрачность достигается? Как ребята понимают какую именно сейчас задачу брать и т.д.?

Точно так же, как понимают, какую задачу брать в спринт.

Вот что вверху бэклога - то и берут.

:)) если в команде 6 +/-3 человека, Вася знает чем занят Петя или это уже не обязательно?

У них single piece flow :)

К той или иной вариации single piece flow, кстати, многие команды приходят.

Рано или поздно :)

А самое поздно это через сколько?

Минут, часов, дней?!

Эээээ

Лет?

Понимаю вопрос глупый и простой, но есть тут важный аспекты...

Как только команда начинает сознательно оптимизировать поток работы, которая через нее проходит, она приходит к single piece flow.

А вот сколько у команды уходит времени на то, чтобы начать оптимизировать поток работы - зависит от команды.

В команде может не быть прозрачности, "PO" раздает задачи каждому, по сути делает force-assign, только он/она знает зависимости и все через него проходит...

Я предполагаю...

В команде может не быть прозрачности, "PO" раздает задачи каждому, по сути делает force-assign, только он/она знает зависимости и все через него проходит...

Мы еще scrum обуждаем?

Поэтому может у вас уже и не нужны эти ивенты...

Мы еще scrum обуждаем?

😁😁😁😁👍

Как только команда начинает сознательно оптимизировать поток работы, которая через нее проходит, она приходит к single piece flow.

А что такое single piece flow

Может я что-то упуская?!

http://www.kaizenworld.com/kaizen/one-piece-flow.html

Всякие вещи типа "планирование спринта", "ревью итерации" и сама концепция итерации существовали сугубо в виде административных процедур :)

Все комменты к этой фразе были

Ну эта фраза только в контексте имеет смысл :)

https://www.youtube.com/watch?v=JoLHKSE8sfU

Пояснение без текста :)

Ну эта фраза только в контексте имеет смысл :)

😁 все последующее в этом контексте и шло, вне бысмысленно

В общем, если коротко: команда уже умела самостоятельно управлять потоком ценности и потоком работ так, что любая предзаданная итерация и, соответственно, все обслуживающие итерацию механизмы Scrum становились лишними.

В agile product management'е действительно много метрик и их меряют или так утверждают. А толку... Innovation rate, customer satisfaction, usage index, time-to-market, time-to-learn... Если они низкие и время большое, определенно вся скрам команда делает не то

В общем, если коротко: команда уже умела самостоятельно управлять потоком ценности и потоком работ так, что любая предзаданная итерация и, соответственно, все обслуживающие итерацию механизмы Scrum становились лишними.

Отменяйте ивенты, пробуйте анти-паттерны. 1-2 спринта без планирования и ревью проведите

Команда сама даст ответ

Отменяйте ивенты, пробуйте анти-паттерны. 1-2 спринта без планирования и ревью проведите

Спасибо за своет, я им передам :)

👌

В общем, если коротко: команда уже умела самостоятельно управлять потоком ценности и потоком работ так, что любая предзаданная итерация и, соответственно, все обслуживающие итерацию механизмы Scrum становились лишними.

Тут на мой взгляд - либо очень хорошо поставили не только практики и процессы, но в том числе у команды есть тот самый пресловутый agile-mindset и высокий уровень самоорганизации. Что по сути бэклог сформирован и прозрачен команде на 1-3 спринта вперед. И всем сторонним наблюдателям кажется - зачем теперь проводить какие то митинги, не понимая что эти самые события все это и обеспечивают...

Либо команда давно уже не работает по скраму, не видела и не читала скрам гайд, роли просто формальны, больше озабочены и делании вещей правильно, нежели о делании правильных вещей...

Возможных кейсов и стечения сценариев много...

Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum.

Halliluya!

🙏😇

При всём уважении к авторам фрейморка, в этом абзаце я всегда видел столько же маркетинга и брендинга сколько и здравого смысла. Например, спринт нельзя именовать итерацией. Тут мне видится аналогия с религией и церковью. С позиции последней если человек не ходил в течение месяца по воскресеньям в специальные помещения, то "он больше не scrum". В то же время простой человек, делающий добро может оказаться "больше scrum" чем те кто ходят по воскресеньям куда стоило бы. В общем я в данном вопросе солидарен с Pavel по всем пунктам. У самого опыт ухода от стандартов scrum не большой, но в одной команде мы заменили единое ретро в конце спринта множеством коротких (минут 30) ретро по запросу. И да, я знаю что тем самым мы рисковали целостностью ведения событий в рамках спринта. Но в нашем контексте тогда слепое следование написанному в гайде было очередным impediment, которое мы устранили (необходимость ждать до 3 недель, чтобы внедрить изменение).

При всём уважении к авторам фрейморка, в этом абзаце я всегда видел столько же маркетинга и брендинга сколько и здравого смысла. Например, спринт нельзя именовать итерацией. Тут мне видится аналогия с религией и церковью. С позиции последней если человек не ходил в течение месяца по воскресеньям в специальные помещения, то "он больше не scrum". В то же время простой человек, делающий добро может оказаться "больше scrum" чем те кто ходят по воскресеньям куда стоило бы. В общем я в данном вопросе солидарен с Pavel по всем пунктам. У самого опыт ухода от стандартов scrum не большой, но в одной команде мы заменили единое ретро в конце спринта множеством коротких (минут 30) ретро по запросу. И да, я знаю что тем самым мы рисковали целостностью ведения событий в рамках спринта. Но в нашем контексте тогда слепое следование написанному в гайде было очередным impediment, которое мы устранили (необходимость ждать до 3 недель, чтобы внедрить изменение).

Я встречал очень умных внедренцев, которые еще не успев внедрить начинали сразу менять фреймворк. Обоснование классическое "мы особые, нам это не подходит". Павел не зря упомянул сухари. Прежде чем менять надо попользоваться пол года - год без изменений основ. Если не было пользования без изменений, значит не боло и понимания. А если не было понимания то и изменения к лучшему не пошли.

Пользовались 2 года, для ясности

При всём уважении к авторам фрейморка, в этом абзаце я всегда видел столько же маркетинга и брендинга сколько и здравого смысла. Например, спринт нельзя именовать итерацией. Тут мне видится аналогия с религией и церковью. С позиции последней если человек не ходил в течение месяца по воскресеньям в специальные помещения, то "он больше не scrum". В то же время простой человек, делающий добро может оказаться "больше scrum" чем те кто ходят по воскресеньям куда стоило бы. В общем я в данном вопросе солидарен с Pavel по всем пунктам. У самого опыт ухода от стандартов scrum не большой, но в одной команде мы заменили единое ретро в конце спринта множеством коротких (минут 30) ретро по запросу. И да, я знаю что тем самым мы рисковали целостностью ведения событий в рамках спринта. Но в нашем контексте тогда слепое следование написанному в гайде было очередным impediment, которое мы устранили (необходимость ждать до 3 недель, чтобы внедрить изменение).

Скрам не запрещает улучшения раньше окончания итерации. Там как раз все основано на 3х китах, 2 из которах возможность к инспекции и адаптации. И то что Вы сделали, разбив свою ретро на более мелкии и частые тоже хорошо.

Сам Скрам когда-то в 80х-90х создавался именно чтобы уменьшить количество мало продуктивных и непродуктивных совещаний в том числе.

Плюс много было взято из Kaizen, как непрерывное улучшение...

При всём уважении к авторам фрейморка, в этом абзаце я всегда видел столько же маркетинга и брендинга сколько и здравого смысла. Например, спринт нельзя именовать итерацией. Тут мне видится аналогия с религией и церковью. С позиции последней если человек не ходил в течение месяца по воскресеньям в специальные помещения, то "он больше не scrum". В то же время простой человек, делающий добро может оказаться "больше scrum" чем те кто ходят по воскресеньям куда стоило бы. В общем я в данном вопросе солидарен с Pavel по всем пунктам. У самого опыт ухода от стандартов scrum не большой, но в одной команде мы заменили единое ретро в конце спринта множеством коротких (минут 30) ретро по запросу. И да, я знаю что тем самым мы рисковали целостностью ведения событий в рамках спринта. Но в нашем контексте тогда слепое следование написанному в гайде было очередным impediment, которое мы устранили (необходимость ждать до 3 недель, чтобы внедрить изменение).

Так что все ОК 👍

Я как раз из тех кто добивается осмысленности всего происходящего. И если человек, понимающий смысл предоставляет мне на ретро доказательство бесполезности или вредности какого-либо явления, пусть даже фундаментального, я скорее прислушаюсь к этому мнению чем буду кидаться камнями и говорить что мол раз ты против значит ты недостаточно понимаешь, иди прочти скрам гайд 3 раза и agile манифест 10 раз

Я встречал очень умных внедренцев, которые еще не успев внедрить начинали сразу менять фреймворк. Обоснование классическое "мы особые, нам это не подходит". Павел не зря упомянул сухари. Прежде чем менять надо попользоваться пол года - год без изменений основ. Если не было пользования без изменений, значит не боло и понимания. А если не было понимания то и изменения к лучшему не пошли.

+

Я как раз из тех кто добивается осмысленности всего происходящего. И если человек, понимающий смысл предоставляет мне на ретро доказательство бесполезности или вредности какого-либо явления, пусть даже фундаментального, я скорее прислушаюсь к этому мнению чем буду кидаться камнями и говорить что мол раз ты против значит ты недостаточно понимаешь, иди прочти скрам гайд 3 раза и agile манифест 10 раз

У меня вопрос, а скрам мастер успевает подготовиться к коротким ретро ? Составить план, отрисовать флипчарты ?

У меня вопрос, а скрам мастер успевает подготовиться к коротким ретро ? Составить план, отрисовать флипчарты ?

Скрам-мастер в постоянной боевой готовности, но вот флипчартов у нас и на больших ретро не было. Если для Вас это критерий успешного ретро, то мы не успевали =) Наши ретро скорее напоминали дифдиагностику у доктора Хауса - доска, маркер и юмор - достаточный набор

Принятые решения заносились в истории и задачи, критичные брались в работу сразу же, если они способствовали достижению цели спринта, а не удаляли нас от неё.

Принятые решения заносились в истории и задачи, критичные брались в работу сразу же, если они способствовали достижению цели спринта, а не удаляли нас от неё.

👍

Вам нужно понимать, почему в Scrum guide описана последоватьльность Обзор->ретро-> Планирование

Вам нужно понимать, почему в Scrum guide описана последоватьльность Обзор->ретро-> Планирование

Так может просвятите?

Почему только так и никак иначе

Даже так. Почему по умолчанию выстроена такая цепочка - я прекрасно понимаю, просьба не описывать банальные истины вроде "пришли в точку Б, осмотрелись, сделали работу над ошибками, спланировали следующее действие, двинулись". Объясните пожалуйста почему нельзя вынести ретро в параллельный поток? Какой вред за этим следует?

https://www.youtube.com/watch?v=JoLHKSE8sfU

👍👍

Даже так. Почему по умолчанию выстроена такая цепочка - я прекрасно понимаю, просьба не описывать банальные истины вроде "пришли в точку Б, осмотрелись, сделали работу над ошибками, спланировали следующее действие, двинулись". Объясните пожалуйста почему нельзя вынести ретро в параллельный поток? Какой вред за этим следует?

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

У меня вопрос, а скрам мастер успевает подготовиться к коротким ретро ? Составить план, отрисовать флипчарты ?

флипчарты так то необязательно рисовать, если sm делает свою работу как надо план у него говорится по мере наблюдения за тем что в команде происходит на спринте.

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

Да. Причём тут 2 момента. Во-первых, к концу спринта обнаруживалось что контекст ушёл и сложно сформулировать проблему/улучшение. Я считаю что обсуждение должно быть с одной стороны остывшим, чтобы не наломать дров и не психовать по любому поводу. С другой стороны обсуждение должно быть ещё тёплым, ибо говорить о старом скучно. Второй момент. Изменения принимаемые на наших ретро часто прямо влияли на цель спринта (положительно). Отсрочка таких изменений можно было бы рассматривать как противоречие agile, а не следование культуре. Мы не принимали резко решение заменить таким образом классическое ретро. Все началось с собрания по проблеме, которое не умещалось в дейли таймбокс. Формат понравился команде. А когда за спринт бы проводили 3-4 таких встречи, то на ретро в конце спринта обнаруживалось что тем для разговора как бы и нет. В итоге ретро после спринта отменили. Но, повторюсь, это было только в одной команде, это было решение команды и оно было взвешено и опробировано. С удовольствием послушаю как можно было бы решить эти проблемы не нарушая строгость фрейморка.

Павел также затронул другой пример когда сам фреймворк (жёсткое следование гайду, а не основополагающей идеи) становится узким местом - есть команды, которые релизятся раза три за день! а не раз за три недели. И это полноценный разлив, сразу доступный пользователям. Проводить в этом случае ревью раз в неделю - может оказаться бессмысленной церемонией. Скрам задумывался как противоположность длинному производственному циклу, но рано или поздно заложенные во фреймворк скорости сами становятся низкими в актуальном контексте. Адаптироваться можно и не дожидаясь правок в гайде.

Павел также затронул другой пример когда сам фреймворк (жёсткое следование гайду, а не основополагающей идеи) становится узким местом - есть команды, которые релизятся раза три за день! а не раз за три недели. И это полноценный разлив, сразу доступный пользователям. Проводить в этом случае ревью раз в неделю - может оказаться бессмысленной церемонией. Скрам задумывался как противоположность длинному производственному циклу, но рано или поздно заложенные во фреймворк скорости сами становятся низкими в актуальном контексте. Адаптироваться можно и не дожидаясь правок в гайде.

тогда зачем Вам скрам?

Павел также затронул другой пример когда сам фреймворк (жёсткое следование гайду, а не основополагающей идеи) становится узким местом - есть команды, которые релизятся раза три за день! а не раз за три недели. И это полноценный разлив, сразу доступный пользователям. Проводить в этом случае ревью раз в неделю - может оказаться бессмысленной церемонией. Скрам задумывался как противоположность длинному производственному циклу, но рано или поздно заложенные во фреймворк скорости сами становятся низкими в актуальном контексте. Адаптироваться можно и не дожидаясь правок в гайде.

Ревью и релизы в скраме никак не связаны

Релизьте хоть каждый день. На спринт ревью не только инкремент можно показывать

Ревью и релизы в скраме никак не связаны

👍

Блин, так и знал что станут комментировать только то, что удобно =) вместо корневого вопроса по существу..

Блин, так и знал что станут комментировать только то, что удобно =) вместо корневого вопроса по существу..

Это жизнь))

тогда зачем Вам скрам?

Пример не из моего опыта, не могу комментировать. Однако как по мне это не является строго ни причиной использовать ни причиной не использовать скрам. Надо смотреть на картину целиком

Ревью и релизы в скраме никак не связаны

Связь не в Скраме, связь через общность примеров указывающих на скрам как bottle neck

Повторю тогда корневую проблему. Во время спринта возникают значимые явления, достойные обсуждения на ретро. Спринт длится 3 недели. Или для яркости давайте возьмём 4. Проблема - приходится ждать конца спринта чтобы провести ретро, ибо так говорит гайд. Два компонента проблемы: за 3-4 недели уходит контекст и то, что легко обсуждать было "по месту" становится сложно обсуждать спустя 3-4 недели. Второй компонент - изменения принятые к действию на ретро вступят в силу в лучшем случае на следующем спринте. Наше решение - уход от одного большого ретро после ревью к ряду асинхронных ретро по запросу. С сохранением тайминга, подготовки, реальности решений и прочих атрибутов. Нарушили только "правило" проводить ретро после ревью и до планирования.

Повторю тогда корневую проблему. Во время спринта возникают значимые явления, достойные обсуждения на ретро. Спринт длится 3 недели. Или для яркости давайте возьмём 4. Проблема - приходится ждать конца спринта чтобы провести ретро, ибо так говорит гайд. Два компонента проблемы: за 3-4 недели уходит контекст и то, что легко обсуждать было "по месту" становится сложно обсуждать спустя 3-4 недели. Второй компонент - изменения принятые к действию на ретро вступят в силу в лучшем случае на следующем спринте. Наше решение - уход от одного большого ретро после ревью к ряду асинхронных ретро по запросу. С сохранением тайминга, подготовки, реальности решений и прочих атрибутов. Нарушили только "правило" проводить ретро после ревью и до планирования.

1) скрам не мешает изменить спринты на недельные 2) скрам не запрещает добавлять в спринт дополнительные встречи (например, если вам нужно ситуативное ретро)

Связь не в Скраме, связь через общность примеров указывающих на скрам как bottle neck

если вы читали хреновые примеры, это не вина скрама все крутые команды, с которыми я работал, релизили несколько раз в день, работая по скраму одно другому никак не противоречит

вообще кто сказал что инкремент продукта - это не продукт который уже задеплоен на прод

очень частое недопонимание когда думают что посреди спринта релизить нельзя :D

1) скрам не мешает изменить спринты на недельные 2) скрам не запрещает добавлять в спринт дополнительные встречи (например, если вам нужно ситуативное ретро)

1) скрам не мешает, жизнь мешает. Или по Вашему команды с длинной спринтов 3-4 убогие? Есть объективные причины такой длины. Оставайтесь пожалуйста в рамках условий задачи. 2) именно так, поэтому мы добавили эти встречи, нашли их эффективными, взяли за постоянную практику и это привело бесполезности ретро по результатам спринта. Вы настаиваете что в этом случае надо было их проводить? Если да, то зачем?

Я ни на чём не настаиваю, живите как хотите)

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

На мой взгляд, это уже за гранью разумного) ребята нашли способ как быстро, прям сейчас, чинить проблемы, и они убогие, потому что ретро не нужно?)

На мой взгляд, это уже за гранью разумного) ребята нашли способ как быстро, прям сейчас, чинить проблемы, и они убогие, потому что ретро не нужно?)

Если у парней, работает и их так устраивает, то аусть работают. Нужно понимать, что Scrum guide ничего не запрещает,, он рекомендует. На мой скромный взгляд, нужно проводить одну общую ретро в конце спринта, что бы посмортреть глобально каждую проведенную ретро в течении спринта, а где у нас дисфункция, и почему у нас много мелких ретро ?

Связь не в Скраме, связь через общность примеров указывающих на скрам как bottle neck

меня не покидает ощущение, что вы себе сами придумали где там bottle neck. У вас внутри фреймворка есть миллион опций подтюнить под свою реальность, оставаясь в рамках скрама. У вас значиные события происходят - делайте ретры под них. Общая ретроспектива в конце спринта тоже не просто так, её основная цель не конкретные проблемы решить, а системно посмотреть на то, что происходит, запланировать и проинспектировать эксперименты процессные. Ситуативные ретроспективы на такой вопрос не отвечают, но полезны во многом другом

Строго говоря ретроспектива вообще не прерогатива скрама