Самоорганизованные и кроссфункциональные команды в Scrum: начало дискурса

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

Актуальность вопроса

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

Я имел честь внедрять Scrum в крупных компаниях в США, Сингапуре, Великобритании и других странах, благодаря чему получил ценный опыт и успехов, и поражений, которым хочу поделиться с единомышленниками на страницах Agile.Live.

Дело в том, что все попытки ввести Scrum в соответствии с постулатами Agile может перечеркнуть один маленький, но коварный нюанс — устаревшая практика командной работы.

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

Именно с командами тесно связана сущность Scrum. Ведь задача скрам-мастера состоит в том, чтобы создать среду, в котором во время каждого спринта команда сможет создать инкремент из согласованного (не с “начальством”, а между участниками процесса разработки) задач, а также проверить результаты и внести соответствующие коррективы в следующий спринт.

Термины и понятия

Итак, для начала выясним значение ключевых терминов.

В Украине бытуют такие понятия, как “самоорганизованные команды”, а также “самоуправляемые команды”. В западной деловой культуре также используют оба термина, self managing и self organizing (teams). Некоторые даже спорят о том, какой из них правильный. Не будем терять на это время. Я буду говорить о командах, как их определяет Scrum.

В пособии “Скрам” используют понятия self-managing teams, self-management и cross-functional, cross-functionality. В них и заложена сущность скрам-команды в Scrum-подходе. (Подробности см. в оригинале пособия на английском “The 2020 Scrum Guide” на официальном сайте Scrum.org).

Говоря о самоорганизованных или самоуправляемых командах, я имею в виду небольшие команды по 6-10 человек, которые не организовал “кто-то”; они сами себя организовали.

При этом, самоорганизация скрам-команд не абстрактно-философская или популистско-пиарная (“Мы — единая команда!”, “Мы единомышленники!”, “Вместе мы сила!” и тому подобное), а предполагает ответственность за четко обозначенный спектр вопросов, которые придется решать вместе в процессе разработки.

Речь идет о вопросах, лежащих в трех плоскостях:

1. Что.
2. Когда.
3. Как.

ТРИ ПЛОСКОСТИ САМОУПРАВЛЯЕМЫХ КОМАНД

Вряд ли существует что-либо проще с точки зрения теории. В то же время, вряд ли существует что-то более сложное, чем “что, когда и как” с точки зрения практики — профессионального функционирования команд в парадигме Scrum.

Трудности при внедрении Scrum-подхода

Независимо от географического местоположения (США, Восточная Европа, Австралия, страны Ближнего или Дальнего Востока), уровня экономики государства или отрасли (IT, банковская сфера, производство товаров или предоставление услуг), — большинству команд не удается сразу отвечать “букве и духу” Scrum.

Почему? Что мешает быстро ввести изменения и функционировать профессионально как скрам-команда?
Даже при условии прохождения тренинга, предыдущего опыта разработки продукта и надлежащей теоретической подготовки тим-лида или скрам-мастера, остается уязвимая зона — человеческий фактор.

Представим на минутку специалиста, обладающего полномочиями агента перемен.

Ему нужно отказаться от рядя полномочий, после чего, как говорят украинцы, “не суй носа в чужое просо”.
Что если команда допускает ошибку? Что когда избрала ложный путь? Что если у лидера есть собственное видение решения проблемы?

Здесь и возникает соблазн допустить первую ошибку — продолжать контролировать процессы (что, когда, как), считая, что без мудрости старшего брата (руководителя) группа специалистов не сможет выполнить задание.
Руководитель, который продолжает функционировать в старой парадигме “начальника” (речь идет не обязательно о лице пенсионного возраста; представителями “старой парадигмы” могут быть даже студенты), которому не нравится решение команды, собственноручно перечеркивает его и однако решает действовать по-своему.

Такие лидеры создают иллюзию скрама. Ведь все роли есть, команда есть, сертификат есть, фреймворк есть. Вот только команда может быть пассивной, ждать повеления босса или наоборот — руководитель навязывает свою волю команде.

Я сам допустил когда-то эту ошибку под влиянием человеческого фактора, когда впервые внедрял скрам в компании Ciklum. К счастью, у меня был наставник, который помог вовремя выявить недостатки, а сам продукт получился успешным. Тогда я усвоил один из важнейших принципов, о котором подробнее расскажу в статье “Мой первый фейл в введении аджайл-культуры”. Кроме фейлу, я также расскажу об успешных кейсах и правильном подходе — стратегии поэтапного формирования и развития успешной скрам-команды.

Особенности скрам-команд

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

В каждую скрам-команду входят:

1. Скрам-мастер.
2. Владелец продукта.
3. Разработчики.

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

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

Количественно это небольшие команды (6-10 человек). Этот лимит является результатом эмпирических наблюдений. Ведь именно небольшие группы профессионалов способны эффективнее использовать время, быстрее достигать согласия, демонстрировать более высокую производительность. “Раздувание” команды является нежелательным для Scrum. Вероятно, большие группы будут расформированы на несколько небольших команд, сосредоточенных на соответствующем продукте.

Хочу также подчеркнуть, что самоорганизованность и кроссфункциональность предполагает ответственность каждого участника команды, что существенно влияет на производительность разработки и качество продукта.

“Самоорганизованность и кроссфункциональность предусматривает ответственность каждого участника команды, что существенно влияет на производительность разработки и качество продукта”.

Вячеслав Москаленко — первый сертифицированный тренер Scrum в Украине, соучредитель Agile.Live

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

ПРИСОЕДИНЯЙТЕСЬ К AGILE.LIVE

Ближайшие сертификационные тренинги Agile.Live: Professional Scrum Master (PSM), Professional Agile Leadership Essentials (PAL-E), Professional Scrum Product Owner (PSPO)
Подписаться на страницу в LinkedIn
Подписаться на Telegram-канал Agile.Live
Подписаться на YouTube-канал Agile.Live