Самодизайн команд

Это перевод статьи Team Self-Design, который выполнен с разрешения автора Ahmad Fahmy, а также мнения российских экспертов, которые множество раз проводили сессии самодизайна команд.

Предпосылки и цель

В подразделении Global Securities Operations Technology крупной финансовой компании Bank of America’s Merrill Lynch (BAML) приняли решение внедрить Scrum, и для этого им потребовалось провести ряд изменений. Ключевым из них было создание настоящих «команд» в соответствии с тем, как они определены в Scrum: кросс-функциональные и кросс-компонентные команды, 100% выделенных специалистов, каждая примерно из семи человек, которые могли бы независимо выполнять все задачи (анализ, разработка, тестирование, …) для обеспечения полностью «готовой» сквозной функциональности.

До перехода на Scrum организационная структура в основном состояла из функциональных групп (группа бизнес-анализа, группа разработки, группа тестирования). Кроме того, разработчики были разделены на подгруппы по отдельным программным компонентам, и в каждой группе компонентов существовало «приватное владение кодом» (противоположность подходу «внутренний открытый исходный код»). Следовательно, реализация  любой «вертикальной» сквозной функциональности, ориентированной на клиента, было сопряжено с огромными проблемами передачи данных и координации, поскольку эта работа захватывала группу бизнес-анализа, группу компонента-1, группу компонента-2, группу компонента-3 и группу тестирования. Разрозненность компонентных групп приводила к длительным и сложным циклам интеграции и регрессионного тестирования, и в результате —  к семинедельному циклу релиза.

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

Но как сформировать новые команды из подразделения в 35 человек? Кто должен определить состав команд?

Люди и традиционные взгляды

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

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

Однако, у руководителя департамента была встреча с Крейгом Ларманом, консультантом и тренером по Large-Scale Scrum (LeSS), который помогал группе. Во время этой встречи он предложил идею, описанную в книге Scaling Lean & Agile Development: создание самоорганизующихся команд или самодизайн команд.

Крейг поделился историей о подразделении из примерно 100 человек в Ханчжоу (Китай), который внедрял Large-Scale Scrum и столкнулся с похожей проблемой:

Вместо того чтобы самостоятельно принимать решение о новых командах, руководитель китайского подразделения Люй И (вместе с Басом Водде, экспертом по Scrum, который работал с группой) пригласил всех в большую комнату, объяснил цель создания новых Scrum-команд и просто попросил членов группы принять решение самостоятельно. Группа согласилась и сообщила, что для этого ей нужно четыре часа, и Люй И сказал: «Я вернусь через четыре часа, и если к тому времени кто-нибудь не определится, я приму решение». Четыре часа спустя, после долгих разговоров и активной деятельности, группа самостоятельно создала свои новые команды. Затем в центр комнаты вышли люди, кто добровольно вызвался на роль Скрам-мастера, и команды выбрали тех Скрам-мастеров, которых хотели.

Крейг отметил, что такой подход соответствует принципу самоорганизации в гибких организациях, которые переходят от культуры управления по принципу «командование-контроль» к более самоуправляемой культуре. Он спросил: «О чем это говорит людям, если менеджеры говорят: “Мы собираемся принять Scrum и принципы самоорганизации”, — а затем менеджеры сами принимают решение и говорят людям, какие у них команды и кто их Scrum-мастера?» Крейг также спросил: «А если кому-то не понравится его новая команда, кого он будет винить, если все решили менеджеры, и какие действия предпримет недовольный член команды, чтобы все исправить? И с другой стороны, кого они будут винить, если они сами определяют свои команды, и какие действия они могут предпринять, если им не понравится, как все обернется?».

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

Руководитель отдела быстро понял суть и сказал: «Мне нравится эта идея! Давайте попробуем». Другой менеджер на встрече казался открытым и любопытным, но также был обеспокоен тем, что это может не сработать с точки зрения создания хорошо сбалансированных команд. Чтобы решить эту проблему, Крейг предложил начать сессию с обзора (руководителем подразделения) целей и необходимости разнообразия навыков, опыта, возраста и пола в командах.

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

Сергей Рогачев, ScrumTrek: Распространенная в крупных компаниях культура командного контроля подразумевает беспомощность 2 сторон: не только руководители не готовы делегировать полномочия сотрудникам, но зачастую и сотрудники не готовы брать ответственность. Но первый шаг по изменению ситуации должен сделать руководитель. Ровно поэтому достойны восхищения руководители, которые решаются на проведение сессии Team Self-Design. В наиболее тяжелых случаях руководители идут на полумеру — проведение сессии Team Self-Selection: определение количества и состава компетенций команд руководитель оставляет на себе, а сотрудникам позволяет далее выбрать команду, в которой они хотели бы работать.

