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

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

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

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

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

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

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

Узнать, как проводить стендапы с максимальной пользой, и чтобы никому не было скучно😉: https://onagile.ru/trends/agile/stand-up

Ближайшие тренинги: Agile, Scrum, Kanban

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

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

Присоединяйтесь!  

Разобраться в базовых инструментах Agile, Scrum и Канбан, чтобы начать их применять в своей компании. Тренинг Certified Agile Professional, с получением международного сертификата:
13 – 14 февраля, Москва.
05 – 06 марта, Москва.
19 – 20 марта, Петербург.
23 – 24 апреля, Москва.

Освоить ключевые знания по Канбан-методу и на реальных примерах разобраться, как выстраивать Канбан-систему в различных сферах бизнеса. Kanban Method Professional:
17 – 18 февраля, Москва.

Научиться выстраивать продуктивную командную работу, прокачать навыки фасилитации. Тренинг Advanced Scrum Master & Agile Coach, с получением международного сертификата:
20 – 21 февраля, Москва.
06 – 07 апреля, Москва.

Узнать, как создавать успешные продукты с использованием методик Agile и Lean. Понять, что нужно клиентам, как донести ценность своего продукта и своевременно выпустить его на рынок. Agile Product Management, с получением международного сертификата:
27 – 28 февраля, Москва.
27 – 28 апреля, Москва.

Разобраться в особенностях управления проектами и их эволюционированию в Agile-среде. Agile Project Management, с получением международного сертификата:
02 – 03 марта, Москва.

👨‍🎓Чтобы дать вам максимум полезной информации и на практике отработать ключевые механики, все наши тренинги двухдневные с занятиями с 10 до 18.
Зарегистрироваться или узнать больше: https://onagile.ru/trainings

Новые результаты старыми методами

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

Кто нужен, чтобы начать создавать концептуально новые продукты и услуги: https://onagile.ru/trends/business-agility/digital-people

Друзья, спасибо за участие в опросе!
Делимся нашим опытом — смотрите 6 реальных примеров применения Канбан в российских компаниях: https://onagile.ru/trends/agile/kanban-in-industries

Критерии готовности и почему они необходимы командам

Критерии готовности (Definition of Done) — это договоренности команды, когда считать задачу (или продукт) готовыми.
Они обязательно должны быть сформулированы и приняты командой в самом начале совместной работы. Давайте рассмотрим, почему.

Представьте, что вы едете на встречу и должны быть на ней к 11.00: навигатор показывает время прибытия 10:58 — все отлично. Вот только парковка перед офисом занята. Вы 10 минут ищете, где оставить машину, потом идете к офису, вызываете лифт… а коллеги в это время ждут в переговорке, кофе стынет.

Получается, что хотя вы и подъехали к офису к 11.00 (задачу «подъехать» сделали), но встреча начаться вовремя не может.

Так и в работе над проектами. «Мы действительно сделали задачу?»
Если результат нельзя поставить пользователям или на следующий этап процесса — значит, не сделали. Это принципиально важный момент перехода от мышления задачами к тому, чтобы начать фокусироваться на результатах и повысить продуктивность команды.

После первого вопроса самим себе попробуйте задать еще один: «А что еще осталось сделать, чтобы получить нужный результат, готовый к использованию?».

Почему диаграммы Ганта врут, и как работает прогнозирование в Agile

Важный текст об управлении проектами. Разбираем, что не так с самым распространенным инструментом визуализации планирования, и как Agile-подходы решают задачу делать точные прогнозы:
https://onagile.ru/trends/leadership/gantt-chart

#projectmanagement

Что делать менеджеру в Agile-среде

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

Какие сценарии развития карьеры есть сейчас на рынке, и на что стоит обратить внимание:
https://onagile.ru/trends/leadership/management-in-agile

Scrum vs Kanban

Пару лет назад от основателей Scrum вышла красная книга под названием «Делать вдвое больше работы за половину времени». Они предлагали ускориться в четыре раза, начав применять Scrum.

Дэвид Андерсон, автор Канбан, пошел дальше, и предлагает научный подход, как ускориться в 80 раз, если применять Канбан-метод! :)

От себя могу сказать, что чем более неясная и запутанная ситуация с процессами (например, разработки), тем больше пользы можно получить именно от Канбан-метода. И очень быстро.

С чего начать Agile-инициативу

Нас часто спрашивают: с чего начать внедрение Agile, вернувшись на работу после обучения?

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

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

Классный пример влияния энтузиастов наблюдаем сейчас в одной крупной производственной компании. Провели обучение для 35 человек с 6 фабрик по всей России. И на каждой ребята запустили по скрам-команде! Прошло 2-3 спринта: команды ощущают, что работают с большим фокусом, люди активно друг другу помогают, и результаты появляются быстрее.

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

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

