Практика Scrum: как создать бэклог продукта

Итак, у нас есть классная идея для нового продукта, мы знаем наших будущих пользователей и их потребности, которые закроет наш продукт. Можно приступать к работе😉

Но прежде чем Scrum-команда начнет работу в первом спринте, предстоит создать бэклог продукта. Записали для вас пошаговый алгоритм:
https://onagile.ru/trends/lean-startup/how-to-create-product-backlog

А с какими сложностями вы сталкивались при создании бэклога?

Интересно, как дискуссия иногда обнаруживает ловушки мышления🙂 Например, идея для новой фичи или нового продукта кажется нам абсолютно логичной. Мы готовы всячески обосновать ее полезность для пользователей, и руки так и чешутся приступить к реализации. Но стоит начать проверять гипотезу и вдохновленному владельцу продукта открывается много интересного😏

У продуктологов для таких идей есть ёмкий термин — галлюцинации. Потому что все гипотезы, какими бы стройными они не казались, важно сверять с реальными пользователями. Это поможет избежать ошибок в видении продукта и расходов на то, что в итоге не принесет ценности.
#AgileProductManagement

Может ли скрам-мастер быть частью команды?

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

Скрам-мастер (SM) фокусируется:
🔹на команде: фасилитирует встречи, помогает конструктивно решать конфликты и вырабатывать командные договоренности.
🔹на Владельце продукта: помогает ему в работе с бэклогом продукта и в общении со стейкхолдерами и командой.
🔹на организации в целом: выявляет системные проблемы и становится инициатором необходимых изменений, которые помогают скрам-командам работать эффективнее в компании.

Это большой объем работы, который сложно совмещать с другой деятельностью без ущерба качеству. О чем еще важно знать, выбирая SM, поговорим в следующий раз.
#scrum

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

Senior’ы и менеджеры обычно сами выбирают Скрам-мастера из числа сотрудников. А между тем важно учитывать желание выбранного кандидата. В этом вопросе лучше вообще уйти от директивного стиля принятия решений к более Agile стилю: прислушаться к людям, дать возможность развиваться в том, что им интересно.

Возможно, желающие стать Скрам-мастером найдутся за пределами команды. Можно подключить HR и устроить «ярмарку вакансий» внутри компании. Или воспользоваться схемой с голосованием стикерами ⬆️

По нашему опыту, SM, у которого горят глаза, будет активно развиваться в новой роли и станет проводником Scrum в компании. С большей вероятностью такие ребята будут проактивными и покажут собственным примером целевую модель взаимодействия в команде: взятие ответственности за общий результат, взаимопомощь и тд.
#scrum

Как сделать по-настоящему классный продукт, который будет пользоваться успехом? Ответов на этот вопрос почти столько же, сколько книг по маркетингу🙂

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

Подробнее об этом рассказываем в блоге➡️ https://onagile.ru/trends/lean-startup/jobs-to-be-done

#productmanagement

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

Представьте, что вам нужно прямо сейчас посадить за руль своей машины другого человека (а для этого он должен быть вписан в полис ОСАГО).

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

А что, если такой сервис встроить в путь клиента (customer journey)?

Путь «АльфаСтрахования»: сели в авто, зашли в приложение, внесли данные второго водителя — через секунду на email пришел обновленный полис. 2-3 минуты, и можно спокойно ехать.

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

#productmanagement

Расписание программ обучения на октябрь — декабрь, созданных в партнерстве с International Consortium for Agile.

Мы разработали полный курс обучения, состоящий из трех уровней погружения в Agile, Scrum и Kanban.

От понимания, как работает Agile и что нужно сделать для внедрения Scrum в команде, до детального изучения подходов к созданию востребованных продуктов.

👨‍🎓 Международный сертификат от консорциума ICAgile каждому участнику.

Посмотреть программу и зарегистрироваться можно здесь
➡️ www.onagile.ru/trainings

Очень интересная статья с кучей примеров от Dodopizza про их путь к проведению полезных Sprint Review (обзоры спринтов)

https://habr.com/ru/company/dodopizzaio/blog/452202/

Следует ли менять лимит на количество одновременно выполняемой работы (Work in Progress Limit)? #практика_Канбан

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

Да, если мы говорим об изменениях с течением времени. Установление ограничения WIP — часть процесса постоянного улучшения, и значение лимита нужно пересматривать, если параметры Канбан-системы изменились: например, поменялась численность команды, устранено очередное узкое место в системе или изменилась структура запросов на входе в систему.

Нет, если речь о сиюминутном увеличении лимита ради добавления в систему нового элемента (задачи, проекта) с высоким приоритетом, который, как это часто бывает, появился неожиданно, и требуется взять его в работу «прямо сейчас, а лучше вчера».

В этом случае увеличение WIP лимита просто замаскирует проблему, тогда как гораздо полезнее разобраться 1) почему новый элемент появился сверх ограничения 2) в причинах возникновения узкого места — и попытаться решить эти проблемы.

Это одно из преимуществ применения лимита — он ​​выявляет недостатки и ранее скрытые слабые места в системе (процессе).

Что делать, если появилась срочная задача с высоким приоритетом?

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