Знаменательный день

Руководитель департамента запланировал сессию на полдня для проведения мероприятия по самодизайну команд и пригласил весь свой отдел. Он пригласил меня присоединиться к сессии в качестве наблюдателя. Но за несколько минут до начала он попросил меня не просто наблюдать, а фасилитировать это мероприятие! И я согласился.

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

Сергей Рогачев, ScrumTrek: Такое действительно возможно. Однажды на такой сессии разработчик не смог попасть ни в одну из команд: как только он помещал свой стикер на флипчарт команды, все остальные переносили свои стикеры на другой флипчарт. Тяжелый случай, но уверен, что коллектив принял адекватное решение в сложившихся обстоятельствах и результат был одинаково полезен как команде, так и этому разработчику, который смог построить отношения в коллективе на новом месте работы на новом уровне.

В комнате в Лондоне находилось 42 человека, включая 35 будущих членов команды, а также несколько Скрам-мастеров и других наблюдателей. Сессия началась с того, что руководитель отдела сделал обзор Scrum, хотя некоторые люди уже были на вводном занятии с Крейгом. Я чувствовал, что некоторые скептически относятся не только к идее самоорганизации в собственные команды, но и к идее Scrum в целом — в первую очередь те, кто не был на вводном занятии по Scrum и не совсем понимал идеи и мотивы.

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

На этом этапе руководитель определил два ограничения на создание команд:

• команды должны быть расположены в одном месте;
• команды должны быть кросс-функциональными и кросс-компонентными: они должны уметь (или быть в состоянии научиться) реализовывать и поставлять любой элемент из Бэклога Продукта.

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

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

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

Фасилитация самодизайна команд

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

Я попросил всех присутствующих написать своё имя и основной навык на стикере. Четыре листа для флипчарта были размещены в углах комнаты и служили командными досками. Я проинструктировал группу, что у них есть 25 минут, чтобы объединиться в команды. Они все были обескуражены, так как думали, что на это у них будет три часа. Я сказал им, что в этой технике никому не разрешается сидеть в течение трёх часов, и все должны физически перемещаться к доске команды. Без лишних слов я запустил таймер, и они приступили к работе.

Цикл первый: «Мы все за улучшения, мы просто не хотим ничего менять»

Сразу же начали формироваться объединения людей по группам, которые уже работали вместе. Когда прозвенел таймер, я был немного разочарован. Чуда, на которое я надеялся, не произошло. Участники перегруппировались в соответствии со своими текущими составами команд, в основном организованных по существующим компонентам программного обеспечения. Казалось, команды наслаждались этим, как бы говоря: «Видите, нам суждено быть вместе».

Я запустил таймер на пять минут, и мы начали первый обзор. Я подошёл к первой команде и попросил зал дать обратную связь. Я отметил каждый озвученный недостаток (отклонение от идеальной команды) на розовом стикере и повесил его на стену рядом с командной доской. Это было проделано довольно быстро, и мы смогли уложиться в пять минут. Когда все завершилось, у каждой команды в среднем было по шесть недостатков.

Цикл второй: Празднование смелости изменяться

Теперь стало по-настоящему интересно. В это время начало становиться все более шумно. У меня возникло ощущение, что люди осознали, насколько им тяжело решиться перейти в другую команду. Я бродил по комнате, пытаясь помочь командам. Всякий раз, когда я обнаруживал, что один из старейшин команды указывает другим, кому и куда перейти, я вмешивался и пытался фасилитировать дискуссию, используя такие приёмы, как «5 почему»: «Почему вам нужно так много разработчиков X?» — и так далее.

В конце концов, люди в одной из давно сформировавшихся команд сказали, что решить, кто должен уйти, слишком сложно, и что, возможно, лучше пригласить менеджера, чтобы он принял решение. Добавив немного грубого юмора, я ответил: «Может быть, он сможет решить, что мы все будем есть на обед? Если мы это сделаем, то только укрепим командно-контролирующую культуру». В этот момент один из членов команды признал, что они выглядят нелепо, и вызвался пойти в ту команду, которая испытывала недостаток в его главном навыке. Я тут же отметил этот факт достаточно громко, чтобы вся комната могла услышать. Это стало своего рода переломным моментом, и затем, наконец, другие члены последовали его примеру.

