​​Личное мнение важнее командных ценностей?

Доводилось сталкиваться на встречах, что команда никак не может прийти к консенсусу по техническому или организационному вопросу. Продолжать "давить друг на друга" - путь в никуда. Каждый при своём мнении.

Я использую два способа выхода из спорной ситуации:

⭐️ на уровне команды возвращаюсь к командным договорённостям, если это не помогает, то джокером выступает призыв к принципам и ценностям Agile и Скрам. Не случалось ситуаций, чтобы участники наплевательски относились к ценностям, какого бы уровня ни достиг спор.

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

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

#скрам #agile #конфликты

​​Личный тайм-менеджмент #непропроекты

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

Недавно вернулся из отпуска и начал этот "славный" путь в почте и рабочих чатах. С чатами проще: смотришь, где тебя тегнули лично и отвечаешь на эти запросы, если не сделал это в отпуске. Остальная информация, как с пропущенными новостями, непременно дойдёт вновь от команды. Но что делать с 300+ письмами?

Я давно выработал для себя правило приоритизации писем:

👉 Делегируемые - те письма, задачи в которых можно поставить на исполнение подчинённым, коллегам, командам или даже руководителям.
❓ Уточнения - лучше через ответное письмо, т.к. в письме мы склонны лучше структурировать подачу информации, чем голосом на встрече
💬 Информационные письма (спам, рассылки, FYI и т.д.), которые можно просто скипнуть прочитанными
⚠️ "Срочные и неважные" письма - запланировать в календаре встречи на ближайшую неделю
❗️ "Важные и несрочные" письма - метка в задачи в outlook/gmail и.т.д
‼️ "Срочные и важные" письма - уделить оставшиеся половину первого рабочего дня этим вопросам

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

P.s. хотя есть подход проще, который практиковал мой напарник - "пометь прочитанным все письма. кому очень надо вернутся к тебе"😜 немножко цинично и игнорно, но тоже возможный путь и гораздо быстрее моего😏😉

Вспоминается флотская притча на этот счёт. Молодой лейтенант пришёл к адмиралу с просьбой. Адмирал ответил, что рассмотрит её. Через неделю лейтенант возвращается, т.к. просьба не решена, а адмирал говорит: "пиши просьбу на листке А4 и клади на вон в ту стопку бумаг". Прошла ещё неделя, лейтенант возвращается, а адмирал ему говорит: "поищи свой листок и переложи наверх стопки". Через месяц лейтенант в расстройстве пришёл к адмиралу, а тот ему: "ты бумагу писал? - Писал. Ты в пачку бумаг клал? - Клал. Наверх пачки перекладывал? - Перекладывал. Ну вот теперь можно и выполнить твою просьбу"😎

А у вас есть лайфхаки работы с пропущенной информацией после отпуска?

​​2 правила MVP

Руководитель проекта вертится в треугольнике сроков, скоупа и денег. Это отлично работает, если не подразумевается запуск нового продукта, который не предусматривает MVP. "Но всё меняется, когда приходят они"🤪

15 лет назад я впервые попробовал грузинскую кухню в ресторане. Это сейчас с лёгкостью эксперта я смогу объяснить разницу между аджапсандали и оджахури или тонкости того, чем мегрельское харчо отличается от супа харчо. Тогда же в меню - это были дивно звучащие слова на русском языке🤯

Но вот, что главное: я не помню, что я заказал, но помню, что мне - это понравилось!🤩

Эта мысль натолкнула на 1️⃣-е правило: когда запускается MVP не столь критично важно, чтобы в функционале программы сразу становилась доступна killer-фича. Необходимо добиться того, чтобы хоть и ограниченный функционал, который мы предлагаем пользователю работал максимально качественно.

Пусть он не узнает всех "блюд", но захочет вернуться снова и снова, и снова.

Проблема в том, что попадаются вредные посетители (читай Заказчики), а клиент - всегда прав. И в "идеальном блюде" MVP такой человек найдёт к чему придраться. Отсюда 2️⃣-е правило: саботёры известны заранее на этапе реализации проекта. Необходимо выстроить с ними грамотный диалог, заручиться коалицией вышестоящего спонсора, либо снизить влияние такого заказчика к минимуму на момент запуска MVP.

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

Вот такая кухня😏

#projectmanagement

Прыгни выше головы! - стать лучше - возможно!

Пройденный руководительский тренинг помимо прочей пользы побудил прочесть книгу Маршалла Голдсмита "Прыгни выше головы! 20 привычек, от которых нужно отказаться, чтобы покорить вершину успеха".

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

