Почему Скрам молчит о роли тим-лида (а я - нет)

Неужели Скрам забыл о роли тим-лида?

Перепрочёл Scrum Guide…

Всё еще никаких упоминаний. Ни словечка по этой теме.

По поиску слова “лид” выдаёт два результата:

 

“Скрам-мастер - servant-leader (дословно “служащий ЛИДЕР”) для Скрам команды”.

и

Scrum-мастер ... коучит и направляет организацию, ЛИДИРУЕТ процесс внедрения Скрама”.

 

Единственная причина, по которой Scrum Guide не упоминает об этой широко распространённой роли - это потому, что эта роль нерелевантна для Скрама.

Думаю, что так и есть...

Но всё же эта роль может стать очень релевантной, когда речь зайдёт о внедрении Скрама. Потому что, скорее всего, в иерархии эта роль есть, и она - часть системы, с которой вы работаете. Поэтому, она не может быть просто проигнорирована.

Сегодня на одном из моих тренингов для Скрам-мастеров (на удивление наполненном тим-лидами), меня окружила стайка искателей правды. Они хотят знать, как вписать эту роль в Скрам организации.

Я спросил, чем именно они занимаются, и в большинстве случаев услышал что-то вроде:

“Я отвечаю за общую техническую экспертизу и развитие групп определенных специалистов”.

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

 

И тут на меня снизошло прозрение (лучше позже, чем никогда)

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

Я вспомнил одного парня, который формально не был лидом, скорее он был одним из “старичков” среди разработчиков (не в буквальном смысле, а тем, кто сделал первый комит), но который вёл себя довольно напыщенно и любил поруководить другими.

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

Дело не в должностях и ролях.

Дело в зрелости личности и стиле руководства. И у каждого он уникален.

Лидерская зрелость

Недавно мне повезло познакомиться с Питом Беренсом и его работами по agile-лидерству. Пит использует следующую диаграмму (не уверен точно, кто исконный автор), которая наглядно показывает путь развития лидера. От “эксперта” (я делаю всё сам лучше всех) до "достигатора" (достигает результата посредством влияния на других) и “катализатора”  (раскрывает потенциал других в принятии решений и управлении).

Технический “эксперт”: "Я тут накодил фреймворк на днях. Интегрируйте это".

Технический “достигатор”: "Нам нужен фреймворк. Думаю, что лучше всего это поручить Максу и Сане".

Технический “катализатор”: "Давайте соберемся и подумаем вместе, как мы можем вывести наш фреймворк на новый уровень. У меня уже есть мнение на этот счёт, но я бы хотел узнать ваше мнение, перед тем как мы примем решение".

Кто-угодно может “командовать” (но не каждый должен)

Итого: так как угроза нападения “любителей покомандовать” на самоорганизацию команды может произойти в любой момент и с любой неожиданной стороны, нам (коучам команд) нужно быть начеку и внимательно отслеживать “командирский синдром” среди членов команды. А также обучать членов команды адекватному стилю лидерства, наставлять их и коучить.

Так что меня с недавнего момента перестали интересовать титулы: Team Lead, Tech Lead, Team Coordinator, Delivery Manager, Engineering Manager и т.д.

Должности второстепенны. Главное – это личности. Это всегда будут какие-то конкретные люди, которые либо помогут вам внедрить Scrum, либо станут главной угрозой на его пути. Так что забудьте про чины и звания и начинайте работать с людьми.


Write a comment

Comments: 0