Командный старт (Сергей Дмитриев, AgileDays-2011)

Материал из CustisWiki

Версия от 15:08, 3 июня 2011; StasFomin (обсуждение | вклад)

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

Аннотация

Докладчик
http://2011.agiledays.ru/members/profile/568/ Сергей Дмитриев

Мастер-класс.

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

Структура мастер-класса:

  • Рассмотрим поближе наш гибкий процесс (scrum, kanban, и тп).
  • Сравним «твой аджайл» и «мой аджайл».
  • Познакомимся друг с другом поближе, мы же команда (навыки, компетенция, способности, личные пожелания и ценности).
  • Создаем совместное видение (что в этом для меня лично, что в этом для нас, как команды, что в этом для нас как компании, что в этом для мира?).
  • Изучим работу, что нам предстоит проделать, поближе (представим, рассмотрим бэклог).



Примечания и отзывы

Сергей Дмитриев

Фотографии флит-чартов с мастер-класса: http://www.dropbox.com/gallery/3490871/4/Documentation/Conferences/AgileDays%20Msk%202011/Team%20startup?h=06ae92

DmitvievTeamStart1.jpg
DmitrievTeamStart2.jpg
Какие бывают игры…

Это был мастер-класс посвященный такому процессу как «командный старт». Сергей под командным стартом понимает специально выделенное время, когда собирается вся команда вместе, а также люди имеющие отношение к проекту (типа Product Owner `a и руководства заинтересованного в результате), с целью познакомиться друг с другом и проектом в целом, а также определить общие ценности и видение проекта.

Сергей рекомендует для командного старта отвести один день. Командный старт необходимо проводить когда:

  1. Собирается новая команда для проекта
  2. В команду приходят новые члены
  3. Команда начинает новый проект
  4. При внедрении agile.

Проведение командного старта позволяет:

  1. Найти общую отправную точку
  2. Обозначить общие ценности команды
  3. Определить общее видение проекта
  4. Увеличить шансы на успех

Во время командного старта необходимо сделать:

  1. Понять по какому процессу сейчас работает команда, и определить каким образом команда хочет работать дальше
  2. Привести понятие agile к общему знаменателю у всех членов команды. Каждый под гибкой методологией разработки может понимать разные вещи и этот шаг необходим для того, чтобы все четко представляли какую методологию они собираются использовать
  3. Познакомиться друг с другом, узнать, кто и какими навыками обладает, какую пользу может принести проекту каждый участник команды и т. д.
  4. Создать общее видение проекта. Сергей рекомендует на этот шаг пригласить как можно более высокое лицо, которое заинтересовано в проекте. Идеально, если это будет генеральный директор компании, который расскажет, почему этот проект важен для компании и почему необходимо его успешное завершение.
  5. Ознакомиться с предстоящей работой.

Первый и пятый шаги должны занимать большую часть времени командного старта. Сергей придерживается концепции Брюса Такмана по развитию команды (Forming-Storming-Norming-Performing) и считает, что при изменении состава команда вновь оказывается в стадии Forming и из-за этого некоторые команды никогда не выходят на performing. Командный старт направлен именно на то, чтобы сократить стадии forming, storming, norming и выйти на performing. Это необходимо потому, что производительность хорошо сработанной команды может быть выше в несколько раз, чем просто у группы людей собравшихся для выполнения одной работы (по некоторым исследованиям прирост производительности составляет до 400 %).

В качестве инструмента для проведения командного старта докладчик рекомендует использовать игры (в выступлении были приведены в качестве примера, игры «35», «Мне интересно…», «спагетти» и т. д.). Игровая форма расслабляет людей и позволяет быть более открытыми и ускоряет процесс решения задач. Например, для знакомства членов команд друг с другом просить каждого рассказать о себе достаточно бесполезно, так как из рассказа вряд ли удаться понять какими навыками человек обладает и чем он увлекается. А при использовании игры типа «рынок навыков» это получиться сделать легко и непринужденно. Сергей также рекомендует в качестве пособия по играм обратиться к книге Innovation Games.

После мастер-класса была серия вопросов и ответов не всегда по теме, но достаточно интересных. Мне больше всего понравился вопрос про то, как команда должна принимать технические решения. Сергей считает, что команда должна принимать решения только единогласно и пока среди всех членов команды не будет достигнуто взаимопонимание, то должно продолжаться обсуждение. При этом уровень решений, которые принимает команда, должен быть ограничен итерацией. Решения, которые влияют на проект в целом, должны приниматься product owner`ор, причем возможно без учета мнения команды или вопреки ему. Более того команда для product owner`а не является единственным инструментов для выполнения проекта, у него также могут быть люди не входящие в команду, но при этом работающие на проекте. Например, таким человеком может быть системный архитектор, который также в своей работе может не принимать во внимание мнение команды, но при этом должен убедить product owner`а в правильности своего решения. Фактически PO и его люди отвечают на вопросы, что делать, а команда — как делать, причем именно в рамках итерации.

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

Докладчик
Сергей Дмитриев
Компания
AgileCoach.ru

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

Действо продолжалось чуть больше двух часов. Честно говоря, не понял, какое имеет отношение название мастер-класса «Командный старт» к рассказанному и показанному.

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

Вывод: малоинтересное мероприятие сомнительной ценности.

  • Командный старт (Сергей Дмитриев, AgileDays-2011)

Очень понравилось. Знаю, что некоторые наши, кто присутствовал, применяли уже у нас тут в деле.

e-mail: sergey@agilecoach.ru

Фотографии flipchart’а с мастер-класса: http://www.dropbox.com/gallery/3490871/4/Documentation/Conferences/AgileDays%20Msk%202011/Team%20startup?h=06ae92#/

Всё, что мы написали на тренинге, мы развешивали на стенах в зоне видимости, чтобы можно было в любой момент посмотерть + чтобы был виден объем проделанной нами работы.

Началось все с представления тренера
Дмитриев 03.jpg
Затем Сергей озвучил план мероприятия:
Дмитриев 04.jpg
Затем мы все вместе написали наши ожидания от мероприятия (мы говорили — он писал)
Дмитриев 01.jpg
Дмитриев 02.jpg
Командный старт занимает ~1 день. Когда проводится и зачем:
Дмитриев 05.jpg
Почему необходимо проводить командный старт, даже если в команду добавился всего один человек:
Дмитриев 11.jpg
Есть исконный agile, как он описан в книжках. Назовем его «Сердце agile» (слева вверху).

Есть Первая команда, которая подкрутила его под себя, добавив командный опыт и ритуалы (справа вверху).

Есть вторая команда, тоже подкрутившая его под себя, но в другом напрвлении (слева внизу).

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

Поэтому при переходе из одной команды в другую, происходит нестыковка в понимании agile, поэтому нужен командный старт.

Это затратно, но дает большие плюсы в дальнейшем: команда будет работать продуктивнее.

Повторили еще раз про 4 стадии развития команды:

Дмитриев 14.jpg
Новая команда формируется, проходя в этом процессе кульминацию (storming) и выходя на нормализацию процесса. После этого идет только совершенствование.

Если же хотя бы один человек добавился в команду — это уже новая команда, и она снова сваливается на стадию Forming.

Что нужно, чтобы командный старт состоялся
Дмитриев 06.jpg
Основная структура командного старта: слева указаны соотношения по времени, которое надо отводить на каждый пункт (3:1:1:1:3).

Отдельно пункты разбираются ниже.

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

Для этого используют value stream mapping. Рисуют процесс от старта до отгрузки продукта/версии/релиза и на всех переходах и узлах ставят время, которое он занимает. Потом анализируют. Утверждается, что менеджеры удивляются результатам.

Дмитриев 15.jpg
И далее вывод: локально оптимизировать нельзя

И откровение про PO. Он должен все делать с такой позиции: «Что я сегодня могу сделать, чтобы команде было лучше» (сравните с вашим подходом!)

Итак, освежаем процесс:
Дмитриев 08.jpg
Знакомимся поближе
Дмитриев 09.jpg
Группа людей должна учиться думать как команда — должен появляться командный разум, не сосредоточенный в одной чьей-либо голове, а распределенный по команде.

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

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

Другие игры, помогающие сплочению команды и решению некоторых задач, описаны в книге «Innovation games» by Luke Hohmann

Дмитриев 16.jpg
Далее команда обсуждает предстоящую работу:
Дмитриев 10.jpg
После этого можно приступать к работе.

Нам же далее был предложен список игр, в которые можно поиграть и из которых нам надо выбрать две:

Дмитриев 12.jpg
Наш скрам

Каждому дается в распоряжение флипчарт и он должен нарисовать скрам (модель), такой, каким он его себе представляет. Потом обсуждение или рефликсирование. Преследуется все та же цель: общее понимание общего процесса.


Мне интересно…

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


Что такое самоорганизация

Индекс-карточки: как ощущается самоорганизация. Это все, что было сказано.


35

Играется, если есть несколько наших формулировок чего-то, и нам трудно выбрать одну. Каждый пишет свою на отдельной бумажке. После этого все передвигаются по комнате в произвольных направлениях — перемешиваются, меняются карточками. После сигнала любые двое, находящиеся рядом, образуют пары. Они должны прочитать вдвоем обе карточки и совместно проставить на обратной стороне каждой из карточек баллы так, чтобы в сумме на обеих карточках было 7 баллов. Такая процедура проводится 5 раз. Нетрудно догадаться, что максимум, который может набрать карточка при такой процедуре, 35 баллов (правда, такого еще никогда не было — оно и понятно: если бы была очевидная формулировка-лидер, то и не пришлось бы проводить эту процедуру). Отсюда и название игры. Побеждает формулировка(формулировки), набравшая больше всего баллов. Однако рассматриваются также и отстающие на 1-2 балла. Из них берутся мысли (или не берутся), для дополнения основной формулировки.


Спагетти

Участвует 8 человек. Они берутся за руки и запутываются в «узел». Менеджер должен распутать, но не может. А команда сама легко и быстро распутывается. Играется, чтобы убедить менеджера, что команда и сама способна на многое, а менеджер иногда очень даже мешает.


Рынок навыков

Рисуется стол — витрина. На витрине рисуются навыки и интересы, которые могут пригодиться в проекте — то, что человек предлагает как вклад в команду. Под витриной рисуются навыки и интересы, которые не нужны в проекте, но которыми человек готов поделиться. Пример Сергей нарисовал сам про себя:

Дмитриев 13.jpg
Над столом все читаемо, под столом: семья, есть ребенок, дайвер, из спорта любит сноуборд, футбол, лыжи, байкер.


Жизненное путешествие

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


Угадай-ка

Каждый пишет про себя стикеры двух цветов: на одних то, что 100 % не он — на других то, что 100 % он. Плюс на тот момент уже нарисованы портреты членов команды (это игра, когда каждый дорисовывает в портрет рисуемого члена команды свою деталь: команда ходит по кругу и каждому дается по 3 секунды на дорисовывание). Далее эти бумажки развешивают общими силами/обсуждением на портреты.


Успели поиграть только в 35. Формулировали, зачем нужен командный старт. Вот победившие бумажки.

Дмитриев 23.jpg
Дмитриев 24.jpg
Дмитриев 25.jpg
Дмитриев 26.jpg
По окончании написали плюсы, которые дал нам этот мастер класс:
Дмитриев 27.jpg
По окончании написали «дельта»-плюсы: что может сделать Сергей, чтобы следующий мастер-класс прошел лучше этого:
Дмитриев 28.jpg
Далее были ответы на вопросы, одним из которых был: что делать, если в команде есть эксперт, который очень влияет на решения команды и вносит дисбалланс. Ответ был такой:
Дмитриев 17.jpg
PO — это король. В его ведении находится вопрос «ЧТО делать», а в ведении команды находится вопрос «КАК делать». Этого самого эксперта, который давлеет над командой, надо выводить на уровень PO, чтобы он не мешал команде. Его место именно там. Пусть PO советуется с ним и спускает уже готовое решение, чтобы у команды не складывалось впечатление, что их мнение игнорируется. Надо отметить, что в этой ситуации страдает не только команда, но сам этот эксперт, поэтому это решение в корне меняет настроения в коллективе.


Закончился мастер-класс далеко за 19:00, но эти два с лишним часа пролетели незаметно, все остались довольны, зарядились энергией, получили знания.

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

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

Заметки.

  • Тезис — вписывать хороший дизайн в agile очень сложно
  • Говорить о минусах — разбрасывать какашки. Надо говорить о том, как можно было сделать лучше.
  • Он нацелен на хорошую командность. Типа вывернуть грязное белье. Я: до конца не согласен. Хотя — попросить помощь и быть готовым — оно правильно — это из зала говорили про такой кейс.
  • Он говорит о гиперрезультативных командах. Прирост в разы, от 4 раз и более. (хотя Книберг 2.5 раза дает без этого). Правда такие команды год от года и не переформировывать.
  • Основное — познакомиться внутри. И познакомиться с целями фирмы, команды и прочее.


Призыв к зрителям!

Мы призываем всех зрителей видеозаписей докладов давать хоть какой-нибудь, желательно конструктивный feedback.

Где? — неважно. В блогах, в форумах, в комментах — пофиг, лишь бы можно было найти, например, поиском по блогам, по ключевому слову «AgileDays» (ну и/или по названию доклада).

Что-то побольше твиттер-вскрика, хотя бы пару абзацев. Да, иногда краткая характеристика бывает достаточной («маркетинговый булшит», «унылый самопиар» — обычно в адрес «спонсорских докладов»), но это очень, очень редко, а так хочется прочитать что-то большее, чем «сижу на XXX, говорят о YYY».

Что писать? Что хорошо, что плохо («плохо» неудачное слово, скажем, «неправильно на ваш взгляд»), как вы поняли то, что рассказано, как это спроецировалось конкретно на вас — все это фантастически важно и полезно:

  • Другим потенциальным зрителям (смотреть/не смотреть, «правильно ли я понял»).
  • И докладчикам:
    • «Правильно ли меня поняли»,
    • «Что я делал правильно, а что улучшить»
    • Даже критический отзыв лучше, чем никакого!
    • Плюс — это мотивация, это награда за немалый труд многие готовятся долго, раскрывают свой опыт, старательно делают слайды, репетируют выступление — и ради чего? двадцать минут театра перед парой десятков зритетелей и все?
  • Организаторам конференций (этой и других) — они внимательно следят за отзывами, и пытаются понять, кого имеет смысл звать («рубит фишку и жжет!»), а к кому отнестись скептически, и если брать, то, например, «прокачать в части выступлений» — мы, например, старались это делать, итеративно рецензировали слайды, рассылали подборку литературы о правильных слайдах и искусстве выступлений.
  • Безотносительно лично докладчиков — важно понять, исчерпала себя тема или для народа еще остаются откровениями то, что для более пресыщенных инфопотоками людей (а организаторы обычно такие) уже выглядит как «аццкий боян». Ну и вообще — что еще интересно, и что было бы интересно услышать-увидеть-пообщаться на тему о…
  • Ну и кстати, мне тоже важно — вообще имел ли смысл весь этот сыр-бор с сьемкой, видеомонтажем и обработкой и публикацией (это, вообще-то дорогая работа, расценки профессионалов в этой области весьма недетские, при том, что до этого уровня монтажа им, как правило очень далеко), или кроме участников конференции эти темы никому не интересны. Может есть какие-то косяки в видео? или предложения как сделать лучше? — связывайтесь со мной, возможно это можно будет исправить (или хотя бы вырезать). Это кстати относится и к докладчикам — если есть какие-то позорные неудачные моменты, или что-то не нравится — это можно убрать.


Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».


Репликация: База Знаний «Заказных Информ Систем» → «Командный старт (Сергей Дмитриев, AgileDays-2011)»