📌 Некий добрый человек сделал отличную СХЕМУ - выжимку из книги, но для полного понимания всё же рекомендую ознакомиться с книгой.

P.s. Провёл среди коллег опрос по своим привычкам и открыл для себя инсайты, о которых не догадывался. Выявленные проблемы - путь к улучшениям, чего и вам искренне советую!

❗️ P.p.s Если кому-то нужна книга в pdf или в аудио-формате пишите в личку.

Вакансия для любознательного лидера или желающего им стать😉

Привет! Возможно вы, ваши друзья или знакомые в поисках роли скрам-мастера!

У нас есть все условия, чтобы реализовать такие амбиции.

⚡️ 2 команды для работы (в стадиях "Storming" & "Norming" по Такману)
🕋 2 разных, но интересных продукта
✌️ 2 agile - эксперта для обмена опытом
3️⃣ года компания практикует Скрам в соответствии со Scrum Guide
🤝 всесторонняя поддержка Agile со стороны руководства
🏄‍♂️ для нас agile - это mindset, а уж потом различные практики и инструменты
💫 мы руководствуемся слоганом: "Эта работа сделает тебя счастливей!"

🤔 Больше о вакансии можно узнать кликнув ТУТЪ😊

💬 Для связи писать nastya_astr

🙏 Благодарен за репост в лички заинтересованным и в профильные каналы.

В продолжение поста про статистику хорошая статья: http://ronlichty.blogspot.com/2021/04/measuring-productivity.html

Краткое summary какие метрики использовать для команд:

🔸 Метрика итогов (созданный функционал в конце спринта, который особо ценен для пользователей)
🔸 Метрика счастья (команды и клиентов, использующих продукт)
🔸 Метрика cycle time и возможности её оптимизации
🔸 Метрика вовлечения (если говорить про Скрам) участников
🔸 Метрика психологической безопасности участников команды

​​Убрать нельзя оставить

На отдыхе я люблю готовить из местных продуктов и первое что делаю, когда арендую жильё по airbnb - это покупка в ближайшем магазине острого ножа. Хозяева обычно пекутся об исправном душе, чистом постельном белье и доступном wi-fi, но точно не о заточенных ножах🔪🔪🔪
Конечно можно приготовить блюдо и с тупым инструментом🤷, но сколько на это уйдёт времени, потерянных нервов и каков получится результат одному Будде известно⛩

Довольно частая ситуация, когда в команде запускается скрам без скрам-мастера или в лучшем случае кто-то из devteam берёт на себя эту роль. Общаясь со скрам-мастерами часто проскальзывает информация, что руководство в компаниях не понимают роли скрам-мастера, хотят считать его метрики, эффективность. Да и потом позиция руководства раз команда уже и так работает по скраму, то зачем он нужен?🧐

Дьявол в деталях… команда в скрам находится в операционном потоке разработки и время взглянуть и порефлексировать возникает только на ретро. Скрам - мастер может подмечать и подсвечивать то, что в пылу работы незаметно для команды, он обязан интересоваться best-practice с точки зрения практик и инструментов, делиться этими знаниями с командой и выступать медиатором всевозможных ситуаций от командных конфликтов до чествования командных побед👂👀 🤲

Если есть желание быть на острие эффективной разработки по скраму - выделенный специалист в этой роли крайне необходимый элемент системы.

Без "хорошего ножа" будет: устали очень тяжело второй год не получается в скрам ничего🤪

Каналы в телеграмм, которые считаю интересными и полезными:

Продукты:
https://news.1rj.ru/str/pmdaily - интересные подходы к управлению высоконагруженными проектами

https://news.1rj.ru/str/dindex - посты, как выстрелы! для продактов самое - то!

https://news.1rj.ru/str/product_proverbs - истории из жизни продакта и как это находит отражение в работе

https://news.1rj.ru/str/pm_god - хорошие советы по продуктовому и проектному управлению

https://news.1rj.ru/str/productionpain - к сожалению не частая, но интересная инфа от продакта

Agile:
https://news.1rj.ru/str/inteamwetrust_rus - что команда, что организация начинается с доверия внутри коллектива. Алексей Пикулев один из лучших может рассказать про эту тему

https://news.1rj.ru/str/tw0_percent - интересные инсайты про Agile - тематику

https://news.1rj.ru/str/no_shame_facilitation - всё, что нужно мастеровитому фасилитатору знают Саша, Женя и Оксана

https://news.1rj.ru/str/condensedAgility - выдержки лучших обсуждений на тему agile из самого большого agile-сообщества в ТГ

