⚡️Ближайшие тренинги

1️⃣ Фундаментальный Certified Agile Professional — основной курс по гибким подходам, включающий Scrum и Kanban.
👉 28-30 июля, 6-8 сентября, 4-6 октября

2️⃣ Продвинутый курс для Скрам-мастеров и всех, кому важны развитие команды, командный коучинг и фасилитация.
👉 7-9 июля, 20-22 октября

3️⃣ Продвинутый курс для Владельцев продуктов Advanced Product Ownership — проектирование и развитие продукта, управление ожиданиями заказчиков, работа в agile-команде.
👉 25-27 августа, 24-26 ноября

4️⃣ Управление проектами и их эволюционирование в гибкой среде — Agile Project Management.
👉 22-24 сентября

5️⃣ Agile in HR — развитие HR-сервисов, мотивационной стратегии и организационной структуры с использованием agile-подходов.
👉15-17 сентября

Вас ждут:

- Разбор актуальных проблем, с которыми сталкиваются команды
- Реальные практические навыки от экспертов, проводящих agile-трансформации в топовых российских и международных компаниях.
- Адаптация программы тренинга с учетом ваших ожиданий
- Международный сертификат от консорциума ICAgile.

Тренинги проходят онлайн: в zoom и miro. Три дня по 4-4,5 часа.
Количество мест ограничено: мы работаем группами до 16 человек.

👉Бронируйте участие заранее

Матрица выбора подхода к проектному управлению

Как понять, какая форма проектного управления поможет достичь наилучших результатов в вашем случае? И классическое проектное управление по PMBook’у, и гибридные решения могут работать лучше Agile — все зависит от условий.

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

Остались вопросы? Будем рады обсудить в комментариях)

Эффективна ли передача роли Scrum-мастера по очереди каждому участнику команды?

Такой вопрос нам недавно задали на тренинге, и вообще вопросы о Скрам-мастере одни из самых часто задаваемых. Действительно, найм отдельного человека на эту роль — вариант скорее для больших компаний. Обычно такой Скрам-мастер сопровождает до 3 команд.

Но и передавать роль по очереди внутри команды не лучший вариант. Это приведет к тому, что нормального Скрам-мастера у команды в итоге вообще не будет.

Как и любой профессионал, Scrum-мастер должен развиваться, фокусироваться, у него должен быть долгосрочный план. Со «сменным» Скрам-мастером так не получится.

Хороший вариант — когда кто-то из участников команды разработки дополнительно берет на себя роль Скрам-мастера. Главное, не забыть соотвественно уменьшить объем его задач;) И не совмещать роли Скрам-мастера и Владельца продукта.

Вот, например, простая механика, помогающая выбрать Скрам-мастера внутри команды

Спасибо, что делитесь своими достижениями!🤩

Как оценить производительность новой команды?

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

На этот случай в SAFe есть отличная практика для оценки производительности команды:

- Например, команда работает в циклах двухнедельных спринтов: берем количество участников команды и умножаем на 8 — получаем ориентировочную производительность команды.
- Если спринт трехнедельный — умножаем на 13.
- Если у кого-то из команды предполагается отпуск или отгул, вычитаем по единице за каждый такой день.
- Затем выбираем из бэклога небольшой элемент, работа над которым по нашим оценкам займет 1 рабочий день (с учетом тестирования). Будем считать этот элемент “единицей”.
- Оцениваем все остальные элементы бэклога относительно этой “единицы”.

Например, у нас есть команда из 7 человек (не включая Владельца продукта), которая будет работать 2-недельными спринтами, отпусков и отгулов в первом спринте не планируется. Получаем 7 х 8 = 56. Если кто-то из членов команды совмещает свою роль с ролью Scrum-Mastera, можно еще немного уменьшить общую производительность.

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

А отслеживать статистику команды помогает Burndown Chart. На первых этапах он очень полезен для прогресса команды, но и развитым командам рекомендуем не забывать про него и отслеживать динамику своих показателей;)

Друзья, привет! Внезапно освободилось 1 место на завтрашнем тренинге Agile Project Management.

Отличный шанс детально разобраться в особенностях управления проектами в Agile и гибридной среде и получить сертификацию ICAgile. По этому случаю сделаем приятную скидку;)

Тренинг будет проходить 22-24 сентября, с 9.00 до 13.00 (мск). Чтобы забронировать место, напишите на почту olga@onagile.ru

Как учитывать User Story, которую не успели доделать за спринт?

Стоит ли изменить ее оценку перед возвращением в бэклог, ведь часть работы мы уже сделали?

