Оо а кто предлагает?

Знаешь, даже теряюсь, с кого начать перечислять. Такое ощущение, что все, кто занимается agile scaling :)

Про правильную мотивацию никто почему-то не упомянул

"покормить маленькими кусочками слона(успеха)" это как раз про неё, например.

Знаешь, даже теряюсь, с кого начать перечислять. Такое ощущение, что все, кто занимается agile scaling :)

Все предлагаю LeSS?

Очень многие, по моим наблюдениям.

Значит надо safe для начала?

Гм.

Это довольно любопытный вывод, но я не уверен, что верный :)

Я тоже не уверен)

SAFe все-таки для больших контор.

Это не вывод, поосто вопрос

Никакого гипноза)

Скажем так, если у вас продукт, требующий совместной работы 5-6 scrum команд - наверное SAFe будет как минимум проще LeSS развернуть без ошибок.

Но ключевое - "совместной".

И один продукт наверное?

Тут уже был не так давно разговор на эту тему :)

Или один продукт, или очень тесно интегрированная связка продуктов, или платформа для продуктов.

SAFe точно НЕ стоит применять только потому, что у вас уже 5-6 команд.

Это да

Скажем так, если у вас продукт, требующий совместной работы 5-6 scrum команд - наверное SAFe будет как минимум проще LeSS развернуть без ошибок.

Не совсем понял мысль из-за отсутствия запятой. SAF легче LESS?

Не совсем понял мысль из-за отсутствия запятой. SAF легче LESS?

В плане внедрения - да.

SAFe более толерантен к плохому пониманию того, как работает scrum и зачем нужен agile на уровне управления портфелем.

+ SAFe предлагает дорогой, но работающий фреймворк для развертывания самого SAFe и элементов.

Дорогой, потому что прям заставляет нанимать коучей

Спс

Ну и, на всякий случай, повторюсь: SAFe хорошо работает только там, где уже есть 5-6 скрам-команд, работающих совместно над одним продуктом. Если есть 5-6 команд, работающих над разными продуктами, или если есть 5-6 команд, которые уже отлично научились работать без зависимостей - SAFe не добавит ценности.

Не помешает, наверное, просто не нанесет никакого добра и не причинит никакой пользы.

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

Я видел как команды меняют коллег. Ответственная за деливери в Скраме - команда. В Канбане - SDM. В остальных мутациях - как фишка ляжет

Я видел как команды меняют коллег. Ответственная за деливери в Скраме - команда. В Канбане - SDM. В остальных мутациях - как фишка ляжет

Методом проб и ошибок выявлено, что никакую задачу нельзя нормально сделать, если у неё нет оунера. «Коллектив» это несуществующее лицо без отвественности. По-другому работать не получается. Может у вас там люди волшебные, но я работал с разными и всегда выходит только так.

Методом проб и ошибок выявлено, что никакую задачу нельзя нормально сделать, если у неё нет оунера. «Коллектив» это несуществующее лицо без отвественности. По-другому работать не получается. Может у вас там люди волшебные, но я работал с разными и всегда выходит только так.

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

Денис, все зависит от того, как выглядит задача.

Если это задача вида "добавить поле Х в базу У" то да, остро необходим владелец

Если это стори... разговор немного другой :)

Опять же, как вы к команде относитесь, так она и будет работать :)

Если подчеркивать, что вы не верите, что они могут самоорагизоваться и решить, как доставлять задачи - они и не смогут. Самосбывающееся пророчество и confirmation bias

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

В данный момент в Германии, в SoundCloud, и это ещё считается на фона других компания с высоким уровнем инженерной культуры. В этом есть доля правды, хотя бы потому что в недрах компании разработали Prometheus. Может сам продукт у нас и не ахти, но мы умеем делать сложные высоконагруженные системы (тысячи серверов, 70 тысяч запросов в секунду и так далее), есть люди из Гугла, Амазона и так далее. Так вот даже у нас - не пнёшь, не полетит.

Денис, а какого уровня пинок?

На отдельных разработчиков?

На всех. Мы правда стараемся друг друга пинать. У нас есть понятие овнера таски. Он пинает исполнителей. Оунера пинает начальник.

