Скрам-мастер — перспективная профессия 2019 года по версии LinkedIn

Компания Scrum.org совместно с Agile of Product опубликовали исследование о Скрам-мастерах, проведенное в 2018 году. В опросе приняли участие более 2500 участников. Полную версию отчета можно скачать по ссылке.

Ниже вы найдете самые интересные, с нашей точки зрения, детали отчета.

  • LinkedIn включил Скрам-мастера в список наиболее перспективных профессий 2019 года. Подробнее об этом можно почитать в статье «LinkedIn most promising jobs 2019»
  • Возраст половины из опрошенных Скрам-мастеров от 30 до 39 лет.
  • 71% Скрам-мастеров — мужчины.
  • 26% Скрам-мастеров работают в компаниях размером более 10000 человек, 18% до 10000, 16% до 1000, 11% до 250.
  • 58% респондентов сказали, что в данных момент их компания находится в процессе трансформации.
  • SAFe, LeSS, Nexus самые популярные фреймворки, которые используются компаниями для масштабирования (23%, 9%, 11% соответственно).
  • 78% Скрам-мастеров имеют опыт работы менее 5 лет, 35% менее двух.
  • 39% Скрам-мастеров имеют официальный титул «Скрам-мастер», 15% «Agile Coach».
  • 31% Скрам-мастеров бывшие менеджеры проектов,  25% разработчики, 9% бизнес-аналитики, 8% QA.
  • 81% команд используют Kanban вместе со Скрамом, 55% DevOps, 34% TDD.
  • Топ-3 сертификации для Скрам-мастеров Professional Scrum Master (PSMI), Certified Scrum Master (CSM), Professional Scrum Product Owner (PSPOI).

Надеюсь эта информация будет полезной для вас!

Scrum ON!

 

 

Почему T-специалисты?

Перевод оригинальной статьи Джейсона Йипа “Why T-spaped people”.

Т-специалист разбирается во многих областях и как минимум в одной является экспертом.

В противовес узкому специалисту («I-shaped») и специалисту широкого профиля (который «умеет всё, да по чуть-чуть»), T-специалист («T-shaped») является экспертом по меньшей мере в одной области, но при этом разбирается во многих других. Таких T-специалистов еще называют «generalizing specialist».

«I-shaped» vs Специалист широкого профиля vs «T-shaped»

Т-специалист адаптируется к различным требованиям

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

Как LeSS фундаментально решает организационные проблемы

Короткая статья текста по следам презентации, которую я показывал на последнем митапе, посвященному LeSS.

Презентацию в формате PDF можно скачать по ссылке.

Быстрые и фундаментальные решения

Часто спрашивают «почему именно LeSS, а не другой фреймворк для масштабирования?» Один из аргументов — LeSS дает системные фундаментальные решения. Считаю важным предлагать организациям и их руководителям не симптоматическое лечение, которое лишь на время приносит облегчение, чтобы затем вернуться с еще большими побочными эффектами, а фундаментальные решения организационных вопросов. Давайте капнем глубже.

Читать далее «Как LeSS фундаментально решает организационные проблемы»

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 % всех команд и организаций, использующих Скрам, станут отличными организациями-разработчиками. Вот такое помню. Читать далее «Скрам и шахматы»