Не нужно: оценка остается такой же. В текущем спринте будет падение Velocity (потому что, если задача не сделана до конца и не соответствует Критериям готовности, мы не можем засчитать ее сторипойнты). Но в следующем спринте мы снова возьмем в работу эту задачу, доделаем, и в итоге к спринту добавятся все те сторипойнты, которые были заложены в задаче.

На показатели производительности команды это не повлияет, потому что для их оценки используется среднее значение по спринтам, которое нивелирует эти скачки.

Когда стоит выполнить переоценку User Story?

В прошлый раз мы обсуждали сценарий, когда команда не успевает завершить за спринт историю и не засчитывает в свою velocity баллы за выполненную ее часть. Обычно мы рекомендуем использовать именно этот подход, но есть исключения. О ситуациях, когда переоценка полезна, отлично пишет Майк Кон в книге «Agile: Оценка и планирование проектов».

Бывает, что команда не может завершить незаконченную часть User Story в следующем спринте. В этом случае лучше позволить команде получить баллы за завершенную часть истории: на основе новых знаний об объеме и сложности истории мы оцениваем, сколько баллов назначить за завершенную часть, и учитываем эти данные в velocity спринта.

Оставшуюся часть истории мы:
1. Переформулируем с учетом реализованного функционала.
2. Оцениваем на основе полученных в этом спринте знаний.

Суммарная оценка завершенной части истории и оставшейся не обязательно должна быть равна первоначальной оценке, ведь теперь мы знаем об истории больше и можем оценить точнее.

2 хороших способа приоритизации элементов бэклога

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

Первый вы наверняка знаете, но все же напомним;) Это приоритизация по трем категориям, или MoSCoW.

Акроним MoSCoW включает в себя следующую классификацию элементов бэклога:
- Must Have — эпики/ истории/ фичи, которые обязательно должны быть поставлены. Обычно они касаются решения существующщих проблем бизнеса или требований внешних регуляторов.

Например, мы делаем финасовый продукт, и чтобы не получить штраф, должны к 1 декабря поставить протокол безопасности.

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

- Should Have — эпики/ истории/ фичи, имеющие решающее значение для успеха релиза.

Такие элементы бэклога не менее важны, чем элементы категории Must, но могут быть несрочными.

- Could Have — «желательные» эпики/ истории/ фичи: они представляют собой значительную ценность для релиза или продукта в целом, но не являются критичными, как Must и Should.

- Дополнительная категория — Won't Have: эти элементы бэклога хорошо бы реализовать, если останется время, но, скорее всего, часть из них или даже все не войдут в ближайший релиз.

Метод приоритизации MoSCoW не слишком точный, но достаточно интуитивный и подойдет даже начинающим командам.

Более точный, но и сложный метод — Weighted Shortest Job First, основанный на соотношении ценности элемента бэклога для бизнеса к «размеру» работы, которую нужно совершить для поставки этого элемента.

Подробно об этом методе читайте в блоге.

А какими методами приоритизации чаще пользуетесь вы?
Делитесь опытом в комментариях — соберем все методы в отдельный пост: будет полезно для новичков и не только;)

Нужен ли вам аудит команд и чем его заменить

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

Первое, на что стоит ориентироваться — как устроена работа в вашей компании сейчас.

1. У вас есть команды, которые уже работают по Scrum. Задача: найти дисфункции и потенциальные риски, выявить точки роста и составить план по развитию команды.

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

2. У вас пока нет команд, которые используют agile. В этом случае аудит как отдельная активность по сути не требуется, поскольку планируется значительное изменение всех процессов. Нам предстоит постоить работу над проектом или продуктом заново, и эффективнее сосредоточиться именно на этом: на подготовке и обучении людей, на формировании договоренностей с бизнесом.

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

Если у вас много команд, рекомендуем выбрать в качестве пилота 1-2 и запустить сначала их, а через 2-3 месяца масштабировать опыт на остальные команды.

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

—
Если вам нужна консультация по Agile, обучение, помощь с запуском команд или поддержка Agile-трансформации компании, напишите или позвоните нам, будем рады поделиться опытом и помочь.
info@onagile.ru, +7 495 221 87 39

Итак, подарки открыты, все новогодние фильмы посмотрены, а впереди еще несколько дней каникул.

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

Команда OnAgile подготовила для вас небольшой адвент🎁 с рекомендациями, которые помогут подготовиться к первому рабочему дню и начать 2022-й максимально продуктивно.

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

Начинаем!

Мысленная ретроспектива 2021 года