При этом оунером может быть кто угодно, даже джуниор.

А как таска выглядит?

Зависит, как правило на неё есть бриф с описанием kpi, дизайном и описанием майлстоунов. Майлстоуны конечно часто приходится перепланировать, часто ещё нужно взаимодействие с внешними командами, архитектурны вопросы решаются написанием RFC, потом нужно дизайнить эксперименты и отдавать на анализ. В общем есть туча административной работы, которая не делается «сама собой» (да и мало кому интересна, на самом деле) и нужен человек чтобы следил. Но мы же продвинутые, мы эту работу не сваливаем на менеджера, а шарим между собой.

Product Owner, backlog ownership

В спринте есть standup для самоконтроля.

Product Owner, backlog ownership

Продакт оунер есть, конечно, от него мы и получаем формулировку задачи и kpi, но это 10% задачи, но нужен ещё технический менеджмент (которого в стандартном скраме не прописано)

Ну...

технический менеджмент на уровне команды - это acceptance criteria и task breakdown командой на планинге и груминге.

Но это плохо работает на уровне нескольких команд. Потому для нескольких команд начинаются надкомандные структуры, как system team в nexus или system architect в SAFe

Я не очень помню, как в LeSS dependency management реализован.

Помимо рекомендации не иметь зависимостей, разумеется :)

технический менеджмент на уровне команды - это acceptance criteria и task breakdown командой на планинге и груминге.

Это очень simplistic view для каких-то очень простых проектов :) У нас аж две сессии груминга за спринт, не считая кучи подготовительных шагов в виде написания RFC и встреч. Вот мы ща переделываем систему индексации 1 миллиарда документов. Вы как себе груминг видите, сели мы такие и придумали систему за раз? :)

Не за раз, наверное. Но в целом да.

Сели и придумали. Вопрос в том, как вы управляете этим "сели и придумали" :)

Сели и придумали. Вопрос в том, как вы управляете этим "сели и придумали" :)

Вот говорю как, множество встреч, множество документов, написание планов. Всё итеративно. И за ходом всего этого следит оунер топика.

Методом проб и ошибок выявлено, что никакую задачу нельзя нормально сделать, если у неё нет оунера. «Коллектив» это несуществующее лицо без отвественности. По-другому работать не получается. Может у вас там люди волшебные, но я работал с разными и всегда выходит только так.

Не соглашусь. Тут все от подхода зависит.

Вот говорю как, множество встреч, множество документов, написание планов. Всё итеративно. И за ходом всего этого следит оунер топика.

План по плану и планом подгоняет :) Мне кажется это немного другое, не Agile ... Я когда еще не знал что такое Scrum - старался с людьми работать по контуру управления, делегируя все кроме целеполагания. И развивал их так, чтобы они и сами планировали и сами контролировали. Оставлял только такой метод контроля как "Доклад в случае исключительных ситуаций". Но отвечал за все я! Ответственность не делегируется. В Agile все очень похоже. Я пришел к нему через много шрамов и набитых шишек. И я знаю, что это работает. Сейчас картину дам.

Так в классическом управлении. Я старался развить сотрудников, чтобы они 2,3 и 4 этапы делали самостоятельно. Я лишь ставил цели.

А так я вижу спринт в Scrum'e

За результат отвечает Владелец Продукта.

Из Скрам-гайда - "Владелец Продукта несет ответственность за достижение максимальной ценности продукта как результата работы, которую выполняет Команда Разработки."

А так я вижу спринт в Scrum'e

и нижняя часть повторяется раз в день 😉

А это что за книга? Эссеншиал канбан конденст? Не встречал ее в переводе.

http://kanbanguide.ru

и нижняя часть повторяется раз в день 😉

Ага. Та самая петля обратной связи в виде Daily Scrum, это зона ответственности команды.

Инспекция и адаптация, мать ее ...

Инспекция и адаптация, мать ее ...

👍

http://kanbanguide.ru

Мерси

