перевод оригинального паттерна Involve the Managers
... организация, которая приняла решение внедрить Скрам, начинает использовать Скрам для формирования идей и разработки своих продуктов. Скрам значительно отличается от традиционных организационных структур, поэтому возникают вопросы о месте традиционных организационных ролей. Те, кто привык к управленческим ролям в традиционной разработке продуктов, теперь ищут аналоги в культуре Скрама. Менеджмент есть в традиционных организациях любого размера. В Скраме зоны ответственности частично пересекаются с обязанностями менеджмента. Неминуемая дилемма становится очевидной, когда организация определяет степень влияния менеджмента и необходимость менеджмента как такового.
✥ ✥ ✥
Во фреймворке Скрам нет менеджеров. В Скраме Development Team является самоуправляемой командой, и Product Owner, хотя и подотчетен заинтересованным сторонам и инвесторам, не подлежит контролю со стороны какой-либо высшей инстанции внутри организации. Поэтому менеджерам в процессе аджайл-трансформации трудно найти точку приложения своих усилий, кроме как в качестве недифференцированной вспомогательной роли.
Менеджер разработки в традиционной организации координирует работу и фактически ставит задачи Development Team. Однако, необходимость оперативной реакции и быстрого принятия решений предполагает, что разработчики должны сами управлять своей ежедневной работой. Так происходит разработка продукта в Скраме. Тем не менее, традиционный набор менеджерских навыков может иметь смысл в организации, занимающейся разработкой комплексных продуктов. Этот набор навыков выходит за рамки обычной разработки и вне того, что Скрам приносит в организацию.
Должность "менеджер" часто имеет особое положение, с точки зрения возможности выступать от имени компании и нести ответственность за корпоративную деятельность. У менеджеров есть возможность и полномочия для реструктуризации организации, а у Product Owner - нет. Scrum Teams могут справляться с ежедневными проблемами, если они не выходят за пределы команды. Например, Product Owner неудобно нести договорную ответственность за отношения с вендором, который обеспечивает разработку нескольких продуктов компании (т. е. усилия по разработке нескольких Product Owner).
Согласно словарному определению, менеджмент - это в основном контроль и ответственность. Ответственность означает желание принимать обязательства, отвечать за совершенное действие. Одна из причин отсутствия менеджмента в Скраме заключается в том, что контроль над процессом разработки децентрализован между членами самоуправляемой команды. Комплексность разработки продукта приводит к тому, что лидерство динамично переходит от одного члена команды к другому. Эффективная работа чахнет в условиях централизованного контроля и менеджмента. Однако существуют и другие функции, помимо самой разработки, необходимые для поддержки разработки продукта. Product Owner контролирует (имеет последнее слово) направление развития продукта, что действительно является формой менеджмента, поэтому мнение о том, что Скрам не имеет никаких точек контроля, является мифом.
Существуют и другие моменты в работе организации, которые, как и в случае с Product Owner, больше подходят для централизованного принятия решений, чем для коллективного консенсуса. Например, некоторые важные бизнес-решения в большей степени могут быть обусловлены “внутренним чутьем”, нежели обоснованы консультациями или эмпирическим обоснованием. При рассмотрении вопроса о переходе от аналоговых к цифровым телекоммуникациям компания AT&T обосновала, что существующая аналоговая технология экономически более выгодна. Компания решила не выходить на рынок цифровой коммутации. Другая компания Northern Telecom начала разработку цифрового коммутатора DMS-100 в конце 1970-х годов и застала AT&T врасплох, поскольку цифровые технологии вошли в моду. Рыночное восприятие ценности взяло верх над инженерным анализом. Развития существующего продукта было недостаточно: речь шла о запуске новой линейки продуктов. Хотя эти вопросы активно обсуждались на инженерном уровне в Northern Telecom, в конечном итоге решение о внедрении цифровой коммутации было принято руководством компании на основе интуиции и видения. Они опередили AT&T на этом рынке в 1979 году.
В организации, разрабатывающей несколько продуктов, существующим Scrum Teams неудобно принимать решения, связанные с жизненным циклом продукта или самим существованием команды или продукта. К таким решениям относится, например, ответственное распределение рисков между различными продуктами в разное время. Хотя Product Owners и могут взять на себя ответственность за продукт, но они не могут полноценно отвечать за него. Вряд ли они будут обладать достаточно объективным взглядом, чтобы отказаться от своего продукта, когда бизнес подсказывает, что это необходимо сделать. Таким образом, отдельные продукты могут сами по себе не иметь возможностей, ресурсов или запасных вариантов для принятия на себя серьезных рисков.
Scrum Teams практикуют кайдзен. Кайдзен - это постоянные, локальные, постепенные изменения. Иногда продукт или даже организация должны претерпевать скачкообразные изменения, чтобы выжить. К экстремальным случаям относятся Sun Microsystems, сократившая свой аппаратный бизнес, Nokia, перешедшая от производства резиновых сапог к производству сотовых телефонов, Toyota, перешедшая от производства ткацких станков к производству автомобилей. Компания IBM прошла путь от продаж комплектующих для компьютеров, составлявших в 1985 году почти три четверти ее дохода (при этом программное обеспечение было составной частью), до организации, предоставляющей услуги, где в 2015 году продажи комплектующих составляли менее 10 процентов дохода. В 1986 году руководство решило увеличить объем предоставления сервисных услуг с 25 процентов дохода до 40 процентов дохода в течение шести лет.
Product Owners и Scrum Teams могут не замечать такие возможности, потому что они обычно сфокусированы на управлении рисками посредством постепенных изменений кайдзен. Возможно, они не захотят снижать риски, убивая свой собственный продукт. Члены команды могут воспринимать радикальные изменения, по-японски кайкаку (см. Kaizen and Kaikaku), как угрозу. Любая продуктовая организация может посчитать, что скачкообразные изменения (как в примерах выше) слишком большой риск. Когда организация перекладывает всю ответственность за улучшение на отдельные продукты или на самом низком уровне - на команду, результатом может быть несколько локально оптимизированных продуктов, которые не замечают потенциала более широкого продукта или бизнес-синергии.
Менеджеры часто присутствуют в организации на начальном этапе аджайл-трансформации; они могут даже инициировать ее. И они хотят помочь. Команды, которым внушили, что они самоуправляемые, часто воспринимают такую помощь менеджмента как нежелательную. Менеджмент продолжает вмешиваться в дела Scrum Team, отвлекает команду и вообще становится помехой. В крайнем случае менеджер может даже брать на себя техническую работу или указывать членам команды, как им выполнять свою работу. Уэйн Росинг избавился от всех таких менеджеров, когда в 2001 году занял пост вице-президента по инженерным вопросам в Google, и заставил все 160 или около того менеджеров подчиняться непосредственно ему. Однако Розинг сам принял это решение, как менеджер: кто-то должен инициировать скачкообразные изменения, чтобы организация продвигалась вперед не только в области локальной оптимизации.
Поэтому:
Поддерживайте менеджерскую функцию, которая может действовать с позиции силы, инициировать радикальные изменения в организации и брать на себя ответственность за них, а также бороться с препятствиями, которые могут быть слишком тяжелыми для ScrumMaster или Product Owner в Scrum Team. Scrum Teams самостоятельно решают все вопросы тактического и большинство вопросов стратегического направления развития продукта, функционируя, в основном, как автономные команды. Scrum Teams взаимодействуют с менеджерами в еженедельных мероприятиях MetaScrum (в основном через Product Owners), однако менеджеры не принимают участия в других событиях Скрама.
Пока Scrum Teams сами определяют свое собственное направление кайдзен, менеджмент будет искать возможности бросить им вызов с помощью более радикальных изменений кайкаку. Таким образом, менеджеры могут играть ключевую роль в инновациях: мыслить в направлениях, которые менеджмент продукта (Product Owner) может счесть угрозой своему собственному существованию.
Хорошие менеджеры выполняют роль лидера-слуги, но в силу своего положения они обладают большей властью, чем ScrumMaster. Менеджер может вмешаться, чтобы разрешить конфликты между Product Owners различных продуктов. И менеджеры могут использовать свои полномочия для разработки политики, которая определяет стратегию организации по достижению Greatest Value. Например, менеджмент может снять ответственность за направление продукта с существующего руководящего комитета и передать ее Product Owner, желающему взять на себя эту ответственность. На ежедневной основе менеджмент может служить последним этапом для эскалации препятствий, стоящих на пути поставки продукта; их сила и ресурсы часто могут решать проблемы способами, недоступными для Scrum Team.
Менеджеры могут эффективно выполнять роль фасилитатора и координатора в крупных организациях, разрабатывающих несколько продуктов. Они также могут использовать свое положение и, возможно, доступ к корпоративным ресурсам, чтобы помогать Scrum of Scrums и MetaScrum в устранении неотложных препятствий. Если успешность Sprint под угрозой из-за препятствий, например, разногласий с внешним вендором, MetaScrum может обратиться к менеджменту с просьбой оказать поддержку в решении проблемы.
Менеджер также может выполнять роль щита (см.паттерн Firewall), ограждая команду от стейкхолдеров, которые могут им помешать. Традиционно это ответственность ScrumMaster, однако менеджеры могут быть более эффективными в решении этой проблемы, особенно, когда в нее вовлечены стейкхолдеры вне организации.
Несколько дополнительных управленческих ролей могут возглавлять группы Birds of a Feather, особенно в том, что касается традиционной деятельности по карьерному росту. Такие менеджеры, приближенные к командам, могут заниматься развитием персонала и администрированием.
✥ ✥ ✥
Теперь организация может управлять рисками с точки зрения большей перспективы и объективности, чем любой отдельный Product Owner. В целом инновации и эффективность на корпоративном уровне могут улучшаться быстрее. Product Owners сохраняют ответственность за управление рисками и принятие решений на уровне их собственного продукта. Тем не менее, менеджмент может утолить свой аппетит к риску, приняв радикальные решения (например, изменение направления развития организации), влияние которых шире одного продукта. Если продукт умирает, может возникнуть необходимость закрыть его (см. Product Wake), чтобы освободить людей для работы над другими новыми продуктами. Это может стать толчком для глобальных улучшений, которые в противном случае могли бы остановиться на локальной оптимизации в рамках кайдзен-области Product Owner. Например, посмотрев шире на организацию можно заметить, что один продукт поглощает рынок другого, и, что чистая выгода для рынка и реализация наивысшей ценности (см. Value and ROI) будут результатом остановки разработки одного из двух продуктов.
Одна из причин, по которой менеджмент может пойти на риск и начать действовать в радикально новых направлениях, заключается отчасти в том, что он контролирует широкий портфель продуктов, которые могут подменять друг друга, а отчасти в том, что у него есть дар "великого предчувствия", благодаря которому он занял свою должность. Чем выше позиция менеджмента в организации, тем больше он добавляет рациональности решениями, принимаемыми "изнутри", как отмечает Герд Гигеренцер в книге "Лидерство и интуиция". Менеджеры могут устранять организационные препятствия, чтобы привести организационную структуру в соответствие с целями Скрама. Например, менеджмент может забрать ответственность за решения о направлении развития продукта из отдела продаж и маркетинга и отдать ее Product Owner. Опираясь на опыт Nortel, мы находим следующее:
Отличительной чертой компании Nortel было то, что даже менеджеры и директора самого высокого уровня были готовы (более того привыкли) открыто размышлять о методах работы и путях организации, поэтому они были готовы подвергать сомнению актуальность текущих портфелей продуктов и услуг. На всех уровнях они подходили более играючи и импульсивно к размышлениям об организации.
...Они признали ряд парадоксов и, похоже, были готовы не только жить с ними, но и применять их в управлении организацией и инновациями.
...Они предположили, что постепенные инновации могут быть достигнуты с помощью традиционных организационных структур, но радикальные инновации требуют организации, способной выйти за рамки существующих структур.
Кроме того, менеджеры обеспечивают как стратегическую, так и тактическую координацию и поддержку в крупных организациях. “Наделение полномочиями” было модным словами 80-х годов - своего рода культ Autonomous Teams. В то время как менеджеры изначально поддерживали команды координацией и фасилитацией, исследования в DuPont, AT&T и других крупных компаниях показали, что расширение полномочий разрушает ценные связи между командами. Менеджмент выполнял важную функцию, которую разрушают Autonomous Teams, доведенные до крайности. Несмотря на упомянутое выше, держите численность менеджеров будет небольшой: вспомните, что у Розинга из предыдущей истории Google было 160 прямых подчиненных. Это, вероятно, означает, что большая часть существующего менеджерского состава будет находиться в поиске новых ролей в организации.
Фактически, Project Oxygen в Google переосмыслил роль тех, кого называли менеджерами. Они действовали больше как коучи, нежели менеджеры. Google признал, что хорошие менеджеры не занимаются микроменеджментом, что они эффективно общаются, заботливы, но продуктивны и что они сосредоточены на карьерном развитии своих сотрудников. Хотя эти черты характеризуют отличных менеджеров в традиционной среде, отличный ScrumMaster выполняет эту роль коуча в Scrum Team.
На регулярной основе, Scrum Team может предлагать менеджерам устранять препятствия, мешающие поставке продукта. Это позволяет решать системные проблемы, вместо поиска обходных путей и борьбы с симптомами силами разработки.
Обратите внимание, что менеджмент должен стремиться к синергии между продуктами, каждый из которых уже имеет свой собственный Value Stream. Этот паттерн не является оправданием передачи части разработки продукта нескольким вендорам, если только каждый компонент уже не имеет устоявшегося рынка (например, как товары массового потребления) сам по себе. Если компания в целом не экономит за счет эффекта масштаба, когда несколько продуктов могут разделять поставки от внешнего вендора, отдельные Product Owners должны управлять такими субподрядными активностями.
Менеджмент может решить, что текущая бизнес-стратегия (например, доминирование IBM в продаже железа и меди) отжила свое, и может принять решение о прекращении работы с поддерживающими стратегию продуктами, за исключением гарантийной замены и минимального технического обслуживания. Это освобождает бизнес для движения в новом направлении (например, продажа услуг, консалтинг, аутсорсинг, облачные сервисы). Маловероятно, что Product Owner сам доведет свой продукт до самоубийства, даже если с широкой точки зрения бизнеса это будет во благо для всей корпорации. Менеджмент может начать новый замещающий бизнес, управляемый Product Owner, который привнесет соответствующее новому направлению Vision. Это радикальное изменение или кайкаку.
Конечно, менеджеры тесно работают с Product Owners во всех подобных инициативах. Основное различие между Product Owner и менеджером заключается в масштабе и степени изменений: кайдзен и кайкаку. Менеджеры взаимодействуют со Scrum Teams в MetaScrum, в первую очередь с Product Owner. MetaScrum - это один из форумов, который помогает менеджеру быть в курсе того, что происходит в организации (поддерживает прозрачность и обмен информацией), и наоборот. Он дает регулярный формальный доступ менеджмента к Scrum Teams. Менеджеры не должны иным образом вмешиваться в События Скрама.
Менеджеры становятся центром масштабирования. Вместо того чтобы масштабировать продукт, менеджеры масштабируют организацию и фасилитируют взаимодействие между частями корпорации. Product Owner, а не менеджер, возглавляет каждый продукт, с очень тонкой прослойкой менеджмента на уровне выше. Это будет препятствием, если менеджеры начинают нуждаться в менеджменте со стороны других менеджеров. Опять же, возвращаясь к роли, которую сыграли менеджеры Northern Telecom в инновациях:
Nortel очень плоский. Вы не увидите здесь иерархии... вы найдете чемпионов повсюду на всех уровнях.
В крупной организации менеджеры могут помочь с так называемым HR, который не ограничивается подбором талантливых кандидатов для удовлетворения сиюминутных потребностей, а фокусируется на широте компетенций и склонности к обучению. Хорошие компании нанимают сотрудников, обладающих несколькими компетенциями и желанием учиться, которые будут приносить пользу множеству продуктов снова и снова на протяжении своей долгой карьеры в организации, а не нанимают в отчаянии звезд, которые позволят любому текущему продукту достичь поставленных целей. Другие менеджерские функции могут поддерживать постоянный карьерный рост, обучение и развитие компетенций, возможно, возглавляя Birds of a Feather в организации. В Spotify есть Chapter Lead, которые, оставаясь членами Development Team, выполняют функции линейных менеджеров в своих Chapter. Некоторые их обязанности: развитие персонала и администрирование заработной платы. Каждый Chapter сфокусирован на определенной тематике. Такой подход работает до тех пор, пока менеджер не управляет разработкой; в противном случае группа, подотчетная менеджеру, скорее всего, будет представлять собой эту область экспертизы, и не будет Cross-Functional Team.
Эрик Рис говорит, что наша вера в успех предпринимательства часто связана с мифом об "упорстве, творческом гении и тяжелой работе", в то время как в действительности он обнаружил, "что именно скучные вещи имеют наибольшее значение… Предпринимательство - это вид менеджмента.ˮ Мы часто стереотипно представляем ScrumMaster, как главного повара и посудомойки, который выполняет грязную работу, однако в хорошей команде каждый вносит свой вклад в повседневную работу. ScrumMaster и менеджер несут немного больше этого бремени. Позволяя Development Team заниматься своими делами, вы создаете основу для создания большей ценности. Неприятные вещи отвлекают от этого.
В качестве примера мы расскажем историю голландской компании Tony's Chocolonely. Некоторые журналисты обнаружили, что большинство шоколада производится с использованием рабского и детского труда (вспомните The Mist). Компания задумались о том, как они могут улучшить мир: "Мы покажем на примере и докажем, что коммерчески успешный шоколад можно производить без рабства и эксплуатацииˮ (подумайте о Vision). "И не только наш шоколад. Нет. Весь шоколад во всем мире. Когда в шоколадной промышленности больше не будет рабства, тогда мы достигнем нашей целиˮ (Greatest Value). Бизнес рос. С ростом фирмы появились отвлекающие факторы, связанные с финансами, закупками и другими управленческими проблемами. Они больше не могли сосредоточиться на своей цели. Они неохотно начали поиски менеджера, который знал бы, как справиться с такими проблемами. Основателю казалось, что те, с кем они беседовали, занимались этим только ради денег, как "продавцы подержанных автомобилейˮ. Отчасти проблема заключалась в том, что один из основателей, Морис Деккер, искал кого-то похожего на себя. Однако ирония судьбы заключалась в том, что именно его набор навыков (читайте, отсутствие менеджерских навыков) - был корнем проблемы, которую мог решить менеджер. В итоге они начали сотрудничество с человеком, который сейчас является их генеральным директором, Хенком Яном. С тех пор Tony's Chocolonely стали крупнейшим производителем шоколада в Нидерландах. Компания производит шоколад, не используя рабский труд, что было признано в голландском суде в 2007 году.
Некоторые потенциально менеджерские обязанности часто переходят к ScrumMaster, например, надзор за соблюдением Definition of Done. ScrumMaster может бросить вызов Scrum Team, чтобы она сделала радикальное изменение, или кайкаку, в пределах зоны ответственности команды. Важно понимать, что, в отличие от менеджмента, ScrumMaster не имеет прямого контроля над командой, поэтому должен работать через убеждение и наставничество.
В литературе можно встретить такие советы, как "менеджмент должен создать хорошую (безопасную, благоприятную и т.д.) среду, в которой команда может работать.ˮ Возможно. У менеджеров меньше возможностей усилить чувство безопасности в команде, чем разрушить его. Если ответственность за окружение лежит на менеджменте, то это значит, что Scrum Team потеряла контроль над своей окружением, или, возможно, что у нее никогда не было такого контроля. Здесь необходимо соблюдать баланс, но лучше склониться в сторону признания самостоятельности команды в том, что она может контролировать, а менеджменту сосредоточиться на вопросах, находящихся вне сферы влияния команды.
Традиционные менеджеры должны следить за тем, чтобы не вернуться к своей прежней деятельности, когда они начнут развивать свою роль в рамках Скрама, особенно если они вмешиваются в работу Product Owners или Development Team. Менеджеры должны, в частности, уважать Product Owner в отношении наполнения и выпуска продукта. Они также должны уважать самоуправление Development Team в отношении того, как, кто, а иногда и когда разрабатывать функциональность. Работа ScrumMaster заключается в том, чтобы делать препятствия видимыми, и инициировать их устранение. И хотя менеджеры могут контролировать команду, такой контроль никогда не осуществляется на уровне отдельных продуктов или стратегии релизов. Самая прочная основа менеджерской власти - это нежелание ее использовать и делать это умеренно..
Паттерн Smoke-Filled Room предваряет этот паттерн. Smoke-Filled Room говорит о том, что иногда менеджменту приходится принимать решения без вовлечения всех, на кого эти решения могут повлиять, ошибочно считая ситуацию секретной. Менеджеры могут быть мощной силой, которая реагирует на чрезвычайные ситуации и успешнее управлять большим кораблем, чем полагаясь на процесс достижения консенсуса. Они должны работать в условиях доверия и открытости, а не действовать как теневая группа заговорщиков, которая подразумевалась в вышеупомянутом паттерне.
