Возможно ли организовать эффективную работу распределенной команды, и на что при этом обратить внимание? Несколько полезных практик из нашего опыта➡
https://vc.ru/hr/77384-ofis-vs-udalennaya-rabota-v-agile-komande

Обратная связь внутри команды

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

Регулярная практика обратной связи с коллегами (peer feedback) помогает процессу постоянного улучшения. Вот несколько простых правил, которые помогут наладить фидбэк без лишнего стресса:

🔹 Базовые принципы обратной связи — обсуждение один на один, и только когда коллега готов ее услышать.
🔹Анонимная обратная связь — «часть нашей команды считает, что...» — работает хуже. Гораздо полезнее для всего рабочего процесса создать среду, в которой возможны открытые и честные отзывы.
🔹Контекст: обратная связь всегда относится к ситуации, а не к человеку. Описывая ситуацию со своей точки зрения, мы улучшаем взаимопонимание.
🔹Наблюдения вместо простого перечисления фактов. «Я заметил, что...»
🔹Чувства важны: описывая, как ситуация влияет на нас, мы даем понять, чем мотивирован фидбэк, и фокусируем разговор на важности изменений.
🔹Предложения: как можно улучшить ситуацию? как избежать повторения подобных сценариев? Даже если коллега не воспользуется ими буквально, это хорошая возможность еще раз сверить ориентиры.
🔹Диалог: обратная связь не должна превращаться в монолог, который неизбежно поставит одного члена команды выше другого. Важно узнать, как сам коллега видит ситуацию, с чем согласен, а с чем — нет.
🔹Для формулирования обратной связи можно воспользоваться акронимом OSCAR (observed, situation, consequence, alternative, resulting): «Я наблюдал.., особенно в этой ситуации…, возможные последствия… Я предлагаю следующую альтернативу… В результате...»

А в вашей команде принято делиться мнениями о работе друг друга? С какими сложностями при этом сталкивались?

Product owner и скрам-мастер: почему важно разделять эти роли

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

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

Product owner в это время должен развивать продукт, чтобы тот удовлетворял потребности потребителей и приносил прибыль компании. Он отвечает за видение продукта, за понимание потребностей клиентов, обеспечивает коммуникации между стейкхолдерами и командой и формирует бэклог, над которым будет работать команда.

По сути, product owner говорит команде, что нужно делать, но не навязывает свое видение, как этого добиться. А скрам-мастер помогает команде научиться работать максимально эффективно, постоянно улучшая процесс своей работы. И если обе этих роли соединить в одном человеке, мы вернемся к модели работы классического менеджера, и наши Agile и Scrum превратятся в просто наклеивание стикеров и постоянные встречи.

Анализ продуктов конкурентов

Когда product owner задумывается о развитии продукта и повышении его ценности для клиентов, сравнение обычно идет с тем, что предлагают конкуренты. И вот почему этого недостаточно:

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

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

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

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

❓ А какие неочевидные альтернативы есть у вашего продукта?

Управление проектами в Agile - наш новый сертификационный курс для руководителей проектных офисов и менеджеров проектов.

🔹Как совместить Agile с классическим управлением проектами?
🔹Как развивать продукт и планировать проект в гибридной среде
🔹Как взаимодействовать с Agile-командами в классическом проекте и как работать с подрядчиками в Agile-среде
🔹Как управлять стоимостью проектов и выстраивать проектную отчетность в Agile.

Тренинг подготовлен на базе Delivery Management Track и PMI Agile Practice guide и дает знания, необходимые для сдачи экзамена PMI Agile Certified Practitioner (PMI-ACP).

Приходите к нам за новыми знаниями и сертификатом от ICAgile (ICP-APM).

Москва, 24-25 сентября 2019.

Забронировать участие ➡️ https://onagile.ru/trainings/agile-project-management

Сколько новых идей для своего продукта вы получаете каждую неделю? Уверены, что немало.

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

Практика, которая помогает контролировать ситуацию, называется backlog refinement. Что это такое и как ей пользоваться ➡️ https://onagile.ru/trends/lean-startup/backlog-refinement

О роли менеджера в Agile

С приходом Agile в компанию менеджеры задаются вопросом, как изменится их роль в новых условиях. В самом Agile роль менеджера детально не рассматривается, поэтому стоит обратиться к более широкому понятию Business Agility, или Гибкость бизнеса. Оно охватывает все сферы управления организацией, в том числе дает понимание процесса эволюции менеджера в лидера.

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

Как создать такую среду — тема для отдельного большого разговора, и мы к нему непременно вернемся. А пока: Don’t manage people, manage system.

Скачать постер➡️ onagile.ru/tools

Практика 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