- Еще многие участвуют в митинге с телефона из самых разных мест, где их застала встреча (магазин, машина и тп) - что приводит к минимальной их вовлеченности в формате "меня спросили - я ответил".

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

В вашей команде бывает такое?
Что еще из "гигиенических" факторов онлайн-встреч команды вы бы отметили?

Онлайн-обучение Agile и Scrum — ближайшие курсы на апрель.

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

Здесь пригодятся практики Agile: работа с мотивацией команды, налаживание прозрачного процесса на основе Scrum и Kanban, техники проведения эффективных и коротких встреч онлайн — все, что работает на скорость получения результата.

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

22-24 апреля - основной курс по гибким подходам — фундаментальный Certified Agile Professional — теперь доступен онлайн.
Программа адаптирована на 3 учебных дня по 4 часа. После обучения вы получаете сертификат от консорциума ICAgile.
https://onagile.ru/trainings/certified-agile-professional

20-21 апреля - наш новый курс Scrum Professional — практическое руководство по переходу к Scrum-процессу.
Если вы решили оптимизировать свои процессы с помощью фреймворка Скрам, эти 2 дня по 4 часа помогут детально разобраться с практиками и инструментами подхода.
https://onagile.ru/trainings/scrum-professional

Приходите сами и приглашайте коллег. При регистрации троих человек из одной компании, третий участник — бесплатно!

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

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

Мне очень нравится определение Potentially Shippable Product (PSP) - Продукт, который может быть поставлен. Первый раз я услышал о нем в 2013 году от Алистера Коберна, одного из "отцов" Agile.

Очень хорошо этот термин раскрыт в описании LeSS, рекомендую: https://less.works/less/framework/potentially-shippable-product-increment.html

Potentially shippable is a statement about the quality of the software and not about the value or the marketability of the software.

Друзья, есть 1 бесплатное место для представителя НКО на онлайн-тренинг Scrum Professional 20-21 апреля 🚀

Подробно разберемся, как применять фреймворк, запустить скрам-команду и получить впечатляющие результаты;)

Что еще вас ждет интересного: https://onagile.ru/trainings/scrum-professional
Обучение с 14 до 18 на платформе zoom.us

UPD Место забронировано🙂

Привет! Мы возвращаемся с новой порцией историй о нашем опыте применения Agile в российских компаниях и реалиях.

Все это время мы продолжали лидировать Agile-преобразования у наших клиентов — это 6 компаний в четырех разных отраслях, помогли им запустить 23 новых команды и провели обучение 18 групп по темам, связанным с Agile как культурой работы, особенностям Scrum-подхода, Kanban-методу и разработке продуктов в условиях быстро меняющейся среды.

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

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

Например, работы по отдельной задаче команда оценивает так: аналитику нужно 2 дня, разработчику 6 дней, тестировщику 3 дня. Получаем общую сумму в 11 дней, кладем на календарь, получаем дату окончания работ = день начала + 11 дней.
И примерно в 100% случаев результат по задаче выдается позже озвученной даты и наши заказчики начинают становиться недовольными.

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

Есть два способа улучшить точность оценки, не сделав ее процесс сложнее.

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

То есть процесс оценки в часах обычно выглядит так - "если тебя никто не будет отвлекать, ты сядешь и целиком погрузишься в задачу - сколько часов тебе потребуется, чтобы ее сделать?"

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

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

Например, задача по выпуску виртуальной карты может иметь оценку в 13 поинтов, а задача по отображению ее реквизитов - оценку в 3 поинта.
Что это для нас значит?
Что реквизиты примерно в 4 раза проще выпуска карты и очевидно более определенные с точки зрения требований, зависимостей и возможных рисков.

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

Продолжая тему с оценками, давайте посмотрим, в чем вообще проблема с ними. Почему в общем случае крайне сложно дать точную оценку?

(Применимо к оценке работ так называемого умственного труда, knowledge work).

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

2. Требования, которые у нас есть на старте - не описывают будущий продукт на 100%, какими бы объемными и детальными они ни были. В отличие от, например, изготовления детали по чертежу или строительство дома по готовой проектной документации.

3. И самое главное - проблема в ДНК процесса оценки.
Когда нас просят что-то оценить, нам говорят буквально следующее «На основе информации, которая есть у вас сейчас и вашего опыта, когда, как вам кажется, вы могли бы это сделать?».
Мы говорим (применяя любую методику оценки), например, через 20 дней, или к 17 ноября. И это тот оценочный срок, который нас попросили назвать.

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

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

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

И у меня вопрос - а как вы решаете проблему со сроками в своих командах? Напишите, пожалуйста, в комментариях.