Плохой, негодный PO, скормите его коучу :)

=))))

Как так получилось, что от одного зависит работа 50ти человек?

Про "скормите коучу" - я реально сталкивался с клиентами, которые PO сначала вот такой вот перегрузкой доводили до полностью непродуктивного состояния, а потом шли в поисках коуча, который научит ПО быть лучше :)

Как так получилось, что от одного зависит работа 50ти человек?

А и не должна.

Лесс, смотрю, все чаще упоминается..

Потому что в чате есть человек, который LeSS на практике использует :)

)

Так-то я могу на SAFe ссылаться :)

Но в SAFe как раз проблемы с единым бэклогом нет.

Круто. 2.1К участников..

В SAFe проблема с количеством строго предписанных практик есть.

С ролями

Мне safe нравиться то же..

Дофига с чем, на самом деле.

Всегда можно понадергать практик, для точечных изменей

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

Всегда можно понадергать практик, для точечных изменей

А зачем их из SAFe понадергивать, в нем вообще ничего оригинального нету.

Весь SAFe состоит из понадерганных практик.

Собрано в одном месте

Да, ссылаться удобно, все материалы доступны и хорошо описаны.

леффингвелл всегда хорошо умел в маркетинг и PR :)

Как так получилось, что от одного зависит работа 50ти человек?

никак, весь фокус в том что от меня никто не зависит =) я scrum master. И если возникают (а они возникают) зависимости от меня, то я в первую очередь прорабатываю как их убрать. Но это не мешает всем этим людям обращаться ко мне с вопросами

леффингвелл всегда хорошо умел в маркетинг и PR :)

+

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

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

Поздравляю, ты постиг дзен скрама :)

Непрерывное улучшение и поддержание уровня вовлеченночюсти непрерывно и работа...

Ы идеале команде и PO не нужен, кстати :)

Ы идеале команде и PO не нужен, кстати :)

соглашусь =)

Выдели такое наяву?

)

Непрерывное улучшение и поддержание уровня вовлеченночюсти непрерывно и работа...

да, но это может и сама команда.. в лучшем случае

Выдели такое наяву?

эм... так это как раз очень частое явление - нет PO

Fundamental assumption of LeSS - команды это понимают, Sm и PO к этому стремятся

Выдели такое наяву?

Я даже видел команду, у которой scrum стал ораничением :)

Похоже и правда секта))

В общем разделение труда эффективно. так и так кто-то будет лидировать по предложениям и продфуктовым и процессным. Такое перетекание ролей я видел.. Но прям супер слаженную ровную команду почти видел.

А стремиться к целе - само собой..

в сериале Silicon Valley команда без PO и SM, да и вообще без скрама, работает очень хорошо

естественно идеально было-бы, как вы говорите.

в сериале Silicon Valley команда без PO и SM, да и вообще без скрама, работает очень хорошо

Я тоже люблю фантастику :)

у меня есть несколько реальных примеров команд, которым это всё тоже нафиг не надо =)

Но в SV есть и PO, и SM :)

у jetBrains без скрама получается неплохо

Есть жизнь и за пределами скрама :)

несомненно!

Там даже больше

Хорошего вечера..

Привет

И тебе

Ух, понаписали. Будет время попробую ответить.

В общем и целом я понял о чем написал Павел. Скрам-гайд гласит, что "Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team." Если мы говорим о LeSS, то в идеале они одинаковые. Но в жизни команды все равно не равноценны. Разный опыт, возраст и пр. Поскольку они выбирают PBI в Спринт сами, они конечно пытаются оптимизироваться и взять что-то более удобное знакомое и пр. Я это тоже в своих командах наблюдаю. Как с этим борются в LeSS (я стараюсь применять практики из LeSS гайда https://www.amazon.com/Large-Scale-Scrum-More-Craig-Larman/dp/0321985710). PBR проводится в два этапа. На первом представители команд поверхностно рассматривают PBI, оценивают его и разбивают на более мелкие сторри при необходимости. Сразу решается как будет делаться вторая часть PBR. Тут два варианта. Первый это командный PBR, второй это Многокомандный PBR. Второй вариант предпочтительнее. Участвуют ВСЕ челны ВСЕХ команд. Далее еще момент - решение о том какая клманда возьмет PBI в Спринт оттягивается до последнего момента и принимается на Spinnt planing (в Нексус все наоборот - как можно раньше). В результате все команды понимают каждую задачу (как проводить такой PBR это отдельная тема). И каждая команда может взять ее в работу. И еще момент. Идея о нескольких владельцах продукта св LeSS реализуется в виде анлитиков с хорошим уровнемполномочий и взаимодействия с Владельцем Продукта. Это по сути "Прокси". но они взаимодействует между собой и находятся в командах. Я как-то приводил цитату и описанной книги. Владелец максимально сотредотачивается на приоритезации и ценности эпиков для бизнеса, а команды на кларификации, актуализации. По сути продакт говорит ЧТО, а команда решает, именно решает КАК. Это еще к более ранеей дискуссии с Pavel , что делать если Продакт уезжает в отпуск. А вот как раз все живет и работает в этом случае. Но в команде должны быть полномочия принимать решения.

Сергей, в итоге получаем то же, что высказал Павел - нужны хорошие аналитики с расширенными полномочиями.. по сути те же PO

Мне в этом всём с позиции теории не нравятся иерархические структуры в масштабированных схемах.. но как без них пока ума не приложу =)