Результаты выглядели намного лучше. Во время анализа у команд в среднем выявилось по два-три недостатка. Казалось, что мы наконец-то преодолели перевал и можем достичь цели. Второй цикл был завершён.

Сергей Рогачев, ScrumTrek: Задача сессии самодизайна в одном подразделении из 20 человек была в определении 6 человек, которые начнут новый проект в Scrum-команде. Конечно, руководитель отобрал кандидатов, но мне удалось все-таки уговорить его провести самодизайн. Никогда не забуду тот момент… На таймере тикают последние 5 минут, после чего должен вернуться руководитель, а команда — презентовать свой состав. Девчонка, которую руководитель хотел взять в команду, молча сидит перед флипчартом со стикером в руках. Идти в команду или нет? Вдруг она встает и обращается к остальным коллегам: “Ребята, вы просите меня к вам присоединиться, но, извините, я не могу… Дело в том, что я скоро ухожу в декрет”. Больше всех в шоке был руководитель: этого он точно не мог предусмотреть!

Цикл третий: Ахмад открывает ещё один метод преодоления затора

Во время третьего цикла темп снова снизился, и люди упорно держались за свои давние команды. Между двумя командами все ещё существовал дисбаланс: у одной был избыток определённого навыка, а у другой — недостаток того же навыка.

Я предложил, чтобы команда с недостатком физически подошла к команде с избытком и попросила о помощи. Им понравилась эта идея, они сделали это и добились успеха. Увидев, что это работает, я попросил другие команды сделать то же самое.

Время проверки. У одной команды было ноль недостатков, у других — по одному. Неплохо. Я попросил команды провести проверку с точки зрения здравого смысла и действительно «посмотреть» на своих товарищей. Это было сделано, и мы заметили дисбаланс бизнес-знаний в одной команде. Как только это было исправлено, мы почти закончили.

Михаил Вязанкин, AgileVerse: Часто мы для таких сессий подготавливаем карточку, как в ролевой игре — куда люди могут вписать своё имя, ключевые навыки и иногда отметить их уровень численно, это помогает командам между раундами наглядно посмотреть на себя и свои недостатки и быстрее принять решение о том, куда и кому лучше перейти. Однажды я проводил такую сессию для четырех команд и в попытке найти оптимальный состав ребята меняли решение 7-8 раз, но в итоге им удалось договориться и они осталось крайне довольны и проработали в таком составе достаточно долго.

Цикл четвёртый: Выбор Скрам-мастеров и названий команд

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

Сергей Рогачев, ScrumTrek: В моей практике хорошо работают выборы Scrum-мастера. Как это работает? Проговорите с командой и запишите на флипчарте обязанности Scrum-мастера. Затем попросите каждого незаметно для остальных написать на стикере имя того, кто лучше всех справится с этой ролью. Соберите стикеры, обеспечив конфиденциальность голосов. Озвучьте вслух имя победителя и спросите, готов ли он попробовать себя в роли Scrum-мастера при поддержке команды. При положительном ответе обеспечивается согласование с 2 сторон: команда готова делегировать полномочия избраннику, а новый Scrum-мастер чувствует ответственность перед командой. Было всего один раз, когда избранник отказался, пояснив команде причину, тогда я провёл повторный раунд.

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

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

Михаил Вязанкин, AgileVerse: До сих пор моим любимым выбранным названием остаётся “Медоеды” — сильный и непобедимый зверь. Многим важно ассоциировать себя с чем-то важным и интересным, и этап создания названия я стараюсь не пропускать. Только один раз, когда меня позвали помочь провести такую сессию с незнакомой мне командой, они выбрали скучные названия. Во всех остальных случаях названия креативны и хорошо передают дух команды. Хотя руководителям и тяжело привыкать к таким названиям.

Ретроспектива и подведение итогов

Я попросил всех перед уходом оставить как положительные так и отрицательные отзывы об упражнении, и в этой статье в приложении обобщены их мнения.

Как только это было сделано, сессия завершилась.

Я сразу же отправил фотографии команд по электронной почте в отдел и высшему руководству.

Вот так за три часа был преобразован отдел. Теперь дело было за малым — поставлять отличное программное обеспечение с максимальной гибкостью в нашем мире частых изменений и обучения.

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

Рефлексия

