Привет. Кто-нибудь внедрял less? С какими сложностями сталкивались? Хочется сделать

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

Вопрос, как на общем проекте с одним бэклогом на 2 команды внедрять что-то похоже на less, чтобы иметь общий контекст?

Зачем вам лесс на 2 команды? Он про множество, с которым не справляется обычный скрам

"Обычный" скрам - он на одну команду. Если команд больше, всё равно требуется что-то в дополнение к нему. Почему бы и не LeSS?

«Обычный скрам на одну команду» — чего? Вы где такое прочитали? В скрам Гайде, который регламентирует скрам, нет ни слова о том, что в скраме всего 1 команда. Там есть понятие «единица скрама» — это «скрам команда», но это в обобщенном значении, а не буквально, потому что дальше раскрывается мысль по количеству и ролям. Если сдавали экзамен на psm, то должны знать, что там есть в том числе такие вопросы. Вообще, скрам не регламентирует количество команд, но есть нюансы: На 1 небольшую команду делать скрам не имеет смысла, потому что команда будет зря тратить время на процессуальные вещи: 4 обязательных ивента, которые должны проводиться с постоянной регулярностью и по четкому расписанию. +1 опциональный ивент (пбр), 3 артефакта, роли и все это между собой должно быть взаимосвязано. Пренебрегли в одном месте, ощутили в другом последствия. Зачем все эти строгие правила, когда команда всего 1? Как правило в небольшой команде люди и сами могут договориться, это будет быстрее и безболезненно. Вы сами должны понимать это и стремиться к эффективности. Строить процесс ради процесса — такое себе занятие. А когда команд много и сложный продукт, то это уже другой разговор. Лесс так же не регламентирует количество команд, вы сами, как скрам мастер должны понимать в какой момент ПО и команды перестают справляться. То есть, вы начинаете понимать, что текущий процесс нуждается в масштабировании. В этот самый момент имеет смысл открыть лесс и посмотреть, как он может помочь. Эмпирически такое понимание приходит когда команд от 8-9 шт, но это эмпирически, то есть, у кого-то те же 8-9 команд могут прекрасно справляться по классическому скраму. Поэтому надо смотреть на ситуацию и деплоить процесс в тот момент, когда вы понимаете, что иначе нельзя

Привет, в гайде идёт речь именно про одну команду, а не про несколько, там нет практик на совместную работу команд. Он изначально так и задумывался. Отвечу вашими словами, если вы готовились к PSM II , то читали материалы, где говорилось о практиках совместной работы и том же нексус. Да и там есть конкретное упоминание про размер команды. В лесс есть рекомендации по числу команд, если внимательно читать лесс воркс.

Оке, вас не затруднит заскринить эти пункты?

Так а в чем проблема? Бэклог проекта один. У каждой команды свой бэклог спринта(в трелло например это 3 доски делать придется и каждая команда роаботает в своей, но на общем планировании работают с бэклогом проекта, в кайтене на одном экране все доски). Ведуться параллельные дейли с наблюдателем из другой команды, командные ректроспективы, + 1 общая. Делайте всё по фреймворку. А если коллега не хочет такой подход, то получается, что он не гибкий, не хочет пробовать ничего нового, не хочет улучшать гибкость всей компании (если сказать ему, что планируется расширение до 8 команд, спросить какие он видит альтернативы для LeSS, и нужно уже сейчас пробовать на будущее продумывать и прокатывать какую-то систему, может он задумается).

Как вы быстро не вдаваясь в детали определили что коллега не "гибкий", это новый подход? Не хочешь как я - не agile mindset? 😅

Я бы сказал, что элементы less 1. Надо как-то синхронизировать контекст в команд: общее планирование, общий продуктовый pbr 2. Нет общего вектора развития и понимания: Хочется иметь общие DoR для того, чтобы можно было бы зайти в каждую задачу и увидеть про что она 3. Общее ретро не делаем по причинам не готовности всех к этому, плюс большое количество встреч

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

Так почему второй товарищч не хочет синхронизироваться? Это же странно выглядит. Где собака зарылась?

