Не очень понял, что значит "команда приедеет"?

Опечатка, "поредеет" должно быть)

изменение размера команды никак не должно мешать быть автономной.

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

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

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

Спасибо, хорошее замечание.

Я тоже разработчик еще. Все подходы, если их ПРАВИЛЬНО готовить и использовать, принесут свою пользу. Я против самого микроменеджмента, поэтому процессы нужно выстраивать со здравым смыслом и вместе со своей командой. Не просто взять аджайл, лишь потому, что это модно.

А почему бы просто не писать daily/weekly reports с описанием что сделано и дать людям работать? Написание такого отчёта занимает минут 10-15, и не нужно сидеть и слушать что делали коллеги, ожидая когда до тебя дойдет очередь. В Хуавей у нас эти аджайл-митинги занимали по часу, где-то.

Дейлики должны проходить за 15-20 минут в идеале, так и у нас. Дейлики хорошо работают, если команда полностью продуктовая, релизы каждые 2 недели, много межкомандного взаимодействия. И вся команда работает над 1-2 фичами вместе, и идет постоянное обсуждение/решение вопросов, которые зависят друг от друга. В таком случае, дейлики более эффективны, чтобы обсудить что и как идет, проблемы, блокеры.

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

До возвращения в Россию в 2017-м я и не знал что такое дейлики и что такое аджайл, ни в одной из компаний где я работал такого не практиковалось. Правда, это был японский корпоративный мир, там лишнего стараются не делать.

Канбан пришел из Японии. В то время он был популярен, во многих компаниях был. Сейчас тоже развивается.

看板 (канбан) означает “вывеска”, “табличка”. Сама эта методология, насколько я помню, была изобретена в корпорации Тойота как часть lean (бережливого) процесса производства.

Но потом из канбан сделали карго-культ не понимая, для чего он и зачем.

Да, это к вопросу о том, что нужно использовать инструменты со здравым смыслом, не потому что это просто модно.

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

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

Мм мм... По разному бывает. Особенно с решением блокеров. Тут как правило у начальства лоб толще, нижняя челюсть увесистее и круг связей шире.