LeSS в MTC Кассе 7-я часть (первый Спринт, визуализация, координация)

Первый Спринт

Как говорят, «первый блин комом». Это относилось и к первому Спринту. Несмотря на всю подготовку и тренинги, команды лицом к лицу столкнулись со сложностями локальной оптимизации. Ранее в компании не было ориентированного на клиентов Бэклога Продукта. Теперь же порядок в Бэклоге Продукта определялся, главным образом, важностью фич для клиента.

Изучив Бэклог Продукта, дизайнеры и разработчики Android увидели, что в первом Спринте для них мало работы. Поэтому в ходе Спринта они много времени занимались обучением и помогали другим. Это обычная ситуация: первый Спринт выявляет так называемый «долг знаний», который всегда скрыто присутствует в функциональных подразделениях. Особенно это касается масштабных внедрений, когда речь идёт о крупных подразделениях — и крупных «долгах знаний». Этот новый «организационный перенос навыков» (если использовать формулировки из первой статьи о Скраме в Harvard Business Review за 1986 год) был очень непривычен участникам группы. Люди не понимали, почему нужно учиться вместо того, чтобы «делать что-то полезное».

Мы обнаружили несколько проблем, которые не учли во время запуска. Например, как справляться со срочными задачами и багами, поступающими от группы технической поддержки. Также мы не учли заранее, как будем проводить регрессионное тестирование. К сожалению, налицо был большой технический долг, а доля автоматического тестирования была мала. Читать далее «LeSS в MTC Кассе 7-я часть (первый Спринт, визуализация, координация)»

Скрам — это легко! Просто используйте его, как есть!

Перевод оригинальной статьи Кена Швабера “Scrum is simple, use it as it is!”

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

  1. Малые, самоорганизующиеся и самоуправляемые команды;
  2. Принципы Lean;
  3. Эмпирический подход, проведение частых инспекций и адаптаций, чтобы направлять работу команд к наилучшему из возможных результатов.

Руководство по Скраму — это свод знаний, который однозначно определяет, что такое Скрам (а также, разумеется, чем Скрам не является). Руководство по Скраму не указывает вам, как использовать Скрам, как внедрять Скрам или как разрабатывать продукты по Скраму.

Люди изучали Скрам и учились его использовать, посещая курсы и конференции, читая книги и блоги и т. п., но в первую очередь — создавая полезные вещи на основе видений, концепций и желаний, опираясь на свое понимание Скрама. И по мере того, как они продвигались, Скрам приобретал смысл. Скрам помог им достичь результатов, но… Когда люди стали пытаться применять Скрам, они поняли, что сложность заключается в том, чтобы получить разделяемое всеми понимание того, какой желаемый результат, какие у них возможности, что их умения позволят создать, а также как работать вместе, чтобы всего этого достичь. Читать далее «Скрам — это легко! Просто используйте его, как есть!»

LeSS в MTC Кассе 6-я часть (Initial PBR)

Initial PBR

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

Попробуйте воркшоп по разбиению задач

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

Я раздал листы с шаблонами и примерами разбиения элементов (эксперимент «Попробуйте разбить на части элементы Бэклога Продукта). Затем я установил таймер на 10 минут и попросил участников изучить их. Самый эффективный способ усвоить материал — это объяснить его другим людям. Поэтому через 10 минут я попросил участников объединиться в пары и в течение следующих 10 минут объяснить друг другу прочитанное. Затем Владелец Продукта выбрал крупный элемент из Бэклога Продукта. Люди разделились на небольшие смешанные группы и начали разбивать этот элемент на части.

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

Попробуйте оценочную и корреляционную сетку.

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

Фасилитация первого мультикомандного Уточнения Бэклога Продукта (PBR). Ранее команды по внедрению LeSS получали спецификации от выделенной аналитической группы. Теперь они должны были самостоятельно уточнять детали по каждому элементу. Мы пригласили в комнату экспертов в предметных областях. Команды разбились на четыре смешанные группы и начали работу на станциях, каждая у своей стены. На каждой станции эксперт помогал участникам прояснить детали PBI. Через 25 минут все переместились по часовой стрелке на следующую станцию (кроме экспертов). На каждом флипчарте уже были заметки, диаграммы и объяснения, оставленные предыдущей группой, что очень помогло вникнуть в тему. Так командам понадобилось чуть больше часа, чтобы прояснить три PBI. После перерыва мы ещё раз повторили процесс.

LeSS в МТС Кассе 5-я часть (выборы Скрам-мастеров и запуск сообществ)

Выбор Скрам-мастеров

Скрам-мастер в LeSS — это выделенная роль на полный рабочий день, предполагающая работу с 1–3 командами. Мы хотели нанять опытного Скрам-мастера до того, как изменим организационную структуру. К сожалению, у нас не получилось. Поэтому я в итоге решил стать вторым Скрам-мастером, пока мы не найдем замену.

Путём голосований и обсуждений команды выбирали Скрам-мастера, с которым хотели работать. Мы ускорили этот процесс, предложив им составить списки того, что они ожидали от Скрам-мастера. В них попали некоторые интересные моменты. Например: команда может выдать Скрам-мастеру «чёрную метку», и он не должен обижаться, если команда его уволит.

Запуск сообществ

Перед первым Спринтом мы предложили командам сформировать сообщества. Мы организовали встречу в формате Открытого Пространства. Любой, кто хотел основать сообщество, должен был выйти в центр комнаты и громко об этом заявить, а затем написать название сообщества на стикере и приклеить его на флипчарт. Так менее чем за полчаса было создано 14 сообществ.

Некоторые из них начали работу уже через несколько дней, остальные — в ходе первых двух Спринтов. Мы убедились, что Скрам-мастер помог им определить:

  • цель сообщества;
  • рабочие договорённости.

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