Всем привет! Решил провести небольшой "user research" - в прошлом году у меня был достаточно богатый и продолжительный опыт трудоустройства на роль Agile Coach за рубежом. Всего побывал на финальных собеседованиях в 7 компаниях в 3 странах, увидел насколько кардинально по разному там видят данную роль. Собственно вопрос: была бы вам интересна статья с описанием моего опыта, выводов и советов? Спасибо! P.S. Вроде не оффтоп, но если да - удалю :)

Всем привет! Решил провести небольшой "user research" - в прошлом году у меня был достаточно богатый и продолжительный опыт трудоустройства на роль Agile Coach за рубежом. Всего побывал на финальных собеседованиях в 7 компаниях в 3 странах, увидел насколько кардинально по разному там видят данную роль. Собственно вопрос: была бы вам интересна статья с описанием моего опыта, выводов и советов? Спасибо! P.S. Вроде не оффтоп, но если да - удалю :)

конечно

Всем привет! Решил провести небольшой "user research" - в прошлом году у меня был достаточно богатый и продолжительный опыт трудоустройства на роль Agile Coach за рубежом. Всего побывал на финальных собеседованиях в 7 компаниях в 3 странах, увидел насколько кардинально по разному там видят данную роль. Собственно вопрос: была бы вам интересна статья с описанием моего опыта, выводов и советов? Спасибо! P.S. Вроде не оффтоп, но если да - удалю :)

Канеш

Всем привет! Решил провести небольшой "user research" - в прошлом году у меня был достаточно богатый и продолжительный опыт трудоустройства на роль Agile Coach за рубежом. Всего побывал на финальных собеседованиях в 7 компаниях в 3 странах, увидел насколько кардинально по разному там видят данную роль. Собственно вопрос: была бы вам интересна статья с описанием моего опыта, выводов и советов? Спасибо! P.S. Вроде не оффтоп, но если да - удалю :)

+1

Всем привет! Решил провести небольшой "user research" - в прошлом году у меня был достаточно богатый и продолжительный опыт трудоустройства на роль Agile Coach за рубежом. Всего побывал на финальных собеседованиях в 7 компаниях в 3 странах, увидел насколько кардинально по разному там видят данную роль. Собственно вопрос: была бы вам интересна статья с описанием моего опыта, выводов и советов? Спасибо! P.S. Вроде не оффтоп, но если да - удалю :)

А можно еще раз ссылочку?

Интересно.

Всем привет! Решил провести небольшой "user research" - в прошлом году у меня был достаточно богатый и продолжительный опыт трудоустройства на роль Agile Coach за рубежом. Всего побывал на финальных собеседованиях в 7 компаниях в 3 странах, увидел насколько кардинально по разному там видят данную роль. Собственно вопрос: была бы вам интересна статья с описанием моего опыта, выводов и советов? Спасибо! P.S. Вроде не оффтоп, но если да - удалю :)

+

Отлично, всем спасибо! В таком случае, постараюсь в течение следующих 1,5 недель опубликовать на какой-нибудь из площадок (Хабр, Medium, etc) и поделюсь ссылкой здесь.

Отлично, всем спасибо! В таком случае, постараюсь в течение следующих 1,5 недель опубликовать на какой-нибудь из площадок (Хабр, Medium, etc) и поделюсь ссылкой здесь.

Уже ждём)))

Я вот с интересной штукой столкнулся. Она меня в тупик поставила. Есть несколько команд. Есть несколько Скрам-мастеров. Два из них выделенные и занимаются только этим. Скрам-гайд говорит, что Скрам-мастер должен работать и с организацией и с Владельцем Продукта. Но вот два мастера кинулись помогать Организации и Владельцу Продукта. И как-то разошлись во многих вещах. В понимании Скрама, роли Скрам-мастера. Они вроде как равны. У них по несколько команд. Начались проблемы с этим. Как им вообще взаимодействовать между собой? Прочитал массу всего. Про LESS, про Нексус ... ничего по этой теме. Кто-нибудь сталкивался?

Неплохая тема для разбора...

А может расскажете в чем отличие их позиций?

Звучит так забавно. Люди которые должны помогать находить общий язык не могут найти общий язык.

А может расскажете в чем отличие их позиций?

Сейчас попробую.