Мне в этом всём с позиции теории не нравятся иерархические структуры в масштабированных схемах.. но как без них пока ума не приложу =)

кажется, в спотифае отличный подход

Есть подробное описание как они работают с беклогом?

извините, я все равно не понимаю как можно работать из 1го беклога без каких то разграничений такому кол-ву команд. Да и вообще, зачем нужен такой беклог что его нельзя разделить по направлениям/проектам/etc? Как то совсем не гибко. Разве что ради кроссзадач, но проблема организации, которая с ним накладывается того не стоит.

Сергей, в итоге получаем то же, что высказал Павел - нужны хорошие аналитики с расширенными полномочиями.. по сути те же PO

В общих чертах, да. Но они должны быть в командах и должны иметь возможность принимать решения вместе с командой. Даже в отстуствие PO. Тогда единый бэклог продолжает работать. Так в общем то LeSS и рекомендует. Но на масштабах больше 8 команд и это уже не работает и тогда в LeSS Huge появляются Area Product Owner управляющий областью требованй, которому придается от 4-х до 8-ми команд. В пределах Area (команды и Продакт) это LeSS. Вместе все это LeSS Huge. Примерно так.

Мне в этом всём с позиции теории не нравятся иерархические структуры в масштабированных схемах.. но как без них пока ума не приложу =)

Ну тут минимум иерархии добавляется. Только Area Product Owner. Да и они разбиты по областям, которые по идее не пересекаются. А PО скорее общим видением занимается на стратегическом уровне.

))

В общих чертах, да. Но они должны быть в командах и должны иметь возможность принимать решения вместе с командой. Даже в отстуствие PO. Тогда единый бэклог продолжает работать. Так в общем то LeSS и рекомендует. Но на масштабах больше 8 команд и это уже не работает и тогда в LeSS Huge появляются Area Product Owner управляющий областью требованй, которому придается от 4-х до 8-ми команд. В пределах Area (команды и Продакт) это LeSS. Вместе все это LeSS Huge. Примерно так.

по сути такой же масштаб для Nexus, ART в SAFe, Squad в Spotify)

Всем привет! Коллеги, кто нибудь встречал тренинги, мастер-классы, описания кейсов по внедрению "кружков качества"?

Мне в этом всём с позиции теории не нравятся иерархические структуры в масштабированных схемах.. но как без них пока ума не приложу =)

Мне тоже, но линейного бэклога не бывает (это отдельная тема от того, что в scaled среде единого бэклога не бывает)

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

В SAFe, к слову, иерархия сложная, но зависит от масштаба на каждом участке Epic - инициатива уровня предприятия, бэклогом из эпиков управляет комитет. У каждого эпика есть Epic Owner - который управляет бэклогом эпика На уровень программы из бэклога эпика приходят фичи, которыми управляет Product Management Фичи разбиваются на стори - которыми управляет Product Owner

Бэклогом предприятия владеет комитет (потому что, блин, так исторически сложилось, что в монархию в крупных предприятиях давно уже заменили олигархией:)) - это уровень портфолио Бэклогом эпика управляет эпик овнер на уровне портфолио Бэклогом из фич (которые могут быть из разных эпиков) управляет продакт менеджер - это уровень программы (ART/PI) А бэклогом сторей каждая scrum team управляет сама. Напомню, что Product Owner часть scrum team :)

Но это не значит, что Product Owners report to Product Manager, а Product Manager reports to Epic Owner

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

На планнинге в среду команда создала бэклог спринта на 20 sp. Бэклог содержит 2 айтема по 5 sp, каждый и 10 айтемов по 1 sp каждый.

Команда за первый день закончила 1 айтем на 5 sp и держит в in progress еще 4 sp в данный момент

Вопросы: При такой скорости, когда команда завершит спринт? Не кажется ли вам, что кто-то перезаложился с оценками :)

Ответ: - в конце спринта завершит =) - эм.. по месту смотреть, конечно, надо, но sp - оценка сложности, а не времени.. выполнить 5 sp за день, а 1 sp за неделю - ну бывает

Именно :)

Клиент, походу, впервые столкнулся с transparency - борда команды видна на огромном телевизоре в офисе, бигбоссы ходят поломничеством спрашивать "дорогой коуч, что за херня и ПОЧЕМУ ТЫ ПОЗВОЛИЛ!" :)

В прошлом спринте команда захотела попробовать не оценивать баги, кстати. Я хмыкнул, но раз команда хочет, почему бы нет, благо спринты недельные.

Команда запланировала штук 6 багов, потом добавила 14 sp сторей (ну а чо, velocity же 20, но надо reflect)

мы на прошлой работе тоже не оценивали баги в sp.. точнее оценивали только старые добрые, техдолговые

Почему-то закончить смогла 1 сторю (но на 5 sp) но не полностю (потому что передать в review за 20 минут до demo - не считается) :)

В этом спринте к практике оценки багов решили вернуться