Тим лидер или скрам мастер?

Раньше были лидеры команды (тим лидеры), а с приходом Scrum появились Scrum master-а. В чем их отличие? И кто лучше?

В статье я буду ссылаться на свой 10-ти летний опыт работы (в одной компании, но в разных проектах, с разной направленностью и спецификой).

В задачи стандартного тим лидера входило:

• Получать задачи от менеджера проекта
• Прояснять приоритеты, если они не очевидны
• Разбивать задачи на подзадачи при необходимости
• Распределять задачи между участниками команды
• Осуществлять регулярный контроль выполнения
• Проверять задачи на завершенность (если тим лидер одновременно выполнял и роль технического лидера, то еще всевозможные ревью, в противном случае эти ревью он назначал внутри команды)
• Подсвечивать риски, предупреждать менеджера о проблемах
• Давать обратную связь о сотрудниках

Теперь посмотрим на обязанности скрам мастера, согласно Scrum Guideline:

• Отвечает за то, чтобы Скрам был понят всеми участниками и работал. Обеспечивает выполнение этого правила,наблюдая за тем, чтобы все участники команды придерживались теории, практик и правил Скрама.
• Является слугой-лидером для Скрам Команды. Помогает создать обстановку, оптимальную для того, чтобы команда работала с наибольшей эффективностью. Помогает устранять препятствия в работе команды на пути достижения результата.
• Помогает людям, не входящим в состав Скрам Команды понять, какие взаимодействия со Скрам Командой̆ являются полезными, а какие — нет. Помогает каждому изменить эти взаимодействия для увеличения ценности, созданной командой.
• Коучит Команду Разработки в самоорганизации и кросс-функциональности.
• Помогает Команде Разработки создавать продукты высокой̆ ценности.
• Помогает сотрудникам компании и заинтересованным лицам понять и запустить Скрам и принципы эмпирической разработки.
• Выступает инициатором изменений, которые повышают продуктивность Скрам Команды.
• Работает совместно с другими Скрам Мастерами для повышения эффективности использования Скрама в организации.

• Находит методы эффективного управления Беклогом Продукта.
• Помогает Скрам Команде создавать лаконичные и понятные элементы Беклога Продукта.
• Убеждается в том, что Владелец Продукта знает, как упорядочить Беклог Продукта, чтобы максимизировать Ценность.
• Понимает и практикует гибкие методы разработки и управления.
• Выступает фасилитатором мероприятий Скрама.

Какие встречаются проблемы:

Команда профессионалов

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

Самоорганизованные команды

Люди не привыкли брать на себя ответственность. Задачи им дают, результат за ними проверяют. Они оказываются не готовы к такой ответственности — самим распределять себе задачи, ставить цели, планировать и отвечать за результат. В одной из команд, когда мы только начинали внедрять скрам, в одном из первых спринтов, задача по написанию и прогону тестов была разделена между тремя разработчиками. В итоге мы получили сломанные тесты на главном бранче. От разработчиков я услышала следующее: «Мы не виноваты, нас просто никто не организовал и не проверил». Самоорганизация работает сложно и на более высоких уровнях, последний пример: мы сейчас организуем различные Community of Practice, в том числе для систем менеджеров (самых умных и ответственных людей в проекте, отвечающих за качество и развитие продукта), дали им бэклог задач, объяснили ожидания и решили посмотреть, как они сами организуются. Как вы думаете, какой результат? Они не организовались, каждый брал задачу из бэклога. Потому что каждый думал — а почему я должен брать ответственность на себя и организовывать всех?

Кросс-функциональные команды

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

Скрам мастер — коуч

Очень мало людей, готовых понимать идеологию и коучить других людей (не приказывать им, что делать, а именно медленно и методично развивать в них правильное видение процесса, целей и т.д..). Объяснять им основные правила самоорганизованных команд, растить профессионализм команды. Т.е. не фокусироваться на распределении задач, а сделать так, чтобы команды могли сами ставить себе задачи. Тут очень часто встречаю вопрос самих тим лидеров: зачем вообще это надо? Программисты пришли программировать, почему они должны себе еще ставить цели, если это задача тим лидеров? Т.е., понимаете, скрам — это совсем другая идеология, другой подход к работе команды. Так просто взять и поменять название у роли не получится.

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