Обзор Спринта и Ретроспектива (кейс МТС Касса 10-я часть)

Обзоры Спринта

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

  • Владелец Продукта открыл встречу и громко зачитал Цели Спринта, над которыми работала продуктовая группа. Затем Владелец Продукта перечислил элементы, которые уже были выполнены.
  • Команды по очереди кратко рассказали о сложностях, с которыми им пришлось столкнуться во время Спринта, и о том, как им удалось (или не удалось) их преодолеть.
  • Гостей пригласили посетить станции. Событие было организовано в формате «базара» или ее более структурированном варианте «выставка». На каждой станции у нас было по меньшей мере два разработчика. Один из них демонстрировал Инкремент и просил дать отзывы о нем, а другой просто все записывал.
  • После демонстрации мы вернулись к формату открытого обсуждения. Владелец Продукта рассказал о новостях рынка, изменил приоритеты элементов Бэклога Продукта и ответил на все вопросы.
  • Затем гости покинули помещение, а команды и Владелец Продукта собрали обратную связь по всем станциям и, когда это требовалось, обновили некоторые из артефактов — карту влияния (impact map), канвас ценностного предложения (value-proposition canvas), карту историй (story mapping) и, конечно, Бэклог Продукта.

Читать далее «Обзор Спринта и Ретроспектива (кейс МТС Касса 10-я часть)»

Почему создание «Центра Аджайл-компетенции» очень плохая идея

Перевод оригинальной статьи Энтони Мерсино “Why an Agile Center of Excellence is a Really Bad Idea”

Многие компании создают специальные подразделения для сопровождения Аджайл-трансформаций. Они получают разные названия. Два варианта, которые я считаю совершенно неудачными, это “Центр Аджайл-компетенции” и “Офис управления Аджайл-проектами”. Я считаю, что создание подобных подразделений вообще плохая идея. Объясню почему.

Среди целей создания таких подразделений часто указывается, что они призваны «способствовать гибкости организации». Звучит здорово, правда? Но на самом деле их деятельность, напротив, мешает гибкости. Часто “Центр Аджайл-компетенции” практически полностью фокусируется на стандартизации процессов и инструментов, а также на масштабировании и эффективности. Казалось бы, что не так?

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

Мультикомандное уточнение Бэклога Продукта

Перевод оригинальной статьи Сезарио Рамоса «Multi-team Backlog Refinement»

В этой небольшой статье я поделюсь с вами некоторыми советами по мультикомандному Уточнению Бэклога Продукта.

Что такое Уточнение Бэклога Продукта?

Уточнение Бэклога Продукта (Product Backlog Refinement, PBR) — это мероприятие, которое регулярно проводят Скрам-команды, чтобы прояснить и уточнить Элементы Бэклога Продукта (Product Backlog Items, PBI), которые предстоит взять в работу в следующих Спринтах. В однокомандном Скраме команда обычно проводит одну или несколько подобных встреч за Спринт. 

Ниже приведены примеры связанных с этим событием активностей:

  • Понимание того, какую проблему надо решить: Владелец Продукта рассказывает несколько последовательных историй и связывает их с текущими бизнес-целями. Команда обсуждает “почему мы это делаем?”, “как понять, что мы решаем нужную проблему?”. Некоторые команды используют карту историй (story mapping), карту влияния (impact mapping), игры «Speedboat», «Я и моя тень» и технику «5 почему». 
  • Разбивка больших элементов для более простого обсуждения и изучения.
  • Оценка элементов.
  • Понимание потребностей клиента: команда обсуждает“Почему пользователь хочет этого?”, “Правильно ли мы решаем его проблему?”. Некоторые команды используют доску историй (storyboard)  до и после, карты Pain Gain.
  • Прояснение элементов: Некоторые команды используют технику спецификации на примерах (Specification By Example) и создают приемочные тесты для пользовательских историй, используют описание историй с помощью спецификаций языка Gherkin, таблицы потоков и/или таблицы решений.
  • Определение планов исследовательского тестирования: Выявление рисков при достижении цели, выявление фич, которые требуют ручного тестирования. Некоторые команды используют план исследовательского тестирования (Exploratory Test Charter) для каждой фичи и проводят сессии исследовательского тестирования всей командой.
  • Создание первоначального дизайна: Моделирование на магнитной доске, прототипы дизайна…

Читать далее «Мультикомандное уточнение Бэклога Продукта»

6 причин, почему внедрение Канбана может оказаться неудачным

Перевод оригинальной статьи «6 Reasons You May Fail with Kanban Implementation«.

Внедрение Канбана в организации может показаться лёгким процессом, но на самом деле тут есть свои подводные камни. Если вы не уделите должного внимания деталям, внедрение может пойти не так. Читать далее «6 причин, почему внедрение Канбана может оказаться неудачным»

