Agile-коуч: нанимать или нет?

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

Но это гиганты рынка с их ресурсами. А как поступить компании среднего размера или небольшому стартапу?

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

Друзья!

События в мире не смогли обойти и Agile сообщество. Хотя в это трудно поверить.
Один из сертификационных центров, Scrum.org, приостановил работу с Россией по проведению тренингов и выдаче сертификатов.

На сегодняшний день это не затронуло нашу сертификацию от ICAgile.

Все тренинги из нашего расписания актуальны (https://onagile.ru/trainings) и будут проведены в указанные даты.

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

Так же, мы по-прежнему проводим обучение в корпоративном формате, без изменений.

Ждём вас на ближайших тренингах!

Команда OnAgile

Кто еще нужен в SAFe?

Продолжаем серию постов о расширении компании с помощью фрейворка SAFe.

Для организации слаженной работы нескольких команд в SAFe есть специальные люди: Release Train Engineer ("Машинист"), Архитектор решения и Системный архитектор.

Узнать подробнее об этих ролях

Как стать Скрам мастером в 2022 году

Получаем много вопросов о том, как сейчас найти первую работу в роли Скрам мастера: чему учиться? пригодится ли предыдущий опыт? как пройти собеседование?

Собрали ответы на основные вопросы в пост: опытные Scrum-мастера это знают, а новичкам будет полезно.

Чек-лист запуска продукта

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

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

✅ Формирование гипотез. Какими бы логичными ни были наши представления о новом продукте/фиче, они должны быть подкреплены реальными данными: исследованиями по схеме “боль — решения”, результатами проблемного интервью, фреймворком Jobs to be done.

✅ Валидация гипотез. До начала работы над продуктом каждая гипотеза должны быть провалидирована. Важно научиться тестировать гипотезы быстро и дешево, чтобы не застревать на этом этапе и сэкономить ресурсы.
Например, можно тестировать гипотезы с помощью Riskiest Assumption Test. Хорошее описание метода есть у Андрея Торбичева, партнера венчурного фонда «Месторождение» и автора канала «Индекс дятла»: ребята валидируют предположение за 1 неделю, и в рамках спринта успевают проверить 5 гипотез.

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

✅ Ориентируемя на быстрый выпуск MVP (Minimal Viable Product, минимально жизнеспособный продукт), который позволит получить обратную связь от пользователей.

✅ Настраиваем циклы обратной связи: отзывы A/B тестирования, отзывы пользователей MVP, регулярный анализ полученной обратной связи и внесение изменений в продукт на ее основе помогут вовремя сориентироваться, если потребности или поведение пользователей изменится.

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

Как проводить PI планирование

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

Собрали для вас ключевые аспекты, которые помогут провести PI планирование.

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

⚡️"Оценка зрелости Agile-команд" бесплатный вебинар 30 мая

Что дает оценка agile-зрелости? В первую очередь, это простой и эффективный инструмент, который позволяет увидеть слабые места, потенциальные риски и наметить точки роста команды.

▪️На вебинаре мы рассмотрим сразу 3 уровня оценки:

- Team Agility: оценка конкретной Scrum-команды
- Уровень портфеля или стрима создания ценности
- Уровень организации в целом

▪️ Разберем оценку реальных agile-команд на примере нескольких кейсов из нашей практики

▪️Вы научитесь применять матрицу для оценки своих команд и получите необходимые материалы

Ссылка на регистрацию. Участие в вебинаре бесплатное.
30 мая в 19.00 (мск). Длительность около 1 часа.

До встречи на вебинаре!

Как найти точки роста вашей Agile-команды

Сегодня в 19.00 по московскому времени проведем вебинар, посвященный развитию Agile-команды.

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

Чтобы присоединиться к трансляции, переходите по ссылке

Начало: 19.00 (UTC+3 MSK)
Продолжительность: 1-1,5 часа.
Спикер: Артём Гринякин — старший agile-консультант OnAgile Consulting

До встречи онлайн!

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

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

Каждая программа — это три дня глубокого погружения в Agile под руководством экспертов-практиков. С получением международной сертификации.

1. Фундаментальный курс по Agile и Scrum

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

Забронировать участие

Ближайшие группы
21 – 23 сентября
16 – 18 ноября

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

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

Ближайшие группы
19 – 21 октября
14 – 16 декабря
Забронировать участие

3. Продвинутый курс для Скрам-мастеров и руководителей

Более чем на 60% состоящий из практики продвинутый курс для Скрам-мастеров и всех, кому важны развитие команды, эффективное проведение командных встреч, командный коучинг и фасилитация.

Ближайшие группы
28 – 30 сентября
23 – 25 ноября
Забронировать участие

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

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

Ближайшая группа
05 – 07 октября
07 – 09 декабря
Забронировать участие

5. Нужен тренинг для группы коллег?

Адаптируем программу специально для вашей команды и проведем онлайн или очно в Мск/Спб.

Для консультации свяжитесь с нами по тел. +7 495 221 87 39 или на info@onagile.ru

Бывают отзывы, которыми просто невозможно не поделиться:)
Спасибо, Елена, у вас отличная команда, с которой очень приятно работать!

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

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

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

Главный результат тренинга - что уже на следующей неделе после тренинга мы создали рабочую группу и работа по новым правилам началась!»

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

