3 заметки с тегом

команда

Проведение командной сессии по инструменту «5 пороков команды» по одноименному бизнес-роману П. Ленсиони

Инструмент «5 пороков команды» П. Ленсиони отлично помогает командам посмотреть как у них идут дела внутри, провести самодиагностику и выработать шаги по повышению эффективности командной работы.

ВАЖНО:

  1. Проводится опытным Scrum-мастером/Agile-коучем, который знает и понимает как работать с командной динамикой и умеет управлять конфликтами.
  2. Рассчитана на зрелую Agile-команду численностью не более 12 человек.
  3. Первая встреча выездная на 1 день, далее уже в формате ретроспектив

Шаги до встречи:

Чтобы эффективно провести сессию до её начала вам необходимо:

  1. «Продать» данный инструмент команде, в которой вы планируете это сделать, чтобы они понимали цель;
  2. Получить согласие от всех участников команды на проведение данной сессии. Этот аспект очень важен, так как в течение всего мероприятия участники будут выходить из зоны комфорта, они должны быть к этому готовы и согласны;
  3. Направить всем участникам команды тест, который им необходимо заполнить до сессии и принести с собой (тест вы можете найти здесь: https://yadi.sk/i/4tTXFTnY3G9tuQ );

На командной сессии:
Первая часть: открытие продолжительность ~1 ч.

  1. Как и в начале ретроспективы необходимо создать атмосферу. Для этого можно использовать любой дизайн, например с сайта https://retromat.org/
  1. Подготовьте заранее флипчарт, на котором будет написано «Команда — это ...»
    Попросите каждого участника на одном стикере написать одно слово, которое продолжит предложение «Команда — это...», затем попросите каждого участника поочередно подойти к флипчарту и озвучивая, наклеить свой стикер. После того как все наклеят свои стикеры, подведите общий итог, что в целом получилось.
  1. Подготовьте заранее заготовки флипчартов с правилами и расписание сессии.
    Перед тем как перейти к цели встречи с участниками команды необходимо договорится о правилах (например, правило поднятой руки, одного микрофона, парковка, не отвлекаемся на девайсы и т. п.) и о расписании (лучше делать сессию 50 мин. работы и 10 мин. отдыха).
    ВАЖНО: Обязательно получите «ОК» от команды на правила и расписание, в течение встречи, вы не раз будете возвращать команду к правилам. «ОК» также важно получить, чтобы не было сопротивления от команды, так как это их встреча, если им что-то не нравится или они хотят что-то добавить, измените написанное или создайте новый флипчарт.
  1. Перейдите к цели. Озвучьте цель и спросите команду согласны ли они с данной целью (цель следует написать на флипчарте, чтобы команда видела)
    Пример цели: Остановиться, выдохнуть и посмотреть как у нас идут дела внутри, провести самодиагностику и выработать шаги по повышению эффективности нашей командной работы.
    ВАЖНО: если команда не согласна с целью, то совместно создайте новую, удовлетворяющей всех цель сессии.

Вторая часть: общее понимания и диагностика продолжительность ~3 ч.

  1. Ещё раз познакомьте команду с инструментом, расскажите кто его создатель (Патрик Ленсиони) и где можно в интересной форме о нём прочитать (одноименный бизнес-роман «5 пороков команды»). Покажите команде треугольник, но пустой :)
  1. Скажите команде: «Перед тем как приступить к работе с треугольником давайте сведём результаты ваших тестов в единое»
    Это можно сделать на флипчарте, но для скорости и удобства лучше сделать в Excel. Не показывайте команде результаты, вы вернётесь к ним немного позже — сохраните интригу.
    (Excel вы можете найти здесь: https://yadi.sk/i/_9ceVJDVptQmTA )
  1. Верните команду к флипчарту с пустым треугольником и начните совместно с ними заполнять и прорабатывать уровни. Так как вы уже ранее встречались с командой и рассказывали про данный треугольник, здесь важно включить участников в совместное «вспоминание»
    Спросите: «Помнит ли кто-то, что у нас на первом уровне?» После того, как назвали, запишите в треугольник. Далее спросите: «Есть ли кто-то кто считает, что доверие не важно в команде?» Если такие есть спросите: «Можешь, пожалуйста, рассказать почему?» Не критикуйте и не переубеждайте, просто выслушайте и посмотрите на реакцию других участников. Если участник не готов сказать — это его право. Если вдруг начинается дискуссия аккуратно остановите её и верните команду к цели сессии.
  1. Попросите участников команды на стикерах (1 стикер = 1 мысль) написать, что они понимают под фразой «Взаимное недоверие», далее каждый из участников выходит и, озвучивая, клеит свои стикеры. Когда все наклеили свои стикеры, уточните не хотят ли они ещё что-то добавить и если у кого-то возник инсайт, обязательно запишите. Это упражнение повторяем для всех уровней, однако, с небольшим дополнением: уточните не хотят ли участники переместить свои стикеры на другой уровень.
  1. Вернитесь с командой к тесту и посмотрите на результаты, которые получились. В первую очередь посмотрите на те пороки, которые набрали 3-5 баллов. Если у команды получилось более одного порока в данном диапазоне начните с самого первого, например, тест показал, что у команды Порок#1 и Порок#3 попали в диапазон 3-5 баллов, начните с Порока#1 и проработайте его до конкретных шагов и первых результатов и только потом переходим к следующему пороку
  1. Для этого шага у вас заранее должен быть подготовлен флипчарт с вопросом «А как это у нас?».
    Попросите участников команды на стикерах (в данном случае можно использовать длинные стикеры) написать ответ на вопрос «А как это у нас?». На этом шаге важно понять как этот порок проявляется у команды. После того как участники команды написали, попросите наклеить, озвучивая написанное.

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

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

ВНИМАНИЕ: остальные кластеры не выкидываются, а остаются для рассмотрения на будущих ретро команды, желательно не раньше получения первых результатов по первому кластеру.

После данного блока команду желательно отпустить на обед.

Третья часть: разработка плана действий продолжительность ~2 ч.

  1. Для данного шага необходимо подготовить флипчарт с вопросом «Как улучшим ситуацию?»
    Итак, команда выбрала для себя первый кластер, с которым будет работать. Попросите команду на стикерах написать решения (1 стикер = 1 решение). Далее каждый участник озвучивая, клеит свои стикеры на флипчарт.
  1. После того, как все участники наклеили свои предложения проверьте их на адекватность по матрице («решает/не решает» проблематику и сможем «сами/нужна помощь»). Зачитайте каждый стикер и совместно с командой отнесите стикер в соответствующую ячейку. После того как все стикеры распределены фокусируйте внимание команды на ячейки «решает/сами» и «решает/нужна помощь».
    Стикеры, которые по мнению команды попали в «решает/нужна помощь» — это область работы Владельца продукта и Scrum-мастера/Agile-коуча. Уточните у команды чья по их мнению им нужна помощь.
    Далее переходите к стикерам в ячейке «решает/сами» и разрабатываем план действий (см. http://kanban.club/all/do-action-plan/)

ВАЖНО:

  1. В течение данного сессии не переходите на работу в малых группах, здесь важна динамика целой команды и ощущение их самих себя как единого целого. Важна динамика их всех целиком
  2. Если команда начинает позитивно что-то обсуждать и хихикать, не вмешивайтесь, просто молча подождите, когда команда вернётся — это важный командообразующий момент;
  3. Если команда начинает что-то конструктивно обсуждать, не вмешивайтесь, это их встреча и, возможно, им надо выговориться, подождите, когда команда к вам вернётся.
  4. Как только чувствуете, что команда «накалена» или «устала» — сделайте перерыв. Возвращая команду с перерывов сделайте краткий обзор того, что было сделано до ухода на перерыв (recap).

Мы будем рады вашим комментариям. Удачной вам сессии.

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

Способность команды самоорганизовываться вокруг поставленной цели является фундаментом для всех 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

10 Практических советов как стать хорошим скрам-мастером

1. Никогда не принимай решения за команду, не спросив её

Как у скрам-мастера команды, у тебя нет права (власти) принимать от имени команды запросы на изменения (неважно насколько они малы).  Даже если ты абсолютно уверен, что команда справится с этим изменением, ты должен сказать: «Мне нужно обсудить это с командой, прежде чем мы скажем ‘да’»

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

2. Помни, что ты там, чтобы помочь команде стать лучше

Быть скрам-мастером не про то, чтобы самому стать лучше.
Ты становишься лучше, когда команда становится лучше.
Команда становится лучше, когда делает отличную работу

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

3. Не бей команду по голове книгой с правилами agile

Ни Scrum, ни agile не пришли к нам с книгой правил (несмотря на то, что некоторые пытались её создать)
Если у продукта есть клиент, следует подумать о написании пользовательских историй (user stories), но истории не являются требованиями в agile. Если кому-то необходимо знать, когда будет поставлен продукт — оценивайте, если такой необходимости нет, возможно, и оценка не нужна. Если вам кажется, что обратная связь в конце спринта — это уже поздно, делайте обзоры в то время, как фича сделана.

Быть agile означает соблюдать принципы и ценности, которые лежат в основе agility. Если команда остается верной принципам и ценностям, она не собьется сильно с пути, несмотря на то, что ей говорят другие

4. Ничто не постоянно, поэтому экспериментируй со своим процессом

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

5. Убедись, что команда и стейкхолдеры относятся друг к другу как к равным

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

6. Защищай команду, включая те способы, о которых ты даже и не думал

Возможно, наиболее частый agile-совет — этот тот, что скрам-мастер должен защищать команду от слишком требовательного Владельца продукта или стейкхолдеров. И это хороший совет.
Иногда Владельцы продукта «просят» слишком много, слишком часто и слишком требовательно. Это вынуждает команды ускоряться, чаще всего жертвуя качеством, что позже отразится на продукте. Поэтому хороший скрам-мастер защищает команду от этого.

Однако, вы не часто услышите, что хороший скрам-мастер также должен защищать команду от самодовольства.
Хорошие agile-команды постоянно самосовершенствуются. Другие команды останавливаются в развитии, скорее всего бессознательно, думая что они достаточно развились. И возможно они были значительно быстрее и лучше уже до того как услышали об agile. Но даже великие команды часто становятся намного лучше.
Великие скрам-мастера защищают команды от ощущения, что им больше нечему учиться.

7. Запрети себе использовать слово «провал»

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

8. Хвали чаще, но всегда искренне

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

9. Поощряй команду, если она начала делать твою работу

Команда, для которой agile в новинку, будет в значительной степени полагаться на своего скрам-мастера или agile-коуча. Такая команда может не знать как уложиться в 15 минут на ежедневном скрам митинге (прим. ежедневном стэндапе). Или она может не понимать важности параллельной работы или необходимости быть кросс-функциональной.

То же самое справедливо в отношении неопытной спортивной команды. Тренер маленьких детей, которые учатся играть в футбол, обязан научить их всему. Когда тренируются маленькие дети, их тренер бегает вдоль боковой линии всю игру, крича: “Бей и беги!». Если бы он этого не делал, маленькие игроки могли забыть об этом. Даже когда он так кричит, время от времени какой-нибудь ребенок просто садится на траву и глазеет вокруг.

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

Независимо от того, насколько хороша agile-команда, она получает пользу, от того, что у неё есть cкрам-мастер или agile-коуч. Однако, хорошие agile-команды сами берут на себя некоторые простые коучинговые задачи для освоения навыков, необходимых им в продуктовой разработке.

10. Молчи и слушай

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

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

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

Текст адаптирован с оригинальной статьи:  https://www.mountaingoatsoftware.com/blog/ten-sentences-with-all-the-scrum-master-advice-youll-ever-need