https://news.1rj.ru/str/agile_coach_notes - полезные заметки от Agile Coach

https://news.1rj.ru/str/agilethinking - интересности из Agile

https://news.1rj.ru/str/myscrum - канал практикующего Скрам-мастера

https://news.1rj.ru/str/scrummasters - интересности про Agile и Скрам

Другие:
https://news.1rj.ru/str/antxt - Иван пишет очень необычные истории и погружает в вопросы аналитики различных вещей. Для ценителей вопросов аналитики всё очень интересно и второго подобного канала в ТГ точно нет! Советую!

https://news.1rj.ru/str/junior_pm - Артём погружает участников канала в особенности проектного управления и рассказывает про свой путь в этой области

https://news.1rj.ru/str/itSMFRussia - тема ITIL и сервис-менеджмента мне по прежнему близка и интересна, поэтому можно узнать, что происходит в ITSM среде

https://news.1rj.ru/str/pimenov_spoken - канал Алексея Пименова. Лидер Канбан-метода в России, жаль, что не часто пишет в своём канале

Удаление фич в продукте

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

Возможно, ЦЕННОСТЬ будет состоять в том, чтобы не добавить функциональность, а УБРАТЬ! Чтобы не тащить за собой эту "телегу камней", а сделать продукт более мобильным, современным, лёгким и интуитивно понятным для пользователей.

Когда стоит рассмотреть удаление уже имеющегося функционала в продукте:

🗑 Полное несоответствие стратегическому плану развития компании

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

🗑 Чересчур новаторский функционал (не пользуется спросом, непонятный)

🗑 Совсем нишевый функционал (не пользуется спросом)

🗑 Функционал больше не решает проблемы клиента

🗑 Излишнее резервирование - есть другой способ, который решает проблему клиента более лучшим образом

🗑 Несовместимость - попытка "скопировать" функционал с другого успешного продукта, но абсолютно не подходящий для нашего ("натянуть сову на глобус", да 😏)

🗑Чрезмерные затраты на поддержку имеющегося функционала как со стороны команды разработки, так и со стороны хелпдеска

Удаляли функционал из продукта за невостребованностью?

Про жизненный цикл Технологических революций и какое место в них может занимать Биткоин...https://stratechery.com/2021/the-death-and-birth-of-technological-revolutions/

​​Distributed 2021

19 октября состоялась конфа от MIRO - Distributed 2021. Она показалась мне самой "живой" из мероприятий за полгода. Возможно такой эффект сложился потому что участники были со всего мира и профессиональных областей, а не ограничены одной предметной областью или страной. Удивительно, но порой чат конференции было читать не менее интересно, чем слушать спикеров…столько интересных идей и вдохновения поступало от MIROusers.

Среди спикеров очень запомнились двое:


👦🏻 Лэнс Вайлер - использует Миро для сторителлинга, в том числе с помощью AI и Deepfake технологий.

👩🏻 Прия Паркер - фасилитатор с 20 летним стажем и автор бестселлера, которая использует Миро в работе со своей командой и группами, с которыми работает.
Записи выступлений с ними должны появится в канале Миро в ютуб.

Самые запомнившиеся тезисы с мероприятия:

🔥 "Money - could be a good facilitator in future"
🔥 "Design remote leadership. It won't happen at once, but that's the future. It matters. Remote work - style is a part of human life more than ever"
🔥 "Miro storyboarding moves speed of creativity"
🔥 "Facilitator is a storyteller and good storyteller can hold any audience"
🔥 "Show don't tell"
🔥 "Five "С" for remote leader in 2021: Creativity, Collaboration, Communication, Critical Thinking and Compassion"

+ пара книг прочитать на свою виртуальную полку:
📚 Digital Body Language: How to Build Trust and Connection, No Matter the Distance
📚 The Art of Gathering: How We Meet and Why It Matters

Инновации или архаизмы

В компании вопрос: стоит ли в 2021 году водить нового человека по офису "за ручку", чтобы сформировать сопричастность или создать такие условия, чтобы новичок почувствовал себя частью команды в независимости от местоположения?🤔

И вообще может ли удалёнка быть в чём-то лучше, чем очные встречи🤷‍♂️?

Может, если команды хотят преимуществ в поиске инноваций. Для этого может использоваться техника - асинхронный виртуальный мозговой штурм.

❗️Существует вероятность провала, если команда пытается напрямую адаптировать брэйншторм в офисе к формату в Teams, Zoom, whatever. Как только участники, а особенно руководители, видят, что remote-встреча плохо подходит для брэйншторма - принимается решение, что нужно вернуться в офис🙅‍♀️. Это отказ от новых практик в пользу привычек. Одно из когнитивных предубеждений - функциональная закреплённость (functional fixedness, см. ссылку)

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