Проьлема в том, что 1. Мы не самодостаточны. У нас нет фронта 2. Вторая команда берет в работу все подряд, а не цельные задачи и может может иметь 3-4 цели спринта. Это приводит к тому, что она пересекается по задачам с нами и возникают блокеры 3. Стейкхолдеры не понимают, что происходит, когда используется подход с 3-4 целями спринта, техническими задачами

На самом деле чтобы подойти к less нужна подготовка каждого члена команды, отдельные митинги посвященные less (фактически подготовка к сообществам практик), просьба прочесть литературу (подобрать и дать ссылки на кейсы других компаний). Потом в заранее со всеми согласованный спринт запустить работу по less, с учетом раздельных и общих ретроспектив.

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

Я честно пытался его раскручивать. Тут несколько вариантов. Возможно я слишком сильно давил на него и меня он перестал воспринимать. Давление могло возникнуть изза предыдущих срывов сроков в течение двух кварталов или даже больше. Со стороны коллеги есть обвинение стейкхолдеров. Поначалу я поддерживал и убеждал, что все хорошо. Но потом, после того, как плавными шагами не получилось. А стейкхолдеры запросили сроки завтра. Пришлось включить жесткость и ставить общие планирования и пбр. Это скорее всего и привело к подрыву.

Думаю больше дело в стейкхолдерах. В первую очередь они должны поддерживать agile идеологию, иначе система не будет иметь смысла, и любое их решение развалит систему. В скраме невозможно ставить сроки сверху. Нужно исходить из возможностей команды и команда определяет сроки исходя из задач. Нужно задаться вопросом на организационном уровне, а что нужно сделать, чтобы было готово завтра. Например нанять людей на еще одну команду, да, будет меньше прибыль. Нанять нехватающего фронта. Планировать что 1sp - это не 8 часов идеального програмиста, а 16 часов идеального программиста (приведет к выгоранию при использовании более 1 раза и увольнению разработчиков). Ощущение что в головном уровне управления проблема. Снизу фреймворк можно только временно запустить, до отрицательного решения руководителя. Лучше чтобы стейкхолдеры, для работы на высоком уровне так же использовали скрам. Я подобную инициативу продвигал и оно сразу выявляет, кто из стейкхолдеров некомпетентен в работе и боится потерять влияние или власть над процессами, отрицая, и слепо настаивая, что использование скрама работает только в IT (хотя этот подход работает на всех уровнях и улучшает работу всей компании, а не только IT). Из-за сопротивления руководителей как правило и прекращаются попытки применить любую agile методологию.

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

Обе команды работают над одним продуктом компании или это разные внешние заказы?

Один продукт

А почему Less должен решить проблему? В чем вы ее видите, кстати?

.

Это не проблема, а недостаток. Нет фронта это значит что вы решили что что-то должно быть, а поскольку его нет вы это называете проблемой, Но это недостаток. Недостаток решается одним способом. Как правило очень простым. Проблема требует более глубокого погружения.

Затруднит, мне откровенно лень)

Мы пробовали less, в общем что-то используем из него. Но вообще метод слабенькия. Коррдинация работы разных команд - это не просто координация ивентов. Это координация ground work. Nexus гораздо продвинутей со своей Integraion Team. Или Coordination Team в SAFe

интересно, что в less не так? Какие проблемы с координацией возникли? Просто не сталкивался с проблемами, поэтому интересуюсь. Кстати Nexus продуман до 9 команд, LeSS можно расширятся условно бесконечно, хоть до 1000 и более человек

Есть подозрение, что less показался слабеньким, а остальные методы ок, из-за отсутствия полноценных фиче команд

Компонентные команды конечно сразу крест на всем этом ставят. Но даже если команды полноценно фича-команды, беклог то общий. И приемка будет всего инкремента всех команд (программы). То есть с точки зрения внешнего наблюдателя, это все единые фичи

Вот вам пример. Представьте вы решили сделать возможно купить товар на сайте. Она состоит из двух частей - корзины и страницы чекаута. Допустим так вышло, что над этим работает 2 скрам команды. Вы конечно можете попилить строю вертикально. Но только требования вот так легко пилятся только во снах скрам мастера. Вам все равно нужно продумать архитектурно как оно внутри все работает, какие сущности используются и какие там интерфейсы, что бы 2 команды смогли работать независимо. А потом, когда работа завершена, нужно придумать план end-to-end тестирования этой штукенции. Иначе две отдельно разработанные и протестированные фичи просто не будут работать вместе. less ивенты имеют смысл, однако все же я бы добавил несколько ролей - архитектора и програм-менеджера, что бы координировать работу команд.