Рекомендую почитать как тем, кто разрабатывает софт, так и тем, кто его заказывает - я думаю каждый сможет провести много параллелей со своим опытом. Дело было в 2017-19 годах, но сути это не меняет 🙂

https://vc.ru/dev/468325-keys-kak-kompaniya-hertz-zaplatila-agentstvu-accenture-32-milliona-dollarov-za-veb-sayt-kotoryy-tak-i-ne-zapustilsya

Оригинал на английском здесь: https://www.henricodolfing.com/2019/10/case-study-hertz-accenture-website.html

Что интересно, такой сценарий просто невозможен в agile подходе, потому что:

• Весь большой продукт обязательно делится на небольшие, логически разделенные части. Поэтому не нужно ждать конца проекта, чтобы выпустить продукт на первых клиентов, это можно было сделать в случае с hertz уже через месяц-два.
• Вся разработка делится на недельные итерации. Поэтому в конце каждой недели можно увидеть небольшой, но реальный прогресс. Например, на тестовом стенде. Таким образом, мгновенно не заметить отсутствие той же адаптивной верстки, как в кейсе Accenture- Hertz, просто невозможно.
• Задачи ставятся и тз пишется не все и сразу, а «в моменте», непосредственно перед началом разработки. Поэтому любые важные изменения требований от заказчика всегда будут учтены.
• И последнее. Никогда, никогда и ещё раз никогда нельзя использовать fixed price модель разработки.

Приведу пример из собственного опыта - меня пригласили в крупный и известный банк, который на тот момент уже 2.5 года, в сотрудничестве с не менее крупной и известной компанией-аутсорсером, разрабатывал новый продукт для юрлиц. И за 2.5 года не было не только работающей версии у клиентов, но и тестовых версий с хотя бы одним работающим сквозным сценарием. Напоминает кейс Accenture-Hertz, верно?

Только в данном случае вовремя осознали, что нужно срочно менять подход к ведению проекта, перешли на Agile и все стало хорошо (но, конечно, не сразу).

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

Конечно, чтобы выпустить успешный продукт мы потратили ещё несколько месяцев. Но уход от Fixed price модели принципиально сделал успех этого проекта возможным. Жаль, что в Hertz не догадались до этого. Ну или не хватило политической воли, чтобы реализовать такой переход.

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

В этом году на тренингах снова часто спрашивают, в чем основное отличие Agile от Lean.

Я обычно объясняю это так.

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

Добавите что-нибудь?

Сила продуктовых команд

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

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

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

Сила продуктовой команды в крутости обсуждаемых гипотез и скорости их проверки.

И чем больше вовлеченных людей будут драйвить этот процесс, тем лучше будут результаты.

Приведу пример вопросов из реальной команды недавно запущенного продукта, которые мы обсуждаем все вместе:

1. Почему у нас только X% клиентов начинают регистрацию?
2. Почему у нас только X1% завершают регистрацию?
3. Почему только Y% зарегистрированных людей делает целевое действие, а Y1% уходит и не возвращается?
4. Почему так мало (до K%) клиентов возвращаются и повторно делают целевое действие?
5. Что не так с СегментомХ клиентов, живущих в СтранеY?

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

Самое частое возражение - «у нас ведь есть продакт и аналитик, это же их работа».

Тем не менее, через несколько недель команду уже, как правило, не узнать.

А у вас был опыт переключения коллег в продуктовое мышление? Как работали с возражениями?

Друзья, привет, обычно мы так не делаем, но 🙂

У вас есть уникальная возможность посетить последний в этом году тренинг "Управление проектами в Agile" с огромной 25% скидкой!

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

13-15 декабря 2022, онлайн

Всего 5 мест с такой скидкой, запишитесь прямо сейчас: https://icagile.ru/agile-project-management.

P.S. Места со скидкой закончились :)

#agile #управлениепроектами #скидка #профессиональноеразвитие

Друзья, привет! Мы решили немного обновить название и концепцию канала в новом году.

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

Итак, встречайте - OnAgile Learning Hub.

Кстати, первый пост у нас вышел почти 5 лет назад, 10 мая 2018 года. Если кто-то из наших дорогих подписчиков помнит то время, напишите в комментариях или поставьте сердечко 🙂

Хочу поделиться очень понятной вводной статьей про работу с графиком распределения Leadtime, надеюсь, вам будет интересно прочитать: https://mauvisoft.com/2020/10/08/how-to-read-lead-time-distribution/

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

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

Достаточно просто выбрать сущность, время работы над которой хотим измерять (например, Эпик или Инициатива), определить первое состояние жизненного цикла, откуда начнем считать время (например, переход в Анализ) и финальное состояние (обычно это переход в Готово).

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

В дополнение к предыдущему посту про LeadTime, небольшая иллюстрация как именно он считается.

Есть два ключевых понятия.

1. Commitment point (точка Взятия обязательств) - когда мы пообещали, что начали работу над конкретной задачей и соответственно время ожидания в глазах наших заказчиков или клиентов начало идти.

2. Delivery point (Точка Поставки) - когда мы отдаем обещаный результат и заказчик/клиент может его принимать.

По каждой сделанной задаче (прошедшей Delivery Point) мы отмечаем дату, когда задача была сделана, вычитаем из нее дату, когда задача была взята в работу (прошла Commitment Point) и получаем время работы над задачей (LeadTime).

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

Источник иллюстрации: https://www.projectwizards.net/en/blog/2019/01/kanban-corepractices