Нужен ли в скрам тимлид? В одной из команд запустили эксперим | AGILE Practitioner

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

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

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

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

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

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

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

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

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

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