7 примеров, как менеджеры в IT вредят эффективной работе команд

Писатель, редактор и основатель сервиса Serious Scrum Виллем-Ян Эйлинг разобрал несколько ситуаций, когда менеджеры и руководители IT-компаний вредят работе команд, в блоге Medium.

«Я сочувствую всем командам, которые делают все возможное, чтобы их Scrum работал, но в итоге сталкиваются с препятствиями со стороны руководства. Я видел так много команд, которые понимают концепции Scrum и очень мотивированы, значительно улучшают свою продуктивность в первые несколько месяцев, — делится Эйлинг. — И тогда их улучшения прекращаются».

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

Эйлинг отметил, что Scrum-команды, как правило, отлично справляются с самоуправлением. Но они во многом ограничены организацией. Вот несколько примеров.

1. Информирование команд о том, какую работу они должны делать и к какому сроку

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

Вот почему решение о том, что делать, как это сделать и к какому сроку, должно принадлежать Scrum-команде. А владелец продукта (как источник работы для команды) — это единственный человек, который должен определять порядок бэклога продукта. Но это не мешает менеджерам, не входящим в Scrum-команду, обходить владельца продукта и просить команду вместо поставленной задачи делать что-то другое. Это не имеет никакого смысла, тем не менее часто случается. По мнению Эйлинга, такое управление игнорирует саму концепцию Scrum.

2. Требование выполнять запланированную работу, а не добиваться целей продукта

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

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

3. Сохранение индивидуальных оценок, противоречащих целям команды

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

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

4. Похвала командам, которые не успевают выполнять работу

Scrum-команды работают в сложной среде, которая требует сотрудничества и творчества. Члены команды должны совместными усилиями сосредоточиться на поставленных целях. Работа в стабильном темпе — необходимый фактор для этого.

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

5. Ожидание, что команды будут работать над несколькими направлениями одновременно

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

6. Промежуточный результат как показатель успеха

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

Скрам-команды должны проверить, приближают ли их результаты работы к цели — продукту, в котором нуждаются пользователи, клиенты. Менеджеры, которые продолжают рассматривать любые промежуточные результаты как меру успеха, подталкивают команды в неправильном направлении, далеком от принципов Scrum.

7. Игнорирование организационных препятствий

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

Некоторые культурные аспекты внутри организации могут не соответствовать философии Scrum (например, несовместимость с принципами гибкого управления). Если они мешают прогрессу команды, эти препятствия должны быть устранены.

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

Совет: дорабатывайте идеи менеджеров и лидеров компаний

Большую часть времени Scrum-мастера и Agile-коучи сосредоточены только на командах, проводят бесчисленное количество тренингов и коучинговой поддержки. Но нет смысла пытаться убедить людей, которые уже являются активными верующими. Они либо уже в вашем лагере, либо наоборот: настолько разочарованы практической реализацией методов Scrum, что стали еще более скептичными.

Если вы — Scrum-мастер или Agile-коуч, то в таких случаях надо сосредоточиться на менеджерах и лидерах компании. Проблема может быть именно с ними, а препятствием для прогресса может быть их ложное представление об Agile. Тренируйте менеджеров и расширяйте применение Scrum, чтобы включить их в процесс.