Авторы: Ахмед Фами и Крейг Ларман. Оригинальная публикация Scrumalliance.org, 2013)
Оригинальная статья: How to form teams? A story of self-designing teams
Bank of America’s Merrill Lynch (BAML) Global Securities Operations Technology решила внедрить Скрам и нуждалась в некоторых изменениях, чтобы это сделать. Ключевое место среди них занимало формирование реальных “Команд” в Скраме: мотивированных, подлинно кроссфункциональных и кросскомпонентных команд, состоящих приблизительно из семи человек, которые могли бы независимо выполнять все задачи (анализ, разработку, тестирование…) для поставки полностью “завершенного” сквозного функционала.
До внедрения Скрама, эта организационная структура представляла собой преимущественно монофункциональные группы (группа бизнес-анализа, группа разработки, группа тестирования). Далее, разработчики подразделялись на подгруппы, занимающиеся разработкой одного программного компонента и в группе каждого из компонентов присутствовало “приватное владение кодом” (вместо “внутреннего открытого кода”). Следовательно, выполнение одного клиент-ориентированного “вертикального” сквозного функционального элемента включало в себя массивную передачу незавершенной работы и связанные с этим сложные задачи координации, поскольку нужно было вовлекать группу бизнес-анализа, группу компонента 1, группу компонента 2, группу компонента 3 и группу тестирования. Такие разобщенности между группами компонентов обусловили длительные и сложные циклы интеграции и регрессии, приводя к семинедельной фазе релиза.
Поэтому в качестве одного из ранних шагов во внедрении Скрама этому отделу нужно было реорганизовать существующие группы в новые команды - подлинные кроссфункциональные и кросскомпонентные Скрам-команды.
Как формировать эти новые команды, если общее число сотрудников составляет 35 человек? Кто должен определять принадлежность к этим командам?
Поскольку я сам (в данном случае, Ахмед) - “ в прошлом программный менеджер” в отделе, переходящем к Скраму c самоорганизующимися командами, - был очень заинтересован в данном фреймворке и его удачном введении, эти вопросы присутствовали в моем уме. Ранее я узнал об идее самоформирующихся команд от нашего Скрам-коуча и посчитал эту идею интересной, но, возможно, неподходящей для нашей ситуации.
Почему она нам не подходила? Во-первых, менеджер, руководящий этим отделом, поначалу предположил - все мы предположили - что он и другие старшие менеджеры будут определять участников этих новых команд. Это было предположением по умолчанию, связанным с нашей прежней культурой (что заметно во многих организациях): менеджеры сами решают такие вопросы.
Однако, начальник отдела предварительно провел встречу с консультантом по крупномасштабному Скраму и коучем, помогавшим этой группе, Крейгом Ларманом, в ходе которой он предложил идею, описанную в книге Scaling Lean & Agile Development: создание самоорганизующейся команды или самоформируюшиеся команды.
Крейг поделился историей отдела, насчитывающего около 100 сотрудников в Ханчжоу (Китай), который внедрял крупномасштабный Скрам, и столкнулся с похожей проблемой.
Вместо того, чтобы принимать решение по поводу новых команд, китайский менеджер отдела, Лу Йи (вместе с Басом Воддом/Bas Vodde, Скрам-экспертом , работавшим в этой группе) пригласил всех в большую комнату, объяснил цель новых Скрам- команд и просто попросил участников группы решить это между собой. Группа договорилась, что для этого потребуется четыре часа, и Лу Йи сказал: “Я вернусь через четыре часа, и если какие-то сотрудники не будут определены, решать буду я”. Четыре часа спустя, после множества разговоров и активности, группа самостоятельно сформировала свои новые команды. Затем волонтеры - Скрам-Мастера вышли в центр комнаты и команды выбрали тех Скрам-Мастеров, которых хотели.
Крейг отметил, что этот подход отвечал самоорганизующему принципу гибких организаций, движущихся от культуры директивного менеджмента к большему самоуправлению. Ведь когда каждый член команды влияет на принятие решение,
Он спросил: “Что это несет в себе для сотрудников, когда менеджеры говорят: “Мы намерены внедрить Скрам и принципы самоорганизации”, но затем принимают решение сами и рассказывают сотрудникам, каковы их команды, и кто является их Скрам-Мастерами?” Кроме того, Крейг спросил: “А что если кому-то не нравится их новая команда, кого они обвинят в этом, если менеджеры уже сами все решили, и что сделает недовольный участник команды, чтобы это исправить? С другой стороны, кого винить, если сотрудники сами определили свои команды, и что они могли бы сделать, если им не нравится, что из этого получилось?”.
Он также предложил поэкспериментировать, чтобы понять, сможет ли команда (внутри себя), “нанять или уволить” своего Скрам-мастера, вместо того, чтобы он был назначен.
Этот начальник отдела быстро смекнул, в чем дело и сказал: “Мне очень нравится такая идея! Давайте же ее испробуем”.
Начальник отдела запланировал полудневную сессию для мероприятия с участием самоформирующихся команд и пригласил туда весь свой отдел.
Встрече предшествовало множество разговоров. Один из самых опытных разработчиков тихонько отвел меня в сторону перед началом встречи и выразил мне свою обеспокоенность тем, что его не выберут. Это меня ошарашило. Я подумал было, что все это отдает начальной школой.
Комната в Лондоне вместила 42 человека, включая 35 новых участников команд, нескольких Скрам-Мастеров и других наблюдателей. Сессия началась с того, что начальник отдела сделал обзор Скрама, хотя некоторые сотрудники уже прослушали вводную лекцию от Крейга. В воздухе витала атмосфера недоверия и скептицизма.
Один из более старших бизнес-аналитиков выражал беспокойство тем, что Agile может не сработать в более крупных группах и может лучше подходить для небольшого объёма работы с независимыми изменениями. В этот момент вмешался я и попросил аудиторию проголосовать по поводу нынешней способности поставлять программы с крупномасштабными изменениями, поставлять ценность, радовать спонсора в нашей нынешней (традиционной) организации и при наших способах работы. Большинство проголосовало за то, что нынешняя способность организации поставлять продукт могла быть значительно улучшена.
В этот момент он завершил свое выступление двумя ограничениями по поводу создания этих команд:
• Командам нужно было быть совмещенными - физически находиться в одном помещении.
• Командам нужно было быть кроссфункциональными и кросскомпонентными, им нужно быть способными (или смочь научиться) разработать и поставить любой элемент из Бэклога Продукта
Он сделал свои последние ремарки, после чего ушел, а я оказался оставленным в большой комнате в окружении множества скептиков. У нас было три часа, чтобы реорганизовать отдел, ранее десятилетиями работавший внутри фиксированного шаблона.
Сценария или формулы, чтобы им следовать, у меня не было. Возникла идея провести сессию как четыре цикла по 25 минут с пятиминутным ревью в конце каждого из них, плюс несколько перерывов.
Я ничем не показал и без того скептически настроенной аудитории, что изобретал все на ходу, не говоря уже о том, что сам я не верил, что это сработает. Еще давным-давно я открыл для себя, что шансы нового протокола или ритуала быть принятым в небольшой группе на ходу были гораздо выше, если они преподносятся так, будто это уже делалось годами.
Я попросил каждого из присутствующих написать свое имя и основной навык на стикере. Четыре листа флипчарта, которые могли бы послужить командными досками, были вывешены в углу этой большой комнаты. Я проинструктировал группу о том, что у них в распоряжении есть 25 минут, чтобы самостоятельно сформировать команды. Все были потрясены этим, поскольку думали, что на это есть три часа. Я сказал им, что в этой технике никому не разрешается садиться на протяжении трех часов, и нужно физически продвигаться к командной доске. Поэтому без лишних слов я включил свой таймер, и они начали.
Немедленно стали формироваться кланы на основе групп, уже работавших вместе. Когда зазвонил таймер “Помодоро”, я был несколько раздосадован. Чуда, на которое я надеялся, не произошло. Группа распределилась по нынешним командам, в основном организованным по программному компоненту. Казалось, что командам все это очень нравилось - все равно, что сказать: “Смотрите-ка, мы действительно созданы быть вместе”.
Я установил свой таймер на пять минут и мы начали первое ревью. Я подошел к первой команде и попросил аудиторию дать мне фидбэк. Я отметил каждый дефект (отклонение от определения идеальной команды) на розовом стикере и прикрепил его к стене рядом с командной доской. Это было сделано достаточно быстро, и нам удалось уложиться в пять минут. Когда мы закончили, у каждой команды было в среднем по шесть дефектов.
Сейчас все начало становиться действительно интересным. Так бывает, когда группа намного активнее заявляет о себе. Возникло чувство, что людям было очень тяжело свободно перемещаться. Я бродил по комнате, стараясь по пути помочь командам. Всякий раз замечая, что более старшие участники команды приказывают другим идти, я вмешивался и старался фасилитировать такой разговор при помощи техник вроде “пяти почему”. Зачем вам нужно так много разработчиков? И так далее.
В конце концов, сотрудники в одной из давно сформированных команд сказали, что решать, кто должен был уйти, им было слишком сложно, и что, по всей видимости, лучше было бы снова пригласить менеджера, чтобы решение принял он. Добавив немного грубоватого юмора, я ответил так: “ А может он еще и сможет решить, что у нас будет на обед? Если мы поступим так, то будем усиливать эту самую “культуру директивного менеджмента”. В этот момент один из участников команды признал, что они выглядели смешно и вызвался добровольно перейти в ту команду, где не хватало именно его основного навыка. Я немедленно отметил этот факт вслух, так чтобы было слышно всем присутствующим. Это стало переломным моментом, и затем, наконец-то, другие участники последовали его примеру.
Во время этого ревью команды в среднем насчитали у себя по два-три дефекта. Все выглядело уже намного лучше. Возникло ощущение того, что кризис миновал и мы можем достичь цели. Цикл два был завершен.
В ходе третьего цикла все снова замедлилось и люди с упорством держались своих подолгу существующих команд. По-прежнему сохранялся дисбаланс между двумя командами, в одной из которых присутствовал избыток одного навыка, а в другой - недостаток того же навыка.
Я предложил, чтобы “команда с недостатком” физически подошла к “команде с избытком” и попросила помощи. Им понравилась эта идея, они это сделали, и достигли успеха. Заметив, что это работает, я попросил другие команды сделать то же самое.
Время ревью. У одной команды был ноль дефектов, у других команд в сумме было только два. Неплохо. Я попросил команды провести проверку работоспособности и действительно “присмотреться” к своим коллегам по команде. Это было сделано, и мы заметили дисбаланс бизнес-знаний в одной из команд. Когда это было исправлено, мы практически закончили.
У начальника отдела и его команды менеджмента были четверо заранее отобранных кандидатов на позицию Скрам-Мастера. Они были выбраны, исходя из профиля, данного в ходе Скрам-тренинга и добровольного желания сотрудников занять эту позицию. Поскольку начальник отдела в комнате отсутствовал, я решил изменить эту ситуацию: проинформировал эти команды, что они могли выбрать себе Скрам-Мастера из четырех предложенных имен или выбрать кого угодно из собственной команды быть их Скрам-Мастером. Я попросил выбранных заранее Скрам-мастеров выйти из комнаты. Затем дал командам пять минут на размышления. В конце концов, команды выбрали Скрам-мастеров среди первоначальных кандидатов. Было некоторое соперничество вокруг одного из Скрам-мастеров, однако оно быстро разрешилось путем тайного голосования.
Сейчас у нас появились четыре по-настоящему кроссфункциональных и кросскомпонентных, вновь сформированных Скрам-команды. Настроение в комнате было хорошим. Я решил добавить немного юмора и закончить на высокой ноте, попросив команды выбрать себе названия. Это был момент, когда они больше всего оживились в тот день. Было много смеха и беспечных дебатов по поводу этих названий. Это тоже удалось закончить за пять минут.
Я сделал фотографию каждой из команд под своим командным названием. Так этот опыт стал более вещественным для многих, включая меня самого.
Я попросил каждого записать позитивный и негативный фидбэк о выполненном упражнении перед уходом, и эта статья резюмирует их фидбек в приложении.
Когда это было сделано, сессия завершилась.
Я немедленно отправил мейлом фотографии команд в отдел и старшему менеджменту.
Вот как отдел был преобразован за три часа. Сейчас он снова занят своим делом - поставкой прекрасного программного обеспечения с гибкостью в нашем мире частых перемен и обучения.
После этой сессии - и двух последующих мероприятий по самоопределению, описанных в следующем разделе - один участник команды сменил команду на следующий день после сессии. Это было сделано по собственной инициативе сотрудника, и мы увидели в этом признак успеха для ментальности самоорганизующейся команды. Весьма маловероятно, что это произошло бы, если бы менеджер назначил сотрудников в команды.
Сбалансированные команды могли бы создаваться командой менеджмента и, весьма вероятно, что они не слишком отличались бы от команд, созданных в данном процессе. Большая разница, однако, состоит в том, что сессия самоорганизующихся команд задает настрой тому изменению культуры, которое проходит организация при правильном внедрении Скрама. На ранних стадиях оно драматическим способом демонтирует множество конструкций управления и контроля. Спустя три часа возникло ощущение расширения возможностей, которого раньше не было (См. Приложение Б).
Такая потребность в сильной фасилитации также жизненно важна, чтобы проводить сессию плавно и эффективно. Опытный Скрам-мастер или коуч agile идеально подошел бы на роль ведущего такой сессии.
Значительное внимание нужно уделить тем, кто находится в комнате. Эти сессии не должны предназначаться исключительно для технологических сотрудников, но должны привлекать все группы, ответственные за поставку ценности бизнеса. Это критично, поскольку становится разрушительным, если участников “вводят” в команды на более поздней стадии. Это может навредить как зарождающейся культуре, создаваемой сейчас, так и командному духу.
Важно, чтобы в комнате была хорошая атмосфера. Например, большой стол для конференц-зала в нашей комнате оказался препятствием и стал главной жалобой. (см. Приложение Б)
Позитивный фидбэк
• Процесс, фасилитация & хронометраж, 11
• Чувство расширения возможностей, 7
• Создание хорошо сбалансированной команды, 8
• Чувство командного духа, которое было воспитано, 3
Что требует улучшений:
• Неверный выбор комнаты, 6
• Сессия слишком длинная, 5
• Большее участие менеджмента/фасилитация требовалась для разрешения безвыходных ситуаций, 5
• Давление “зала”, приложенное с тем, чтобы вы примкнули к команде, куда вы не хотите, 3
• Перед встречей нужно было больше информации об индивидуальных профилях, задачах сессии & типе работы, выполняемой командами, 3
• Нежелание участников команд передвигаться, покидать первоначально созданные команды, 3
• Хаос временами, 2
• Процесс не создает сбалансированных команд, 2
К счастью, после этого первого опыта, мы фасилитировали еще две сессии для самоформирующихся команд внутри этого банка и усовершенствовали процесс, исходя из принципа инспекции и адаптации.
Во-первых, перед мероприятием для самоорганизующихся команд организуйте вводное обучение Скраму (например, в курсе Certified ScrumMaster) для большинства участников, чтобы они поняли эти идеи, мотивации и контекст.
Мы внесли два значительных изменения в эту сессию и процесс, которые мы рекомендуем:
• Вся группа (вместо менеджера) определяет идеальное устройство новой команды в начале сессии. Ключевая предпосылка: Они делают это на основе предварительного обучения тому, что такое подлинные Скрам- команды в общем и с обучением и фидбэком от фасилитатора.
• Скрам-Мастеров не отбирают заранее; вместо этого, команды голосуют за своих Скрам-мастеров из пула волонтеров, которые продемонстрировали свои знания и интерес.
Обновленное расписание сессии резюмировано в Приложении А.
После фасилитации трех сессий формирования самоорганизующихся команд, меня недавно попросили фасилитировать создание 14 команд из 100 человек. Ввиду такого масштаба, я сделал следующее:
• Добавил еще один час к первоначальному формату
• Разделил комнату на 3 части и попросил помощи двух других Скрам-мастеров с тем, чтобы фасилитировать такой ревью между циклами
В результате, команды были сформированы за три часа. Процесс, конечно же, может масштабироваться до тех пор, пока Скрам-мастер фасилитирует процесс обзора не более пяти команд.
Конечно же, на то, чтобы по-настоящему успешно внедрить полномасштабный Скрам, не хватит лишь трех часов: формирование команд за три-четыре сессии - лишь один из многих очевидных и тонких элементов изменений. Однако стоит отметить, сколь многое можно изменить действительно быстро, если для этого есть организационная воля, подходящий практический сотрудник и поддержка руководства. Кроме того, заслуживает внимания и то обстоятельство, что при некоторой фасилитации сотрудники достаточно способны к тому, чтобы между собой принять решение о том, как организовывать команды, без управляющего и контролирующего менеджмента .
Взгляды, выраженные в статье, принадлежат автору, они не обязательно представляют точку зрения и не должны приписываться Bank of America..
Если обсуждаемая тема для вас актуальна, то советуем обратить внимание на предстоящий тренинг CERTIFIED LESS PRACTITIONER "CLP" WITH CESARIO, уже 23-25 сентября, в Киеве мы будем учиться как внедрять масштабный Скрам в компании. Каждый уйдет с планом действий и четким виденьем с чего начать трансформацию и как развиваться дальше.
Зустрічі у компаніях, які займаються розробкою програмного забезпечення, часто визнаються найважливішою складовою успішного продукту (чи проєкту). Однак, їх вартість і вплив на бізнес часто залишаються недооціненими. Проведення зустрічей вимагає великих витрат часу і ресурсів, і саме тому …
Я проводжу ретроспективи досить часто, близько сотні на рік, а почав уперше це робити майже 10 років тому. У цій статті я хочу відповісти на Top 5 із питань про Ретроспективи, які найчастіше задають учасники тренінгів та Agile-ком'юніті.
Однією з основних функцій сучасного менеджера лідера є розкриття потенціалу кожного учасника команди для досягнення максимальної ефективності та реалізації цілей. Scrum Masters, Product Owners, Facilitators та інші лідери й керівники можуть використовувати коучинговий підхід для підвищення …