Почему фокус на Velocity убивает Agility

В этой статье я расскажу об опасной динамике, которая возникает в случае, когда Владелец Продукта, Скрам-мастер и/или менеджмент организации фокусируют Команду Разработки на Velocity.

О чем говорит Velocity.

Концепция Velocity означает:

Скорость, с которой Команда Разработки конвертирует элементы Бэклога Продукта в ГОТОВЫЙ К РЕЛИЗУ инкремент продукта.

Обратите особое внимание на выделенные слова. Velocity применима тогда, когда Команда Разработки может доставлять каждый Спринт готовый к релизу инкремент. В этом случае Done = DoD = releasable.

Но даже в этом случае Velocity не показывает:

  • Была ли решена проблема клиента.
  • Занимаемся ли мы самыми приоритетными проблемами клиента.
  • Объем поставленной ценности.
  • Степень удовлетворенности клиента.

Velocity лишь показывает, что команда была чем-то занята.

Является ли это достоверной оценкой успешности ваших продуктов и сервисов? Оценивают ли клиенты ваши продукта по тому, насколько были заняты сотрудники компании?

Если хотите, Velocity отражает объем “выработки” Команды Разработки. К сожалению, этого недостаточно для создания успешных продуктов и сервисов. Читать далее «Почему фокус на Velocity убивает Agility»

PBR в LeSS (кейс МТС Касса часть 9-я)

Уточнение Бэклога Продукта (PBR) в LeSS

В масштабируемом Скраме PBR становятся обязательным событием (а не активностью). Это происходит, потому что в крупных продуктовых группах PBI получаются очень большими и возникает необходимость в масштабном обучении и координации между командами. Появляется необходимость планировать минимальное количество встреч с клиентами и пользователями. В LeSS есть несколько вариантов проведения PBR (руководство «Типы Уточнений Бэклога Продукта»):

  • Общее Уточнение Бэклога Продукта с представителями команд, которое предполагает высокоуровневый анализ и видение, оценку и разбиение элементов (руководство «Общее Уточнение Бэклога Продукта»).
  • Мультикомандное Уточнение Бэклога Продукта. Несколько команд в одной комнате уточняют несколько PBI одновременно (предпочтительно) (руководство «Мультикомандное Уточнение Бэклога Продукта»).
  • Однокомандное Уточнение Бэклога Продукта. Проводится как в Скраме для одной команды.

Нет каких-либо особых правил по комбинированию PBR, однако LeSS рекомендует проводить мультикомандные PBR. Давайте остановимся на их подробнее. Читать далее «PBR в LeSS (кейс МТС Касса часть 9-я)»

Владелец Продукта, а не прокси

Перевод оригинальной статьи Кена Швабера «Product Owner, not proxies»

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

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

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

Я никоим образом не предполагал, что Владелец Продукта станет бизнес-аналитиком, отвечающим за разработку технических требований.

Читать далее «Владелец Продукта, а не прокси»

Как вырастить T-специалистов?

Перевод оригинальной статьи Джейсона Уипа “How to develop T-shaped people”.

Предположим, мы согласны с тем, что Т-специалисты — ценные сотрудникиЧто мы можем сделать, чтобы вырастить их в нашей команде?

Самое эффективное — это начать обучение на задачах из смежных процессов

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

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

Планирование в LeSS (кейс МТС Касса 8-я часть)

Первая часть Планирования Спринта

За час до Первой Части Планирования Спринта Владелец Продукта и двое бизнес-аналитиков вносили финальные изменения в Бэклог Продукта. Затем представители всех команд (обычно по два человека от команды) принимали участие в Первой части Планирования Спринта.

Агенда встречи. Мы обычно придерживались следующей агенды:

  • обновляем Бэклог Продукта (вернуть невыполненную работу в Бэклог Продукта и оцениваем объем оставшейся работы);
  • Владелец Продукта очередной раз кратко описывает основные моменты в Бэклоге Продукта и при необходимости поясняет отдельные детали элементов (это уже было на PBR);
  • повторно рассматриваем Критерии Готовности (DoD);
  • представители команд выбирают стикеры с PBI из верхней части столбца «Ready» и прикрепляют их на дорожки своих команд на доске;
  • находим возможности для совместной работы команд (зависимости) и визуализируем их на доске;
  • решаем, нужна ли мультикомандная Вторая часть Планирования Спринта (когда между командами есть зависимости);
  • определяем общую Цель Спринта для продуктовой группы и/или отдельные Цели Спринта для команд.

Читать далее «Планирование в LeSS (кейс МТС Касса 8-я часть)»

Скрам-мастер — перспективная профессия 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!