Асинхронный виртуальный мозговой штурм может предложить следующие этапы:

✍️ Генерация идей в онлайн-инструменте (например, MIRO, Mural, и т.п.) не собираясь на общую встречу, а каждый в своём рабочем режиме, но к установленной дате
📝 "Очистка" идей: группировка идей фасилитатором
💬 "Оценка" идей: анонимные комментарии к идеям
💥 Наброс дополнительных идей после комментариев
💬 Повторить п.2
💥 Повторить п.3
🤝 Встреча для обсуждения идей, которые пойдут в реализацию

Финальный пункт - может пройти как виртуально, так и в офисе. При этом важно избежать выполнения пунктов 1-6 в офисе, чтобы не отрывать всю команду от текущей деятельности + избежать критики участников от более статусных коллег при генерации идей.

Исследования показали, что офисные группы чувствуют себя лучше в отношении сотрудничества, но чувство обманчиво, т.к. ВИРТУАЛЬНЫЙ МОЗГОВОЙ ШТУРМ ПРИВЁЛ К ПОЯВЛЕНИЮ БОЛЬШЕГО КОЛИЧЕСТВА ИДЕЙ.

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

Стоит ли начинать адаптироваться под реалии 2021 выбирать каждому. Но если выбирать работать по-новому, то, возможно, и on-boarding новых сотрудников стоит пересмотреть.

P.s. Больше про когнитивные искажения можно посмотреть по ссылке. Все описания кликабельные.

Доступна картинка с когнитивными искажениями на русском.

канбан, Канбан, КАН-БА-ААН! 🥷

Вспомнились фразы, которые встречал при подходе к имплементации командами канбан-метода:
😤 "У нас Agile - мы работаем по канбан"
🤔 "Зачем нам обучение по Канбан? У нас уже есть канбан-доска"
😯 "Канбан же работает только на производстве, в ИТ - нужен Скрам"
😡 "Какие такие лимиты WIP? Мы не можем себя ограничивать - у нас дэдлайны - сколько надо столько и возьмём в работу!"

Нещадно экспериментируем с гибкими практиками🏗 Стартовали новый метод в компании для нашей команды по Master Data. Пока другие пробуют революционный Scrum, новой команде потребовался оптимальный способ, чтобы увязать существующий процесс с будущим. Поскольку текущий подход в работе - сервис—ориентированный остановились на Канбан-методе⚖️

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

Промежуточный итог:
☑️ Провели обучение по использованию канбан-метода
☑️ Сформировали командные договорённости
☑️ Определили каденции, митинги, подробные статусы, лимиты и классы обслуживания

Дальше больше!💪

P.s. Во многом первое понимание канбан-метода упрощает канбан-гайд, который вышел в этом году. Советую к прочтению тем, кто хочет на пальцах понять что-то такое канбан-метод.

PMI выпустил рейтинг 50-ти весомых проектов года.

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

Я выделил для себя самые интригующие:

🏠🧑‍💻 Большой эксперимент по работе из дома. Переосмысление того, что значит "быть на работе". Будущее работы подвижно. И быть agile теперь не только про майндсет, но и про воркстайл. Появляются такие должности как "директор по удалёнке". Создание профилей сотрудников для определения оптимального соотношения удалённой и офисной работы

🇸🇦🚇 Метро Эр-Рияд в Саудовской Аравии как часть реализации плана страны "Видение до 2030 года", который призывает к снижению зависимости страны от нефти и созданию более устойчивой экономики в будущем

🇩🇰🏝⚡️ Энергетический остров для всей энергосистемы Дании. Обеспечение только за счёт ветра и никакой атомной энергии - возможно ли?

🇲🇻🏖🏗 Плавучий город на Мальдивах - как ответ на риск того, что острова поглотят последствия изменения климата. Пока действительно "проект", но, если он будет воплощён, это откроет проторённую дорогу для многих прибрежных поселений, которым грозит исчезновение, если не принимать меры уже сейчас

🇰🇪🔎🦏 Перепись дикой природы в Кении. "Вы способны управлять только тем, что знаете". Масштабность проекта: 100 человек, исследование животных на 360 000 квадратных километров. Фотоловушки, лёгкие самолёты, вертолёты, 4x4 авто. Т.к. в небе могло находиться одновременно до 15 самолётов требовалось наличие "центра управления воздушными полётами из кустов"😂, чтобы пилоты не пересекались и животные не учитывались дважды.

