AgileDays-2011:Отчет Никитина В.В./Командный старт
Очень понравилось. Знаю, что некоторые наши, кто присутствовал, применяли уже у нас тут в деле.
e-mail: sergey@agilecoach.ru
Фотографии flipchart’а с мастер-класса: http://www.dropbox.com/gallery/3490871/4/Documentation/Conferences/AgileDays%20Msk%202011/Team%20startup?h=06ae92#/
Всё, что мы написали на тренинге, мы развешивали на стенах в зоне видимости, чтобы можно было в любой момент посмотерть + чтобы был виден объем проделанной нами работы.
Началось все с представления тренера |
Затем Сергей озвучил план мероприятия: |
Затем мы все вместе написали наши ожидания от мероприятия (мы говорили — он писал) |
Командный старт занимает ~1 день. Когда проводится и зачем: |
Почему необходимо проводить командный старт, даже если в команду добавился всего один человек: |
Есть исконный agile, как он описан в книжках. Назовем его «Сердце agile» (слева вверху).
Есть Первая команда, которая подкрутила его под себя, добавив командный опыт и ритуалы (справа вверху). Есть вторая команда, тоже подкрутившая его под себя, но в другом напрвлении (слева внизу). В итоге по компании получаются команды, у которых только в некоторых аспектах agile пересекается. Поэтому при переходе из одной команды в другую, происходит нестыковка в понимании agile, поэтому нужен командный старт. Это затратно, но дает большие плюсы в дальнейшем: команда будет работать продуктивнее. Повторили еще раз про 4 стадии развития команды: |
Новая команда формируется, проходя в этом процессе кульминацию (storming) и выходя на нормализацию процесса. После этого идет только совершенствование.
Если же хотя бы один человек добавился в команду — это уже новая команда, и она снова сваливается на стадию Forming. |
Что нужно, чтобы командный старт состоялся |
Основная структура командного старта: слева указаны соотношения по времени, которое надо отводить на каждый пункт (3:1:1:1:3).
Отдельно пункты разбираются ниже. |
Далее он говорил, что в его практике встречались случаи, когда просили улучшить ситуацию в одной команде, но оказывалось, что проблемы не только в ней, но во всем процессе, в который встроена команда, поэтому улучшение в команде незначительно повлияет на процесс в целом и будет мало заметно. Надо в этом случае улучшать процесс в целом.
Для этого используют value stream mapping. Рисуют процесс от старта до отгрузки продукта/версии/релиза и на всех переходах и узлах ставят время, которое он занимает. Потом анализируют. Утверждается, что менеджеры удивляются результатам. |
И далее вывод: локально оптимизировать нельзя
И откровение про PO. Он должен все делать с такой позиции: «Что я сегодня могу сделать, чтобы команде было лучше» (сравните с вашим подходом!) |
Итак, освежаем процесс: |
Знакомимся поближе |
Группа людей должна учиться думать как команда — должен появляться командный разум, не сосредоточенный в одной чьей-либо голове, а распределенный по команде.
Тогда команда будет сама думать о своих узких местах. Чтобы их определить, можно использовать матрицу компетенций. По строкам перечисляются участники команды, по столбцам все возможные компетенции, которые нужны в проекте. На пересечнии проставляется
Другие игры, помогающие сплочению команды и решению некоторых задач, описаны в книге «Innovation games» by Luke Hohmann |
Далее команда обсуждает предстоящую работу: |
После этого можно приступать к работе.
Нам же далее был предложен список игр, в которые можно поиграть и из которых нам надо выбрать две: |
Наш скрам
Каждому дается в распоряжение флипчарт и он должен нарисовать скрам (модель), такой, каким он его себе представляет. Потом обсуждение или рефликсирование. Преследуется все та же цель: общее понимание общего процесса.
Каждый по кругу спрашивает, начиная фразу словами «Мне интересно, как в скраме …». Ответы, обсуждения. Цель та же: общее понимание общего процесса.
Индекс-карточки: как ощущается самоорганизация. Это все, что было сказано.
Играется, если есть несколько наших формулировок чего-то, и нам трудно выбрать одну. Каждый пишет свою на отдельной бумажке. После этого все передвигаются по комнате в произвольных направлениях — перемешиваются, меняются карточками. После сигнала любые двое, находящиеся рядом, образуют пары. Они должны прочитать вдвоем обе карточки и совместно проставить на обратной стороне каждой из карточек баллы так, чтобы в сумме на обеих карточках было 7 баллов. Такая процедура проводится 5 раз. Нетрудно догадаться, что максимум, который может набрать карточка при такой процедуре, 35 баллов (правда, такого еще никогда не было — оно и понятно: если бы была очевидная формулировка-лидер, то и не пришлось бы проводить эту процедуру). Отсюда и название игры. Побеждает формулировка(формулировки), набравшая больше всего баллов. Однако рассматриваются также и отстающие на 1-2 балла. Из них берутся мысли (или не берутся), для дополнения основной формулировки.
Участвует 8 человек. Они берутся за руки и запутываются в «узел». Менеджер должен распутать, но не может. А команда сама легко и быстро распутывается. Играется, чтобы убедить менеджера, что команда и сама способна на многое, а менеджер иногда очень даже мешает.
Рисуется стол — витрина. На витрине рисуются навыки и интересы, которые могут пригодиться в проекте — то, что человек предлагает как вклад в команду. Под витриной рисуются навыки и интересы, которые не нужны в проекте, но которыми человек готов поделиться. Пример Сергей нарисовал сам про себя: |
Над столом все читаемо, под столом: семья, есть ребенок, дайвер, из спорта любит сноуборд, футбол, лыжи, байкер.
Каждый рисует свой жизненный путь от начала до текущего момента, как взлеты, так и падения.
Каждый пишет про себя стикеры двух цветов: на одних то, что 100 % не он — на других то, что 100 % он. Плюс на тот момент уже нарисованы портреты членов команды (это игра, когда каждый дорисовывает в портрет рисуемого члена команды свою деталь: команда ходит по кругу и каждому дается по 3 секунды на дорисовывание). Далее эти бумажки развешивают общими силами/обсуждением на портреты.
|
По окончании написали плюсы, которые дал нам этот мастер класс: |
По окончании написали «дельта»-плюсы: что может сделать Сергей, чтобы следующий мастер-класс прошел лучше этого: |
Далее были ответы на вопросы, одним из которых был: что делать, если в команде есть эксперт, который очень влияет на решения команды и вносит дисбалланс. Ответ был такой: |
PO — это король. В его ведении находится вопрос «ЧТО делать», а в ведении команды находится вопрос «КАК делать». Этого самого эксперта, который давлеет над командой, надо выводить на уровень PO, чтобы он не мешал команде. Его место именно там. Пусть PO советуется с ним и спускает уже готовое решение, чтобы у команды не складывалось впечатление, что их мнение игнорируется. Надо отметить, что в этой ситуации страдает не только команда, но сам этот эксперт, поэтому это решение в корне меняет настроения в коллективе.
|