Иллюзия гибкости (судьба большинства аджайл-трансформаций)

Перевод оригинальной статьи Гюнтера Верхеена Illusion of Agility

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

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

Никакая схема не может описать или изобразить уникальные характеристики, определяющие гибкость организации. Читать далее «Иллюзия гибкости (судьба большинства аджайл-трансформаций)»

Модель коммуникации определяет продуктивность команды

Наука или искусство

Кто-то считает, что создание высокопроизводительных команд — это искусство, а не наука. Но исследование, проведенное лабораторией динамики человеческой деятельности MIT, выявило конкретные факторы, которые характеризуют высокоэффективные команды.

Паттерны коммуникации успешных команд

В статье The New Science of Building Great Teams профессор Сэнди Пентлэнд пишет, какие паттерны коммуникации и поведения определяют успешные команды:

  1. Все говорят и слушают примерно в равной мере.
  2. Общение происходит лицом к лицу и достаточно энергично.
  3. Люди общаются напрямую, не через лидера или руководителя команды.
  4. Участники команды периодически покидают группу, отправляясь на поиски информации, а затем приносят и делают доступной для каждого в команде.

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

Исследование очень сильно перекликается с многолетним исследованием Эми Эдмондсон о психологической безопасности, которое легло в основу проекта Аристотель (исследование в компании Google). Мне кажется, что психологическая безопасность является основополагающим фактором, который “открывает” людей и затем дает возможность раскрыться команде с помощью эффективных паттернов коммуникации.

Как это может изменить вашу работу как Скрам-мастера и агента изменений? 🙂

Скрам и шахматы

Перевод известной статьи Кена Швабера, в которой он представил метафору шахмат, а также термин СкрамНО или Скрам-бат.

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

Я задумался. Не помню, чтобы я такое говорил. Вероятно, это неправильно истолкованная фраза, что только 30 % всех команд и организаций, использующих Скрам, станут отличными организациями-разработчиками. Вот такое помню. Читать далее «Скрам и шахматы»

Психологическая безопасность и командная эффективность

Проект Аристотель

В 2012 в Google был запущен проект Аристотель, главной целью которого был поиск критериев, определяющих эффективность командной работы. Поворотным моментом для исследователей стало знакомство с работами Эми Эдмондсон, профессором Гарвардской бизнес школы. Эми более 20-ти лет исследовала концепцию психологической безопасности. Команда проекта пришла к выводу, что ключевой фактор, влияющий на эффективность команды — степень психологической безопасности.

 

Межличностный риск

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

LeSS в МТС Кассе 5-я часть (от Lean Coffee до DoD)

Попробуйте организовать Lean Coffee!

На ранних стадиях внедрения уровень неуверенности и подавленности может зашкаливать. Все модели управления изменениями подчеркивают ценность коммуникаций, а формат Lean Coffee — прекрасный способ организовать наиболее эффективное общение. При этом можно вести открытый диалог и устранять «слепые пятна». Я разослал всем приглашения на сессию Lean Coffee по электронной почте и подумал: «А что, если никто не придёт? Это будет полный провал». К счастью, народ собрался, и у нас получилась замечательная дискуссия. После тренинга оставалось много вопросов, и на встрече в формате Lean Coffee все смогли получить на них ответы. Я использую такой формат встреч уже давно, и опыт подсказывает мне, что количество посетителей обычно отражает уровень интереса в группе к определённой теме.

Выбор Владельца Продукта

Кандидатурой на роль Владельца Продукта, естественно, оказался Технический директор, так как он один из основателей компании и знает рынок, бизнес и клиентов лучше, чем кто-либо ещё. Выбор был настолько очевиден, что я не ожидал никаких подвохов, однако они появились через несколько месяцев. Читать далее «LeSS в МТС Кассе 5-я часть (от Lean Coffee до DoD)»

LeSS в МТС Кассе 4-я часть (обучение LeSS)

Дальнейшие шаги по внедрению LeSS

Летом 2017 года я посетил в Милане мастер-класс Крэга Лармана по LeSS. Одна из самых запомнившихся рекомендаций звучала так: «Думай как политик, а не как инженер». Хотя Владелец Продукта подталкивал меня внедрить LeSS как можно быстрее, совет Крэга помог мне притормозить внедрение. После успеха пилотной фиче-команды я увидел, что уровень доверия со стороны менеджмента вырос. К тому времени мы получили полную поддержку от руководства компании. Круто! С другой стороны, я понял, что многие разработчики из компонентных команд скептически относились к идее LeSS. Мы решили обучить их, чтобы перемены в компании были добровольными, а не вынужденными (руководство «Три принципа внедрения»).

Бэклог трансформации

В группу по трансформации компании вошли Владелец Продукта, несколько добровольцев из группы производства, Скрам-мастер пилотного проекта и я сам. Вот как выглядели некоторые задачи:

  • провести сертифицированный тренинг по основам LeSS (Certified LeSS Basics, CLB);
  • провести несколько семинаров в формате Lean Coffee для ответов на частые вопросы по LeSS;
  • создать первоначальный Бэклог Продукта;
  • создать HitMap;
  • организовать мастер-класс по самостоятельному формированию команд;
  • сформулировать цель для совершенствования;
  • выбрать Скрам-мастеров в командах;
  • разработать Критерии Готовности (DoD);
  • запустить работу сообществ и найти компонентных менторов;
  • провести первоначальное Уточнение Бэклога Продукта (PBR).

Если вспомнить, то мы потратили полтора месяца, чтобы подготовить изменения и создать подходящую для внедрения LeSS организационную структуру. Читать далее «LeSS в МТС Кассе 4-я часть (обучение LeSS)»