Самоорганизующиеся команды не собираются случайно

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

В Agile Manifesto самоорганизующиеся команды — это ключевой принцип: «Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд»

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

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

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

Не каждая Agile команда самоорганизуется одинаково

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

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

Можем ли мы ожидать самоорганизации от Agile команд?

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

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

Менеджмент осуществляет искусный контроль над самоорганизацией

В оригинальной статье, описывающей Scrum, Такеучи и Нонака определили «искусный контроль» как один из шести его принципов. Они считают кадровые решения ключевой обязанностью менеджеров:

«Выбор подходящих людей для проектной команды во время мониторинга изменений в групповой динамике и добавление или удаление участников в случае необходимости [является ключевой обязанностью менеджера]. „Мы бы добавили в команду более взрослого и более консервативного участника, если бы баланс слишком сильно сместился в сторону радикализма“, — сказал руководитель Honda. „Мы тщательно отбираем участников проекта после долгих размышлений. Мы анализируем различные личности, чтобы увидеть, будут ли они ладить“»

Поиск подходящих людей в Agile команду

Если вы менеджер по персоналу или можете влиять на состав команды в вашей компании, вот некоторые моменты, которые следует учитывать при формировании Agile команд:

1) Включите все необходимые компетенции

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

2) Сочетайте уровень технического мастерства

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

3) Находите баланс среди экспертов в определённой области

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

4) Ищите разнообразия

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

5) Учитывайте постоянство при формировании команды

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

Некоторые возражения по поводу самоорганизации команд

Давайте рассмотрим несколько возражений по поводу того, что команда может самоорганизоваться

Один доминирующий человек будет принимать все решения

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

Если вы замечаете, что такое начинает происходить, поясните данному человеку, что в тех ситуациях, где ему кажется, что он лучше всех знает «как правильно делать», ему следует давать команде право высказать своё мнение.

Спросите у него, как он думает, сможет ли команда принять правильное решение, если он представит свои мысли как мнение, а не как неоспоримое решение.

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

Моя команда ожидает, что Scrum Master возглавит

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

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

Команда слишком «зелёная» для самоорганизации

Третье возражение заключается в том, что команда слишком «зелёная» для самоорганизации

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

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

Искусно контролируйте то, кого вы объединили в команду и какую поставили цель, а не то как им самоорганизоваться для выполнения своей повседневной работы.

Текст адаптирован с оригинальной статьи:
https://www.mountaingoatsoftware.com/blog/self-organizing-teams-are-not-put-together-randomly

Поделиться
Отправить
Запинить
Популярное