🚀🪐🛖 Вояджер - отель с искусственной гравитацией в космосе. Этим всё сказано

🥩🥑🍓 Безотходность - эволюция систем управления запасами. Автоматически снижать ценник на продукты питания к истечению срока годности. Выкинуть товар или получить за него соизмеримую прибыль и сэкономить затраты на утилизацию решит бизнес

🇨🇳 🛣🚆 Мост через реку Янцзы, который позволит преодолеть расстояние между Шанхаем и Ляньюнган почти в 4 раза быстрее (с 11 часов сократили до 3-х). Самое ценное у нас время. Сотни сэкономленных часов в год на поездках в офис продемонстрировал мне собственный опыт . А если помножить это на миллионы людей, которые будут экономить время, то получается колоссальный вклад в свободное время для людей. А это спорт, знания, время с семьёй, хобби и т.д.

🇦🇪👀 🕋 Музей будущего в Дубай. Удивили окна в виде арабской письменности и экологически-выверенные проектные решения.

P.s. Оказанное влияние проектов "Токийского туалета" с "Playstation 5" и "Clubhouse" - это бо-о-ольшой вопрос, но они тоже в рейтинге😉

Все проекты можно поглядеть тут

Что такое хорошо и что такое плохо?

На спринт ревью команда с гордостью демонстрирует результат работы, а стейкхолдер говорит, что хотел вообще не это! Кто виноват? Команда неверно разобрала задачу в части definition of Done? Product Owner недостаточно описал критерии приёмки в User story? Или сам заказчик "переобулся" и теперь хочет другое решение? А нужно ли искать виноватого?

Первая эмоция защититься или найти крайнего. Увы, но такие ситуации происходят...😕

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

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

Суть здесь не в том, у кого знания шире, а у кого эго больше. Не надо перед людьми "в теме" кичиться своим авторитетным мнением. Это выглядит как каратист, который в кимоно спустился в магазин и встал в стойку. Для покупателей вы, конечно, будете значимым, но для людей в теме - смешным. Всегда найдутся те, кто разбирается в вопросе лучше. Поэтому на новом месте гораздо выгоднее слушать первые пару недель, чем делать едкие замечания вне зависимости от статуса сотрудника.

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

Когда стейкхолдеры говорят, что хотели получить решение не так, как прописано в критериях приёмки feel free & use ценность Agile - "готовность к изменениям"🤝

P.s. про ситуацию с Боингами и почему т.к. произошло можно послушать по ССЫЛКЕ, кому это интересно.

Нужен ли в скрам тимлид?

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

Почему появилась необходимость в такой роли? Команда работает по скрам гайду над продуктом последние пару лет, но специфика у бизнеса такова, что потребовалось в кратчайшие сроки воплотить мини-проект в рамках продукта. Срок - 1,5 месяца. Отдельные задачи ценности не дадут - необходимо завершить весь пул работ для успешности проекта.

И тут встал вопрос: команда привыкла двигаться итерациями и демонстрировать результат каждые 2 недели, но как поступать сейчас? Делать спринты короче? - но что тогда демонстрировать? Уходить в долгие 1,5 месяца работ? - но что, если технически код "пойдёт не в ту степь"?

В каскадной модели роль координатора мог бы занять менеджер проекта, но для команды - это избыточный сотрудник, а потребность в координации разработчиков есть. Изучив опыт других компаний, мы поняли, что тимлид/техлид не противоречит скраму. Зачастую тимлид существовал изначально - он трансформируется в скрам-мастера или PO со временем. Но у нас возникла обратная ситуация, нам потребовался координатор, т.к. команде не хватило самоорганизации. Да-да, это задача скрам-мастера повысить самоорганизацию и вовлечённость скажите вы, но когда от бизнеса стоит дедлайн 31 декабря 2021, нет времени на раскачку.

При этом почему эта роль - не тимлид?
▫️потому что есть Product Owner - общается с бизнесом
▫️потому что есть Скрам мастер - помогает команде со скрам-процессом
▫️потому что есть Функциональный руководитель - управляет ресурсами

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

При этом главных целей две:
🕚 добиться успешных результатов проекта в срок
🙅‍♂️ "не включить директивный стиль управления в команде и забрать ответственность за продукт на себя"

Кстати, это решение родилось в ходе Daily Scrum. Одно из свидетельств того, что не стоит откладывать важное для команды решение до ретроспективы.

P.s. Почитать больше на тему тим-/тех- лида в скрам-командах можно по ссылкам