КАК AGILE УБИВАЕТ МЕНЕДЖЕРОВ

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

Давным-давно в далекой-предалекой стране у каждого разработчика и у каждого тестировщика был менеджер. Многие хотели быть менеджерами. У них была власть и им платили лучше. Но только лучшие инженеры ставали менеджерами. Они ненавидели свою работу. Они хотели быть инженерами и зарабатывать больше, и не любили все задачи сопутствующие менеджемнту.  Но потом произошел Agile и ба-бах! менеджеры исчезли.

Давайте пофантазируем на тему “Что с ними случилось?” 

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

Больше Вам не нужен титул или подчиненные, чтобы быть лидером.

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

Что менеджеры потеряли с приходом Agile?

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

   

• Власть над людьми и бизнес ценностями. В традиционной модели командования и управления менеджеры решали что необходимо сделать, назначали задачи на сотрудников, проверяли выполнение и отчитывались о статусах наверх. Но в нынешних реалиях, ответственность над бизнес ценностями (проще говоря, “что делать”) принадлежит, в большей степени, владельцу продукта, в то время как знания о том, что необходимо сделать, чтобы достичь поставленной цели (“как сделать”) является ответственностью команды. Менеджеры в этой модели могут чувствовать себя исключенными из процесса и не имеющими функций контроля.
•  Техническую экспертизу. Сегодня, от менеджеров не ожидается, что они эксперты в данной области или технические гуру. Иметь техническую квалификацию все еще ценно, но более важно быть лидером, иметь видение, быть визионером, служить команде и сотрудникам, а также помогать им расти в их профессионализме. Этот переход может быть очень сложным для тех, кто привык быть единственным лицом принимающим решение во всех технических аспектах.
• Метрики. Это может явиться очень болезненным для тех, кто привык к традиционному управлению проектами. В традиционном SDLC проектная работа выражена в процентах выполнения в разрезе каждой из фаз проекта, используются такие метрики как KPI, системы показателей (scorecards), планы проектов и финансовые прогнозы. Можно смело утверждать, что все эти метрики дают ложное ощущение видимости, но отсутствие метрик вообще вызывает много беспокойства.

Как менеджеры могут злоупотреблять Agile?

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

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

Примеры контрпродуктивных и вредящих управленческих решений и действий

• Постоянно менять состав команд.
• Давать сотрудникам задачи вне их зоны ответственности и вне их роли в команде.
• Подрыв и неуважение к решениям команды. Вероятно, самый сильный способ лишить силы и оттолкнуть команду.
• Самовольно менять цель и задачи спринта во время спринта. То же самое что и выше, только еще и против владельца продукта.
• Измерение скорости работы команды как цель к улучшению, а также сопоставление скоростей работы разных команд. Ориентация на цифры приводит к инфляции. Команды могут легко придумать систему как обманывать такого менеджера.
• Следить за метриками “оцененное время” сравнивать с “реальным временем”  и беспокоиться по поводу того, что люди недозагружены. Помним, что высокая загруженность представляет высокий риск. Когда загрузка доходит до 100%, время пропускной способности команды (сотрудника) растет в геометрической прогрессии, что в свою очередь ведет к тому, что даже самая мелкая задача будет делаться “вечно”.
• Вознаграждение людей, которые проявляют антикомандное поведение.

Продолжение статьи ->