Сбалансированные команды могли бы быть созданы командой менеджеров, и, по всей вероятности, они не сильно отличались бы от команд, созданных в ходе этого процесса. Основное отличие, однако, заключается в том, что сессия по самодизайну команд задаёт тон изменениям в культуре, которые претерпевает организация при правильном внедрении Scrum. Она разрушила многие конструкции стиля «руководи и контролируй» на ранних этапах весьма выразительным образом. В конце трёхчасового занятия появилось чувство расширения возможностей, которого не было прежде (см. Приложение B).

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

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

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

Совершенствование процесса самодизайна команд: больше опыта

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

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

Мы внесли два существенных изменения в сессию и процесс, которые мы рекомендуем:

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

Обновленное расписание сессий приведено в Приложении А.

Алексей Воронин, ScrumTrek: Можно пойти ещё дальше, как я обычно и делаю на сессиях самодизайна, и добавить в начале ещё один этап, на котором предложить участникам сделать “черновой подход” к определению структуры всей продуктовой группы до момента непосредственного самоопределения участников по командам. То есть задачей участников будет не просто договориться о том, кто в какую команду идёт, а ещё и определить количество, структуру и другие особенности команд. На старте это позволяет людям ещё больше погрузиться в тему и увидеть различные варианты оргдизайна продуктовой группы. Как я это делаю? В начале сессии я разбиваю участников на несколько небольших смешанных групп, раздаю им флипчарты и ставлю задачу нарисовать внутри группы их видение оргструктуры. Далее в формате World Cafe участники договариваются и отрисовывают их видение оргдизайна продуктовой группы. Каждые 15-20 минут группы меняются местами и дорабатывают вариант оргструктуры их коллег. После трёх 20-ти минутных раундов каждая группа презентует свой вариант дизайна продуктовой группы, а менеджмент и эксперты дают обратную связь, подсвечивая проблемные моменты или наоборот положительные аспекты получившейся структуры. Далее самодизайн проходит по предложенному в статье подходу.

Масштабирование до 100 участников

После проведения трёх сессий по формированию команд, я недавно получил просьбу помочь в создании 14 команд, всего в которых было 100 человек. Учитывая масштаб, я сделал следующее:

• добавил ещё один час к первоначальному формату;
• разделил комнату на 3 части и обратился за помощью к двум другим Скрам-мастерам, чтобы они помогли фасилитировать анализ результатов;
• были даны заранее определённые критерии, но в «комнате» давалось 25 минут, чтобы переопределить правила определения команд.

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

 

Резюме

Конечно, трёх часов недостаточно, чтобы полностью и успешно внедрить Large-Scale Scrum. Формирование команд на трёхчасовой сессии — это лишь один из многих очевидных и тончайших элементов изменений. Но интересно, как много можно быстро изменить, если есть организационная воля и соответствующая поддержка со стороны исполнителей и руководства. И примечательно, что при некоторой фасилитации люди вполне способны сами решать, как им организоваться в команды, без использования командно-контрольной системы управления.

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

Приложение A: Примерное расписание

 

Секция	Продолжительность (минуты)
Введение и предпосылки	20
Определение идеальной команды. Определите основные навыки, необходимые в любой команде. Это создаёт скорее приблизительный ориентир, чем строгое правило.	20
Цикл #1	25
Обзор	15
Цикл #2	25
Обзор	15
Перерыв	10
Цикл #3	25
Обзор	15
Названия команда и фотографирование	15
Ретроспектива: Обратная связь «плюс-дельта»	5
Выводы и дальнейшие шаги	10

Дополнительная сессия может быть запланирована на следующий день для обсуждения любых возможных запросов на изменения.

Приложение B: Обратная связь по сессии

Положительные отзывы:

• Процесс, фасилитация и хронометраж, 11
• Чувство расширения ответственности, 7
• Создание хорошо сбалансированной команды, 8
• Ощущение командного духа, которое было укреплено, 3

Зоны улучшения:

• Неудачный выбор помещения, 6
• Слишком длинная сессия, 5
• Для выхода из тупика требуется большее участие руководства/фасилитатора, 5
• Давление со стороны «аудитории» с требованием присоединиться к команде, которая вас не устраивает, 3
• Требуется больше информации перед встречей относительно индивидуальных профилей, целей сессии и типа задач, над которыми будут работать команды, 3
• Нежелание членов коллектива покидать первоначально созданные команды, 3
• Временами хаотично, 2
• Процесс не создаёт сбалансированных команд, 2