А зачем отдельный человек который является узким горлышком и несёт за собой ответственность, плодя бас фактор, безответственность и зависимость остальных? Почему команды сами не могут договориться о взаимных зависимостях? Почему не могут решить что вон тот человек в этот раз проведёт проектирование/команды вместе это сделают и потом пошарят знания?

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

Почему нужен этот человек? Команды коллаборируют через код и инженер-капитан, вместе уточняют и планируют в общем виде + сообщества + путешественники + Тайгер тим и куча инструментов координации. Ими обмазаться можно, используй нехочу

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

через код взаимодействия не происходит, команды же обычно вокруг каких-то capabilities строят.

А один ПО и общий беклог не помогают формировать общее понимание?

Вот мы так пытались работать. Помаялись, собрались и забили на итерации. Теперь работаем в четыре потока в своем процессе с использованием канбан-метода. Все счастливы.

Что значит человек, который знает что твориться в командах? Наверно вы имеете кто знает что творится в проекте? Так это product owner. Если речь об архитектуре, всегда есть один разработчик, который лучше всех в этом понимает, и правильная схема, когда он организует сообщество практик по архитектуре. Он помогает освоить разработчикам, то что знает он, чтобы не только он, а любой мог грамотно выстраивать архитектуру. Обычно это значит, что он не предлагает готовое решение, а предлагает разработать команде/командам, чтобы повысить квалификацию всей компании. И тогда в какой-то момент уже не будет от одного человека зависить архитектура. Разбиение на команды конечно уменьшит прямую коммуникацию, которая происходит сама собой, но если предположить, что у вас должно работать не 2 а 8 команд, то вариантов и нет. Поэтому в LeSS вводится понятие наблюдателя - который присутствует на каждом дейли другой команды, и сообщает важную информацию, есть общее планирование и общая ретроспектива помимо командных. В конце концов межкомандное ревью кода дает хороший результат для избежания проблем и с архитектурой в том числе.

Я же говорю, в каких-то случаешь это работает, в каких-то лучше уже смотреть на SAFe. Вы же не станете утверждать, что Less (как и другой метод) работает всегда? Есть условия при которых какой-то метод работает или нет. У Less это условно - shared code ownership. Если ваша компания переросла это, и у вас там десятки микросервисов, то про общее понимание можно забить. Добавьте к этому удаленку (в офисе общую картинку гораздо проще удержать) и вуаля

Работает или не работает любой фреймворк зависит от людей в компании, а не от продукта.

А как же «с людьми все ок, проблемы в системе?»

Бытие определяет сознание

+

В одном из вводных роликов по SAFe, есть отличные слова: "У нас нет плохих людей, мы их сами собеседовали и сами нанимали. Следовательно, проблема в системе, которая не даёт нам добиться того, чего хотим. Вот именно систему мы и будем менять." Чистая психология, наука продавать.

Так и что думаете насчёт «кто виноват»?)

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

а тут курица и яйцо, кажется надо и взгляды менять и систему

Ну, типа того :) Только продать изменение системы проще, чем изменение людей.

в том-то и самый смак — менять систему с помощью людей так, чтоб они потом сами и менялись тоже

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

Это хорошо подходит для Тойота, но не подходит для обычной небольшой компании в нашей стране до 100 человек.

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

Термин "подходит" - это то что надо, как для большой, так и для маленькой компании! Даже в небольшой компании можно использовать какие то компоненты из тех, что используют в больших компаниях. Главное, чтобы подходило для людей, находящихся в определенных ситуациях

Я думал, что эту историю закончите тем, что в « в итоге ребята обновляют своё резюме « )))

Почему не подходит? По вашему lean это только для производства?

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

некоторые конечно! но большинство остается.

Термин "подходит" про реальную ситуацию и про людей, обладающих определенными компетенциями, то есть это про чистую практику

@vemashov , что за производственная корпорация? Можно в личку, пожалуйста?))

сорямба, NDA :)

Подобные Лидерские программы есть также в Unilever , Mars, например :)

Спасибо!

В смысле, были?