Отвлеченный от рабочих будней контекст долгого праздника — самое время ненадолго вернуться в 2021 год и спросить себя:

🔹 Чем из того, что я (или моя команда) сделали в ушедшем году, мы действительно можем гордиться?
🔹 Какие из проблем, с которыми мы столкнулись, можно было решить гораздо проще и быстрее?
🔹 Что из сделанного оказалось не очень полезным и можно было не тратить свои силы и время на это?

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

Новые идеи по продукту

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

Например, можно протестировать несколько интересных на ваш взгляд гипотез, которые могут дать ценные данные и подтолкнуть к новым идеям.

🔹 Также рекомендуем лишний раз посмотреть продукты/сайты конкурентов: на что они делают упор, что появилось интересного в этих продуктах за последнее время, что конкуренты говорят клиентам о себе и о своем сервисе?

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

Клиенты и конверсия

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

Например:
🔹 Кого из конкретных клиентов (или представителей определённого сегмента) можно было бы кратко проинтервьюировать в первые рабочие дни, чтобы лучше понять, что им сейчас нужно, как они взаимодействуют с нашим продуктом, что у них не совсем получается?
🔹 Как выглядит конверсия на разных этапах пути клиента: какой процент людей возвращается, какой процент делает полезное действие, на каком этапе уходит больше всего клиентов и с чем это может быть связано?
🔹 Какой ещё сегмент клиентов мы могли бы привлечь, чтобы протестировать их интерес к нашему продукту? И как это обернуть в высококонверсионное ценностное предложение?

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

Встреча с командой по ближайшим целям

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

🔹 Что нам предстоит сделать в ближайшие 2-3 месяца? На чем нам следует сфокусироваться? Как мы сможем измерить результат?
🔹 Еще один важный вопрос — что можно улучшить в процессах работы команды. Что мы можем сделать по-другому по сравнению с тем, как работали в прошлом году? Вспомните, как проходили стендапы, планирование и другие командные встречи: были ли они достаточно эффективными? Как можно их улучшить?

Запланируйте встречу на первый или второй рабочий день, пока у всех еще свободны календари. Такая встреча будет полезна и с точки зрения укрепления внутрикомандных связей и поможет быстро настроиться на рабочий ритм.

Друзья, на этом наш адвент подошёл к концу. Напишите в комментариях, понравились ли вам вопросы, возникали ли у вас новые идеи, пока вы читали посты и помогло ли это подготовиться к рабочей неделе.

Желаем вам чудесного, интересного и продуктивного года!

Команда OnAgile

Стартовал новый тренинговый сезон🚀 Так что если вы планируете развить компетенции в сфере Agile, выбирайте программу, которая отвечает вашим интересам, а мы позаботимся о том, чтобы трехдневный интенсив принес вам максимум практических знаний

Ближайшие тренинги

1. Фундаментальный курс по всему, что есть в Agile: Scrum, Kanban, SAFe, LeSS

Cамый широкий по охвату тем тренинг, основной курс по гибким подходам, включающий Scrum, Kanban и обзор фреймворков масштабирования. Идеальная программа для тех, кто присоединился к scrum-команде или планирует перестроить работу своей команды.

Ближайшая группа на следующей неделе, 26 – 28 января. Забронировать участие.
Следующие группы 01-03 марта, 20-22 апреля, 18-20 мая, 20-24 июня

2. Продвинутый курс для Владельцев Продуктов

Углубленный курс по созданию, выводу на рынок и развитию продуктов в быстроменяющейся среде. Включая управление ожиданиями заказчиков, работу в agile-команде, проектирование и развитие продукта на основе глубокого понимания потребностей клиентов.

Ближайшие группы 09 – 11 февраля, 25-27 мая, забронировать участие.

3. Продвинутый курс для Скрам-мастеров
Лучший тренинг по отзывам 2021 года — продвинутый курс для Скрам-мастеров и всех, кому важны развитие команды, эффективное проведение командных встреч, командный коучинг и фасилитация.

Ближайшие группы 23-25 февраля, 27-29 апреля, забронировать участие.

4. Курс по управлению проектами в Agile

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

Ближайшие группы 29 – 31 марта, 28-30 июня забронировать участие.

5. Курс по Agile для сотрудников HR

Специальный курс для HR-специалистов и руководителей HR департаментов — Agile в HR. Ранее доступный только для корпоративных клиентов тренинг теперь проходит в открытом формате. Разберем развитие HR-сервисов, мотивационной стратегии и организационной структуры компании на основе agile-практик, процесс найма и онбординга сотрудников.

Ближайшая группа 06 - 08 июня, забронировать участие.