Подробно разбираем Канбан метод и практики выстраивания Канбан-систем в различных сферах бизнеса на нашем тренинге Kanban Method Professional.
Ближайший пройдет в Москве 21-22 ноября, приходите: https://onagile.ru/trainings/kanban-method-professional

Как декомпозировать продукт и элементы бэклога

Сделать все и сразу — обычный запрос от клиентов и заказчиков. Но как бы мы ни старались, «все и сразу» сделать невозможно. Зато можно ускорить поставку результата, если выделить из общей идеи главное и сфокусироваться на реализации этой части. А остальное несколько отложить.

Понимание, что нужно сделать прямо сейчас, дает декомпозиция. Существуют два уровня: уровень самого продукта (MVP, MLP) и уровень элементов бэклога — требования/функции/задачи (MMF).

О ключевых паттернах декомпозиции читайте в новом посте ➡️ https://onagile.ru/trends/lean-startup/backlog-decomposition

Из серии «нельзя не поделиться» 🙂

Яндекс выпустил большой бесплатный видео-курс «Школа менеджмента», я думаю, многие смогут найти в нем полезную для себя тему.

https://www.youtube.com/playlist?list=PLEs8EuAPI73Bj78n7-BIW3s1we0r15yJl

Одна из самых интересных возможностей, которая открывается перед организацией при «переходе на Agile» — это полное преобразование организационной структуры.

Было: функциональные колодцы (маркетинг, логистика, ИТ, производство, продажи, юристы), образующие иерархию и вовлекающие компанию в сложные взаимодействия между подразделениями, согласования, KPI и долгую реализацию проектов/инициатив.

Стало: новая структура, ориентированная на клиента (обслуживаемые компанией сегменты рынка) и создаваемые продукты или сервисы.

Департамент, или как часто называют «трайб», — сегмент или продуктовое направление, состоящее из набора кросс-функциональных продуктовых и сервисных команд с end-to-end ответственностью за результат.

В качестве примера на слайде фрагмент роадмапа движения в Agile, который мы делали для одного из банков Восточной Европы.

Распространенные ошибки работы с новой Agile (Scrum) командой

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

Разбираем типичные ошибки во взаимодействии с командой, которые существенно замедляют процесс изменений в компании. ➡️ https://onagile.ru/trends/leadership/mistakes-working-with-new-agile-team

#Agile_лидерство

Agile для HR, или Когда бонусы перестают работать

С началом Agile-трансформации компании приходят к переосмыслению корпоративной культуры и практик работы с людьми. То, что работает в классическом подходе с вертикальным управлением — например, система поощрений — для Agile-команд может работать не так или не работать вообще.

Agile для HR — большая тема, и мы еще будем подробно говорить о ней.
А чтобы основные тезисы всегда были под рукой, мы перевели для вас классный плакат.

Скачать в высоком разрешении➡️  https://onagile.ru/tools

#Agile_для_HR

#Agile_для_HR

В Agile-среде HR-сервис оказывается перед двумя параллельными задачами: перестроить собственный рабочий процесс и по-новому выстроить взаимодействие с сотрудниками компании — пересмотреть стратегии развития персонала, систему поощрений, критерии найма и тд.

Лучшие результаты от применения инструментов и практик получают те, кто уделил внимание пониманию сути подхода. Разобраться в этом помогает Agile-манифест и сформулированные на его основе принципы работы. Подробнее о них и вещах, о которых важно помнить при работе над HR-проектами: https://onagile.ru/trends/talents/agile-for-hr

Когда нужен Agile?

Пожалуй, лучшая статья о Киневин фреймворке за все 5 лет существования информации о нем на русском языке.

Возможно, поводом для описания послужил недавно пройденный тренинг, но описано очень кратко и емко - рекомендую! И иллюстрация отличная.

http://blog.liruoko.ru/ru/2019-06/cynefin/

P.S. Ответ на вопрос из заголовка как раз по ссылке.

Когда-то Звездную Карту использовали для формирования и развития scrum команд в разработке ПО, а теперь это полноценный инструмент HR.

Подробное описание с примерами из private banking.

https://onagile.ru/trends/talents/agile-for-hr-stars-map

А вы знали, что в Scrum нет такого инструмента, как доска задач?

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

Но доска задач - это же фундаментальный инструмент выстраивания работы любой команды!

https://www.scrumguides.org/scrum-guide.html

Сервисные команды могут получить от применения Agile-подхода такой же мощный эффект, как и продуктовые. Про вторые просто говорят больше)

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

Здесь и пригождается Agile — с проблемой пиковой нагрузки хорошо справится заранее собранная кросс-функциональная команда, которая отвечает за подготовку к пиковому сезону, а в процессе будет координировать ситуацию. В состав, как правило, входят представители всех подразделений/ этапов сервиса: продукт-менеджер, специалист сервиса поддержки, представитель фулфилмент-оператора, ИТ, маркетолог и тд.

https://onagile.ru/industries/retail/customer-service-new-year-challenge

Вот буквально вчера видел, как ребята выделили из общей задачи MVP и это было слово «department». Вроде инструмент правильный использовали, и скрамом это называли, а итоговый результат получился далеко не идеальный. Надеюсь, у вас такого не бывает:)